ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ CÔNG NGHỆ DỊCH VỤ MẠNG TRONG XÂY DỰNG PHẦN MỀM

Website: Email : Tel : 0918.775.368

ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ
VÀ CÔNG NGHỆ DỊCH VỤ MẠNG TRONG
XÂY DỰNG PHẦN MỀM
Danh mục từ viết tắt
STT

Từ viết tắt

1.

CBD

2.

CORBA

3.

DCOM

4.

IDL

5.

JINI

6.

JMS

7.

HTTP

8.

NASSL

9.

RMI

10.

SDL

11.

SOA

Giải nghĩa
Phát triển hướng thành phần
Component-Based Development
Kiến trúc môi giới yêu cầu đối tượng chung
Common Object Request Broker Architecture
Mơ hình đối tượng thành phần phân tán
Distributed Component Object Model

Ngôn ngữ đặc tả giao diện
Interface Description Language
Hạ tầng mạng thông minh cho Java
Java Intelligent Network Infrastructure
Dịch vụ thông điệp Java
Java Message Service
Giao thức truyền siêu văn bản
HyperText Transfer Protocol
Ngôn ngữ đặc tả dịch vụ có khả năng truy cập qua mạng
Network Accessible Service Specification Language
Triệu gọi phương thức từ xa
Remote Method Invocation
Ngôn ngữ đặc tả dịch vụ
Service Description Language
Kiến trúc hướng dịch vụ

1


Website: Email : Tel : 0918.775.368

STT

Từ viết tắt

Giải nghĩa
Service-Oriented Architecture

12.

SOAP

13.

UDDI

14.

WSDL

15.

XML

Giao thức truy cập đối tượng đơn giản
Simple Object Access Protocol
Mơ tả, tích hợp và tìm kiếm tồn cầu.
Universal Description Discovery and Integration
Ngôn ngữ đặc tả dịch vụ mạng
Web Service Description Language
Ngôn ngữ đánh dấu mở rộng
eXtensible Markup Language

2


Website: Email : Tel : 0918.775.368

Danh mục hình vẽ

3


Website: Email : Tel : 0918.775.368

Mục lục
Danh mục từ viết tắt..................................................................................................................1
Danh mục hình vẽ.....................................................................................................................3
Mục lục.......................................................................................................................................4
MỞ ĐẦU....................................................................................................................................6
CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ.............................................8
1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin..................................8
2. Kiến trúc hướng dịch vụ - một giải pháp.............................................................................10
2.1. Sự tiến hóa của lý thuyết phát triển phần mềm.................................................................................10
2.2 Kiến trúc hướng dịch vụ.....................................................................................................................13
2.3. Dịch vụ và thành phần.......................................................................................................................21

3. Thiết kế theo kiến trúc hướng dịch vụ.................................................................................25
3.1. Các nguyên tắc trong thiết kế hướng dịch vụ....................................................................................26
3.2. Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ.................................................26
3.3. Các mức độ chấp nhận kiến trúc hướng dịch vụ...............................................................................29
3.4. Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ........................................30
3.5. Vòng đời phát triển của dịch vụ........................................................................................................34

4. Các công nghệ hướng dịch vụ...............................................................................................35
4.1. Sun JINI............................................................................................................................................35
4.2. Openwings.........................................................................................................................................37
4.3. Dịch vụ mạng....................................................................................................................................39
4.4. Enterprise Service Bus (ESB)...........................................................................................................40

5. Kết luận chương....................................................................................................................42

CHƯƠNG II. CÔNG NGHỆ DỊCH VỤ MẠNG..................................................................43
1. Kiến trúc dịch vụ mạng.........................................................................................................44
2. Các chuẩn cho dịch vụ mạng................................................................................................45
2.1. Ngôn ngữ mô tả dịch vụ mạng WSDL..............................................................................................45
2.2. Giao thức truy cập đối tượng đơn giản SOAP..................................................................................49
2.3. Đặc tả mơ tả và tích hợp tìm kiếm UDDI.........................................................................................54

3. Các kiểu liên kết trong dịch vụ mạng...................................................................................59
3.1 Liên kết tĩnh.......................................................................................................................................59
3.2. Liên kết động trong thời gian xây dựng............................................................................................60
3.3. Liên kết động trong thời gian chạy...................................................................................................62

5. Xây dựng dịch vụ mạng........................................................................................................63
5.1. Vòng đời của dịch vụ mạng..............................................................................................................63
5.2. Bảo mật trong dịch vụ mạng.............................................................................................................64
5.3. Tính liên thơng giữa các dịch vụ mạng.............................................................................................69

6. Kết luận chương....................................................................................................................70

Chương III: CÀI ĐẶT ỨNG DỤNG.....................................................................................71
1. Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ..............71
2. Mơ tả bài tốn........................................................................................................................72
3. Cài đặt bài tốn.....................................................................................................................74
3.1. Thành phần cung cấp dịch vụ............................................................................................................74
3.2. Thành phần sử dụng dịch vụ.............................................................................................................79
3.3 Thành phần đăng ký dịch vụ..............................................................................................................81

4. Các kết quả đạt được............................................................................................................81

4


Website: Email : Tel : 0918.775.368

5. Đánh giá về ứng dụng............................................................................................................85
5.1. Ưu điểm.............................................................................................................................................85
5.2. Các điểm hạn chế..............................................................................................................................86

KẾT LUẬN..............................................................................................................................87
Danh mục tài liệu tham khảo................................................................................................89

5


Website: Email : Tel : 0918.775.368

MỞ ĐẦU
Kiến trúc phần mềm của một hệ thống mô tả các thành phần của hệ thống và
cách thức các thành phần này tương tác với nhau; tương tác giữa các thành phần được
gọi là “liên kết” (connector) [1]. Trong một hệ thống phần mềm có quy mơ lớn và
phức tạp thì kiến trúc của hệ thống giữ một vị trí quan trọng trong việc hiểu hệ thống,
việc tổ chức phát triển và tăng cường tái sử dụng.
Ngày nay, khi mà độ phức tạp của phần mềm ngày càng tăng thì các kiến trúc
phần mềm truyền thống dường như đang tiến tới giới hạn khả năng giải quyết vấn đề
của chúng; trong khi đó, các tổ chức cơng nghệ thơng tin vẫn phải đáp ứng được
những yêu cầu đặt ra như: yêu cầu được đáp ứng nhanh, yêu cầu giảm giá thành, yêu
cầu về khả năng thu hút và tích hợp với các đối tác mới v.v…, và đặc biệt là sự thay
đổi nhanh chóng của các cơng nghệ.

