ĐẠI HỌC THÁI NGUYÊN

KHOA CÔNG NGHỆ THÔNG TIN

--------------------

ĐỀ TÀI NGHIÊN CỨU KHOA HỌC

CẤP SINH VIÊN 2010

Đề tài:

KIẾN TRÚC HƯỚNG DỊCH VỤ & ỨNG DỤNG

(SERVICE-ORIENTED-ARCHITECTURE)

Mã số đề tài : S2010-08-21
Chủ nhiệm đề tài : Nguyễn Thị Dung
Cố vấn khoa học : Th.s. Nguyễn Hồng Tân

Thái Nguyên 12/2010

i
 MỤC LỤC
MỞ ĐẦU...........................................................................................................................1
CHƯƠNG 1:
TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED-
ARCHITECTURE).........................................................................................................2
1.1. Kiến trúc phần mềm hiện nay................................................................2
1.1.1. Một số kiến trúc phần mềm phân tán hiện nay...................................2
1.1.2. Vấn đề phát sinh, nguyên nhân và giải pháp......................................3
1.2. Kiến trúc hướng dịch vụ - SOA.............................................................5
1.2.1. Khái niệm............................................................................................5
1.2.2. Nguyên lý SOA...................................................................................7
1.2.3. Tính chất của SOA..............................................................................8
1.2.4. Lợi ích của SOA...............................................................................10
1.2.5. Ưu nhược điểm của SOA..................................................................11
CHƯƠNG 2:
PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA............................................................12
2.1. Mô hình hoạt động và kiến trúc chi tiết của hệ thống..........................12
2.1.1. Mô hình tổng thể của SOA...............................................................12
2.1.2. Mô hình giao tiếp bằng thông điệp (message) trong SOA...............13
2.1.3. Kiến trúc phân tầng chi tiết...............................................................14
2.2. SOA và ứng dụng Web Service...........................................................16
2.2.1. Giới thiệu về Web service.................................................................16
2.2.2. SOA và Web service trong vấn đề tích hợp hệ thống.......................16
2.2.3. Cấu trúc và chi tiết các thành phần của Web service........................18
2.3. Qui trình xây dựng hệ thống SOA.......................................................26
2.3.1. Thách thức khi xây dựng hệ thống...................................................26
2.3.2. Vòng đời của hệ thống......................................................................28
....................................................................................................................29
2.3.3. Các pha cơ bản xây dựng hệ thống SOA..........................................30
2.3.4. Các chiến lược xây dựng hệ thống....................................................31
CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN...............................................................36
3.1. Chương trình demo..............................................................................36
3.1.1. Chức năng chính của chương trình:..................................................36
3.1.2. Xây dựng chương trình.....................................................................36
.........................................................................................................................................41

ii
 3.2. Đánh giá chương trình.........................................................................41
KẾT LUẬN....................................................................................................................42
TÀI LIỆU THAM KHẢO.............................................................................................43
CHỮ KÝ XÁC NHẬN..................................................................................................45

iii
 MỞ ĐẦ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.
Tuy nhiên, một thực tế hiện nay là phần mềm đang ngày càng trở nên
phức tạp quá mức và dường như đang vượt khỏi khả năng kiểm soát của các mô
hình phát triển hiện có. Nguyên nhân khiến cho hệ thống có độ phức tạp tăng cao
là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất,
trong khi nhu cầu trao đổi, chia sẻ, tương tác giữa các hệ thống ngày càng tăng và
không thể đáp ứng được trong môi trường như vậy. Cùng với đó là vấn đề lập
trình dư thừa và không thể tái sử dụng gây tốn kém rất nhiều không những trong
giai đoạn phát triển hệ thống mà trong cả vận hành bảo trì phần mềm. Giải pháp
cho các vấn đề này là gì?
“SOA” hay “Kiến trúc Hướng dịch vụ” là mô hình phần mềm không phải
là mới, song đang rất phát triển hiện nay. Đây cũng được coi là giải pháp ưu việt
cho các vấn đề đã đề cập ở trên. Kiến trúc này được phát triển từ đầu những năm
2000 đi đầu là IBM. Hiện nay SOA đang được ứng dụng rộng rãi với sự đầu tư
nghiên cứu của rất các tập đoàn lớn như IBM, Oracle, SAP, Microsoft…
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 sẽ nghiên cứu và trả lời.

Thái Nguyên, năm 2010

Nguyễn Thị Dung

1
 CHƯƠNG 1:
TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ
(SERVICE-ORIENTED-ARCHITECTURE)
1.1. Kiến trúc phần mềm hiện nay
1.1.1. Một số kiến trúc phần mềm phân tán hiện nay
Một số mô hình kiến trúc phân tán đang sử dụng phổ biến nhất hiện nay
là: CORBA, RMI, DCOM, và EJB. Các kiến trúc này là sự mở rộng của các hệ
thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng.
Đối tượng có thể có không gian địa chỉ bên ngoài ứng dụng, hoặc ở một máy
khác so với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một
phần của ứng dụng.
RMI (Remote Method Invocation):
RMI là một phần của bộ J2SDK (Java 2 Platform Standard Development
Kit) của Sun và là các hàm thư viện hỗ trợ cho các lời triệu gọi phương thức từ
xa và trả về giá trị cho các ứng dụng tính toán phân tán. RMI cho phép chạy các
đối tượng trên môi trường JVM (Java Virtual Machine) triệu gọi với đối trượng
chạy trên nền JVM khác thông qua việc sử dụng giao diện chung của các phương
thức trên client và server. RMI cung cấp cho việc trao đổi truyền thông giữa các
chương trình được viết bằng ngôn ngữ lập trình Java.
Ưu điểm của kiến trúc đối tượng phân tán RMI là người lập trình chỉ cần
lập trình các lời gọi phương thức vì đối tượng được gọi đã hiện diện trong máy
ảo của nó. Nhưng nhược điểm là RMI chỉ thích hợp cho các ứng dụng viết trên
ngôn ngữ Java.
CORBA (Common Object Request Broker Architecture)
Là một chuẩn công nghiệp được đưa ra bởi OMG (Object Management
Group), cho phép gọi các phương thức từ xa và nhận kết quả trả về, nhưng không
giống như RMI, nó có thể được sử dụng khi bên phía gọi và bên phía phương
thức được gọi có thể sử dụng ngôn ngữ lập trình khác nhau, bao gồm cả trường
hợp cả 2 bên không sử dụng ngôn ngữ Java.
CORBA được định nghĩa từ 2 thứ:

2
 • Thực thể mà cho phép liên lạc giữa 2 tiến trình được gọi là 1 mô
giới yêu cầu đối tượng (Object Request Broker - ORB).
• Một giao thức được ORB dùng để liên lạc giữa nhiều tiến trình,
được gọi là IIOP (Internet Interoperability Protocol).
Ưu điểm của CORBA: các lập trình viên có thể tùy chọn ngôn ngữ lập
trình, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn
thỏa mãn các tính chất của CORBA. Tuy nhiên CORBA có nhược điểm là nó là
ngôn ngữ lập trình cấp thấp, rất phức tạp, khó học và cần một đội ngũ phát triển
có kinh nghiệm. Ngoài ra các đối tượng CORBA khó tái sử dụng. Các ứng dụng
dựa trên CORBA hiện nay đang dần đi vào thoái trào.
DCOM (Distributed Component Object Model)
DCOM là công nghệ độc quyền của Microsoft, nó định nghĩa các thành
phần của phần mềm được phân tán qua các mạng máy tính để truyền thông với
các thành phần khác. DCOM hỗ trợ kết nối giữa các đối tượng và kết nối này có
thể được thay đổi lúc đang chạy. Các đối tượng DCOM được triển khai bên trong
các gói nhị phân chứa mã lệnh quản lý vòng đời của đối tượng và việc đăng ký
đối tượng.

Hình 1.1: Mô hình tương tác của các đối tượng DCOM.
DCOM mang đến nhiều ưu điểm như: dễ triển khai, chi phí thấp, tính ổn
định, không phụ thuộc vào địa lý, quản lý kết nối hiệu quả và dễ mở rộng. Tuy
nhiên, các công nghệ của Microsoft có một nhược điểm lớn là bị giới hạn trên hệ
nền Windows do chiến lược độc quyền của Microsoft.
1.1.2. Vấn đề phát sinh, nguyên nhân và giải pháp
Hiện nay áp lực đặt lên các doanh nghiệp ngày càng lớn như: giảm chi phí
đầu tư cơ sở hạ tầng, khai thác có hiệu quả các công nghệ có sẵn, phục vụ yêu
cầu khách hàng tốt hơn, đáp ứng tốt các thay đổi thường xuyên về nghiệp vụ, khả
năng tích hợp cao với các hệ thống bên ngoài…

