MỤC LỤC
MỤC LỤC............................................................................................................... 1
KẾT LUẬN..........................................................................................83.................1
MỞ ĐẦU................................................................................................................ 2
DANH MỤC CÁC TỪ VIẾT TẮT............................................................................4
DANH MỤC CÁC HÌNH VẼ.................................................................................... 4
CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ.....................................5
1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin.........................................................5
2. Kiến trúc hướng dịch vụ - một giải pháp.........................................................................................................7
2.1. Sự tiến hóa của lý thuyết phát triển phần mềm........................................................................................7
2.2 Kiến trúc hướng dịch vụ.........................................................................................................................10
2.3. Dịch vụ và thành phần...........................................................................................................................18
3. Thiết kế theo kiến trúc hướng dịch vụ...........................................................................................................22
4. Các công nghệ hướng dịch vụ..........................................................................................................................35
4.1. Sun JINI.................................................................................................................................................35
4.2. Openwings.............................................................................................................................................36
4.3. Dịch vụ Web..........................................................................................................................................39
4.4. Enterprise Service Bus (ESB)................................................................................................................40
5. Kết luận chương:...............................................................................................................................................41

CHƯƠNG II. CÔNG NGHỆ DỊCH VỤ WEB.........................................................43
1. Kiến trúc dịch vụ Web......................................................................................................................................44
2. Các chuẩn cho dịch vụ Web.............................................................................................................................45
2.1. Ngôn ngữ mô tả dịch vụ Web WSDL....................................................................................................45
2.2. Giao thức truy cập đối tượng đơn giản SOAP.......................................................................................48
2.3. Đặc tả mô tả và tích hợp tìm kiếm UDDI..............................................................................................53
3. Các kiểu liên kết trong dịch vụ Web..............................................................................................................57
3.1 Liên kết tĩnh............................................................................................................................................57
3.2. Liên kết động trong thời gian xây dựng.................................................................................................58
3.3. Liên kết động trong thời gian chạy........................................................................................................60
5. Xây dựng dịch vụ Web.....................................................................................................................................61

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
Trang 2


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 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 soát. Vậy làm thế nào chúng ta có thế giải quyết vấn đề này?


DANH MỤC CÁC TỪ VIẾT TẮT
DANH MỤC CÁC HÌNH VẼ

Trang 4


CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG
DỊCH VỤ
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 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


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 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 có một dịch vụ khác
có chất lượng tốt hơn tồn tại.
Trang 6


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ề SOA cũng như bản chất những khái niệm tạo nên
SOA, chúng ta cần phải hiểu về lịch sử phát triển của SOA 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ế

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ụ
Web 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.

Trang 8


Hình 1.6: Phát triển phần mềm hướng dịch vụ
Như vậy, theo thời gian, 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ầ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 toá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 toá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ã bằng
các phương pháp như kế thừa, kết tập, 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
Trang 9

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

Rất thấp

Thấp

Trung bình

Cao

Xác định

Riêng tư /Công
khai

Công khai

Xuất bản

Thấp

Thấp

Trung bình

Cao

Độ gắn kết



Hình 1.7: Kiến trúc phần mềm theo định nghĩa cổ điển
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.
Trang 10


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.
“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 Web Service có khả năng tái sử dụng. Trong khi Web
Service 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 hoá 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 toà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 hoá 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
ngoà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 ngoài kiến trúc hướng nghiệp vụ, cái mà cho
phép tính linh hoạt của các ứng dụng nghiệp vụ, để trở thành độc lập nhưng cộng
Trang 11

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
Trang 12


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
hoàn toà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 toàn bộ quy trình
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

ứ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ự linh hoạt 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ụ.
Thật ra, triết lý SOA không hoàn toà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 quan trọng 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ụ web .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ừ 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ụ.

 Cung cấp giao kèo 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ó yê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 kèo.
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
Trang 15