Trong suốt bốn thập kỷ qua, thực tế phát triển phần mềm đã trải qua nhiều
phương pháp phát triển khác nhau. Mỗi phương pháp mới xuất hiện đều hướng tới
mục tiêu quản lý độ phức tạp ngày càng tăng của phần mềm bằng cách đưa ra các cấu
trúc có mức độ đóng gói tăng dần: từ hàm (function), lớp (class), tới thành phần
(component); các cấu trúc này được xem như những phần mềm “hộp đen”, chúng che
giấu cài đặt nhờ việc kiểm soát việc truy cập tới hành vi và dữ liệu của mình thơng
qua một giao diện tường minh. Ở mức độ đóng gói thấp, chúng ta sử dụng đối tượng
để che giấu dữ liệu, ở mức độ đóng gói cao hơn, chúng ta sử dụng các thành phần để
thực hiện việc này. Việc sử dụng đối tượng để che giấu thông tin hoạt động tốt với
các hệ thống nhỏ, nó cho phép tạo ra các cấu trúc phần mềm phản ánh được các đối
tượng trong thế giới thực. Vấn đề nảy sinh khi chúng ta cố gắng nhóm một số lượng
lớn các đối tượng cùng với nhau. Mặc dù truy cập tới các đối tượng được điều khiển
thông qua giao diện của chúng, mức độ đóng gói thấp của các đối tượng vẫn làm cho
sự phụ thuộc giữa chúng trở nên khó kiểm soát trong một hệ thống tương đối lớn.
Khái niệm thành phần được phát triển giúp quản lý các hệ thống lớn tốt hơn: một
thành phần được định nghĩa là một nhóm các đối tượng hoạt động cùng nhau để thực
hiện một chức năng của hệ thống. Các công nghệ như EJB (Enterprise Java
Bean), .NET, CORBA (Common Object Request Broker Architecture) tỏ ra rất hiệu
quả trong việc cài đặt các thành phần. Phương pháp phát triển phần mềm dựa thành
phần (Component-based Development - CBD) cho phép những nhà phát triển tạo ra
các hệ thống phức tạp hơn, có chất lượng cao hơn và nhanh hơn bất kỳ phương pháp
phát triển phần mềm nào khác trước đó. Nhưng khi chúng ta xây dựng các thành phần
trên các ngôn ngữ khác nhau, hay thậm chí là trên những nền tảng khác nhau (các
thành phần khơng đồng nhất) cho một hệ thống thì cần có khả năng tích hợp chúng
lại với nhau, nhưng một vấn đề nảy sinh: các thành phần dùng công nghệ EJB địi hỏi
việc triệu gọi phương thức thơng qua RMI (Remote Method Invocation – Triệu gọi
phương thức từ xa), trong khi đó, các thành phần dùng cơng nghệ CORBA thì lại
dùng IIOP (Internet Inter-ORB Protocol), hơn nữa, khi các thành phần được định vị
qua Internet, các thông điệp giữa chúng có thể bị chặn bởi tường lửa. Ngay cả khi
khơng gặp phải những vấn đề trên thì để sử dụng được thành phần, chúng ta vẫn cần

phải biết vị trí chính xác và giao diện của thành phần để nếu giao diện thay đổi,
chúng ta cũng phải thay đổi cách gọi đến chúng. Vì số lượng người dùng thành phần
6


Website: Email : Tel : 0918.775.368

có thể rất lớn nên việc này sẽ tạo ra các phụ thuộc có quy mơ lớn, rất khó kiểm sốt.
Vậy làm thế nào chúng ta có thế giải quyết vấn đề này?
Kiến trúc hướng dịch vụ (Service-oriented architecture, viết tắt là SOA) đang
được phát triển và được xem như một bước đột phá tiếp theo trong kiến trúc phần
mềm giúp giải quyết vấn đề “khủng hoảng” phần mềm. Sự xuất hiện của công nghệ
dịch vụ mạng (Web services) trong vài năm trở lại đây đã tạo ra sự quan tâm mạnh
mẽ tới kiến trúc này bởi Web service hiện thực hóa việc phát triển hệ thống theo kiến
trúc hướng dịch vụ một cách tự nhiên và dễ dàng hơn. Web service và kiến trúc
hướng dịch vụ đang thay đổi một cách căn bản cách thức xây dựng các hệ thống nội
bộ (các hệ thống thông tin hỗ trợ trong các tổ chức) và cách các hệ thống nội bộ
tương tác với các hệ thống bên ngoài mà chưa một kiến trúc nào trước đó có thể thực
hiện được. Thuật ngữ “dịch vụ” trong kiến trúc hướng dịch vụ cũng không phải là
khái niệm mới: các ứng dụng khách/chủ (client/server) trong những năm 90 đã sử
dụng “dịch vụ” để chỉ khả năng thực hiện lời gọi phương thức từ xa. Kiến trúc hướng
dịch vụ đặc biệt đề cao tính liên thơng (interoperability) và sự trong suốt về vị trí của
các dịch vụ, nói tới dịch vụ và kiến trúc hướng dịch vụ là nói về việc thiết kế và xây
dựng các hệ thống sử dụng các thành phần phần mềm không đồng nhất.
Sử dụng công nghệ dịch vụ mạng và kiến trúc hướng dịch vụ đem lại các lợi
ích sau:
• Mở rộng các lựa chọn về mặt cơng nghệ.
• Các hệ thống được xây dựng linh hoạt và nhạy bén hơn.
• Giảm thời gian phát triển.
• Giảm chi phí bảo trì.

Trong đồ án tốt nghiệp này, người viết đồ án (NVĐA) sẽ trình bày về lý
thuyết của kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, tại sao những công
nghệ này có thể xóa bỏ những rào cản cơng nghệ để tạo ra các hệ thống phần mềm có
tính tích hợp cao, và tại sao lựa chọn công nghệ dịch vụ mạng là thích hợp nhất cho
việc cài đặt ứng dụng theo kiến trúc hướng dịch vụ cũng như lợi ích của những ứng
dụng này khi xây dựng theo kiến trúc hướng dịch vụ.

7


Website: Email : Tel : 0918.775.368

CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG
DỊCH VỤ
Kiến trúc hướng dịch vụ là một làn sóng mới trong phát triển ứng dụng. Nó
có thể được xem như là một tập hợp của các khái niệm kiến trúc hoặc một mơ hình
lập trình.
Chương này sẽ trình bày các khái niệm cơ bản về :
 Sự tiến hóa của các kỹ thuật phát triển phần mềm.
 Kiến trúc hướng dịch vụ và phát triển phần mềm theo kiến trúc hướng
dịch vụ.
 Các công nghệ giúp hiện thực hóa triết lý của kiến trúc hướng dịch vụ.

1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ
thông tin
Trong khi các nhà quản lý công nghệ thông tin đang phải đối đầu với việc
giảm giá thành và tối đa lợi ích của các cơng nghệ hiện có, họ vẫn phải liên tục cố
gắng để phục vụ khách hàng được tốt hơn, trở nên cạnh tranh hơn và phản ứng nhanh
hơn với chiến lược của doanh nghiệp.
Có hai yếu tố chính ẩn sau những áp lực này, đó là tính khơng đồng nhất của

các hệ thống và sự thay đổi nhanh về mặt công nghệ. Phần lớn các doanh nghiệp
ngày nay đều gồm nhiều hệ thống, ứng dụng và kiến trúc khác nhau với thời gian tồn
tại và cơng nghệ khác nhau. Việc tích hợp các sản phẩm từ nhiều nhà cung cấp và
nhiều nền tảng thực sự là điều khó khăn. Nhưng chúng ta cũng không thể cố gắng
tiếp cận theo kiểu một nhà cung cấp đối với cơng nghệ thơng tin vì các bộ ứng dụng
và kiến trúc hỗ trợ rất không mềm dẻo.
Sự thay đổi công nghệ là yếu tố thứ hai mà các nhà quản lý công nghệ thông
tin phải đối mặt. Sự tồn cầu hố và kinh doanh điện tử đang làm tăng tốc sự thay
đổi. Sự tồn cầu hố dẫn tới sự cạnh tranh gay gắt trong việc rút ngắn chu kỳ sản xuất
để có thể chiếm ưu thế đối với đối thủ cạnh tranh. Các thay đổi về yêu cầu và nhu cầu
của khách hàng nhanh chóng hơn do tác động của phân phối cạnh tranh và sự phong
phú về thơng tin sản phẩm trên Internet. Do đó lại càng thúc đẩy việc cải tiến trong
sản phẩm và dịch vụ diễn ra nhanh hơn.
Các cải tiến trong công nghệ tiếp tục tăng, làm tăng sự thay đổi yêu cầu của
khách hàng. Doanh nghiệp phải nhanh chóng thích nghi để tồn tại, chưa kể đến việc
phải thành công trong môi trường cạnh tranh động ngày nay, và hạ tầng công nghệ
thơng tin phải đem lại khả năng thích nghi cho các doanh nghiệp.
Vì vậy, các tổ chức kinh doanh đang phát triển từ sự phân chia doanh nghiệp
theo chiều dọc, cô lập của những năm 1980 về trước thành các cấu trúc chú trọng quy
trình kinh doanh theo chiều ngang của những năm 1980, 1990, tới mơ hình kinh
8


