1. Trang chủ
  2. » Luận Văn - Báo Cáo

Tiểu luận Phát triển phần mềm hướng đối tượng GIỚI THIỆU KIẾN TRÚC HƯỚNG DỊCH VỤ (SOA) VÀ CÁCH THỰC HIỆN

74 790 7

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 74
Dung lượng 3,7 MB

Nội dung

Để thực hiện điều đó SOA định ra một chuẩn giao tiếp dùng để gọi hàm dịch vụ được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng.. Điều này đạt được do tách b

Trang 1

GIỚI THIỆU KIẾN TRÚC HƯỚNG DỊCH VỤ

(SOA)

VÀ CÁCH THỰC HIỆN

BÁO CÁO ĐỒ ÁN MÔN HỌC

Giáo viên hướng dẫn: Ths Tăng Mỹ Thảo

Nhóm:

2 Vương Hà Thanh Mẫn MSSV: 06250282

Trang 2

và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộcsống của chúng ta Điều đó đòi hỏi các ứng dụng không chỉ là những hệ thống hoạtđộng đơn lẻ trên một máy trạm (máy client) và chịu phụ thuộc vào một nền tảng cốđịnh nào nữa, mà chúng phải là những hệ thống linh động giúp người dùng làm việc

“mọi lúc, mọi nơi” Điều đó đã làm nhà phát triển phải đối mặt với hàng loạt cácvấn đề mới như làm sao tích hợp các thành phần phân tán lại với nhau; hay tái sửdụng những thành phần có sẵn; vấn đề triển khai và bảo trì, … đang là một vấn đềlàm điên đầu các nhà phát triển

“Tôi cần một dịch vụ lưu trữ”; “Khách hàng của tôi yêu cầu một dịch vụphân tích và đánh giá chứng khoán” Đó là hai trong số rất nhiều yêu cầu của kháchhàng với các nhà phát triển và các nhà cung cấp Gần như tất cả mọi thứ đang dần

trở thành những dịch vụ, chứ không còn là những thiết bị hay phần mềm cụ thể nữa,

từ những việc cơ bản như lưu trữ dữ liệu, đến xử lý, phân tích và đánh giá,…

Mô hình phần mềm như những dịch vụ đang rất phát triển hiện nay được gọi

là mô hình SOA – (Service Oriented Architecture) hay Kiến trúc Định hướng Dịch vụ Vậy thật sự SOA là gì ? Nó có thật sự hoàn hảo ? Làm thế nào để triển

khai SOA ? Các vấn đề của hệ thống SOA là gì ? Đó cũng chính là những câu hỏi

mà đề tài này sẽ nghiên cứu và trả lời

Trong quá trình tìm hiểu đề tài và biên soạn tài liệu không thể tránh khỏinhững thiếu sót nhất định, rất mong nhận được sự đóng góp ý kiến của quý thầy cô

và các bạn để đề tài thêm hoàn thiện

Tp Hồ Chí Minh, tháng 01, năm 2010

Nhóm SOA

Trang 3

1.2.1 Ranh giới rõ ràng 2

1.2.2 Các dịch vụ tự hoạt động 3

1.2.3 Các dịch vụ chia sẻ lược đồ 3

1.2.4 Tính tương thích của dịch vụ dựa trên chính sách 3

1.2.5 Loose coupling 4

1.2.6 Sử dụng lại dịch vụ 5

1.2.7 Sử dụng dịch vụ bất đồng bộ 5

1.2.8 Quản lý chính sách 5

1.2.9 Khả năng cộng tác 6

1.2.10 Tự động dò tìm và ràng buộc động 6

1.3 Lợi ích của SOA 7

2 Kiến trúc của SOA 9

2.1 Kiến trúc tổng quan của SOA 9

2.2 Kiến trúc chi tiết 10

2.3 SOA và Web service 11

2.4 Mô hình giao tiếp bằng thông điệp (message) trong SOA 12

3 Các phương pháp xây dựng một hệ thống SOA 14

4 Triển khai SOA và Web service trong ứng dụng thực tế 16

4.1 Mô tả bài toán 16

4.2 Yêu cầu chức năng 16

4.2.1 Các yêu cầu về quản lý dự án (project) 16

4.2.2 Tạo dự án (project) mới 19

4.2.3 Chỉnh sửa, xóa một project 20

4.2.4 Thêm, xóa thành viên của một project 20

4.2.5 Liệt kê các project của một thành viên 20

Trang 4

4.2.9 Thêm một cột mốc (milestone) mới 21

4.2.10 Chỉnh sửa, xóa và đóng một milestone 22

4.2.11 Tạo mới một danh sách công việc (tasklist) 22

4.2.12 Hiển thị danh sách các tasklist và các task tương ứng 22