vụ. Thực thể này xuất bản giao kèo 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ụ:
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 kèo từ các thành phần
cung cấp dịch vụ và cung cấp các giao kèo đó cho những thành phần sử dụng dịch
vụ.
Giao kèo dịch vụ:
Một giao kèo 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 kèo 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

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 kèo 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 nguyên 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ả
Trang 17


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.


Trang 18


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.
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ụ. Ngoà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ụ
Trang 19


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.

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ó thêm vào
các kỹ thuật 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 theo 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 và 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. SOA 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

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, công nghệ và
các ngôn ngữ 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 dưới đây 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 ngoà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.

Trang 22


Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng dịch vụ, thành phần
Các nguyên tắc trong thiết kế SOA
Việc tiếp cận xây dựng các hệ thống dựa trên mô hình hướng dịch vụ phải
tuân theo bốn nguyên tắc sau :
Nguyên tắc 1 : ranh giới phải rõ ràng. Các dịch vụ tương tác qua việc truyền
đi các thông điệp tường minh. Chúng ta không cần biết về không gian nằm sau ranh
giới của dịch vụ. Vượt qua các ranh giới của dịch vụ có thể tốn nhiều công sức và
chi phí. Các ranh giới rõ ràng cho phép cài đặt các tương tác độc lập – không cần
biết về nền tảng hay các ngôn ngữ lập trình được lựa chọn để cài đặt các dịch vụ.
Nguyên tắc 2: Dịch vụ là tự trị. Các dịch vụ hoạt động như là các thực thể
độc lập. Không có quyền làm chủ trong một môi trường hướng dịch vụ. Các dịch vụ
được triển khai, thay đổi, quản lý một cách độc lâp.
Nguyên tắc 3 : Các dịch vụ chia sẻ lược đồ (schema) và giao kèo(contract),

các thay đổi trong các dịch vụ kỹ thuật có mức độ đóng gói thấp hơn
(các dịch vụ này thường có xu hướng thay đổi thường xuyên hơn so
với các nghiệp vụ ở mức cao hơn). Các nhân tố của tính mềm dẻo sẽ
là các tiêu chuẩn chính cho việc đóng gói hơn là việc chỉ đơn thuần
đóng gói chức năng.
• Tính gắn kết không chặt chẽ và cấu hình lại động là một quyết định
thiết kế yêu cầu việc tách các giao diện khỏi cài đặt và cài đặt giao
thức thông qua các chuẩn mở. Kết nối giữa các thành phần cung cấp
và sử dụng dịch vụ cần phải bền vững và được cấu trúc rõ ràng, có
khả năng cấu hình lại linh hoạt. Có khả năng cấu hình lại có nghĩa
lấcc thành phần sử dụng dịch vụ và các thành phần cung cấp dịch vụ
hiện có có thể được lắp ghép lại với chức năng không bị thay đổi để
đạt được các giải pháp nghiệp vụ trong các môi trường kỹ thuật khác
nhau và với các ràng buộc thao tác khác nhau của các đối tác kinh
doanh mới.
• Các tầng SOA: Các thành phần của một kiến trúc hướng dịch vụ.
Các thành phần chính của một kiến trúc hướng dịch vụ là:
• Danh mục dịch vụ: mô tả các dịch vụ nghiệp vụ trong SOA, bao gồm
một danh sách, phân loại và cấu trúc cây của các dịch vụ được xác
định thông qua kx thuật phân tích và thiết kế hướng dịch vụ.
• Các thành phần: Cung cấp các cài đặt chức năng của dịch vụ.
• Thành phần sử dụng dịch vụ, thành phần cung cấp dịch vụ và thành
phần môi giới dịch vụ (tùy chọn) với các kho đăng ký dịch vụ, ở đó,
các định nghĩa và mô tả dịch vụ được xuất bản.
• Các tầng SOA: vị trí của các thành phần và dịch vụ.
Trang 24


Hình dưới đây mô tả các tầng SOA. Với mỗi tầng, các quyết định thiết kế và
kiến trúc được tiến hành.