Website: Email : Tel : 0918.775.368

doanh mới trong đó các doanh nghiệp có tác động lẫn nhau. Các dịch vụ kinh doanh
ngày nay cần phải được thành phần hoá và phân tán. Cần chú trọng vào dây chuyền
cung cấp mở rộng, cho phép khách hàng và đối tác truy cập tới các dịch vụ kinh
doanh.

Hình 1.1: Sự phát triển của các công ty
Làm thế nào để môi trường công nghệ thông tin trở nên linh hoạt và nhạy bén
hơn đối với sự thay đổi của các yêu cầu kinh doanh? Làm thế nào để các hệ thống và
ứng dụng không đồng nhất trao đổi với nhau một cách liền mạch? Làm thế nào để đạt
được các mục tiêu kinh doanh mà không làm phá sản các doanh nghiệp?
Đã có nhiều giải pháp được đề ra song song với sự phát triển của các vấn đề
kinh doanh, như được chỉ ra trong hình 1.2. Hiện nay, nhiều nhà quản lý và các
chuyên gia công nghệ thông tin tin rằng chúng ta đang tiến ngày một gần hơn tới câu
trả lời với kiến trúc hướng dịch vụ (SOA).

Hình 1.2: Sự phát triển của kiến trúc
Để đáp ứng được nhu cầu về sự khơng đồng nhất, tính liên thơng và sự thay
đổi yêu cầu không ngừng, một kiến trúc như vậy phải đem lại một nền tảng cho việc
xây dựng các dịch vụ ứng dụng với các đặc tính sau:
•

Liên kết lỏng lẻo (Loosely coupled)

•

Vị trí trong suốt (Location transparent)

•

Độc lập về giao thức (Protocol independent)

Dựa trên một kiến trúc hướng dịch vụ như vậy, người dùng dịch vụ thậm chí
khơng cần phải quan tâm tới một dịch vụ cụ thể mà mình đang trao đổi thơng tin vì
hạ tầng cơ sở, hay là tuyến dịch vụ (service bus), sẽ tạo ra một lựa chọn thích hợp cho
9

Website: Email : Tel : 0918.775.368

người dùng. Các đặc tả kỹ thuật cụ thể từ các công nghệ cài đặt khác nhau như J2EE
hay .NET không làm ảnh hưởng tới người dùng SOA. Người dùng cũng có khả năng
cân nhắc và thay thế một cài đặt dịch vụ tốt hơn nếu tồn tại một dịch vụ khác có chất
lượng tốt hơn.

2. Kiến trúc hướng dịch vụ - một giải pháp
2.1. Sự tiến hóa của lý thuyết phát triển phần mềm.
Trước khi giải thích về kiến trúc hướng dịch vụ cũng như bản chất những khái
niệm tạo nên kiến trúc hướng dịch vụ, chúng ta cần phải hiểu về lịch sử phát triển của
kiến trúc hướng dịch vụ bằng cách nhìn lại những khó khăn mà những nhà phát triển
phần mềm đã phải đối mặt trong vài thập kỷ qua và xem xét các giải pháp được đưa
ra để giải quyết các khó khăn đó.
Những người lập trình đã sớm nhận ra rằng việc viết phần mềm đã đang ngày
càng phức tạp hơn. Họ cần một cách tốt hơn để sử dụng lại những đoạn mã đã viết.
Khi những nhà nghiên cứu quan tâm tới vấn đề này, họ đã đưa ra khái niệm thiết kế
mô đun. Với các quy tắc của thiết kế mơ đun, các lập trình viên có khả năng viết các
hàm và chương trình con và sử dụng lại mã đã viết. Đó quả là một bước đột phá và
một điều tuyệt vời cho việc xây dựng phần mềm. Cách này có hiệu quả tốt trong một
thời gian, từ 1960 đến 1980.

Hình 1.3: Phát triển phần mềm theo mơ đun
Nhưng sau đó, các lập trình viên lại nhận thấy rằng họ đang thực hiện việc cắt
dán các mô đun vào các ứng dụng khác, điều này bắt đầu tạo ra một cơn ác mộng về
bảo trì: khi một lỗi được phát hiện trong một hàm nào đó, họ phải kiểm tra tất cả các
ứng dụng có sử dụng hàm này và thay đổi mã để sửa chữa. Những nhà phát triển
không muốn điều này, họ cần một mức trừu tượng cao hơn. Các nhà nghiên cứu đã

đưa ra khái niệm các lớp và phần mềm hướng đối để giải quyết vấn đề này. Phương
pháp phát triển phần mềm hướng đối tượng đã có hiệu quả trong một thời gian, từ 1980
đến 1990.

10


Website: Email : Tel : 0918.775.368

Hình 1.4: Phát triển phần mềm hướng đối tượng
Lại một lần nữa, khi độ phức tạp của phần mềm tăng lên, các nhà phát triển
bắt đầu nhận thấy việc xây dựng và bảo trì phần mềm là rất phức tạp, họ muốn một
cách nào đó để sử dụng lại và bảo trì các chức năng chứ không chỉ đơn thuần là mã
nguồn. Các nhà nghiên cứu lại đưa ra một lớp trừu tượng khác để kiểm sốt độ phức
tạp này, đó là phần mềm dựa thành phần (Component-based software - CBD).

Hình 1.5: Phát triển phần mềm hướng thành phần
CBD là một giải pháp tốt cho việc sử dụng lại và bảo trì, nhưng nó khơng
kiểm sốt được tất cả các độ phức tạp mà các nhà phát triển hiện nay đang phải đối
mặt như: phần mềm phân tán, các ứng dụng tích hợp, các nền tảng, thiết bị khác nhau
v.v… Phần mềm ngày nay phải được xây dựng sao cho có thể đáp ứng được tất cả
các yêu cầu trên. Và kiến trúc hướng dịch vụ cùng với công nghệ dịch vụ mạng xuất
hiện đã đem lại một giải pháp cho tất cả các yêu cầu. Bằng cách thực hiện SOA, các
nhà phát triển có thể loại bỏ được những sự khơng tương thích về giao thức, nền tảng
và các ứng dụng được tích hợp một cách dễ dàng.

11


Website: Email : Tel : 0918.775.368

Hình 1.6: Phát triển phần mềm hướng dịch vụ
Như vậy, theo thời gian, chúng ta nhận thấy rằng những phương pháp phát
triển phần mềm đã liên tục tiến hóa, từ phương pháp xây dựng phần mềm đơn giản
nhất cho đến những phương pháp xây dựng phần mềm đồ sộ như ngày nay.
Quá trình tiến hóa của phương pháp phát triển phần mềm có thể tóm lược lại
như sau: ban đầu là phương pháp phát triển tự phát, tức là cần máy tính thực hiện như
thế nào thì viết lệnh như thế đó. Đơn vị có thể tái sử dụng của phần mềm là rất nhỏ từng dòng lệnh. Những phần mềm được viết ra thường nhỏ, và đơn giản, chủ yếu là
các phần mềm hỗ trợ tính tốn. Sau đó kỹ thuật phát triển phần mềm tiến thêm một
bước mới, đó là phát triển phần mềm theo mô đun. Nhờ phương pháp này, những đơn
vị chương trình có khả năng tái sử dụng đã tăng lên và quy mô của phần mềm cũng
đã lớn hơn, không chỉ dừng ở các phần mềm hỗ trợ tính tốn, mà cịn bao gồm cả
những ứng dụng thương mại. Kỹ thuật phát triển phần mềm hướng đối tượng đã trở
thành một làn sóng mới về kỹ thuật phát triển phần mềm trong một vài thập kỷ gần
đây, việc đưa ra các khái niệm lớp, hàm và biến thành phần, kế thừa, kết tập... đã
khiến cho việc xây dựng phần mềm trở nên dễ dàng hơn, cấu trúc chương trình trở
nên dễ hiểu hơn, với khái niệm đối tượng tương đối gần với các thực thể trong đời
sống tự nhiên và xã hội. Kỹ thuật phát triển phần mềm hướng đối tượng đã làm tăng
khả năng tái sử dụng mã, và nó cũng làm cho phần mềm có khả năng khả chuyển hơn
do đặc tính khép kín của các lớp. Cùng với sự phát triển ngày càng nhanh của các
phần mềm cả về quy mô lẫn yêu cầu về thời gian phát triển, phương pháp phát triển
phần mềm hướng thành phần là mức trừu tượng hóa cao hơn của phương pháp phát
12