4.2.13 Chỉnh sửa và xóa một tasklist 23

4.2.14 Tạo mới một công việc (task) 23

4.2.15 Chỉnh sửa, xóa và đóng một task 24

4.2.16 Phân công công việc cho một hay nhiều thành viên 24

4.2.17 Thêm và xóa thành viên khỏi một project 24

4.2.18 Các yêu cầu về quản lý thành viên/người sử dụng (user) 25

4.2.19 Liệt kê tất cả các thành viên 25

4.2.20 Thêm một thành viên mới vào hệ thống 25

4.2.21 Xóa một thành viên khỏi hệ thống 26

4.3 Yêu cầu phi chức năng 27

4.3.1 Các thành viên có thể cập nhật tiến độ công việc của họ 27

4.3.2 Yêu cầu hiệu quả 27

4.3.3 Bảng trách nhiệm yêu cầu hiệu quả 28

4.3.4 Yêu cầu tiện dụng 30

4.3.5 Bảng trách nhiệm yêu cầu tiện dụng 31

4.3.6 Yêu cầu tương thích 32

4.3.7 Yêu cầu công nghệ 32

4.3.8 Yêu cầu tiến hoá 33

4.3.9 Bảng trách nhiệm yêu cầu tiến hoá 33

4.3.10 Yêu cầu an toàn 34

4.3.11 Bảng trách nhiệm yêu cầu an toàn 35

Trang 5

4.4.4 Các actor và các use-case của hệ thống 39

4.4.4.1 Danh sách các actor của hệ thống 39

4.4.4.2 Danh sách các use-case 39

4.4.5 Biểu đồ tuần tự (Sequence Diagram) 43

4.5 Sơ đồ lớp 44

4.5.1 Mục đích 44

4.5.2 Sơ đồ các lớp trong EPM (mức phân tích) 44

4.5.2.1 Sơ đồ các lớp chính 44

4.5.2.2 Danh sách các lớp đối tượng và quan hệ 45

4.6 Thiết kế dữ liệu 48

4.6.1 Sơ đồ logic 48

4.6.2 Sơ đồ logic chi tiết: 49

4.7 Thiết kế giao diện 49

4.7.1 Danh sách các màn hình 49

4.8 Mô tả chi tiết các màn hình 51

4.8.1 Màn hình “Desktop” 51

4.8.1.1 Chức năng 51

4.8.1.2 Các thành phần của giao diện 51

4.8.2 Màn hình “Project” 55

4.8.2.1 Chức năng 55

4.8.3 Màn hình “Milestone List” 56

4.8.3.1 Chức năng 56

4.8.4 Màn hình “Milestone Add/Edit” 56

4.8.4.1 Chức năng 56

Trang 6

4.8.6.1 Chức năng 58

4.8.7 Liệt kê và thêm user vào project Màn hình “My Project” 58

4.8.7.1 Chức năng 58

4.8.8 Màn hình “Add Project” 58

4.8.8.1 Chức năng 59

4.8.9 Màn hình “User profile” 59

4.8.9.1 Chức năng 60

4.8.10 Màn hình “Edit user” 61

4.8.10.1 Chức năng 61

4.8.11 Màn hình “My Task” 61

4.8.11.1 Chức năng 62

4.8.12 Màn hình “Add Task List” 62

4.8.12.1 Chức năng 62

4.8.13 Màn hình “Add Task” 63

4.8.13.1 Chức năng 63

4.8.14 Màn hình “User Administration” 64

4.8.14.1 Chức năng 64

4.8.15 Màn hình “Add User” 65

4.8.15.1 Chức năng 65

4.9 EPM Web Service 65

4.10 Xây dựng ứng dụng Client – EPM Agent 67

4.10.1 Gọi EPMService từ client 67

4.10.2 Thiết kế giao diện 68

4.10.2.1 Màn hình Login 68

4.10.2.2 Màn hình chính 68

Trang 8

1. Tổng quan về SOA

1.1 Khái niệm

SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là

một cách tiếp cận hay một phương pháp luận để thiết kế và tích hợp các thành phầnkhác nhau, bao gồm các phần mềm và các chức năng riêng lẻ lại thành một hệ thốnghoàn chỉnh Kiến trúc SOA rất giống như cấu trúc của các phần mềm hướng đốitượng gồm nhiều module Tuy nhiên khái niệm module trong SOA không đơn thuần

là một gói phần mềm, hay một bộ thư viện nào đó Thay vào đó, mỗi module trong

một ứng dụng SOA là một dịch vụ được cung cấp rải rác ở nhiều nơi khác nhau và

có thể truy cập thông qua môi trường mạng Nói một cách ngắn gọn, một hệ thốngSOA là một tập hợp nhiều dịch vụ được cung cấp trên mạng, được tích hợp lại vớinhau để cùng cộng tác thực hiện các tác vụ nào đấy theo yêu cầu của người dùng