3
 Xây dựng được hệ thống đáp ứng được tất cả các nhu cầu đó quả là vấn đề
vô cùng khó khăn. Bởi vậy một hướng đi mới cho các doanh nghiệp chính là tìm
kiếm các giải pháp tích hợp các ứng dụng có sẵn hoặc kết hợp với ứng dụng của
các doanh nghiệp khác sao cho thỏa mãn nhu cầu.
Trong quá trình kết hợp chắc chắn sẽ gặp những khó khăn:
- Không đủ khả năng quản lý quy trình nghiệp vụ
- Tốn chi phí tích hợp
- Quá nhiều định dạng dữ liệu
- Nhu cầu và yêu cầu của khách hàng thường xuyên thay đổi nhanh
chóng nhằm tạo ra tính cạnh tranh liên tục.
- Vấn đề an ninh bảo mật.
Đa phần những khó khăn trên là bắt nguồn từ các nguyên nhân sau:
- Phức tạp: Ngày nay mỗi doanh nghiệp công nghệ thông tin có nhiều
những hệ thống trên các nền tảng khác nhau, và hoạt động nghiệp vụ
khác nhau. Các công ty phát triển phần mềm phải thuê các nhóm nhân
viên giàu kinh nghiệm, có khả năng trên các lĩnh vực khác nhau để
phát triển, triển khai và quản lý các ứng dụng và hệ thống mà bản thân
chúng không đồng nhất. Thêm đó là việc nâng cấp khó khăn, tích hợp
cùng với nhau, và bảo mật ngày càng cao đã làm gia tăng tính phức tạp
cho hệ thống.
- Không linh hoạt: Cùng với sự phức tạp trong chiến lược phát triển,
cũng như cơ sở hạ tầng của các công ty. Hầu như công ty nào cũng có
những ứng dụng có sẵn nhưng khó nâng cấp, khó kết hợp hoạt động,
mà không thể thay thế được. Vấn đề tích hợp trở nên khó khăn hơn và
tốn kém hơn.
- Không bền vững: Tiếp đó là sự không bên vững của hệ thống. Các
phương pháp tiếp cận truyền thống trong việc xây dựng các hệ thống
phần mềm thương dẫn đến rất nhiều những giải pháp khác nhau được
lắp ghép, tích hợp. Kết quả mỗi khi thay đổi về quy trình nghiệp vụ
hay yêu cầu thì các công ty phải chấp nhận phát triển những dự án tốn
kém hoặc thay thế các công nghệ không phù hợp.

4
 Chính vì vậy mà các doanh nghiệp cần phải có một hướng tiếp cận mới để
giải quyết vấn đề môi trường không đồng nhất và tốc độ chóng mặt của sự thay
đổi công nghệ trong khi nguồn ngân sách bị hạn hẹp. May mắn thay, vẫn còn có
một giải pháp để giải quyết khá toàn diện về mọi mặt khó khăn này và nó đã
được triển triển khai trong thực tế. “Kiến trúc hướng dịch vụ” (Service Oriented
Architecture - SOA) là cách tiếp cận để xây dựng hệ thống công nghệ thông tin
cho phép các doanh nghiệp tận dụng những gì đang có và dễ dàng thay đổi theo
yêu cầu để hỗ trợ cho doanh nghiệp.
SOA được xem như là bước phát triển tiếp theo của nghành công nghệ
phần mềm.

1.2. Kiến trúc hướng dịch vụ - SOA

1.2.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 với 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
đó theo yêu cầu của khác hà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ụ (service) 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ể “giao tiếp” được 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

5
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 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.
Tóm lại, một dịch vụ có các đặc điểm sau:

 Có ranh giới rõ ràng (Boundaries Are Explicit): Mỗi service

được xây dựng dựa trên các giao chuẩn hóa đã được sử dụng rộng rãi. Chi
tiết hiện thực của mỗi service sẽ không được thể hiện ra bên ngoài. Mỗi
service chỉ công bố một số các giao của nó cho người sử dụng có thể dùng
để gởi các yêu cầu và nhận kết quả trả về.

 Tính tự trị (Autonomous): Về mặt lý thuyết, mỗi service có tính

độc lập cao, có thể được xây dựng và đưa vào sử dụng mà không phụ
thuộc vào các service khác.

 Share the Schema and Contract, Not the Class: Về mặt trao đổi
dữ liệu, các service không truyền các class và type. Thay vào đó, các class
và type sẽ được đặc tả hình thức (data được đặc tả trong schema, behavior
được đặc tả thành các contract).

 Service Compatibility Is Based on Policy: Sự tương thích giữa

các service được căn cứ vào các policy (chính sách). Tương thích về mặt
cấu trúc dựa trên các đặc tả hình thức bao gồm contract (dựa trên Web
Service Description Language (WSDL) hoặc Business Process Execution
Language for Web Services (BPEL4WS)) và schema (XSD). Sự tương
thích dựa trên policy cung cấp khả năng phân tích cũng như đảm bảo sự
tương thích giữa các service.
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à Web Service trông có vẻ

6
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
Web Service trong các phần tiếp theo.

Hình 1.2: Mô hình cơ bản của SOA.

1.2.2. Nguyên lý SOA
SOA tìm cách giải quyết một số vấn đề theo cách nhìn lấy ứng dụng làm
trung tâm. Có thể tóm gọn những phát biểu đó theo các nguyên lý như sau:
- Ứng dụng phải mở ra khả năng cho phép các ứng dụng mới hoặc ứng
dụng đang tồn tại có thể sử dụng được. Nó cũng phải có khả năng kết nối
tới các dịch vụ được đưa ra bởi các ứng dụng khác để tạo thành các dịch
vụ cao cấp hơn hay còn gọi là ứng dụng tổ hợp.
- Sự khác biệt về công nghệ không thành vấn đề và khả năng tương tác trở
thành mục tiêu then chốt.
- Các chuẩn mở phải được thông qua để cho phép tích hợp giữa các doanh
nghiệp. Phối hợp tiến trình nghiệp vụ giữa nhiều nhà cung cấp, nhiều đối
tác thậm chí có thể với cả khách hàng.
- Phải chú ý tới việc quản lý và và đảm bảo khả năng có thể quản trị của hệ
thống để đảm bảo tính linh hoạt do ba nguyên tắc đầu tiên không bị xáo
trộn và xung đột với nhau.
Nói cách khác, SOA nhấn mạnh việc hạ thấp các rào cản truyền thống tới
khả năng tái sử dụng của ứng dụng. Tôn trọng nguyên tắc thiết kế này của SOA
sẽ giải quyết được bài toán lớn về vấn đề tích hợp cũng như bảo trì hệ thống phần
mềm đang là thách thức đối với các nhà phát triển công nghệ thông tin trong giai
đoạn hiện nay.
Dựa trên nguyên lý, hệ thống SOA có những tính chất cơ bản. Để có thể
xem xét hoạt động và xây dựng được hệ thống thì việc hiểu rõ tính chất của hệ
thống đóng vai trò rất quan trọng.

7
1.2.3. Tính chất của SOA
1.2.3.1. Kết nối lỏng lẻo
Vấn đề kết nối nói tới một số ràng buộc giữa các module lại với nhau. Có
2 loại kết nối là lỏng lẻo và chặt chẽ. Các module có tính chất kết nối lỏng lẻo có
một số ràng buộc được mô tả rõ ràng trong khi các module có tính kết nối chặt 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 kết nối lỏng lẻo giữa các module. Mức độ kết nối của hệ thống
ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống. Kết nối càng chặt bao
nhiêu thì có nhiều thay đổi chỉnh sửa khi có sự thay đổi nào đó xảy ra. Mức độ
kết nối tăng dần khi bên sử dụng dịch vụ cần biết nhiều thông tin ngầm định của
bên cung cấp dịch vụ để sử dụng dịch vụ được 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ệ sẽ càng trở nên chặt chẽ. 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 2
bên càng có tính lỏng lẻo.
Kết nối lỏng lẻo làm cho sự phụ thuộc ở mức tối thiểu. Khi đó, những sự
thay đổi sẽ có ảnh hưởng ít nhất tới hệ thống và hệ thống vẫn có thể hoạt động
khi có thành phần nào đó bị hư hỏng. Tối thiểu hóa sự phụ thuộc giúp hệ thống
linh hoạt, và ít xảy ra sự cố.
Tính kết nối lỏng lẻo 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 năng xuấ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 dấu đi. Tính chất kết nối lỏng lẻo đ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 giao diện 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.
1.2.3.2. Tái sử dụng dịch vụ
Bởi vì các dịch vụ được cung cấp trên môi trường mạng và được đăng ký
ở một nơi nhất định nên chúng dễ ràng được tìm thấy và sử dụng lại. Nếu một
dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến giao diện mô tả.
Các dịch vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theo 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 tốc độ 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ố