Website: Email : Tel : 0918.775.368

triển hướng đối tượng. Đặc điểm chính của các phần mềm phát triển theo phương
pháp này là chúng gồm nhiều thành phần, mỗi thành phần có thể hồn thành một
hoặc một số cơng việc cụ thể, nhất định. Mỗi thành phần bao gồm một tập các lớp,

các đối tượng. Phần mềm được tạo ra bằng cách ghép các thành phần đó lại với nhau,
thông qua việc sử dụng các giao diện giữa chúng. Phần mềm được tạo ra theo phương
pháp này có khả năng tái sử dụng mã rất cao, việc bảo trì và nâng cấp khá dễ dàng.
Tuy nhiên, quy mô của phần mềm ngày càng nở rộng, thời gian đưa ra thị trường
được đòi hỏi ngày càng phải sớm hơn, yêu cầu về khả năng tái sử dụng mã và khả
năng dễ bảo trì đối với phần mềm đã khiến cho phương pháp phát triển phần mềm
hướng dịch vụ ra đời và đang được xem như là một làn sóng mới trong phát triển
phần mềm.
Bảng so sánh dưới đây cho ta thấy rõ ưu thế của phương pháp phát triển phần
mềm hướng dịch vụ so với các phương pháp phát triển phần mềm trước đó.
Hướng cấu
trúc

Hướng đối
tượng

Mức độ đóng
gói

Rất thấp

Thấp

Trung bình

Cao

Giao ước sử
dụng

Xác định

Riêng tư /Công
khai

Công khai

Xuất bản

Khả năng tái
sử dụng

Thấp

Thấp

Trung bình

Cao

Độ gắn kết

Chặt

Chặt

Lỏng lẻo

Rất lỏng lẻo

Các ràng buộc
Phạm vi
truyền thơng

Hướng thành Hướng dịch
phần
vụ

Thời gian biên Thời gian biên Thời gian biên
dịch
dịch
dịch
Nội bộ ứng
dụng

Nội bộ ứng
dụng

Thời gian
chạy

Nội bộ ứng Giữa các công
dụng
ty

2.2 Kiến trúc hướng dịch vụ
Kiến trúc phần mềm của một chương trình hoặc một hệ thống tính tốn là cấu
trúc hoặc các cấu trúc của hệ thống, bao gồm các thành phần phần mềm, các thuộc
tính có thể nhìn thấy từ bên ngồi của các thành phần đó và các mối quan hệ giữa
chúng[1].

Hình 1.7: Kiến trúc phần mềm theo định nghĩa cổ điển

13


Website: Email : Tel : 0918.775.368

Kiến trúc hướng dịch vụ là một loại kiến trúc phần mềm đặc biệt có nhiều đặc
tính riêng biệt.

Hình 1.8: Mơ hình kiến trúc hướng dịch vụ
2.2.1. Các định nghĩa về kiến trúc hướng dịch vụ
Kiến trúc hướng dịch vụ (Service-oriented architecture - SOA) là một cụm từ thông
dụng trong công nghệ thông tin ngày nay. Mặc dù đã có nhiều cố gắng nhưng vẫn
khơng có được sự thống nhất trong định nghĩa về kiến trúc này [4].
“SOA là một framework cho phép tính năng ứng dụng được cung cấp, tìm ra và tiêu
thụ như là các tập dịch vụ mạng có khả năng tái sử dụng. Trong khi dịch vụ mạng
không phải là SOA, nó là một trong các chuẩn cho phép xây dựng SOA. SOA trừu
tượng hố tính phức tạp và chi tiết cài đặt, khiến cho nó trở thành một kiến trúc hoàn
thiện để xây dựng các hệ thống phần mềm.” Scott Rosenbloom is chief strategist with WRQ
Inc.

“Các giải pháp cơng nghệ thơng tin an tồn, tích hợp đáp ứng được các yêu cầu
nghiệp vụ. Các giải pháp phải cài đặt, tối ưu và chỉ dẫn sự thực thi quy trình nghiệp
vụ bằng cách kết hợp tính năng của các dịch vụ riêng lẻ, đóng kín và có khả năng tái
sử dụng. SOA không nặng nề về việc phát triển ứng dụng phức tạp mà tập trung vào
việc chuẩn hoá giao diện giữa các thành phần dịch vụ với sự quản lý tập trung và cài
đặt phân tán”.Dave Morris, I.T. Security Lead TransAlta Corp
“SOA mơ hình hố nghiệp vụ như là một tập các dịch vụ tự chứa đựng (selfcontained) có hiệu lực giữa các tổ chức và có thể được gọi cả từ bên trong và bên

ngồi thơng qua các giao thức chuẩn.”. Dave McComb, president, Semantic Arts
“SOA không phải là cái gì khác ngồi kiến trúc hướng nghiệp vụ, cái mà cho
phép tính mềm dẻo của các ứng dụng nghiệp vụ, để trở thành độc lập nhưng cộng
tác, trong khi cung cấp các dịch vụ của chúng. Các ứng dụng dưới kiến trúc này
cùng một lúc có thể là trình khách và chủ với các dịch vụ tuỳ thích.” Satheesan
Kunnel, USWWI

14


Website: Email : Tel : 0918.775.368

“SOA là một hướng tiếp cận để thiết kế và tích hợp phần mềm theo một
phương pháp mơ đun trong đó, mỗi mơ đun là một “dịch vụ được kết nối lỏng lẻo”
có thể truy cập qua mạng và có khả năng tích hợp động với các dịch vụ khác trong
thời gian chạy. Một dịch vụ phải đưa ra một giao diện chuẩn (WSDL) cho tính năng
và các lời gọi các phương thức của nó.” Rajesh Dawar
“Các dịch vụ cung cấp một số chức năng cho những người biết cách yêu cầu
và tiêu thụ chúng mà không cần phải biết làm thế nào để tạo ra được chức năng ấy.
SOA là một cách tiếp cận để xây dựng các ứng dụng phần mềm như là các tập hợp
dịch vụ tự trị, tương tác không cần quan tâm tới nền tảng, cấu trúc dữ liệu hay các
thuật toán bên trong của các dịch vụ khác.” Michael Champion, R&D specialist, Software
AG