Một trong những cách hiểu sai lầm nhất về SOA là coi SOA là một công nghệ Mặc dù SOA hoạt động được là nhờ công nghệ, nhưng khách hàng cần phải

chuyển đổi từ chỗ chỉ việc tích hợp công nghệ SOA sang việc phải điều chỉnh cácphương pháp thực hiện dự án, chính sách bảo trì và thay đổi để đạt được các lợi ích

về khả năng trưởng thành và đáp ứng

Dịch vụ là yếu tố then chốt trong SOA Có thể hiểu dịch vụ như là một loại

module thực hiện một quy trình nghiệp vụ nào đó Một trong những mục đích củaSOA là giúp các ứng dụng có thể 'nói chuyện' với nhau mà không cần biết các chitiết kỹ thuật bên trong Để thực hiện điều đó SOA định ra một chuẩn giao tiếp (dùng

để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và

có thể tái sử dụng Như vậy, SOA là cấp độ cao hơn của phát triển ứng dụng, chútrọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ

Trang 9

của công ty đó mà không cần phải chỉnh sửa mã nguồn hay phải tái cấu trúc lại hệthống.

Có nhiều cách khác nhau để kết nối các dịch vụ, chẳng hạn dùng các giao

thức mạng có sẵn, hoặc tạo một giao thức riêng Nhưng từ năm 2001, các dịch vụ web (Web service) được xây dựng dựa trên nền tảng web toàn cầu, bất cứ nơi nào

cũng có, đã trở thành một phương pháp phổ biến cho việc kết nối các thành phầncủa hệ thống SOA với nhau Thoạt nhìn SOA và dịch vụ web trông có vẻ giốngnhau nhưng chúng không phải là một Chúng ta sẽ tìm hiểu rõ hơn về các dịch vụweb trong các phần tiếp theo

Hình 1.1 – Mô hình cơ bản của SOA.

1.2 Các nguyên tắc và tính chất của hệ thống SOA

Những phần sau sẽ giới thiệu những nguyên tắc cơ bản của một dịch vụhướng Kiến Trúc (SOA).Những nguyên tắc không không chính xác tuyệt đối,nhưng được dùng như một khung tham khảo cho các cuộc thảo luận liên quan đếnSOA

1.2.1 Ranh giới rõ ràng

Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giaotiếp Thành phần giao tiếp này sẽ quy định những dạng thông điệp sử dụng trong

Trang 10

quá trình trao đổi : thông điệp nào sẽ được chấp nhận và những thông điệp nào sẽkhông được xử lý Và đây chính là cách duy nhất để các đối tượng bên ngoài có thểtruy cập thông tin và chức năng của dịch vụ Ta chỉ cần gửi thông điệp theo cácđịnh dạng đã được định nghĩa trước mà không cần quan tâm đến cách xử lý củadịch vụ như thế nào Điều này đạt được do tách biệt giữa thành phần giao tiếp vàthành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ.

1.2.2 Các dịch vụ tự hoạt động

Các dịch vụ cần phải được triển khai và họat động như những thực thể độclập mà không lệ thuộc vào các dịch vụ khác Dịch vụ phải có tính bền vững cao,nghĩa là nó sẽ không bị sụp đổ khi có sự cố Để thực hiện điều này , dịch vụ cần duytrì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tụchọat động trong trường hợp một dịch vụ bị hỏng, và để tránh các cuộc tấn công từbên ngoài (như gửi thông điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các

kỹ thuật về an toàn, bảo mật …

1.2.3 Các dịch vụ chia sẻ lược đồ

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bênngoài, và hổ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua cáclược đồ dữ liệu (chema) chuẩn (độc lập ngôn ngữ , đa nền) Như thế hệ thống của ta

sẽ có tính lên kết và khả năng dễ mở rộng

1.2.4 Tính tương thích của dịch vụ dựa trên chính sách

Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thìphải thỏa mãn các chính sách (policy) và yêu cầu (requirement) của dịch vụ đó như

là mã hóa, bảo mật… Để thực hiện điều này, mỗi dịch vụ cần pahỉ cung cấp côngkhai các yêu cầu, chính sách đó

Trang 11

Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module vớinhau.Có 2 loại coupling là rời (loose) và chặt (tight) Các module có tính loosecoupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tightcoupling lại có nhiều ràng buộc không thể biết trước Hầu như mọi kiến trúc phầnmềm đều hướng đến tính loose coupling giữa các module Mức độ kết dính của mỗi

hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó Kếtdính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía

sử dụng dịch vụ mỗi khi có thay đổi nào đó xảy ra Mức độ coupling tăng dần khibên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm đinhj của bên cung cấp.Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bêncung cấp dịch vụ thì quan hệ giữa hai bên càng chặt Ngược lại, nếu bên sử dụngdịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước khi triệu gọi nó thìquan hệ giữa hai bên cáng có tính loose coupling

SOA hỗ trợ loose coupling thông qua việc sử dụng hợp đồng và liên kết(contract and binding) Một người sử dụng truy vấn đến nơi lưu trữ và cung cấpthông tin dịch vụ (registry) để lấy thông tin về loại dịch vụ cần sử dụng Registry sẽtrả về tất cả những dịch vụ thỏa tiêu chuẩn tìm kiếm Từ bấy giờ người dùng chỉviệc chọn dịch vụ mà mình cần, và thực thi phương thức trên đó theo mô tả dịch vụnhận được từ registry Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào càiđặt của dịch vụ mà chỉ dựa trên hợp đồng mà dịch vụ hỗ trợ

Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệthống đầu cuối Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng hiệu suất, khảnăng mở rộng và khả năng đáp ứng cao Những thay đổi cài đặt cũng được che giấu

đi Loose coupling đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nóđòi hỏi các interface phải theo chuẩn và cần một thành phần trung gian quản lý,trung chuyển yêu cầu giữa các hệ thống đầu cuối

Trang 12

1.2.6 Sử dụng lại dịch vụ

Bởi vì các dịch vụ được cung cấp lên mạng và được đăng ký ở một nơi nhấtđịnh nên chúng dễ dàng được tìm thấy và tái sử dụng Nếu dịch vụ không có khảnăng tái sử dụng, nó cũng khồn cần đến interface mô tả Các dịch vụ có thể được tái

sử dụng bằng cách kết hợp lại với nhiều mục đích khác nhau Tái sử dụng lại cácdịch vụ còn giúp loại bỏ những thành phần trùng lắp và tăng độ vững chắc trong càiđặt, nó còn giúp đơn giản hóa việc quản trị.Thực ra tái sử dụng dịch vụ lại dễ dànghơn tái sử dụng thành tố hay lớp Những dịch vụ được dùng chung bởi tất cả cácứng dụng của hệ thống SOA gọi là những shared infrastructure service

1.2.7 Sử dụng dịch vụ bất đồng bộ

Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi một thông điệp vớiđầy đủ thông tin ngữ cảnh tới bên nhận Bên nhận xử lý thông tin và trả kết quả vềthông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệpđược xử lý xong Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch

vụ chuyển thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lývới tốc độ tối ưu Do bên gọi không phải chờ đợi cho đến khi yêu cầu được xử lýxong và trả về nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch

vụ bất đồng bộ Trên lý thuyết một hệ thống SOA có thể hổ trợ gửi và nhận cảthông điệp đồngbộ và bất đồng bộ

1.2.8 Quản lý chính sách

Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có mộtluật kết hợp riêng gọi là các policy Các policy cần được quản lý các áp dụng chomỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi Việc này tăng khả năngtạo ra các dịch vụ có đặc tính tái sử dụng Bởi vì các policy được thiết kế tách biệt,

và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm Nếu không sửdụng các policy, các nhân viên phát triển phần mềm, nhóm điều hành và nhóm hổ

Trang 13

trợ vào các luật kết hợp.

1.2.9 Khả năng cộng tác

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác (Interoperability),khả năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và các ngônngữ khác nhau Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua

một dạng kết nối Một kết nối được gọi là interoperable chứa bên trong nó một giao

thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu Khả năngcộng tác đạt được bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn củadịch vụ và các client Kỹ thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngônngữ qua một đặc tả trung gian Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữađịnh dạng của dữ liệu khả kết gian Đặc tả trung gian sẽ chịu trách nhiệm ánh xạgiữa định dạng của dữ liệu khả kết (interoperable) đến định dang dữ liệu tùy thuộcvào nền tảng hệ thống Ví dụ Web Service là một đặc tả trung gian cho giao tiếpgiữa các hệ thống JAX-RPC và JAXM chuyển đối tượng Java thành SOAP,…

1.2.10 Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery) Một người sửdụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêuchuẩn khi cần Người sử dụng chỉ cần hỏi một registry về dịch vụ nào thỏa yêu cầutìm kiếm Ví dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìmtất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng Registry trả về một tấp cácentry thỏa yêu cầu Các entry chứa thông tin về dịch vụ, bao gồm cả phí giao dịch.Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách cácdịch vụ trả về, kết nối đến nhà cung cấp dịch vụ đó dựa trên thông tin registry entry

để sử dụng dịch vụ kiểm tra thẻ tín dụng.Trong phần mô tả dịch vụ kèm theo đã cótất cả các tham số cần thiết dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng

Trang 14

dữ liệu yêu cầu đúng theo mô tả cung cấp và gửi đi.Nhà cung cấp dịch vụ sẽ thựcthi kiểm tra thẻ tín dụng và trả về một thông điệp có định dạng đúng như trong phần

mô tả dịch vụ Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bảnhợp đồng được cung cấp bởi registry trung gian Mối ràng buộc này là ràng buộctrong thời gian chạy chứ không phải ràng buộc trong lúc biên dịch Tất cả thông tincần thiết về dịch vụ được lấy về và sử dụng trong khi chạy

Ví dụ trên cho thấy cách bên sử dụng triệu gọi dịch vụ một cách “động” Đây là một thế mạnh của SOA Với SOA, bên sử dụng dịch vụ không cần biết địnhdạng của thông điệp yêu cầu và thông điệp trả về, cũng như địa chỉ dịch vụ cho đếnkhi cần

1.3 Lợi ích của SOA

Sử dụng mô hình SOA trong việc thiết kế hệ thống mang lại nhiều lợi ích vềmặt kinh tế và kỹ thuật

o Ở góc nhìn người sử dụng, vị trí các service có tính trong suốt(transparency), việc di dời các service đến một máy tính khác khôngảnh hưởng khả năng phục vụ yêu cầu khách hàng

Trang 15

o Tái sử dụng phần mềm Nếu gói mã mà tạo thành một dịch vụ có quy

mô và kích thước phù hợp sau đó nó có thể được tái sử dụng cho lần

kế tiếp Một đội phát triển cần chức năng cụ thể đó cho một ứng dụngphần mềm mới mà nó mong muốn xây dựng, họ không cần biết bất cứthứ gì về việc mã được gói chặt như thế nào hay nó có nguồn gốc từđâu Tất cả những thứ mà họ cần làm đó là xây dựng một sự kết nốiđến dịch vụ đó

Trang 16

-oOo -2. Kiến trúc của SOA

2.1 Kiến trúc tổng quan của SOA

Hình 2.1 – Kiến trúc tổng quan của SOA.

Service Provider: Cung cấp các dịch vụ phục vụ cho một nhu cầu nào đó.

User (người sử dụng hay một ứng dụng sử dụng service) không cần quan tâmđến vị trí thực sự mà service họ cần sử dụng đang hoạt động

Serive Consumer: User sử dụng dịch vụ được cung cấp bởi Service

Provider

Service Registry: Nơi lưu trữ thông tin về các service của các Service

Provider khác nhau, Service Consumer dựa trên những thông tin này để tìmkiếm và lựa chọn Service Provider phù hợp

Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp(các chức năng có thể cung cấp, khả năng của hệ thống (resource, performance), giá

cả dịch vụ, ) vào Service Registry Service Consumer khi có nhu cầu về mộtservice nào đó sẽ tìm kiếm thông tin trên Service Registry Ngoài chức năng hỗ trợ

Trang 17

Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lậpkênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hànhthương lượng thêm (về mặt giá cả, resource sử dụng, ).

2.2 Kiến trúc chi tiết

Hiện nay chưa có một mô hình chính thức nào của SOA Thật sự SOA là mộtphương pháp luận giúp chúng ta tận dụng sức mạnh của các nguồn lực, nguồn tàinguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất Mỗi mộtcông ty có một mô hình SOA khác nhau Nhìn chung mô hình SOA có các đặc điểmsau:

Hình 2.2 – Kiến trúc phân tầng chi tiết của SOA.

Tầng Connectivity: đây là tầng thấp nhất của SOA, có nhiệm vụ giao tiếp

trực tiếp với các thành phần khác như cơ sở dữ liệu, giao tiếp với các ứngdụng khác, các web service,… Vì vậy có thể coi đây là tầng vật lý của SOA

Tầng Orchestration: là các dịch vụ xử lý các quy trình nghiệp vụ và dộc lập

với tầng vật lý phía bên dưới

Tầng Composite Application: là các ứng dụng tổng hợp nhằm mục đích

trình diễn (presentation) và hiển thị thông tin cho người dùng cũng như cung

Trang 18

cấp một giao diện cho người dùng tương tác với hệ thống như là một phầnmềm duy nhất Tầng này có thể là các website, portal, các ứng dụng client

mở rộng (rich client), các thiết bị di động thông minh (smart device),…

Các thành phần khác: gồm có quy trình phát triển (development), quản lý

các dịch vụ (service management), và quản lý con người (governance) Nhưvậy có thể thấy SOA không chỉ đơn thuần là về mặt công nghệ mà nó là tổnghòa của rất nhiều yếu tố: công nghệ, cơ sở hạ tầng, con người và quy trìnhnghiệp vụ

Hình 2.3 – Mô hình triển khai SOA trong thực tế.

2.3 SOA và Web service

Chúng ta có thể thấy mô hình trên của SOA rất giống với của mô hình Web service:

Trang 19

Hình 2.4 – Mô hình cơ bản của Web Service.

SOA và Web service là hai khái niệm tách biệt nhau SOA chỉ đặc tả một môhình phát triển các ứng dụng dựa trên dịch vụ, Còn Web service tập trung vào côngnghệ để thực hiện điều đó dựa trên nền tảng Web Nói ngắn gọn, Web service làmột mô hình cụ thể hóa của SOA Web service được sử dụng phần lớn trong cácứng dụng SOA Chúng ta cần chú ý là khái niệm “service” của SOA không chỉ làWeb service mà nó bao hàm cả các dịch vụ khác mà chúng ta có thể tìm thấy và sửdụng chúng trong một mạng máy tính

2.4 Mô hình giao tiếp bằng thông điệp (message) trong SOA

So với kiểu thiết kế Component-Based, điểm khác biệt chính của SOA là cungcấp khả năng giao tiếp giữa các thành phần trong hệ thống (service) sử dụng thôngđiệp (message) dựa trên các chuẩn giao tiếp đã được chuẩn hóa (HTTP, FTP,SMTP, ) Chính nhờ đặc điểm này, hệ thống SOA trở nên độc lập với platform(platform independent) Các service hoạt động trên nền các platform khác nhau vẫn

có thể giao tiếp với nhau nhờ vào các interface giao tiếp đã được chuẩn hóa để cộngtác xử lý một tác vụ nào đó

Sử dụng thông điệp (message) để giao tiếp có các lợi thế sau:

Trang 20

Cross-platform: thông điệp (message) trở thành ngôn ngữ chung của các

platform và các ngôn ngữ lập trình khác nhau Điều này đảm bảo các servicetrên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù củaplatform đó

Asynchronous communications: hoạt động gởi nhận thông điệp được thực

hiện theo cơ chế Fire-and-Forget Sender và Receiver không cần phải chờthông điệp trả lời sau khi đã gởi đi một thông điệp Điều này giúp cho Sender

và Receiver tiếp tục xử lý công việc sau khi gởi thông điệp mà không cầndừng thực thi để chờ thông điệp trả lời

Reliable communication: các thông điệp từ Sender có thể được gởi đến một

service trung gian có nhiệm vụ lưu trữ (store) các thông điệp Service trunggian sẽ gởi (forward) thông điệp cho Receiver khi Receiver có thể xử lý yêucầu tiếp theo Cơ chế Store-and-Forward này đảm bảo các thông điệp sẽkhông bị thất lạc trong trường hợp Receiver bị quá tải và không thể nhậnthêm yêu cầu mới

Thread management: Việc trao đổi thông điệp theo cơ chế bất đồng bộ giúp

ứng dụng không cần ngừng thực thi để chờ một tác vụ kết thúc mà có thể tạo

ra các thread xử lý các công việc khác nhau

Remote communication: Các thông điệp lưu trữ thông tin về các đối tượng

dữ liệu dưới dạng đặc tả hình thức thay thế việc phải serialization anddeserialization các đối tượng dữ liệu truyền qua mạng khi ứng dụng thựchiện remote call một ứng dụng khác

End-to-end security: Thông điệp có thể lưu trữ thông tin về security context

của kênh giao tiếp Điều này cung cấp khả năng điều khiển liên quan đếnsecurity như authentication and authorization

Trang 21

-oOo -3. Các phương pháp xây dựng một hệ thống SOA

Nhìn chung có hai phương pháp chính để xây dựng một hệ thống SOA Cáchđầu tiên là tự tay xây dựng từ đầu hệ thống theo mô hình SOA Cách thứ hai là xâydựng SOA dựa vào một bộ thư viện hay một framework có sẵn Mỗi cách đều cóđiểm hay và dở riêng Nếu chúng ta tự tay xây dựng ngay từ đầu thì có thể dễ dàngkiểm soát và tối ưu nó, tuy nhiên chúng ta sẽ phải tốn rất nhiều thời gian, nhân lực

và tiền bạc thì may ra mới có thể xây dựng được một hệ thống SOA hoàn chỉnh, bởicác hệ thống SOA thoạt nhìn bên ngoài rất đơn giản nhưng lại rất phức tạp ở bêntrong Ngược lại, nếu xây dựng SOA từ framework có sẵn, chúng ta sẽ có đượcnhiều cái lợi như: thời gian phát triển và triển khai nhanh, được hỗ trợ tốt hơn Bùlại chúng ta sẽ không thể tự do chỉnh sửa và thay đổi theo ý muốn

IBM là công ty đi tiên phong trong việc nghiên cứu và ứng dụng mô hìnhSOA Vì vậy cũng dễ hiểu mô hình xây dựng SOA của IBM là thông dụng nhất.Bên cạnh đó còn có mô hinh SOA của Oracle, SUN và Microsoft

Danh sách một số mô hình SOA phổ biến:

 Xây dựng SOA theo mô hình của IBM với sự hỗ trợ của công cụ Rational

 Xây dựng SOA theo mô hình của Oracle bằng bộ phần mềm lớp giữa OracleSOA Suite

 Mô hình SOA của Microsoft dựa vào công vụ Web Matrix

 Mô hình SOA của SUN được tích hợp vào IDE NetBeans

Do phạm vi của bài viết này là tìm hiểu tổng quát về SOA nên chúng ta sẽkhông đi sâu vào chi tiết các mô hình này Nhìn chung các công ty này đều tuân

Trang 22

theo đặc tả của SOA và họ đều cung cấp cho người sử dụng một công cụ tương táckhá trực quan để thiết kế các xử lý business giữa các dịch vụ và gần như không cầnphải viết dòng mã nào.

Hinh 3.2 - Thiết kế mô hình BPEL trong NetBeans IDE.

Các mô hình này được xây dựng dựa trên ngôn ngữ BPEL (Business Process Execution Language), đây là một ngôn ngữ định dạng kế thừa từ XML

dùng để đặc tả các quy trình nghiệp vụ

Trang 23

-oOo -4. Triển khai SOA và Web service trong ứng dụng thực tế

4.1 Mô tả bài toán

Easy Project Management ( E PM ) là một phần mềm hỗ trợ quản lý dự án.

Hệ thống EPM cung cấp một công cụ hỗ trợ đắc lực cho các quản trị viên (Projectmanager - PM) của các nhóm vừa và nhỏ quản lý hiệu quả hơn nhóm của họ, đồngthời giúp cho toàn bộ các thành viên làm quen với quy trình làm việc nhóm

Với EPM, quy trình làm việc của nhóm sẽ trở nên nhịp nhàng và hiệu quả hơnnhờ các chức năng như phân công nhiệm vụ, quản lý thời gian, tạo các milestone(cột mốc), theo dõi và báo cáo kết quả công việc, cùng nhiều chức năng khác Nhờ

đó mức độ rủi ro của dự án sẽ được giảm thiểu và mức độ thành công sẽ cao hơn

4.2 Yêu cầu chức năng

4.2.1 Các yêu cầu về quản lý dự án (project)

Tạo dự án (project) mới BM1 QĐ1

Chỉnh sửa thông tin project QĐ2

Đóng một project khi hoàn

thành

QĐ2

Thêm thành viên cho project QĐ3

Xóa thành viên trong project QĐ3

Liêt kê tất cả project của một

thành viên

BM2

Hiển thị tiến độ (status) của

các project theo phần trăm %

BM3Hiển thị các thông tin của BM4

Trang 24

Stt Tên yêu cầu Biểu mẫu Quy định Ghi chú

project như như bao nhiêu

ngày nữa đền deadline (days

left); ngân sách (budget);

miêu tả sơ lược (description)

Chỉnh sửa thông tin một task QĐ10

Phân công công việc cho một

hay nhiều thành viên

Trang 25

định dạng PDF

Hiển thị các tập tin và thư

mục của một project

BM13

Upload tập tin lên máy chủ BM15 QĐ15

Thêm một thành viên mới vào

Time tracker: báo cáo thời

gian của các hoạt động trong

project

BM16

Có thể tra cứu các hoạt động

theo thời gian bắt đầu hoặc

Trang 26

 Quy định 1 (QĐ1):

o Tên dự án không được là một chuỗi rỗng;

o Deadline phải lớn hơn ngày hiện tại;

o Một project phải có ít nhất một thành viên

4.2.3 Chỉnh sửa, xóa một project

Trang 27

4.2.6 Hiển thị tiến độ của project theo phần trăm (%)

Trang 28

(Những ngày có đánh dấu là các milestone).

4.2.9 Thêm một cột mốc (milestone) mới

 BM7:

 QĐ5:

o Tên của milestone không được rỗng;

o Deadline phải lớn hơn ngày hiện tại và không được vượt quá deadline của project;

o Chỉ có admin mới có quyền tạo mới một milestone

4.2.10 Chỉnh sửa, xóa và đóng một milestone

 QĐ6:

o Chỉ có admin mới có quyền chỉnh sửa, xóa và đóng một milestone

4.2.11 Tạo mới một danh sách công việc (tasklist)

 BM8:

Trang 29

 QĐ7:

o Tên của tasklist không được rỗng

o Chỉ admin mới có quyền tạo tasklist

4.2.12 Hiển thị danh sách các tasklist và các task tương

ứng

 BM9:

Trang 30

4.2.13 Chỉnh sửa và xóa một tasklist

 QĐ8:

o Chỉ có admin mới có quyền chỉnh sửa và xóa tasklist

4.2.14 Tạo mới một công việc (task)

 BM10:

 QĐ9:

o Tên của công việc không được rỗng;

o Deadline phải lớn hơn ngày hiện tại;

o Công việc phải được giao cho ít nhất một người hay một nhóm người;

o Chỉ có admin mới có quyền tạo mới một task

4.2.15 Chỉnh sửa, xóa và đóng một task

 QĐ10:

o Chỉ có admin mới có quyền chỉnh sửa, xóa và đóng một task

Trang 31

4.2.17 Thêm và xóa thành viên khỏi một project

 QĐ16:

o Chỉ có admin mới có quyền thêm và xóa thành viên khỏi một project

4.2.18 Các yêu cầu về quản lý thành viên/người sử dụng

(user)

Liệt kê tất cả các thành viên

Trang 32

 QĐ18:

o Tên của user không được rỗng và dài không quá 256 ký tự;

o Email không được rỗng và phải hợp lệ;

o Password không được rỗng và dài ít nhất 6 ký tự;

o Cần phải chọn quyền (role) khi tạo một thành viên mới;

o Chỉ có admin mới có quyền tạo mới một thành viên

4.2.21 Xóa một thành viên khỏi hệ thống

 QĐ19:

o Chỉ có admin mới có quyền xóa một thành viên khỏi hệ thống

Trang 33

4.3.1 Các thành viên có thể cập nhật tiến độ công việc của

họ

Các thành viên có thể theo dõi các công việc được giao mà không cần phải vào trựctiếp trang web quản lý dự án của nhóm Việc cập nhật được xác nhận bởi thành viên

có đủ quyền như PM hay team leader

4.3.2 Yêu cầu hiệu quả

Máy tính: CPU core 2 quad Q8400-2.66Ghz, ram 2x2GB bus 1066

lưu trữ

Ghi chú

6 Milestone Tạo milestone Ngay tức thì

Trang 34

Stt Nghiệp vụ Tốc độ xử lý Dung lượng

lưu trữ

Ghi chú

15 Messaging Tạo message Ngay tức thì

18 File manager Quản lý file Tuỳ tốc độ

internet

19 Calendaring Quản lý thời gian Ngay tức thì

20 Time tracking Theo dõi tiến độ Ngay tức thì

21 Permission Phân quyền Ngay tức thì

25 FileSharing Chia sẻ tập tin

4.3.3 Bảng trách nhiệm yêu cầu hiệu quả

Trang 35

14 Chỉnh sửa trạng thái task

Thực hiện đúngyêu cầu

Thực hiện đúngyêu cầu

24 Message

Board

Bảng thông báo Người

dùng cungcấp thông tin

Thực hiện đúngyêu cầu

25 File Sharing Chia sẻ tập tin Người

dùng cungcấp tập tin

Thực hiện đúngyêu cầu

4.3.4 Yêu cầu tiện dụng

Trang 36

5 Quản lý tập tin 10 phút hướng dẫn Trực quan

6 Quản lý thời gian 10 phút hướng dẫn Trực quan, dễ

xem

7 Theo dõi tiến độ 5 phút hướng dẫn Trực quan

8 Phân quyền 15 phút hướng dẫn Tỷ lệ phạm lỗi

không quá 5%

dẫn

Không cần biết nhiều về dự án

10 Gửi email thông báo 1 phút hướng dẫn Dễ sử dụng

11 Bảng thông báo Không cần hướng

dẫn

Dễ hiểu, dễ xem

12 Chia sẽ tập tin 5 phút hướng dẫn

4.3.5 Bảng trách nhiệm yêu cầu tiện dụng

1 Quản lý dự án Đọc tài liệu hướng

dẫn

Thực hiện đúng yêu cầu

2 Quản lý milestone Đọc tài liệu hướng

dẫn

Thực hiện đúng yêu cầu

3 Quản lý tasks list Đọc tài liệu hướng

dẫn

Thực hiện đúng yêu cầu

yêu cầu

Trang 37

4.3.6 Yêu cầu tương thích

St

t

1 Xuất thông tin Ra tập tin PDF

2 Xuất thông tin RSS Xuất tin nhắn, thông báo ra

định dạng RSS

4.3.7 Yêu cầu công nghệ

St

t

hưởng đến chức năng khác

2 Dễ bảo trì Thêm chức năng mới tương

đối nhanh

Không ảnh hưởng đến chức

Ngày đăng: 09/04/2015, 09:53

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w