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

ĐẠI HỌC QUỐC GIA TP.HCM
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
KHOA CÔNG NGHỆ PHẦN MỀM
  
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:
1. Vũ Ngọc Hưng MSSV: 06520197
2. Vương Hà Thanh Mẫn MSSV: 06250282
Lời nói đầu
Sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác, làm việc qua mạng
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ộc
số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ác
vấ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ách
hà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ỏi
nhữ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.
Mục lục
1. Tổng quan về SOA 1
1.1. Khái niệm 1
1.2. Các nguyên tắc và tính chất của hệ thống SOA 2
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 18
4.2.3 Chỉnh sửa, xóa một project 19
4.2.4 Thêm, xóa thành viên của một project 19
4.2.5 Liệt kê các project của một thành viên 19
4.2.6 Hiển thị tiến độ của project theo phần trăm (%) 20
4.2.7 Hiển thị các thông tin của project: days left, budget, description 20
4.2.8 Hiển thị calendar kèm theo milestone 20
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 21
4.2.11 Tạo mới một danh sách công việc (tasklist) 21
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 23
4.2.16 Phân công công việc cho một hay nhiều thành viên 23
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) 24
4.2.19 Liệt kê tất cả các thành viên 24
4.2.20 Thêm một thành viên mới vào hệ thống 24
4.2.21 Xóa một thành viên khỏi hệ thống 25
4.3. Yêu cầu phi chức năng 26
4.3.1 Các thành viên có thể cập nhật tiến độ công việc của họ 26
4.3.2 Yêu cầu hiệu quả 26
4.3.3 Bảng trách nhiệm yêu cầu hiệu quả 27
4.3.4 Yêu cầu tiện dụng 28
4.3.5 Bảng trách nhiệm yêu cầu tiện dụng 29
4.3.6 Yêu cầu tương thích 30
4.3.7 Yêu cầu công nghệ 30
4.3.8 Yêu cầu tiến hoá 31

4.3.9 Bảng trách nhiệm yêu cầu tiến hoá 31
4.3.10 Yêu cầu an toàn 32
4.3.11 Bảng trách nhiệm yêu cầu an toàn 32
4.3.12 Yêu cầu bảo mật 33
4.3.13 Bảng yêu cầu trách nhiệm bảo mật 33
4.4. User-case 34
4.4.1 Mục đích 34
4.4.2 Các quy ước 34
4.4.3 Sơ đồ use-case tổng quát 35
4.4.4 Các actor và các use-case của hệ thống 36
4.4.4.1 Danh sách các actor của hệ thống 36
4.4.4.2 Danh sách các use-case 36
4.4.5 Biểu đồ tuần tự (Sequence Diagram) 39
4.5. Sơ đồ lớp 40
4.5.1 Mục đích 40
4.5.2 Sơ đồ các lớp trong EPM (mức phân tích) 40
4.5.2.1 Sơ đồ các lớp chính 40
4.5.2.2 Danh sách các lớp đối tượng và quan hệ 41
4.6. Thiết kế dữ liệu 44
4.6.1 Sơ đồ logic 44
4.6.2 Sơ đồ logic chi tiết: 45
4.7. Thiết kế giao diện 45
4.7.1 Danh sách các màn hình 45
4.8. Mô tả chi tiết các màn hình 47
4.8.1 Màn hình “Desktop” 47
4.8.1.1 Chức năng 47
4.8.1.2 Các thành phần của giao diện 47
4.8.2 Màn hình “Project” 51
4.8.2.1 Chức năng 51
4.8.3 Màn hình “Milestone List” 52