“SOA là một kiểu thiết kế cố gắng cho phép sự tích hợp dễ dàng và các ứng
dụng linh hoạt. Trong SOA, chức năng ứng dụng được thiết kế như là các dịch vụ có
khả năng tái sử dụng và chia sẻ. Một dịch vụ là một phần của chức năng ứng dụng
thể hiện chức năng của nó qua một giao diện trừu tượng, che giấu các phần việc bên
trong của sự cài đặt dịch vụ.”Anne Thomas Manes, analyst, Burton Group
“SOA là một kiến trúc cho quy mô doanh nghiệp (thường trải rộng nhiều ứng

dụng trong một doanh nghiệp hoặc nhiều doanh nghiệp) trong đó thành phần cấu
trúc chính là dịch vụ.
Một dịch vụ là một tập hợp các chức năng nghiệp vụ liên quan tới nhau tương
tác nội bộ hoặc từ xa sử dụng kiểu truyền thông truyền thông điệp / hướng tài liệu.
Một dịch vụ bao gồm một giao diện dịch vụ và một cài đặt dịch vụ cài đặt một hoặc
nhiều giao diện dịch vụ và gắn liền với một tập hợp tính năng nhất định. Các dịch vụ
cụ thể được xác định dưới dạng giao thức vận chuyển/ ứng dụng/ thông điệp, chứ
khơng phải dưới dạng một mơ hình lập trình cụ thể. SOA điển hình bao gồm các dịch
vụ kỹ thuật để quản lý siêu dữ liệu về các giao diện dịch vụ và các cài đặt, các nguồn
cung cấp và nguồn tiêu thụ dịch vụ; và các dịch vụ cho việc quản lý và bắt tuân theo
các chính sách, điều khiển truy cập, các tính năng bảo mật, các giao dịch, mặc dù tất
cả các dịch vụ này đều là tuỳ chọn trong một thể hiện SOA cụ thể.” Stefan Tilkov, CEO,
innoQ

“SOA là một quy tắc kiến trúc tập trung vào quan điểm cho rằng các tài sản
công nghệ thông tin được mô tả và thể hiện ra như là các dịch vụ. Các dịch vụ này có
thể được kết hợp theo một cách thức lỏng lẻo để tạo thành các quy trình nghiệp vụ ở
mức cao hơn, đem lại cho nghiệp vụ tính nhanh nhẹn trong sự khơng đồng nhất về
mặt công nghệ thông tin. “Ronald Schmelzer, analyst, ZapThink LLC
“SOA

là một cách tiếp cận để phát triển các ứng dụng phân tán liên kết không
chặt chẽ, độc lập giao thức tạo thành từ các tài nguyên phần mềm có tính hồn tồn
xác định, tự chứa đựng có khả năng truy cập như là các dịch vụ giữa các doanh
nghiệp được mở rộng theo một cách được chuẩn hoá nhằm tăng cường tính tái sử
dụng và liên thơng. ” Ankur Gupta, marketing manager, Fiorano Software Inc.
“SOA là một dạng của kiến trúc công nghệ gắn liền với các quy tắc của
hướng dịch vụ. Khi được cài đặt thông qua nền tảng công nghệ Web Service, SOA
tạo ra tiềm năng để hỗ trợ và thúc đẩy các quy tắc này trong tồn bộ quy trình
15

Website: Email : Tel : 0918.775.368

nghiệp vụ và các miền tự động hoá của một doanh nghiệp.”

Thomas Erl, chief architect,

XMLTC Consulting Inc

Nói tóm lại, SOA có thể được hiểu là một hướng tiếp cận để xây dựng các hệ
thống phân tán cung cấp chức năng ứng dụng dưới dạng các dịch vụ tới các ứng dụng
người dùng cuối hoặc các dịch vụ khác:
• SOA là một kiến trúc dùng các chuẩn mở để biểu diễn các thành phần
phần mềm như là các dịch vụ.
• Cung cấp một cách thức chuẩn hóa cho việc biểu diễn và tương tác với
các thành phần phần mềm.
• Các thành phần phần mềm riêng lẻ trở thành các khối cơ bản có thể sử
dụng lại để xây dựng các ứng dụng khác.
• Được sử dụng để tích hợp các ứng dụng bên trong và bên ngoài tổ
chức.
Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức
năng (mơ đun phần mềm) thực hiện quy trình nghiệp vụ nào đó. Các dịch vụ trong
SOA có các đặc điểm sau:
• Các dịch vụ là có thể tìm kiếm được.
• Các dịch vụ có tính liên thơng.
• Các dịch vụ khơng được gắn kết chặt chẽ với nhau.
• Các dịch vụ là phức hợp, bao gồm nhiều thành phần, được đóng gói ở
mức cao.
• Các dịch vụ trong suốt về vị trí.

• Các dịch vụ có khả năng tự hàn gắn.
Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối “mềm dẻo” với nhau
(nghĩa là một ứng dụng có khả năng giao tiếp với một ứng dụng khác mà không biết
các chi tiết kỹ thuật bên trong), có giao diện đượ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. 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 diện chuẩn để che giấu sự phức
tạp kỹ thuật bên dưới.
Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao diện gọi
dịch vụ. Điều này tạo nên một giao diện nhất quán cho ứng dụng sử dụng dịch vụ mà
không cần quan tâm tới cơng nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng
đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn hơn có thể triển khai
và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần
mềm tốt hơn, cũng như tăng sự mềm dẻo vì nhà phát triển có thể cải tiến dịch vụ mà
khơng làm ảnh hưởng đến ứng dụng sử dụng dịch vụ.

16


Website: Email : Tel : 0918.775.368

Triết lý SOA khơng hồn tồn mới, DCOM và CORBA cũng có kiến trúc
tương tự. Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví
dụ như các ứng dụng phân tán muốn làm việc với nhau phải được thỏa thuận về chi
tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay
đổi tương ứng đối với mã lệnh truy cập thành phần COM này.
Ưu điểm lớn nhất của SOA là khả năng kết nối mềm dẻo và tái sử dụng. Các
dịch vụ có thể được sử dụng trên nền tảng bất kỳ và đước viết với ngơn ngữ bất kỳ
(ví dụ, ứng dụng Java có thể liên kết với dịch vụ mạng .NET và ngược lại).
SOA dựa trên hai nguyên tắc thiết kế quan trọng:
• Mơ đun: tách vấn đề lớn thành nhiều vấn đề nhỏ

• Đóng gói: che giấu dữ liệu và logic trong từng mô đun đối với truy cập
từ bên ngoài
Một thiết kế kiến trúc phù hợp với khái niệm của SOA cần tuân theo những
tính chất sau:
• Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có
tính tự chứa đựng và mức độ đóng gói cao (coarse-grained).
• Một dịch vụ có thể dùng lại được, cho phép có thể xây dựng được một
dịch vụ mới từ các dịch vụ hiện có. Do đó, việc quan sát các hàm ý có
thể có của các thuộc tính phi chức năng như tính giao dịch là rất quan
trọng.
• Một giao diện dịch vụ là một điểm cuối mạng (network endpoint) đảm
bảo tính độc lập và trong suốt về vị trí.
• Một dịch vụ cần có khả năng được phát hiện ra một cách công khai
bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên kết
động tới dịch vụ.
• Một dịch vụ cần đảm bảo tính liên thơng bằng cách hỗ trợ các giao thức
truyền thơng được chuẩn hóa và các định dạng dữ liệu rõ ràng.
Các đặc điểm trên đảm bảo cho một kiến trúc hướng dịch vụ khả năng gắn kết
lỏng lẻo của các dịch vụ phân tán và có tính mơ đun bằng cách sử dụng các giao ước
dịch vụ để mô tả các định dạng thông điệp cần thiết.
2.2.2. Các thực thể trong kiến trúc hướng dịch vụ
Các thực thể trong kiến trúc hướng dịch vụ bao gồm:
• Dịch vụ (service).
• Thành phần sử dụng dịch vụ (service consumer/ client/ requester).
• Thành phần cung cấp dịch vụ (service provider).
17


Website: Email : Tel : 0918.775.368