8
hay lớp. Những dịch vụ được dùng chung bởi tất cả các ứng dụng của một hệ
thống SOA gọi là những dịch vụ chia sẻ cơ sở hạ tầng.
1.2.3.3. Quản lý chính sách
Tập các chính sách là tập tất cả các qui tắc chung mà mọi thành phần
trong hệ thống đều phải tuân thủ. 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 chính sách. Các chính
sách cần được quản lý và áp dụng cho mỗi dịch vụ cả trong quá trình thiết kế và
trong thời gian triển khai.
Việc đó làm 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 chính sách đượ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 chính sách, thì 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 những chính sách. Ngược
lại, nếu sử dụng các chính sách, những nhân viên phát triển phần mềm 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ợ tập
trung vào các luật kết hợp.
1.2.3.4. Tự động dò tìm và ràng buộc động
SOA hỗ trợ khái niệm khai thác 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ề một 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ản, khách hàng 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 danh mục thỏa mãn yêu cầu. Các mục đó chứa thông tin về dịch vụ,
bao gồm cả chi 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 địa chỉ registry đã cung cấp để 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 dữ liệu yêu cầu đúng theo mô
tả 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. 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ậy với

9
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.2.3.5. Khả năng tự hồi phục
Với kích cỡ và độ phức tạp của những hệ thống phân tán ngày nay, khả
năng phục hồi của một hệ thống sau khi bị sự cố là một yếu tố rất quan trọng.
Một hệ thống tự phục hồi là hệ thống có khả năng tự phục hồi sau khi lỗi mà
không cần sự can thiệp của con người.
Độ tin cậy là mức độ đo khả năng của một hệ thống xử lý tốt như thế nào
trong tình trạng hỗn loạn. Trong SOA, các dịch vụ luôn có thể hoạt động hay
ngừng hoạt động bất cứ lúc nào, nhất là đối với những áp dụng tổng hợp từ nhiều
dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy phụ thuộc vào khả năng phục
hồi của phần cứng sau khi bị lỗi. Hạ tầng mạng phải cho phép các kết nối động từ
nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một khía cạnh khác ảnh
hưởng đến độ tin cậy là kiến trúc mà dựa trên đó những ứng dụng được xây
dựng. Một kiến trúc hỗ trợ kết nối và thực thi động sẽ có khả năng tự phục hồi
hơn một hệ thống không hỗ trợ những tính năng trên.
Ngoài ra, những hệ thống dựa trên dịch vụ yêu cầu tách biệt giữa giao
diện và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một giao diện.
Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có
thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì. Khả năng này
chỉ có được khi client tương tác với giao diện của dịch vụ chứ không tương tác
trực tiếp cài đặt của dịch vụ. Đây là một trong những tính chất cơ bản của hệ
thống hướng dịch vụ (SOA).
1.2.4. 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 rất nhiều lợi
ích về cả mặt kinh tế và kỹ thuật.
Về mặt kinh tế:
- 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ế.
- Thúc đẩy khả năng phát triển của hệ thống hiện có cũng như khả năng
mở rộng của hệ thống trong tương lai.
Lợi ích về mặt kỹ thuật:

10
 - Độc lập hệ thống : những service không phụ thuộc vào hệ thống và
mạng cụ thể.
- Có khả năng tái sử dụng.
- Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay
đổi về yêu cầu giao dịch.
- Cho phép dễ dàng triển khai chương trình, môi trường chạy và quản lý
service dễ dàng hơn.
- Những sự xác nhận và chứng minh của Service consumer về những tính
năng security dựa trên giao tiếp Service tốt hơn cơ chế kết nối chặt
chẽ.
1.2.5. Ưu nhược điểm của SOA
SOA có thể được coi là một kiến trúc ưu việt trong thiết kế và xây dựng
hệ thống phần mềm cho doanh nghiệp bởi:
- Hệ thống uyển chuyển và lâu dài thuận tiện cho việc chỉnh sửa, nâng cấp
hoặc mở rộng hệ thống.
- Dễ dàng và nhanh chóng tạo ra các tiến trình nghiệp vụ từ các service đã
có.
- Khả năng tương tác của các service.
Tuy nhiên, bên cạnh những ưu điểm SOA vẫn tồn tại một số yếu điểm như sau:
- Hệ thống phức tạp.
- Khó miêu tả dữ liệu không cấu trúc trong header của message.
- Đặc biệt, khi xây dựng ứng dụng tổng hợp từ nhiều dịch vụ với tính tái sử
dụng cao thì vấn đề bảo mật như: xác thực, phân quyền, bí mật và toàn
vẹn dữ liệu, bảo vệ quyền riêng tư… trở thành một bài toán hết sức phức
tạp và đòi hỏi giải quyết bằng những hướng tiếp cận bảo mật hoàn toàn
mới so với các phương pháp bảo mật truyền thống.

Trên đây là những trình bày tổng quan và đặc trưng nhất của SOA. Vậy
SOA hoạt động như thế nào? Bằng cách nào để triển khai nguyên lý SOA vào hệ
thống phần mềm thực tế và qui trình xây dựng hệ thống ra sao? Phần tiếp theo sẽ
đi sâu hơn về SOA và trả lời các câu hỏi đó.

11
 CHƯƠNG 2:
PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA
2.1. Mô hình hoạt động và kiến trúc chi tiết của hệ thống
2.1.1. Mô hình tổng thể của SOA

Hình 2.1: Mô hình tổng quan của SOA

- Service Provider: Cung cấp các service phục vụ cho một nhu cầu nào đó.
User (service consumer) 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. Họ chỉ cần quan tâm dịch vụ đó là gì.
- Serive Consumer: khách hàng dịch vụ hay những user sử dụng service
đượ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 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...).

12
2.1.2. 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 (hướng thành phần), đ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 sử dụng thông điệp (message) dựa trên các giao thức đã đượ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 nền (platform independent). Các service hoạt động trê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 đó.

Hình 2.2: Message được truyền nhận giữa các dịch vụ

Sử dụng thông điệp (message) để giao tiếp có các lợi thế sau:
• Độc lập nền: 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 đó.
• Giao tiếp bất đồng bộ: Người gửi và người nhận 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 người gửi
và người nhận 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.
• Giao tiếp tin cậy: các thông điệp từ bên gửi 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ẽ chuyển tiếp (forward) thông điệp cho bên nhận khi bên nhận 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.
• Quản lý luồng: 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 luồng (thread) xử lý các công việc khác nhau.

13
 • Giao tiếp từ xa: 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 gọi từ xa một ứng
dụng khác.
• Bảo mật end-to-end: Thông điệp có thể lưu trữ thông tin về hình thức
bảo mật 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
bảo mật như xác thực và phân quyền.
2.1.3. Kiến trúc phân tầng 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.3: Kiến trúc 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à độc
lập với tầng vật lý phía bên dưới. Tầng orchestration chứa các thành phần đóng
vai trò vừa là dịch vụ sử dụng vừa là những dịch vụ cung cấp. Những dịch vụ này
sử dụng những dịch vụ của tầng kết nối và các dịch vụ orchestration khác để kết
hợp những chức năng cấp thấp hơn thành những dịch vụ hoạt động ở cấp cao
hơn, có hành vi gần với những chức năng nghiệp vụ hơn.
- 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ư

14
 cung 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.4: Các thành phần tham gia triển khai hệ thống SOA
