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 Giải nghĩa
1. CBD
Phát triển hướng thành phần
Component-Based Development
2. CORBA
Kiến trúc môi giới yêu cầu đối tượng chung
Common Object Request Broker Architecture
3. DCOM
Mô hình đối tượng thành phần phân tán
Distributed Component Object Model
4. IDL
Ngôn ngữ đặc tả giao diện
Interface Description Language
5. JINI
Hạ tầng mạng thông minh cho Java
Java Intelligent Network Infrastructure
6. JMS
Dịch vụ thông điệp Java
Java Message Service
7. HTTP
Giao thức truyền siêu văn bản
HyperText Transfer Protocol
8. NASSL
Ngôn ngữ đặc tả dịch vụ có khả năng truy cập qua mạng
Network Accessible Service Specification Language
9. RMI
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
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
• 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
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
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 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ã, 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ể hoà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
Thời gian biên
dịch
Thời gian biên
dịch
Thời gian
chạy
Phạm vi
truyền thông
Nội bộ ứng
dụng
Nội bộ ứng
dụng
Nội bộ ứng
dụng
Giữa các cô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 toá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 ngoà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
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 hoàn toàn
• 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 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 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:
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ó 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 ướ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ụ
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 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ả 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ở
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ụ. Ngoài ra, trong khi dịch vụ ánh xạ tới một chức năng nghiệp
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
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 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.
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
Copyright: Tài liệu đại học ©