• Thành phần đăng ký dịch vụ (service registry).
• Giao ước dịch vụ (contract).
• Ủy nhiệm dịch vụ.
• Ràng buộc sử dụng dịch vụ (service lease).
Dịch vụ:
Dịch vụ là một chức năng rõ ràng, tự chứa đựng và không phụ thuộc vào ngữ
cảnh hay trạng thái của các dịch vụ khác. Các thành phần sử dụng dịch vụ có thể truy
cập tới dịch vụ thông qua giao diện dịch vụ được xuất bản. Dịch vụ có các tính chất
sau:
• Dịch vụ có tính chất rõ ràng, là một đơn vị chức năng nghiệp vụ để có
thể được triệu gọi.
 Có khả năng triệu gọi thơng qua các giao thức truyền thơng
chung.
 Có tính liên thơng và vị trí trong suốt.
• Dịch vụ được định nghĩa bằng các giao diện tường minh.
 Các giao diện độc lập với cài đặt.
 Cung cấp giao ước giữa các thành phần cung cấp và sử dụng
dịch vụ
Dịch vụ là các mô đun phức tạp, bao gồm nhiều thành phần. Mức độ đóng gói
của dịch vụ càng cao thì dịch vụ càng có khả năng tái sử dụng và linh hoạt.
Thành phần sử dụng dịch vụ:
Thành phần sử dụng dịch vụ là một ứng dụng, một dịch vụ, hoặc một loại mơ
đun phần mềm khác có u cầu sử dụng dịch vụ. Đây là thực thể khởi tạo việc định
vị dịch vụ tại một kho đăng ký dịch vụ, liên kết tới dịch vụ qua một kênh truyền
thông và thực thi chức năng của dịch vụ. Thành phần này thực thi nhiệm vụ bằng
cách gửi tới dịch vụ một yêu cầu được định dạng theo đúng giao ước.
Thành phần cung cấp dịch vụ:
Thành phần cung cấp dịch vụ là một thực thể có khả năng được địa chỉ hóa
qua mạng, nó có thể chấp nhận và thực thi các yêu cầu từ những thành phần sử dụng
dịch vụ. Thành phần cung cấp dịch vụ có thể là một hệ thống máy tính lớn, một thành

phần, hoặc một loại hệ thống phần mềm khác có thể thực thi các yêu cầu dịch vụ.
Thực thể này xuất bản giao ước dịch vụ của nó trong một kho đăng ký dịch vụ để các
thành phần sử dụng dịch vụ có thể truy cập.
Thành phần đăng ký dịch vụ:

18


Website: Email : Tel : 0918.775.368

Thành phần đăng ký dịch vụ là một thư mục trên mạng có chứa các dịch vụ
sẵn dùng. Đây là một thực thể chấp nhận và lưu trữ các giao ước từ các thành phần
cung cấp dịch vụ và cung cấp các giao ước đó cho những thành phần sử dụng dịch
vụ.
Giao ước dịch vụ:
Một giao ước là một bản đặc tả cách thức để thành phần sử dụng dịch vụ có
thể tương tác với thành phần cung cấp dịch vụ. Nó chỉ ra khuôn dạng của thông điệp
yêu cầu và thông điệp đáp ứng từ dịch vụ. Giao ước dịch vụ có thể đòi hỏi một tập
các điều kiện tiên quyết và điều kiện sau. Các điều kiện này xác định trạng thái cần
thiết của dịch vụ để thực thi một chức năng cụ thể. Bản giao ước cũng có thể bao
gồm các mức độ chất lượng của dịch vụ, các đặc tả cho các khía cạnh phi chức năng
của dịch vụ.
Ủy nhiệm dịch vụ:
Thành phần cung cấp dịch vụ cung cấp một ủy nhiệm dịch vụ cho thành phần
sử dụng dịch vụ. Thành phần sử dụng dịch vụ thực thi yêu cầu bằng cách gọi một
hàm API trên nó. Ủy nhiệm dịch vụ (hình 1.9) sẽ tìm một giao ước và một tham chiếu
tới thành phần cung cấp dịch vụ trong nơi đăng ký. Sau đó, nó định dạng thơng điệp
u cầu và thực thi yêu cầu trên danh nghĩa của thành phần sử dụng dịch vụ. Ủy
nhiệm dịch vụ là một thực thể khơng bắt buộc, nó chỉ đơn giản hóa cho thành phần sử
dụng dịch vụ và thành phần sử dụng dịch vụ hồn tồn có thể viết phần mềm để truy

cập trực tiếp tới dịch vụ.
Một thành phần cung cấp dịch vụ sẽ cung cấp nhiều ủy nhiệm cho các môi
trường khác nhau, mỗi ủy nhiệm dịch vụ được viết bằng ngôn ngữ của thành phần sử
dụng dịch vụ. Ví dụ, một thành phần cung cấp dịch vụ có thể cung cấp các ủy nhiệm
cho Java, Visual Basic, Delphi nếu đó là các nền tảng của thành phần sử dụng dịch vụ
sử dụng dịch vụ. Mặc dù ủy nhiệm dịch vụ là khơng bắt buộc nhưng nó có thể cải
thiện một cách đáng kể hiệu năng và tính tiện dụng cho các thành phần sử dụng dịch
vụ.

Hình 1.9: Ủy nhiệm dịch vụ
19


Website: Email : Tel : 0918.775.368

Ràng buộc sử dụng dịch vụ:
Ràng buộc sử dụng dịch vụ mà thành phần đăng ký dịch vụ gán cho thành
phần sử dụng dịch vụ rất cần thiết để dịch vụ bảo trì được thông tin trạng thái liên kết
giữa thành phần sử dụng và thành phần cung cấp. Nó tạo ra sự gắn kết không chặt
chẽ giữa các thành phần này bằng cách giới hạn khoảng thời gian mà chúng được liên
kết với nhau. Khơng có ràng buộc, một thành phần sử dụng dịch vụ có thể liên kết
với một dịch vụ mãi mãi và không bao giờ liên kết lại với giao ước của nó.
Các thao tác trong kiến trúc hướng dịch vụ bao gồm:
Xuất bản dịch vụ: Để có thể truy cập được, một mô tả dịch vụ phải được xuất
bản để nó có thể được tìm thấy và triệu gọi bởi một người dùng dịch vụ.
Tìm kiếm dịch vụ: Một người yêu cầu dịch vụ định vị một dịch vụ bằng cách
yêu cầu nơi đăng ký dịch vụ một dịch vụ phù hợp với các tiêu chí đặt ra.
Liên kết và thực thi dịch vụ: Sau khi nhận được mô tả dịch vụ, người dùng sẽ
gọi dịch vụ theo các thơng tin mơ tả.
2.2.3. Lợi ích của kiến trúc hướng dịch vụ