Vậy khi nào sử dụng SOA? Đó là khi thiết kế hệ thống đặt ra một câu hỏi
lớn là việc cân nhắc giữa khả năng sử dụng lại và hiệu năng của hệ thống. Nếu hệ
thống cần việc chạy nhanh cho một ứng dụng đặc biệt thì RMI, CORBA, DCOM
là sự lựa chọn. Nhưng hệ thống khó có thể thay đổi hoặc sử dụng lại. Nếu hệ
thống dự định thay đổi thường xuyên mà không yêu cầu quá cao về tốc độ thì
SOA là phương cách tiếp cận tốt nhất. Nó dễ dàng sử dụng lại trong tương lai và
cho phép các ứng dụng tương tự được thiết kế một cách nhanh chóng.
SOA là tư duy hệ thống ưu việt cho giai đoạn công nghệ hiện nay. Vậy
làm cách nào để triển khai tư duy đó vào các ứng dụng thực tế? Đó là vấn đề về
công nghệ. Phần tiếp theo sẽ trình bày một công nghệ có thể nói là thể hiện tốt
nhất cho SOA hiện nay – Web Service.

15
2.2. SOA và ứng dụng Web Service
2.2.1. Giới thiệu về Web service
Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện
dịch vụ. Điều này cho phép chúng ta liên tưởng đến một công nghệ được đề cập
nhiều hiện nay: Web Service. Web Service cho phép truy cập thông qua định
nghĩa giao thức-và-giao tiếp.
Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp
và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực
giao tiếp và phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý
kiến trúc này. Thực ra, tên gọi “kiến trúc định hướng giao tiếp” thích hợp hơn
cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao
tiếp, thường theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ một
chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một
phần mềm khác. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối
tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ.
Web service là một công nghệ triệu gọi từ xa có tính khả chuyển cao nhất
hiện nay: mang tính độc lập nền, độc lập ngôn ngữ. Với web service, các chương
trình viết bằng các ngôn ngữ lập trình khác nhau, chạy trên các nền tảng (phần
cứng & OS) khác nhau đều có thể trao đổi với nhau thông qua công nghệ này.
Tầng transport của Web Service thường dùng những công nghệ truyền tải phổ
dụng nhất như HTTP, SMPT... (tuy hiện nay thường chỉ dùng HTTP) nên khả
năng phân tán trên diện rộng như Internet là rất thuận tiện. Mà SOA là kiến trúc
kết nối lỏng lẻo các service và các service đó tương tác với nhau thông qua Web
service. Do đó, kiến trúc SOA sử dụng Web service như là một giải pháp chính
để giải quyết vấn đề tích hợp nghiệp vụ giữa các hệ thống. Và đặc biêt trong quá
trình internet hóa mọi dịch vụ hiên nay, thì triển khai dịch vụ bằng Web service
có thể nói là điều “tất nhiên”.
2.2.2. SOA và Web service trong vấn đề tích hợp hệ thống
Web services là những thành phần ứng dụng, giao tiếp bằng cách sử dụng
giao thức mở chứa đựng và mô tả chính nó, có thể được phát hiện bằng cách sử
dụng UDDI và có thể được sử dụng bởi ứng dụng khác khác nhau. Web service
hoạt động dựa trên nền tảng là XML và HTTP. Trong đó: XML cung cấp một
ngôn ngữ mà có thể được sử dụng giữa các nền tảng và ngôn ngữ lập trình khác

16
nhau và vẫn thể hiện thông điệp và chức năng phức tạp; Các giao thức HTTP là
giao thức Internet được sử dụng nhiều nhất.
Web Service với mô hình hoạt động 3 bên tương ứng với mô hình hoạt
động của SOA, sử dụng một bộ các chuẩn công nghệ. Đó là:
- XML: Chuẩn định dạng dữ liệu và thông điệp.
- SOAP: Giao thức dựa trên XML và HTTP cho phép giao tiếp trên môi
trường mạng.
- WSDL: Ngôn ngữ mô tả Web Service theo chuẩn.
- UDDI: Một bộ khung chuẩn cho phép mô hình hóa và cụ thể hóa các Web
Service đã được đăng ký.

Hình 2.5: Mô hình hoạt động của web service

Hoạt động của mô hình Web Service như sau:

- Service Provider: Dùng Web Services Description Language (WSDL) để
mô tả dịch vụ mà mình có thể cung cấp và xuất bản (đăng ký) với Service
Broker (tương tự với Service Registry trong SOA).
- Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các
Service Provider. Cung cấp chức năng tìm kiếm hỗ trợ Service Requester
(Service Consumer trong SOA) trong việc xác định Service Provider phù
hợp. Thành phần chính của Service Broker là các kho lưu trữ được mô tả
bởi Universal Discovery, Description, and Integration (UDDI).

17
 - Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng (loại service,
thời gian sử dụng, resource cần thiết, mức giá ...) và gởi cho Service
Broker. Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service
Broker, Service Requester có thể tìm thấy Service Provider thích hợp.
Ngay sau đó, giữa Service Requester và Service Provider thiết lập kênh
giao tiếp sử dụng SOAP để thương lượng giá cả và các yếu tố khác trong
việc sử dụng service.
Như vậy, sử dụng Web Service cho việc tích hợp SOA giúp ứng dụng đạt được
những mục tiêu theo nguyên lý SOA:
- Thông qua các chuẩn công nghiệp. Các chuẩn này gồm Web Service với
các định nghĩa thành phần chuẩn công nghiệp cho XML.
- Sử dụng được những phần mềm thương mại đã xây dựng sẵn nhiều nhất
có thể. Phần mềm phải cung cấp các kênh giao tiếp (adapter) cho Web
service.
- Đóng gói các ứng dụng cho phép kế thừa với giao diện đúng theo chuẩn
công nghệ chung. Các Web Service đều phải được sử dụng thông qua giao
diện này.
- Sử dụng dữ liệu và tầng dữ liệu độc lập nằm giữa các ứng dụng để ẩn đi
cấu trúc dữ liệu bên dưới. Mọi tương tác với dữ liệu đều phải thông qua
Web Service.
Làm thế nào Web Service có thể đạt được những mục tiêu trên? Chúng ta
sẽ đi vào xem xét chi tiết các công nghệ và kỹ thuật thực hiện của Web Service.
2.2.3. Cấu trúc và chi tiết các thành phần của Web service

Nền tảng của các dich vụ web gồm các yếu tố: XML (eXtensible Markup
Language), SOAP (Simple Object Access Protocol), UDDI (Universal
Description, Discovery and Integration), WSDL (Web Services Description
Language).

18
 Hình 2.6: Các thành phần của Web service
2.2.3.1. XML - eXtensible Markup Language
XML là một chuẩn mở do W3C đưa ra và được phát triển từ SGML. XML
là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa, nó
được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những
tài liệu B2B.

Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML,
nhưng không tuân theo một đặc tả quy ước như HTML, người sử dụng hay các
chương trình có thể quy ước định dạng các tag XML để giao tiếp với nhau. Trong
khi HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định
nghĩa những thành phần đó chứa cái gì. Với XML, các thẻ có thể được lập trình
viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi
tính phổ biến và hiệu quả mã nguồn mở.

Do Web Service là sự kết hợp của nhiều thành phần khác nhau nên nó sử
dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp. Vì vậy XML
là công cụ chính để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây
dựng một Web Service, tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML.
Khi đó, các thông tin mã hóa sẽ hoàn toàn phù hợp với các thông tin theo chuẩn
của SOAP hoặc XML-RPC và có thể tương tác với nhau trong một thể thống
nhất.

Ví dụ về tài liệu XML:

<?xml version="1.0" encoding = “UTF-8” ?>

19
 <DOCUMENT>
<GREETING>
Xin Chào XML
</GREETING>
<MESSAGE>
Đây là chương trình XML đầu tiên
</MESSAGE>
</DOCUMENT>
Tài liệu XML chỉ chứa dữ liệu, không nhắc đến cách trình bày. Điều này
có ý nghĩa đó là một XML parser, không cần phải hiểu ý nghĩa của các thẻ. Nó
chỉ cần tìm các thẻ và xác định đây là một tài liệu XML hợp lệ vì trình duyệt
không cần phải hiểu ý nghĩa của các thẻ, nên người dùng có thể tạo ra các thẻ bất
kì để sử dụng.

2.2.3.2. SOAP (Simple Object Access Protocol)