4.8.3.1 Chức năng 52
4.8.4 Màn hình “Milestone Add/Edit” 52
4.8.4.1 Chức năng 52
4.8.5 Màn hình “Task List” 53
4.8.5.1 Chức năng 53
4.8.6 Màn hình “User “ 53
4.8.6.1 Chức năng 54
4.8.7 Liệt kê và thêm user vào project. Màn hình “My Project” 54
4.8.7.1 Chức năng 54
4.8.8 Màn hình “Add Project” 54
4.8.8.1 Chức năng 55
4.8.9 Màn hình “User profile” 55
4.8.9.1 Chức năng 56
4.8.10 Màn hình “Edit user” 57
4.8.10.1 Chức năng 57
4.8.11 Màn hình “My Task” 57
4.8.11.1 Chức năng 58
4.8.12 Màn hình “Add Task List” 58
4.8.12.1 Chức năng 58
4.8.13 Màn hình “Add Task” 59
4.8.13.1 Chức năng 59
4.8.14 Màn hình “User Administration” 60
4.8.14.1 Chức năng 60
4.8.15 Màn hình “Add User” 61
4.8.15.1 Chức năng 61
4.9. EPM Web Service 61
4.10. Xây dựng ứng dụng Client – EPM Agent 63
4.10.1 Gọi EPMService từ client 63
4.10.2 Thiết kế giao diện 64
4.10.2.1 Màn hình Login 64

4.10.2.2 Màn hình chính 64
Lời kết 66
Tài liệu tham khảo 67
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 1
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ần
khá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ống
hoà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 đối
tượ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ống
SOA 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ới
nhau để 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ác
phươ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ủa
SOA 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 chi
tiế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ỹ
thuật bên dưới. Sự trừu tượng là cốt lõi của khái niệm dịch vụ, nó giúp cho các

Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 2
doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng mới và các
thành phần này có thể được chia sẻ hoặc tái sử dụng trong nhiều lĩnh vực khác nhau
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ần
của hệ thống SOA với nhau. Thoạt nhìn SOA và dịch vụ web trông có vẻ giống
nhau 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 đến
SOA.
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 giao
tiế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
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 3
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ủa dị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ể độc
lậ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 duy
trì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục
họ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ên
ngoà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ác
lượ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ông
khai các yêu cầu, chính sách đó.
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 4
1.2.5 Loose coupling
Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module với
nhau.Có 2 loại coupling là rời (loose) và chặt (tight). Các module có tính loose
coupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tight
coupling 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ần
mề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ết

dí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 khi
bê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ên
cung 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ụng
dị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ấp
thô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.
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 5
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ác
dị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àng

hơ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ột
luậ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 cho
mỗ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ăng
tạ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ổ
trợ phải làm việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 6
những policy. Ngược lại, nếu sử dụng policy, những nhân viên phát triển phần mềm
giờ chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hổ
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ôn ngữ 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ăng cộ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ủa dị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ôn ngữ 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ộc vào nền tảng hệ thống. Ví dụ Web Service là một đặc tả
trung gian cho giao tiếp giữa các hệ thống JAX-RPC và JAXM chuyển đối tượng
Java thành SOAP,…
1.2.10Tự độ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êu
chuẩ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ầu
tìm kiếm . Ví dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìm
tấ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ác
entry 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ác
dị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ó
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 7
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
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ực
thi 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ản
hợp đồng được cung cấp bởi registry trung gian. Mối ràng buộc này là ràng buộc
trong 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 tin
cầ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 định
dạ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 đến
khi 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.
• Lợi ích kinh tế:
o Doanh nghiệp có điều kiện tập trung thời gian để tìm kiếm các giải
pháp cho các bài toán liên quan đến kinh tế.
o Thúc đẩy sự phát triển của hệ thống hiện có cũng như cung cấp khả
năng mở rộng hệ thống trong tương lai.
• Lợi ích kỹ thuật:
o Hệ thống xây dựng theo mô hình SOA đảm bảo các service trong hệ
thống có tính độc lập cao (độ kết dính thấp) (autonomous và loose
coupling). Đồng thời có thể tận dụng tối đa các nguồn tài nguyên như
CPU, storage, database… với chi phí hợp lý.
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.
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 8
o Hoạt động của các service có tính linh động cao, hành vi của các
service tùy thời đểm, tùy yêu cầu cần xử lý mà có sự khác nhau (late
binding).
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ụng
phầ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ụ đó.
oOo
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 9
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ìm
kiế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ột
service nào đó sẽ tìm kiếm thông tin trên Service Registry. Ngoài chức năng hỗ trợ
tìm kiếm, Service Registry còn có thể xếp hạng các Service Provider dựa trên các
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 10
tiêu chí về chất lượng dịch vụ, bầu chọn từ các khách hàng đã sử dụng service,
Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer.
Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lập
kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành

thươ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ột
phươ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ài
nguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất. Mỗi một
công ty có một mô hình SOA khác nhau. Nhìn chung mô hình SOA có các đặc điểm
sau:
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 ứng
dụ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
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 11
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ần
mề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ổng
hòa của rất nhiều yếu tố: công nghệ, cơ sở hạ tầng, con người và quy trình
nghiệ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:
Đồ án môn học – Nhóm SOA

Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 12
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ông
nghệ để 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à cung
cấ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ộng tá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:
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 13
• 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 service
trên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù của
platform đó.
• 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ần
dừ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 trung
gian sẽ gởi (forward) thông điệp cho Receiver khi Receiver có thể xử lý yêu
cầ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ận
thê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 and
deserialization các đối tượng dữ liệu truyền qua mạng khi ứng dụng thực
hiệ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 đến
security như authentication and authorization.
oOo
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 14
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ây
dự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àng
kiể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ởi

cá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ên
trong. Ngược lại, nếu xây dựng SOA từ framework có sẵn, chúng ta sẽ có được
nhiề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ình
SOA. 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 Oracle
SOA 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
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 15
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ác
khá 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ần
phả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ụ.
oOo
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 16
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 (EPM) 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 (Project
manager - PM) của các nhóm vừa và nhỏ quản lý hiệu quả hơn nhóm của họ, đồng
thờ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ơn
nhờ 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)
Stt Tên yêu cầu Biểu mẫu Quy định Ghi chú
Tạo dự án (project) mới BM1 QĐ1
Chỉnh sửa thông tin project QĐ2
Xóa 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 %
BM3
Hiển thị các thông tin của BM4
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm

Trang 17
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)
Hiển thị một lịch (calendar)
kèm theo các cột mốc
(milestone)
BM5
Hiển thị danh sách các hoạt
động (activity) của một
project
BM6 QĐ4
Xuất danh sách các hoạt động
ra định dạng PDF hay Excel
Thêm một cột mốc
(milestone) mới
BM7 QĐ5
Chỉnh sửa một milestone QĐ6
Xóa một milestone QĐ6
Đóng một milestone QĐ6
Có thể tạo danh sách các công
việc (tasklist)
BM8 QĐ7
Hiển thị danh sách các tasklist
và các task của chúng
BM9
Chỉnh sửa một tasklist QĐ8
Xóa một tasklist QĐ8

Thêm một task mới BM10 QĐ9
Chỉnh sửa thông tin một task QĐ10
Xóa một task QĐ10
Đóng một task QĐ10
Phân công công việc cho một
hay nhiều thành viên
QĐ11
Gửi một thông báo cho một
project
BM11 QĐ12
Hiển thị các thông báo của
một project
BM12
Chỉnh sửa một thông báo QĐ13
Xóa một thông báo QĐ13
Đồ án môn học – Nhóm SOA
Trường Đại học Công nghệ Thông tin - Khoa Công nghệ Phần mềm
Trang 18
Stt Tên yêu cầu Biểu mẫu Quy định Ghi chú
Trich xuất các thông báo ra
định dạng PDF
Hiển thị các tập tin và thư
mục của một project
BM13
Tạo mới một thư mục BM14 QĐ14
Upload tập tin lên máy chủ BM15 QĐ15
Thêm một thành viên mới vào
project
QĐ16
Xóa một thành viên khỏi một

project
QĐ16
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
thời gian kết thúc
BM17
Có thể chỉnh sửa một dòng
trong bản báo cáo
QĐ17
Xóa một dòng khỏi bản báo
cáo
QĐ17
Trích xuất báo cáo ra định
dạng PDF hoặc Excel
4.2.2 Tạo dự án (project) mới
• Biểu mẫu 1 (BM1):
Đồ án môn học – Nhóm SOA