Như đã trình bày trong phần mở đầu, các doanh nghiệp đang phải đối mặt với
hai vấn đề cơ bản: khả năng thay đổi một cách nhanh chóng, và yêu cầu giảm giá
thành sản phẩm. Với kiến trúc hướng dịch vụ, chúng ta có thể nhận thấy nhiều lợi ích
giúp các tổ chức thành cơng trong mơi trường kinh doanh hiện nay:
Thúc đẩy được các tài sản hiện có
SOA cung cấp một lớp trừu tượng cho phép một tổ chức tiếp tục thúc đẩy đầu
tư vào công nghệ thơng in bằng cách đóng gói những tài sản hiện có này thành những
dịch vụ cho các chức năng nghiệp vụ. Các tổ chức có thể tiếp tục thu được lợi nhuận
từ các tài ngun hiện có thay vì phải xây dựng lại chúng từ đầu.
Tích hợp và quản lý độ phức tạp dễ dàng hơn
Điểm tích hợp trong một kiến trúc hướng dịch vụ là đặc tả dịch vụ, không phải
là cài đặt dịch vụ. Điều này làm cho cài đặt được trong suốt và tổi thiểu hoá ảnh
hưởng khi thay đổi hạ tầng và cài đặt xảy ra. Bằng cách cung cấp một đặc tả dịch vụ
trước các tài nguyên và tài sản hiện có được xây dựng trên các hệ thống riêng biệt,
tích hợp trở nên dễ quản lý hơn vì độ phức tạp được cơ lập. Việc này thậm chí cịn trở
nên quan trọng hơn khi nhiều nghiệp vụ hơn hoạt động cùng nhau để tạo nên một dây
chuyền.
Nhạy bén hơn và thời gian tung ra thị trường nhanh hơn.
Khả năng tạo thành các dịch vụ mới từ những tài nguyên hiện có đem lại một
lợi ích khác biệt cho một tổ chức phải nhanh chóng đáp ứng được yêu cầu nghiệp vụ
thay đổi. Thúc đẩy các thành phần và dịch vụ hiện có làm giảm thời gian cần thiết để
đi qua vòng đời phát triển phần mềm gồm: thu thập yêu cầu, thực hiện thiết kế, phát
triển và kiểm thử. Việc này dẫn tới sự phát triển nhanh của các dịch vụ nghiệp vụ mới
20


Website: Email : Tel : 0918.775.368

và cho phép tổ chức nhanh chóng đáp ứng được các thay đổi và giảm thời gian cần
thiết để tung sản phẩm ra thị trường.

Giảm giá thành và tăng cường tái sử dụng:
Với các dịch vụ nghiệp vụ cốt lõi được thể hiện theo cách liên kết lỏng lẻo,
chúng có thể được sử dụng một cách dễ dàng hơn và có thể được kết hợp dựa trên các
yêu cầu nghiệp vụ; có nghĩa là giảm sự trùng lặp về tài nguyên, nâng cao tiềm năng
tái sử dụng và hạ giá thành sản phẩm.
SOA cho phép các doanh nghiệp sẵn sàng cho tương lai. Các quy trình nghiệp
vụ bao gồm hàng loạt các dịch vụ nghiệp vụ có thể được tạo ra, thay đổi và quản lý
một cách dễ dàng hơn để phù hợp với yêu cầu về thời gian. SOA đem lại tính linh
hoạt và nhạy bén cần thiết cho các tổ chức có thể tồn tại và phát triển.
Chuyển sang kiến trúc hướng dịch vụ không phải là một nhiệm vụ đơn giản.
Thay vì việc chuyển tồn bộ các chức năng nghiệp vụ của một doanh nghiệp thành
hướng dịch vụ, hướng tiếp cận được khuyến cáo là chỉ chuyển một tập con phù hợp
của chức năng nghiệp vụ khi doanh nghiệp phát sinh nhu cầu hoặc đoán trước được
các nhu cầu.
Kiến trúc hướng dịch vụ tạo ra một viễn cảnh và một cách suy nghĩ khác so
với các kiến trúc trước đây, nhưng kiến trúc hướng dịch vụ không phải là một sự thay
thế, mà chỉ là sự bổ sung cho các kiến trúc trước, cốt lõi của nó vẫn là kỹ thuật lập
trình hướng dịch vụ và hướng thành phần: kiến trúc hướng dịch vụ thích hợp cho tính
liên thơng giữa các môi trường thực thi khác nhau, bao gồm cả hướng đối tượng,
hướng thủ tục, và các hệ thống khác.
Khi sử dụng kiến trúc hướng dịch vụ, các hệ thống cơng nghệ thơng tin hiện
đang tồn tại có thể được xem như là các dịch vụ cung cấp các chức năng nghiệp vụ.
Các dịch vụ này có thể dễ dàng tích hợp với nhau vì chúng có các giao diện rõ ràng
và có thể truy cập nhờ việc sử dụng các chuẩn và các giao thức truyền thơng phổ
biến. Chính điều này đã đặt nền tảng cho việc tích hợp các dịch vụ thành những dịch
vụ mới phản ánh các quy trình nghiệp vụ.
2.3. Dịch vụ và thành phần
Thành phần là gì?
“Thành phần là một gói các tạo tác phần mềm có thể được phát triển một cách
độc lập và có thể được phân phối như là một đơn vị, các đơn vị này sau đó có thể kết

hợp với nhau để tạo thành một thứ gì đó lớn hơn “.

21


Website: Email : Tel : 0918.775.368

Hình 1.10: Thành phần

Dịch vụ là gì?
“Dịch vụ là một chức năng rõ ràng, tự chứa đựng và không phụ thuộc vào ngữ
cảnh hoặc trạng thái của các dịch vụ khác.”

Hình 1.11: Dịch vụ
Mối quan hệ giữa dịch vụ và thành phần:

Hình 1.12: Mối quan hệ giữa thành phần và dịch vụ
Dịch vụ là một đơn vị xử lý có mức độ đóng gói cao, nó dùng và sinh ra các
tập đối tượng được truyền theo kiểu tham trị. Dịch vụ không giống như đối tượng
trong ngơn ngữ lập trình, nó gần với khái niệm giao dịch kinh doanh hơn.
22


Website: Email : Tel : 0918.775.368

Một dịch vụ gồm một tập hợp các thành phần hoạt động cùng nhau để cung
cấp một chức năng nghiệp vụ. Vì vậy, có thể nói rằng thành phần có mức độ đóng gói
thấp hơn hơn dịch vụ. Ngồi ra, trong khi dịch vụ ánh xạ tới một chức năng nghiệp
vụ thì thành phần ánh xạ tới các thực thể nghiệp vụ và quy tắc nghiệp vụ thao tác trên
các thực thể đó. Ví dụ, xem xét mơ hình thành phần Đơn đặt mua hàng (Purchase

Order) cho ví dụ quản lý mạng lưới cung cấp trong hình sau:

Hình 1.13: Mơ hình thành phần đơn đặt mua hàng
Trong thiết kế hướng thành phần, các thành phần được tạo ra gần tương đương
với các thực thể nghiệp vụ (như Customer, Purchase Order, Oder Item) và đóng gói
hành vi phù hợp với các hành vi mà thực thể cần.
Ví dụ, thành phần Purchase Order cung cấp các hàm nhận thông tin về danh
sách các sản phẩm được đặt và tổng số lượng của đơn đặt hàng; thành phần Item
cung cấp các hàm để nhận được thông tin về số lượng và giá thành của sản phẩm
được đặt. Cài đặt của mỗi thành phần được đóng gói sau giao diện. Vì vậy, một
người dùng thành phần Purchase Order không biết về lược đồ bảng Purchase Order
và thuật tốn tính thuế, số tiền được giảm trên tổng số đơn đặt hàng.
Trong thiết kế hướng dịch vụ, các dịch vụ được thiết kế không dựa trên các
thực thể nghiệp vụ, thay vào đó, mỗi dịch vụ là một khối quản lý các thao tác trên
một tập các thực thể nghiệp vụ. Ví dụ, dịch vụ Customer sẽ trả lời bất kỳ yêu cầu nào
từ hệ thống hoặc dịch vụ khác cần truy cập tới thông tin khách hàng. Dịch vụ
Customer có thể xử lý một yêu cầu cập nhật thơng tin khách hàng, thêm, cập nhật,
xố các danh mục đầu tư, và điều tra về lịch sử đặt hàng của Customer. Dịch vụ
Customer chứa tất cả các dữ liệu liên quan tới khách hàng mà nó đang quản lý và có
khả năng tạo ra các yêu cầu dịch vụ với danh nghĩa là người dùng dịch vụ để cung
cấp một khung nhìn dịch vụ khách hàng thống nhất. Điều này có nghĩa là một dịch vụ
là một đối tượng quản lý tạo ra và quản lý tập các thành phần của nó.
Kiến trúc hướng dịch vụ và phát triển hướng thành phần
Ở rất nhiều khía cạnh, SOA là một sự phát triển các nguyên lý cơ bản của phát
triển hướng thành phần (CBD – Component-based Development). Nó cũng biểu diễn
một bước phát triển trong việc đem các nghiệp vụ và cơng nghệ thơng tin xích lại gần
nhau hơn. Trong khi các dịch vụ SOA là hữu hình đối với người dùng dịch vụ, các
23