Là một giao thức dựa trên XML để cho phép các ứng dụng trao đổi thông
tin qua HTTP, được thiết kế đơn giản và dễ mở rộng. Đơn giản, SOAP là một
giao thức để truy cập một Web Service, một giao thức truyền thông hay một định
dạng để gửi tin nhắn. Tất cả các thông điệp SOAP đều được mã hóa sử dụng
XML, cho nên không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công
nghệ nào. Vì những đặc trưng này, nó không quan tâm đến công nghệ gì được sử
dụng để thực hiện miễn là người dùng sử dụng các message theo định dạng
XML. Tương tự, service có thể được thực hiện trong bất kỳ ngôn ngữ nào, miễn
là nó có thể xử lý được những message theo định dạng XML.

Hình 2.7: Mô hình gửi nhận thông điệp qua SOAP

Bộ khung của một thông điệp SOAP bao gồm:
- Protocol Header: Cho biết thông tin về các chuẩn giao thức được sử dụng.

20
- SOAP Envelop: Phần chính của thông điệp. Thông tin chính của message
bao gồm:
• SOAP Header: Chứa các SOAP header.

• SOAP body: Thông tin về name và data được đặc tả dưới dạng
XML. Ngoài ra còn có trường lỗi được dùng để gởi các web service
exception.

Hình 2.8: Cấu trúc của một SOAP message

Ví dụ:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-
envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...

21
 </soap:Fault>
</soap:Body>
</soap:Envelope>
2.2.3.3. WSDL (Web Service Discription Language)
WSDL là một ngôn ngữ dựa trên XML dùng để mô tả giao diện của Web
Service. Nó cung cấp một cách thức chuẩn để mô tả các kiểu dữ liệu được truyền
trong các thông điệp thông qua Web Service, các hoạt động được thực hiện trên
các thông điệp và ánh xạ các hoạt động này đến giao thức vận chuyển.

• WSDL dựa trên XML.

• WSDL được dùng để mô tả các Web Service .
• WSDL được dùng để xác định vị trí Web Service.
• WSDL là một chuẩn của W3C.

WSDL định nghĩa cách mô tả Web Service theo cú pháp tổng quát của
XML, bao gồm các thông tin:
• Tên dịch vụ.
• Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của Web
Service.
• Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao
diện của Web Service cộng với tên cho giao diện này).
Một WSDL hợp lệ gồm hai phần:
• Phần giao diện: mô tả giao diện và giao thức kết nối.
• Phần thi hành: mô tả thông tin để truy xuất service.
Cả hai phần này sẽ được lưu trong 2 tập tin XML:
• Tập tin giao diện service (cho phần 1).
• Tập tin thi hành service (cho phần 2).

22
 Hình 2.9: Cấu trúc WSDL

 Tập tin giao diện - Service Interface

Một tài liệu WSDL mô tả một Web Service gồm các thành phần chính:

Element Defines
<types> Các kiểu dữ liệu được sử dụng bởi các Web Service
<message> Các thông điệp được sử dụng bởi các Web Service
<portType> Các hoạt động được thực hiện bởi các Web Service
<binding> Các giao thức truyền thông được sử dụng bởi các Web Service
Cấu trúc một tài liệu WSDL sẽ như sau:
<definitions>
<types>
definition of types
</types>
<message>
definition of a message
</message>
<portType>
definition of a port
</portType>
<binding>
definition of a binding....

23
 </binding>
</definitions>
Một tài liệu WSDL cũng có thể có các yếu tố khác, như thành phần mở
rộng, và các yếu tố một dịch vụ mà làm cho nó nhóm lại với nhau để có thể định
nghĩa của một số Web Service trong một tài liệu WSDL.

 Tập tin thi hành - Service Implementation

WSDL mô tả 2 loại thông tin chính bao gồm : service và port.

- Dịch vụ (Service)
Thực hiện những gì đã được định nghĩa trong tập tin giao diện và cách
gọi web services theo thủ tục và phương thức nào đó:
<wsdl: definitions .... >
<wsdl: service name="nmtoken">
<wsdl: port .... />
</wsdl: service>
</wsdl: definitions>
- Port
Là một cổng đầu cuối, nó định nghĩa như một tập hợp của binding và một
địa chỉ mạng.
<wsdl: definitions .... >
<wsdl: service .... >
<wsdl: port name="nmtoken" binding="qname">
</wsdl: port>
</wsdl: service>
</wsdl: definitions>
Ở đây chúng ta thấy rằng thuộc tính kết hợp tên là qname. Nó tham chiếu
tới một mối kết hợp. Một cổng chứa đựng chính xác một địa chỉ mạng, bất kỳ
cổng nào trong phần thi hành phải tương ứng chính xác với một tham chiếu trong
phần giao diện.

Giao diện của một Web Service được miêu tả trong phần này đưa ra cách
thức làm thế nào để giao tiếp qua Web Service. Tên, giao thức liên kết và định
dạng thông điệp yêu cầu để tương tác với Web Service được đưa vào thư mục
của WSDL.

24
 WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung
cấp Web Service qua Internet. Một client khi kết nối tới Web Service có thể đọc
WSDL để xác định những chức năng sẵn có trên server. Sau đó, client có thể sử
dụng SOAP để lấy ra chức năng chính xác có trong WSDL.

2.2.3.4. UDDI (Universal Description, Discovery and Integration)

UDDI là một dịch vụ thư mục nơi mà các công ty có thể đăng ký và tìm
kiếm các Web Service.
UDDI cung cấp một khung ứng dụng về các nghiệp vụ để xuất bản một
Web Service, khám phá các Web Service hiện hữu và xây dựng các đăng ký dịch
vụ chung.
• UDDI là một thư mục để lưu trữ các thông tin về các Web Service.
• UDDI là một thư mục của các Web Service giao diện mô tả bởi WSDL.
• UDDI truyền qua SOAP.
• UDDI được xây dựng trên Microsoft NET.
Để có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận
thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ. UDDI
định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy
tìm và nhận những thông tin được yêu cầu khi sử dụng Web Service.
Những thông tin về Web Service được sử dụng và công bố lên mạng sử
dụng giao thức này. Nó sẽ kích hoạt các ứng dụng để tìm kiếm thông tin của Web
Service khác nhằm xác định xem dịch vụ nào sẽ cần đến nó.
Những UDDI registry hiện có:

• UDDI Business Registry: bộ đăng ký được bảo trì bởi Microsoft, IBM
đặc điểm của bộ đăng ký này là nó phân tán về mặt vật lý.

• IBM Test Registry: bộ đăng ký cho những người phát triển để thử nghiệm
công nghệ và kiểm tra những service của họ.

• Private registries IBM ships: bộ đăng ký UDDI cá nhân.

Trên đây là mô tả bộ chuẩn công nghiệp mà Web Service sử dụng để triển
khai mô hình hoạt động theo tư duy SOA. Thoạt nhìn, SOA và Web Service có
vẻ giống nhau nhưng chúng không phải là một. Định nghĩa cơ bản của Web

25
Service dựa trên các công nghệ XML, WSDL, UDDI và SOAP cho phép xây
dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp.
Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng
công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn.
Rõ ràng, theo định nghĩa thì Web Service là đặc tả công nghệ còn SOA là
triết lý thiết kế phần mềm. Web Service đưa ra giải pháp kỹ thuật để thực hiện
SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không
phải Web Service (và không phải tất cả Web Service đều có kiến trúc SOA).
Tuy vậy, SOA và Web Service có mối quan hệ tương hỗ: sự phổ biến của Web
Service giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp
Web Service thành công.

2.3. Qui trình xây dựng hệ thống SOA

2.3.1. Thách thức khi xây dựng hệ thống
Cũng như các phương pháp phát triển phần mềm khác, để xây dựng được
một ứng dụng hướng dịch vụ cũng phải trải qua các giai đoạn tương tự. Tuy vậy,
dù những lợi ích đạt được từ hệ thống SOA là rất lớn nhưng việc triển khai một
hệ thống SOA không phải là điều dễ dàng. Từ mô hình tính toán tập trung
(mainframe) sang mô hình phân tán client/server, rồi sau đó là kiến trúc dựa trên
nền tảng Web. Và ngày nay quá trình này vẫn tiếp tục. Chúng ta đang ở thời kỳ
quá độ sang mô hình tính toán dựa trên dịch vụ là kiến trúc hướng dịch vụ
(SOA). Kiến trúc này ngày nay cũng đã và đang áp dụng và phát triển cho nhiều
doanh nghiệp trên thế giới. Nhưng để xây dựng và triển khai được hệ thống SOA
thì vẫn phải gặp một số vấn đề trở ngại:
- Xác định dịch vụ