Website: Email : Tel : 0918.775.368

thành phần nền tảng của chúng là trong suốt. Đối với người cung cấp dịch vụ, thiết kế
của các thành phần, sự thể hiện và quản lý dịch vụ phản ánh các quyết định thiết kế
và kiến trúc chính cho phép phát triển dịch vụ trong SOA. Việc ra những quyết định
đó địi hỏi một sự hiểu biết về các thành phần của SOA và mơ hình hóa SOA để nhận
diện, phân loại, xác định và cấu trúc các thành phần của dịch vụ.
Sự phát triển của SOA bắt nguồn từ phát triển hướng đối tượng và hướng
thành phần. Thế giới của các đối tượng bắt đầu với sự xuất hiện của các ngơn ngữ lập
trình hướng đối tượng và được phát triển thành mơ hình, sau đó, nó được thêm vào
các kỹ thuật thiết kế và các phương pháp phân tích thiết kế hướng đối tượng. Các
dịch vụ hạ tầng, các công cụ, các nền tảng phát triển, các mẫu, và các kiến trúc tham
chiếu xuất hiện sau đó.
Phát triển hướng thành phần đã tạo ra một hướng tiếp cận mới trong việc thiết
kế, xây dựng, cài đặt và phát triển của các ứng dụng phần mềm. Các ứng dụng được
lắp ráp từ các thành phần từ nhiều nguồn khác nhau, các thành phần được viết trên
nhiều ngơn ngữ lập trình khác nhau, nhiều môi trường khác nhau, và chạy trên các
nền tảng khác nhau. Nhưng chỉ với phát triển hướng đối tượng, các dịch vụ hạ tầng,
các công cụ, nền tảng phát triển và các mẫu mới làm cho phát triển hướng thành phần
trở thành hiện thực.
Cả hướng đối tượng và hướng thành phần đều yêu cầu tính tái sử dụng trong
phát triển phần mềm. Với phát triển hướng đối tượng thì đó một yếu tố tùy chọn, cịn
với phát triển hướng thành phần là bắt buộc. Phát triển hướng dịch vụ đem lại khả
năng tái sử dụng lớn hơn so với phát triển hướng đối tượng. SOA, với nền tảng là cả
phát triển hướng đối tượng và hướng thành phần, còn tạo ra khả năng tái sử dụng cao
hơn nữa. nó đã trở thành một nhân tố mới để đạt được kinh tế trong công nghệ phần
mềm.
Các khái niệm và quy tắc của phát triển hướng đối tượng và hướng thành phần
được áp dụng để đem lại các framework thích hợp cho việc chỉ đạo thiết kế và phát
triển các dịch vụ SOA.

Rất nhiều các nhà cung cấp dịch vụ thường cài đặt một mô tả dịch vụ. Trong
các thành phần, chúng ta có thể tìm thấy các quy tắc thiết kế của hướng đối tượng xác
định các cấu trúc trong của thành phần. Do vậy, mơ hình hóa dịch vụ là nhằm xác
định đúng các dịch vụ, tổ chức chúng theo một cây phân cấp của các dịch vụ phức
hợp (các thành phần có mức độ đóng gói thấp hỗ trợ các thành phần có mức độ đóng
gói cao), sắp xếp chúng để hỗ trợ cho một quy trình nghiệp vụ. Về phía nhà cung cấp,
các dịch vụ này hoặc là được cấp phát một cách trực tiếp cho các thành phần chứa
hướng thành phần để cài đặt các chức năng của chúng, hoặc được cài đặt bằng cách
thay đổi các chức năng sẵn có.
Đây là bước tiến cơ bản trong công nghệ phần mềm hướng dịch vụ: thành
phần sử dụng dịch vụ không cần phải quan tâm về việc cài đặt hay hiện thực hóa của
dịch vụ, miễn là nó hỗ trợ các chức năng và chất lượng theo đúng yêu cầu của dịch
vụ. Đây được gọi là khung nhìn của thành phần sử dụng (Consumer View). Bên cạnh
đó, khung nhìn của thành phần cung cấp đưa ra một triển vọng về cách thiết kế cài
đặt của thành phần cung cấp dịch vụ; các quyết định và thiết kế kiến trúc của nó.
24


Website: Email : Tel : 0918.775.368

Một sự khác biệt chính với hướng đối tượng truyền thống là chúng ta khơng
cịn phải tạo ra các mơ hình đối tượng lớn, mà chỉ cần tạo ra các thiết kế bên trong
của các ranh giới thành phần có mức độ đóng gói cao hơn, thơng qua hướng đối
tượng có mức độ đóng gói thấp hơn.
Các thành phần cung cấp dịch vụ không cần quan tâm tới các thành phần sử
dụng dịch vụ, chỉ cần các giao ước sử dụng dịch vụ của chúng được thỏa mãn. Thành
phần cung cấp dịch vụ cần thiết kế một cài đặt dịch vụ thỏa mãn các u cầu đó
thơng qua các quyết định về việc chúng chứa đựng, quản lý và cài đặt đặc tả dịch vụ
như thế nào. Khung nhìn bên trong là khung nhìn của người sử dụng hoặc thành phần
sử dụng – tức là những thành phần chỉ nhìn thấy dịch vụ thơng qua thành phần cung

cấp, và khung nhìn ngồi, ở đó thành phần cung cấp dịch vụ tạo ra các dịch vụ thông
qua các giao diện của chúng. Để thực hiện được như vậy, chúng yêu cầu một tập
trong gồm các thành phần có mức độ đóng gói thấp hơn, hoặc ngang bằng tham gia
vào các cộng tác cần thiết để đáp ứng các dịch vụ. Do vậy, trong các thành phần cung
cấp dịch vụ, chúng ta sẽ có các thành phần ở mức độ miền tương ứng với các mơ
hình đối tượng miền trong hướng đối tượng truyền thống và được cài đặt thông qua
các cơ chế chứa đựng thành phần chuẩn hóa như các máy chủ ứng dụng (Application
server).

3. Thiết kế theo kiến trúc hướng dịch vụ
Trong sự tiến hóa của các các kỹ thuật xây dựng phần mềm, kỹ thuật lập trình
hướng đối tượng thích hợp để cài đặt các thành phần. Trong khi các thành phần lại là
cách thích hợp nhất để cài đặt các dịch vụ, mặc dù cần hiểu rằng một ứng dụng dựa
thành phần tốt không cần thiết phải là một ứng dụng hướng dịch vụ tốt. Khi vai trò
của dịch vụ trong kiến trúc ứng dụng được hiểu rõ, chúng ta có thể tích hợp các thành
phần mới và các thành phần hiện có. Hình 1.14 minh hoạ cách các tầng cơng nghệ có
thể được áp dụng cho kiến trúc ứng dụng để đem lại các cài đặt ở mức độ đóng gói
cao hơn khi tiến gần hơn tới người dùng ứng dụng, nó cũng cho thấy dịch vụ là cách
thích hợp để thể hiện khung nhìn ngồi của một hệ thống với sự tái sử dụng bên trong
có sử dụng thiết kế thành phần truyền thống.

Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng, thành phần, dịch vụ

25