• Dịch vụ là gì?chức năng nghiệp vụ nào cần được cung cấp bởi một
dịch vụ? Độ mịn(granularity) của một dịch vụ thế nào là tốt?

• Việc xác định dịch vụ và quyết định đối tượng cung cấp dịch vụ
một cách thích hợp, hiệu quả là giai đoạn quan trọng và đầu tiên
trong một giải pháp hướng dịch vụ .Trong thực tế nhiều chức năng
nghiệp vụ tương tự nhau có thể được cung cấp bởi nhiều hệ thống
trong một tổ chức.

26
- Phân bổ dịch vụ :

• Ta nên đặt dịch vụ ở vị trí nào trong hệ thống?

• Các dịch vụ thường hoạt động dựa trên các thực thể nghiệp vụ.Các
đối tượng này được lưu và quản lí trong hệ thống.Vị trí của các
thực thể này cũng là vị trí tốt nhất để đặt dịch vụ.Tuy nhiên bởi đặc
tính của hệ là phân tán nên các đối tượng này phân bố rải rác ở
nhiều vị trí và có thể một đối tượng được quản lí ở nhiều nơi.Vì
vậy đồng bộ dữ liệu giữa các hệ thống trở nên là một yêu cầu quan
trọng.Trong môi trường như thế thì dịch vụ sẽ được đặt ở đâu.

- Xác định miền dịch vụ:

• Làm sao gom nhóm các dịch vụ thành các miền luận lý(logic
domain)

• Việc phân loại gom nhóm các dịch vụ thành các miền luận lý sẽ
đơn giản hóa kiến trúc bởi sẽ giảm được số lượng các thành phần
cần xây dựng.Việc định nghĩa các miền như thế cũng ảnh hưởng
đến nhiều khía cạnh khác của kiến trúc hệ thống như cân bằng
tải(load balancing), điều khiển truy cập(access control), sự phân
chia theo chiều sâu hay chiều rộng của xử lý nghiệp vụ.

- Đóng gói dịch vụ:

• Làm sao có thể bao bọc các chức năng sẵn có của hệ thống cũ vào
trong một dịch vụ.

• Nếu hệ thống khi được thiết kế đã quan tâm và hỗ trợ vấn đề tích
hợp với các hệ thống mới thì vấn đề này sẽ dễ dàng hơn.Tuy nhiên
các hệ thống cũ này trước đây được xây dựng theo mô hình kín,
đóng gói trong đó chứa toàn bộ các thông tin về nguyên tắc và qui
trình xử lý thì nay, khi được tích hợp, các thông tin này cần được
chia sẻ và phân bố trong nhiều ứng dụng khác nhau.

- Kết hợp các dịch vụ:

27
 • Làm sao để có thể tạo ra các dịch vụ tổng hợp.

• Nhu cầu kết hợp nhiều dịch vụ để đáp ứng được yêu cầu phức tạp
từ đối tượng sử dụng là có thực. Vấn đề là làm sao kết hợp các dịch
vụ này một cách hiệu quả, theo những qui trình với những rằng
buộc phức tạp.

- Định tuyến dịch vụ:

• Làm sao để chuyển một yêu cầu từ một đối tượng sử dụng dịch vụ
đến dịch vụ hay miền dịch vụ thích hợp?

• Một hệ thống SOA phải có tính độc lập địa chỉ cho đối tượng sử
dụng các service của hệ thống.Ngoài ra còn phải quan tâm đến vấn
đề hiệu suất hoạt động của hệ thống vì việc định vị một dịch vụ là
một quá trình cũng chiếm mất nhiều thời gian

- Quản lý dịch vụ:

• Vấn đề quản lý và bảo trì các dịch vụ, việc tạo, xây dựng, theo dõi
và thay đổi các dịch vụ như thế nào cho có hiệu quả?

• Làm sao để lựa chọn một chuẩn định dạng thông điệp trao đổi giữa
các chuẩn? Làm sao có thể xây dựng một chuẩn định dạng dữ liệu
mà mọi hệ thống đều có khả năng hiểu và xử lý?

Ngoài các khó khăn trên mỗi tổ chức với mỗi đặc thù riêng của mình có
thể sẽ phải đối diện với các ấn đề khác trong quá trình triển khai hệ thống.
2.3.2. Vòng đời của hệ thống
Hình vẽ dưới đây mô tả tổng quát các giai đoạn trong chu trình sống của
một hệ thống SOA. Trong đó qui trình hệ thống đi qua 4 giai đoạn chính: Mô
hình hóa, Lắp ghép, Triển khai và Quản lý. Các giai đoạn này đều dựa trên nền
tảng của việc Quản trị và các thực nghiệm.

28
 Hình 2.10: Vòng đời hệ thống SOA
- Pha Model - mô hình hóa và thiết kế.
Ở pha này, cần tập trung vào những mục tiêu chính như sau:
• Thu thập các yêu cầu sử dụng dịch vụ.
• Mô hình hóa và mô phỏng hệ thống.
• Thiết kế từng dịch vụ ở mức cơ sở
- Pha Assemble – Lắp ráp các dịch vụ
• Khai thác
• Xây dựng và thử nghiệm
• Tổ hợp các dịch vụ
- Pha Deploy – Triển khai
• Tích hợp các nguồn nhân lực
• Tích hợp các tiến trình
• Quản lý và tích hợp thông tin.
- Pha Manage – Quản lí
• Quản trị các ứng dụng và các dịch vụ
• Quản lí sự đồng nhất và tính tuân thủ.
• Giám sát các số liệu nghiệp vụ
- Governance and best practice – Quản trị và các trải nghiệm thực tế: Đây
là công việc xuyên suốt trong cả qui trình vòng đời hệ thống.
29
 • Tính toán về tài chính
• Sắp xếp nghiệp vụ/công nghệ thông tin
• Điều khiển các tiến trình
Các thông tin thu thập được trong pha Manage sẽ được cung cấp trở lại
qui trình phát triển và giúp cải thiện quá trình xây dựng hệ thống, làm cho hệ
thống hoàn chỉnh hơn. Có nghĩa, qui trình là một vòng lặp cho tới khi hệ thống
hoàn chỉnh theo nhu cầu thay đổi của doanh nghiệp và khách hàng.
2.3.3. Các pha cơ bản xây dựng hệ thống SOA
Xây dựng hệ thống SOA trải qua 6 pha sau đây:

Hình 2.11: Các bước cơ bản trong xây dựng hệ thống SOA
Bước 1: Phân tích hướng dịch vụ (Service-oriented analysis).
Đây là giai đoạn đầu để quyết định phạm vi của hệ thống SOA. Hệ thống
gồm những dịch vụ nào? Tầng dịch vụ là được lược đồ hóa ra (mapped out), và
chia dịch vụ ra thành các mô hình, bao gồm hệ thống SOA sơ bộ.
Bước 2: Thiết kế hướng dịch vụ (service-oriented design).
Đây là giai đoạn có sự kết hợp chặt chẽ về sự thỏa hiệp của doanh nghiệp
và nguyên lý hướng dịch vụ thành quy trình thiết kế dịch vụ. Trong pha này, làm
cho người thiết kế dịch vụ phải đương đầu với giải quyết vấn đề then chốt đó là
thiết lập nên những ranh giới thông qua các dịch vụ. Các tầng dịch vụ là được
thiết kế trong giai đoạn này có thể bao gồm tầng orchestrantion, các kết quả của
nó là trong sự xác định quy trình nghiệp vụ hình thức.
Bước 3: Phát triển dịch vụ (Service development).
Trong bước này là giai đoạn xây dựng thực tế. Ở đây vấn đề về nền tảng
phát triển đi vào hoạt động, không quan tâm tới nó là loại dịch vụ nào. Một cách

30
cụ thể, là sự lựa chọn ngôn ngữ lập trình và môi trường phát triển sẽ quyết định
những mẫu dịch vụ và quy trình nghiệp vụ orchestrantion nào phù hợp với thiết
kế.
Bước 4: Kiểm thử dịch vụ (Service testing).
Để đưa ra những tiềm năng cho việc dùng lại và bao gồm cả những trạng
thái không biết trước được, các dịch vụ là được yêu cầu trải qua được sự nghiêm
ngặt của việc kiểm thử trước khi được triển khai thành các sản phẩm.
Bước 5: Triển khai dịch vụ (Service deployment).
Giai đoạn thực thi này đưa đến việc cài đặt và cấu hình cho các thành
phần phân tán, các giao diện dịch vụ, và nhiều sản phẩm trung gian (middleware
products) kết hợp với nhau thành những server.
Bước 6: Quản trị dịch vụ (Service administration).
Sau khi các dịch vụ được triển khai, vấn đề quản lý các ứng dụng trở
thành hàng đầu, mối quan tâm cho hệ thống phân tán, và các ứng dụng dựa trên
các thành phần (component-based applications), và việc xem xét chúng như các
dịch vụ trong một tổng thể.
2.3.4. Các chiến lược xây dựng hệ thống
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 nền tảng có sẵn. Mỗi cách
đều có những ưu nhược điểm 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ừ nền tảng 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.
2.3.4.1. Chiến lược top-down
Trong xây dựng một hệ thống SOA, top-down là chiến lược lấy xuất phát
điểm là các yêu cầu ngiệp vụ, sau đó xác định các yêu cầu chức năng, các tiến

31
trình nghiệp vụ và các tiến trình con, các trường hợp sử dụng (use cases) và đi tới
xác định các thành phần, các dịch vụ... của hệ thống.

Hình 2.12: Tiếp cận Top-down xây dựng hệ thống

Chiến lược top-down hỗ trợ tạo ra các bước để hình thành tầng dịch vụ
(service layers). Chiến lược này phổ biến để tạo ra những kiến trúc dịch vụ có
chất lượng cao, trong quá trình tạo ra nhiều những nghiệp vụ được sử dụng lại và
các dịch vụ ứng dụng khác.

Hình 2.13: Các bước xây dựng hệ thống theo chiến lược top-down.

- Bước 1: Define relevant ontology.

Bước này là để xác định, phân loại các tập thông tin được xử lý bởi các cơ
cấu tổ chức của hệ thống. Các kết quả này là các từ vựng phổ biến, như sự định
nghĩa mối quan hệ giữa các tập thông tin này với tập thông tin khác là như thế
nào. Các tổ chức có phạm vi rộng lớn hơn cùng với nhiều phạm vi nghiệp vụ có
thể có vài ontology, theo mỗi cách quản lý thì các nghiệp vụ chia ra một cách rõ
ràng. Nếu có nhiều từ vựng nghiệp vụ không tồn tại cho bất cứ các tập thông tin
nào mà một giải pháp được yêu cầu thực hiện, thì tại bước này nó sẽ được định
nghĩa. Một số lượng đáng kể các tập thông tin trước và kết quả phân tích nghiệp
vụ ở mức cao có thể được yêu cầu.

32
 - Bước 2: Align relevant business models (including entity models)
Sau khi ontology được thiết lập, sự tồn tại các mô hình nghiệp vụ có thể
cần thay đổi (hay tạo ra) để thể hiện các từ vựng bằng cách cung cấp ontology
trong các thuật ngữ mô hình nghiệp vụ. Mô hình thực thể chi tiết rất quan trọng.
- Bước 3: Perform service-oriented analysis
Xác định các dịch vụ và hướng tiếp cận cho các dịch vụ, mô hình hóa các
dịch vụ.
- Bước 4: Perform service-oriented design
Thực hiện thiết kế hướng dịch vụ.
- Bước 5: Develop services
Phát triển các dịch vụ theo yêu cầu. Các dịch vụ được phát triển theo
những bản thiết kế kỹ thuật tương ứng với các đặc tả dịch vụ được tạo ra ở bước
4.
- Bước 6: Test service operations
Giai đoạn kiểm thử được yêu cầu cho tất cả quá trình hoạt động của dịch
vụ và quá trình kiểm tra phải thực hiện đảm bảo chất lượng. Các dịch vụ vượt
qua được sự kiểm tra coi như đạt chất lượng và có thể tái sử dụng sau này.
- Bước 7: Deploy service
Quan tâm tới vấn đề thực thi, xác định tiềm năng tương lai sử dụng lại của
dịch vụ. Để tạo điều kiện cho nhiều người yêu cầu dịch vụ, các dịch vụ sử dụng
lại có thể mở rộng năng lực xử lý và cần có sự bảo mật. Đồng thời, cần phải cung
cấp cả khả năng truy cập cho dịch vụ.
2.3.4.2. Chiến lược bottom-up
Chiến lược này dựa trên việc phân tích tình trạng, các tài nguyên có sẵn
của hệ thống hiện có và tái sử dụng lại những thành phần này trong việc xây
dựng các dịch vụ mới. Sau khi có được các dịch vụ từ những thành phần đó, ta có
thể cải tiến chất lượng dịch vụ hoặc tổ hợp các dịch vụ lại để tạo ra những dịch
vụ cao cấp hơn hay còn gọi là các dịch vụ tổ hợp.

33
 Hình 2.14: Tiếp cận Bottom-up xây dựng hệ thống
Trong hướng tiếp cận này, ta thừa nhận các yêu cầu nghiệp vụ đã tồn tại.

Hình 2.15: Các bước xây dựng hệ thống theo chiến lược bottom-up.
- Bước 1: Model application services
Kết quả của giai đoạn này là sự định nghĩa của các yêu cầu ứng dụng được
thỏa mãn thông qua việc sử dụng Web service. Các yêu cầu này bao gồm những
thiết lập lên các kênh tích hợp point-to-point giữa hệ thống cũ (legacy system)
hoặc giải pháp B2B (Business-to-Business). Các yêu cầu phổ biến khác sẽ dần
xuất hiện để thay công nghệ truyền thông truyền thống bằng những framework
truyền thông điệp SOAP.
Các dịch vụ ứng dụng cũng sẽ được mô hình hóa bao gồm các logic và
quy tắc cho nghiệp vụ cụ thể. Trường hợp này, giống như hai tầng dịch vụ ứng
dụng, bao gồm có các dịch vụ tiện ích và nhân bản.
- Bước 2: Design applicaion services
Một vài các dịch vụ ứng dụng được mô hình hóa trong bước 1 có thể được
trình bày thành bản thiết kế. Các dich vụ có thể cung cấp thêm vào cho thiết kế.
Các dịch vụ ứng dụng tùy chọn sẽ cần đưa qua quá trình thiết kế, ở một khía cạnh

34
nào đó thì tồn tại những chuẩn thiết kế được áp dụng để đảm bảo mức độ bền
vững.
- Bước 3: Deploy application service
Các dịch vụ ứng dụng được phát triển theo sự mô tả dịch vụ và bản thiết
kế chi tiết ứng dụng.
- Bước 4: Test service
Các dịch vụ, môi trường kết hợp của chúng, và logic của những hệ thống
cũ sẽ được kiểm tra để đảm bảo chắc chắn rằng xử lý các yêu cầu là phù hợp. Sự
thực thi và tiêu chuẩn kiểm thử được nhấn mạnh thường là thiết lập lên các tham
số cho hệ thống cũ thông qua các dịch vụ. Kiểm tra bảo mật cũng là phần quan
trọng của giai đoạn này.
- Bước 5: Deploy services
Những giải pháp và các dịch vụ ứng dụng của nó sẽ triển khai thành sản
phẩm. Sự cân nhắc thực thi cho các dịch vụ ứng dụng thường bao gồm sự thực
thi và các yêu cầu bảo mật.
Hiện xu thế SOA đang phát triển rất mạnh. Và cả hai chiến lược xây dựng
hệ thống top-down và bottom-up đều được áp dụng rộng rãi. Một số hệ thống cũ
muốn nâng cấp hay tích hợp thêm một số dịch vụ hoặc tổ hợp lại với nhau thành
một hệ thống lớn thường sử dụng chiến lược bottom-up để tận dụng cơ sở hạ
tầng có sẵn và tiết kiệm chi phí. Còn hầu hết những hệ thống lớn hiện nay đi vào
xây dựng đều theo định hướng SOA và áp dụng chiến lược top-down, nhằm mục
đích đảm bảo khả năng mở rộng và thường xuyên thay đổi các yêu cầu với hệ
thống. Tùy vào từng hệ thống mà việc xây dựng kiến trúc hướng dịch vụ có thể
sử dụng chiến lược phù hợp.

35
 CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN
3.1. Chương trình demo
Sử dụng công cụ: Visual studio 2008, Sql Server 2005 xây dựng Web
Service.
3.1.1. Chức năng chính của chương trình:
- Xây dựng Web Service cung cấp thông tin thời tiết các tỉnh thành phố và
vùng miền trong cả nước.
- Xây dựng giao diện website gọi dịch vụ, đọc thông tin dạng XML trả về
của dịch vụ và hiển thị thông tin.
- Tái sử dụng dịch vụ: Sử dụng giao diện gọi dịch vụ để lấy thông tin thời
tiết các vùng miền của USA từ nhà cung cấp khác:
http://www.webservicex.net/WeatherForecast.asmx?WSDL
3.1.2. Xây dựng chương trình
a. Xây dựng dịch vụ phía nhà cung cấp(Service Provider)
- Dữ liệu của dịch vụ:
Gồm 2 bảng dữ liệu:
TinhThanhPho(#MaTTP, TenTTP): cung cấp mã và tên các địa điểm
trên cả nước.

ThoiTiet(#MaTTP, #Ngay, Nhietdo, Mota): cung cấp thông tin thời tiết
các địa điểm.

36
- Mô tả dịch vụ: dịch vụ chứa một phương thức lấy input là mã tỉnh thành
phố và trả về output là một đối tượng có các thuộc tính là thông tin thời
tiết của tỉnh thành phố đó:
public class ThoiTiet_TinhTP :
System.Web.Services.WebService {
[WebMethod]
public WeatherData
GetWeatherInfor(string matinh){
}
}
- Publish dịch vụ trên localhost:
IIS tự động sinh địa chỉ cổng cho dịch vụ:
http://localhost:2359/WS_DuBaoThoiTiet/ThoiTiet_TinhTP.asmx?WSDL

- Chọn phương thức GetWeatherInfor, nhập vào mã tỉnh thành phố:

37
 - Kết quả: thông tin của đối tượng WeatherData được chuyển đổi sang
dạng XML

b. Xây dựng giao diện sử dụng dịch vụ (Service Consumer)

- Xây dưng giao diện website cho việc gọi dịch vụ và hiển thị kết quả trả
về như sau:

38
- Để sử dụng được Web Service đã xây dựng, ta phải tìm kiếm và đăng ký.
Thực hiện bằng cách thêm vào thêm một đường dẫn tham chiếu tới địa
chỉ của Web service đã được public:
http://localhost:2359/WS_DuBaoThoiTiet/ThoiTiet_TinhTP.asmx?WSDL

- Nhập mã tỉnh thành phố:

- Kết quả:

39
- Sử dụng dịch vụ từ một nhà cung cấp khác:
http://www.webservicex.net/WeatherForecast.asmx?WSDL
Tương tự ta thực hiện Add Web referrence là địa chỉ tìm kiếm dịch vụ:

- Trên giao diện gọi dịch vụ, nhập vào PlaceName. Kết quả trả về:

40
3.2. Đánh giá chương trình
Chương trình đã mô tả được cách thức sử dụng web service:
- Tạo ra một dịch vụ
- Sử dụng dịch vụ đã xây dựng
- Tái sử dụng một dịch vụ được cung cấp sẵn
Chương trình chủ yếu tập trung vào mục đích đưa ra một giải pháp công
nghệ chứ chưa quan tâm nhiều tới khía cạnh xử lý nghiệp vụ, các tiến trình
nghiệp vụ và các vấn đề khác trong xây dựng hệ thống vẫn chưa được đề cập tới
(tạo các tài liệu mô tả dịc vụ, đăng ký dịch vụ, xử lý xác thực, phân quyền…).
Thực tế, xây dựng một hệ thống hoàn chỉnh theo tư tưởng SOA là quá trình rất
phức tạp và đòi hỏi nhiều về kiến thức cũng như kinh nghiệm thực tế không chỉ
về công nghệ thông tin mà còn là quản lý nghiệp vụ, nguồn nhân lực và tài
nguyên của hệ thống… Phạm vi của đề tài chưa thể giải quyết hết các vấn đề.

41
 KẾT LUẬN
SOA sẽ giúp cho công việc phát triển phần mềm trở nên dễ dàng và nhanh
chóng hơn. “Đừng tốn công chế tạo lại bánh xe, hãy kết hợp những linh kiện
(dịch vụ) có sẵn và bổ sung những gì cần thiết để lắp ráp nhanh chóng chiếc xe
đưa bạn đến đích!”. Đó là triết lý của SOA. Trong khi SOA đã và đang làm kiến
trúc ưu việt cho phát triển ứng dụng công nghệ thông tin trong giai đoạn hiện nay
thì việc nghiên cứu để có thể áp dụng triết lý này cho các hệ thống phần mềm là
một việc cần thiết.
Sau quá trình nghiên cứu, đề tài của em đã đạt được một số kết quả sau:
- Hiểu và đưa ra được khái niệm và các vấn đề liên quan tới kiến trúc
hướng dịch vụ SOA
- Ứng dụng công nghệ Web Service trong triển khai tư tưởng SOA
- Qui trình và các hướng tiếp cận phát triển ứng dụng theo hướng dịch vụ
- Xây dựng chương trình demo về Web Service
Tuy nhiên, các kết quả tìm hiểu còn rất tổng quan, chương trình xây dựng
chỉ mang tính mô phỏng nên còn khá đơn giản.
Trong quá trình nghiên cứu đề tài, do kĩ năng nghiên cứu và kiến thức còn
hạn chế, bài báo cáo chưa giải quyết được hết mọi góc cạnh của vấn đề. Em
mong nhận được sự đóng góp của thầy cô để đề tài hoàn thiện hơn. Trong thời
gian tới, em sẽ tiếp tục nghiên cứu để tìm hiểu sâu hơn các vấn đề về SOA như:
sử dụng một số công cụ hỗ trợ để định nghĩa và xây dựng dịch vụ, cách thức
đăng ký một Web Service với Service Broker, các giải pháp bảo mật cho hệ
thống SOA…
Em xin chân thành cảm ơn!

SV. Nguyễn Thị Dung

42
 TÀI LIỆU THAM KHẢO
1. Douglas K. Barry (2003), Web Services and Service-Oriented Architecture:
The Savvy Manager's Guide.
2. IBM Red Book Team (2004), Pattern: Implementing an SOA using
Enterprise Service Bus.
3. IBM Red Book Team (2004), Pattern: Service-Oriented Architecture and
Web Services.
4. IBM Red Book Team (2007), Understanding SOA SecurityDesign and
Implementation.
5. http://www.ibm.com/developerworks/vn/library/ws-soa-progmodel , Loạt
bài về SOA program model.
6. Hồ Bảo Thanh & Nguyễn Hoàng Long (2005) - Luận văn cử nhân tin học
khoa CNTT – ĐH KHTN Tp.HCM, Nghiên cứu về kiến trúc hướng dịch vụ
và ứng dụng.
7. Kris Jamsa (2003), .NET Web Services Solutions Sybex © 2003.
8. Ramarao Kanneganti, Prasad Chodavarapu (2007), SOA Security.
9. Systinet, A Practical Guide to SOA for IT Management
10. Ths. Nguyễn Trọng Dũng Trường ĐHSP Hà Nội, Phát triển Web Service
với các công nghệ chuẩn của java.
11. Các bài viết liên quan:
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://vovanhai.wordpress.com/web-services/c-web-services/t%E1%BA
%A1o-web-service-v%E1%BB%9Bi-c-step-by-step
http://voer.edu.vn/content/m18879/latest/
http://www.phpvn.org/index.php?topic=301.0
http://www.networkworld.com/news/2009/031209-soa-security-the.html
http://www.quantrimang.com.vn/doanhnghiep/doanh-nghiep/58175_Xu-
huong-ung-dung-SOA-o-Chau-A.aspx
http://www.erpsolution.com.vn/showthread.php?t=2248
43
http://www.pcworld.com.vn/articles/quan-ly/nguon-
luc/2009/06/1194174/kien-truc-huong-dich-vu-soa-khong-con-la-khai-niem/

44
 CHỮ KÝ XÁC NHẬN
Ngày 15 tháng 12 năm 2010
Chủ nhiệm đề tài
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
…………………………………………
Ngày 15 tháng 12 năm 2010
Giáo viên hướng dẫn
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
………………………………………
45