Tải bản đầy đủ (.docx) (25 trang)

Tìm hiểu về mô hình phát triển phần mềm hướng dịch vụ, nêu kiến trúc, cách thức hoạt động và lợi ích của việc phát triển phần mềm hướng dịch vụ

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (326.79 KB, 25 trang )

TRƯỜNG ĐẠI HỌC NÔNG NGHIỆP HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN

BÀI TẬP LỚN MÔN
Công nghệ phần mềm
Đề tài: Tìm hiểu về mô hình phát triển phần mềm hướng dịch vụ, nêu kiến trúc,
cách thức hoạt động và lợi ích của việc phát triển phần mềm hướng dịch vụ.

Giáo viên hướng dẫn:

Phạm Thủy Vân

Nhóm 2

Hà Nội, tháng 11/2013
1


Mục lục

Lời mở đầu
Sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác, làm việc qua mạng
và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộc
sống của chúng ta. Điều đó đòi hỏi các ứng dụng không chỉ là những hệ thống hoạt
động đơn lẻ trên một máy trạm (máy client) và chịu phụ thuộc vào một nền tảng cố
định nào nữa, mà chúng phải là những hệ thống linh động giúp người dùng làm
việc “mọi lúc, mọi nơi”. Điều đó đã làm nhà phát triển phải đối mặt với hàng loạt
các vấn đề mới như làm sao tích hợp các thành phần phân tán lại với nhau; hay tái
sử dụng những thành phần có sẵn; vấn đề triển khai và bảo trì, … đang là một vấn
đề làm điên đầu các nhà phát triển.
Các ứng dụng khi sử dụng dịch vụ này chỉ cần gửi thong điệp yêu cầu đến


một dịch vụ (server) khác và chờ nhận kết quả từ dịch vụ đó và dịch vụ này không
phụ thuộc vào môi trường hệ điều hành, ví dụ như Web hiện nay chẳng hạn, có thể
hiện rất rõ ý tưởng này. Công nghệ SOA giúp chúng ta trong việc phát triển các
services này rất hiệu quả. Hiện nay nhiều công ty phần mềm lớn trên thế giới đều
quan tâm phát triển hệ thống này ví dụ như: Oracle, IBM, Microsoft… Mong muốn
tìm hiểu một cách khái quát về công nghệ SOA và những lợi ích đạt được của kiến
trúc này chính là lý do chúng tôi lựa chọn đề tài: “Tìm hiểu về mô hình phát triển
phần mềm hướng dịch vụ, nêu kiến trúc, cách thức hoạt động và lợi ích của việc
phát triển phần mềm hướng dịch vụ.”
2


Trong quá trình tìm hiểu đề tài và biên soạn tài liệu không thể tránh khỏi
những thiếu sót nhất định, rất mong nhận được sự đóng góp ý kiến của quý thầy cô
và các bạn để đề tài thêm hoàn thiện.

I.TỔNG QUAN VỀ MÔ HÌNH HƯỚNG DỊCH VỤ
1.1. Khái niệm về mô hình hướng dịch vụ
SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là
một cách tiếp cận hay một phương pháp luận để thiết kế và tích hợp các thành phần
khác nhau, bao gồm các phần mềm và các chức năng riêng lẻ lại thành một hệ
thống hoàn chỉnh. Kiến trúc SOA rất giống như cấu trúc của các phần mềm hướng
đối tượng gồm nhiều module. Tuy nhiên khái niệm module trong SOA không đơn
thuần là một gói phần mềm, hay một bộ thư viện nào đó. Thay vào đó, mỗi module
trong một ứng dụng SOA là một dịch vụ được cung cấp rải rác ở nhiều nơi khác
nhau và có thể truy cập thông qua môi trường mạng. Nói một cách ngắn gọn, một
hệ thống SOA là một tập hợp nhiều dịch vụ được cung cấp trên mạng, được tích
hợp lại với nhau để cùng cộng tác thực hiện các tác vụ nào đấy theo yêu cầu của
người dùng.
Một trong những cách hiểu sai lầm nhất về SOA là coi SOA là một công

nghệ. Mặc dù SOA hoạt động được là nhờ công nghệ, nhưng khách hàng cần phải
chuyển đổi từ chỗ chỉ việc tích hợp công nghệ SOA sang việc phải điều chỉnh các
phương pháp thực hiện dự án, chính sách bảo trì và thay đổi để đạt được các lợi ích
về khả năng trưởng thành và đáp ứng.
Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là một loại
module thực hiện một quy trình nghiệp vụ nào đó. Một trong những mục đích của
3


SOA là giúp các ứng dụng có thể 'nói chuyện' với nhau mà không cần biết các chi
tiết kỹ thuật bên trong. Để thực hiện điều đó SOA định ra một chuẩn giao tiếp
(dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ
thống, và có thể tái sử dụng. Như vậy, SOA là cấp độ cao hơn của phát triển ứng
dụng, chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự
phức tạp kỹ thuật bên dưới. Sự trừu tượng là cốt lõi của khái niệm dịch vụ, nó giúp
cho các doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng
mới và các thành phần này có thể được chia sẻ hoặc tái sử dụng trong nhiều lĩnh
vực khác nhau của công ty đó mà không cần phải chỉnh sửa mã nguồn hay phải tái
cấu trúc lại hệ thống.
Có nhiều cách khác nhau để kết nối các dịch vụ, chẳng hạn dùng các giao
thức mạng có sẵn, hoặc tạo một giao thức riêng. Nhưng từ năm 2001, các dịch vụ
web (Web service) được xây dựng dựa trên nền tảng web toàn cầu, bất cứ nơi nào
cũng có, đã trở thành một phương pháp phổ biến cho việc kết nối các thành phần
của hệ thống SOA với nhau. Thoạt nhìn SOA và dịch vụ web trông có vẻ giống
nhau nhưng chúng không phải là một. Chúng ta sẽ tìm hiểu rõ hơn về các dịch vụ
web trong các phần tiếp theo.

Hình 1.1 – Mô hình cơ bản của SOA.

1.2. Tính chất của hệ thống SOA

+) Liên kết lỏng (Loose coupling)
4


Vấn đề kết nối ám chỉ các ràng buộc giữa một số module với nhau. Có hai
loại kết nối là rời (loose) và chặt (tigh). Các modul có tính loose coupling có một
số ràng buộc được mô tả rõ ràng, trong khi các modul có tính tigh coupling thì lại
có một số ràng buộc được mô tả rõ ràng, trong khi các modul có tính tigh coupling
thì lại có một số ràng buộc không được biết trước. Hầu hết các phần mềm đều
hướng đến tính loose coupling.
SOA sử dụng loose coupling thông qua việc sử dụng hợp đồng và liên kết
(contract and binding). Một người sự dụng truy vấn đến nơi lưu trữ và cung cấp
thông tin dịch vụ (Registry) để lấy thông tin về loại dịch vụ cần sử dụng. Registry
sẽ trả về mọi dịch vụ thỏa mãn tiêu chuẩn tìm kiếm. Từ đó người dùng chỉ việc
chọn dịch vụ mình cần, thực thi phương thức trên đó theo mô tả để nhận dịch vụ từ
Registry.Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào tin cài đặt của
dịch vụ mà chỉ dựa trên hợp đồng dịch vụ đó hỗ trợ.
Tính loose coupling giúp bỏ những ràng buộc điều khiển giữa những hệ
thống đầu cuối. Mỗi hệ thống có thể tự quản lý độc lập làm tăng hiệu suất, khả
năng mở rộng và khả năng đáp ứng cao. Loose coupling làm tách biệt giữa bên
cung cấp và bên sử dụng, nhưng nó đòi hỏi các interface phải theo một chuẩn và
cần một thành phần trung gian quản lý để trung chuyển yêu cầu giữa các hệ thống
đầu cuối.
+) Tái sử dụng dịch vụ
Những dịch vụ được dùng chung bởi tất cả các ứng dụng của một hệ thống SOA
gọi là shared infrastructure service. Tái sử dụng dịch vụ loại bỏ phần trùng lặp,
tăng độ vững chắc trong cài đặt và đơn giản hóa việc quản trị.
+) Sử dụng dịch vụ bất đồng bộ

5



Phương thức triệu gọi là bất đồng bộ như sau: bên gọi gửi một thông điệp
với đầy đủ thông tin ngữ cảnh tới bên nhận. Bên nhận xử lý thông tin trả về kết quả
cho bên gọi thông qua một kênh thông điêp. Bên gọi không phải chờ cho đến khi
thông điệp được xử lí xong.
Phương thức đồng bộ: Trên lý thuyết, SOA có thể sử dụng cả phương thức
đồng bộ và bất đồng bộ.
+) Quản lý các Policy
Khi sử dụng các dịch vụ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật
kết hợp riêng gọi là các Policy. Việc quản lý các Policy tăng khả năng tạo ra các
đặc tính tái sử dụng dịch vụ vì các Policy được thiết kế tách biệt và tùy vào mỗi
ứng dụng nên giảm tối đa các thay đổi phần mềm đồng thời có thể chia các nhóm
làm việc mà không cần phụ thuộc vào nhau (nhóm phát triển phần mềm và nhóm
điều hành, nhóm hỗ trợ).
+) Coarse granularity
Khái niệm Granularity trong dịch vụ có thể hiểu theo 2 cách: trong phạm vị
toàn bộ kiến trúc của dịch vụ hoặc trong phạm vi từng phương thức của từng
interface triển khai. Mức độ granularity cũng có hai loại: coarse – grained(ví dụ
dịch vụ cài đặt tất cả các chức năng của một ngân hàng) và fined- grained(ví dụ
như dịch vụ chỉ hỗ trợ chức năng rút tiền tự động…) Một hệ thống có chứa các đối
tượng fined – grained thì phức tạp hơn là hệ thống coarse- grained.
+) Khả năng cộng tác (interoperability)
SOA nhấn mạnh đến khả năng cộng tác, khả năng mà các hệ thống khác
nhau có thể giao tiếp trên nhiều nền tảng ngôn ngữ khác nhau. Mỗi dịch vụ cung
cấp một interface có thể được triệu gọi thông qua một dạng kết nối. Một kết nối gọi
6


là interperable chứa trong nó một giao thức và một định dạng dữ liệu mà mỗi client

kết nối đến nó đều hiểu. Interoperability đạt được bằng cách hỗ trợ các giao thức
và định dạng dữ liệu chuẩn của dịch vụ và client hệ thống ánh xạ mỗi tính chất và
ngôn ngữ qua một đặc tả trung gian. Đặc tả này sẽ chịu trách nhiệm ánh xạ giữa
định dạng dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào hệ
thống. Ví dụ Web Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống
JAX – RPC, JAXM chuyển các đối tượng dạng Java thành Soap.
+) Tự động dò tìm và ràng buộc động
SOA hỗ trợ khái niệm dò tìm dịch vụ (Service discovery). Một người sử
dụng cần một dịch vụ nào đó có thể tìm kiếm dịch vụ theo những tiêu chuẩn khi
cần. Người sử dụng dịch vụ chỉ cần hỏi một Registry về dịch vụ thỏa mãn yêu cầu
của họ.
Ví dụ, một hệ thống chuyển khoản (Cónumer) yêu cầu Registry tìm kiếm tất
cả các dịch vụ có khả năng kiểm tra thẻ tín dụng. Registry trả về một tập các thông
ti thỏa dụng sẽ chọn một dịch vụ có chi phí thấp và kết nối đến nhà cung cấp dịch
vụ đó dựa trên thông tin của entry mà registry tìm được để yêu cầu sử dụng dịch vụ
kiểm tra thẻ tín dụng. Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số
cần thiết để thực thi dịch vụ. Bên sử dụng chỉ cần định dạng dữ liệu cần thiết theo
mô tả của nhà cung cấp dịch vụ và gửi đi. Nhà cung cấp sẽ thực thi kiểm tra thẻ tín
dụng và trả về kết quả là một thông điệp theo đúng định dạng như trong phần mô tả
dịch vụ. Mối ràng buộc duy nhất giữa nhà cung cấp và người sử dụng là bản hợp
đồng được cung cấp bởi Registry trung gian. Mối ràng buộc trong thời gian chạy
chứ không phải là ràng buộc trong thời gian biên dịch. Tất cả các thông tin cần
thiết về dịch vụ được lấy về và sử dụng trong khi chạy.

7


Với SOA, bên sử dụng không cần biết định dạng của thông điệp yêu cầu
cũng như thông điệp trả về, hay địa chỉ dịch vụ khi gọi đến. Bên sử dụng triệu gọi
một cách động.

+) Tự hồi phục(Self- healing)
Một hệ thống tự hồi phục là một hệ thống có khả năng tự hồi phục sau khi bị
lỗi mà không cần đến sự can thiệp của con người.
Độ tin cậy là mức độ đo khả năng một hệ thống xử lý tốt như thế nào trong
tình trạng hỗn loạn. Trong SOA, mỗi dịch vụ có khả năng hoạt động hoặc ngừng
bất cứ lúc nào, nhất là những ứng dụng tổ hợp của nhiều dịch vụ thuộc nhiều tổ
chức khác nhau. Độ tin cậyphụ thuộc vào khả năng phục hồi của phần cứng sau khi
gặp lỗi.
1.3. Nguyên tắc của hệ thống SOA
Một hệ thống SOA phải đảm bảo đủ 4 nguyên tắc chính sau đây:
-

Sự phân định rạch ròi giữa các dịch vụ:Do có sự tách biệt giữa các thành
phần giao tiếp và thành phần thực hiện dịch vụ trong kiến trúc hướng dịch
vụ.

-



Các dịch vụ này sẽ thực hiện qua quá trình tương tác chủ yếu thông



qua thành phần giao tiếp.
Thành phần này sẽ quy định những dạng thông điệp trong quá trình



trao đổi:

Thông điệp duy nhất để các đối tượng bên ngoài có thể truy cập vào



thông tin và chức năng của dịch vụ,
Ta chỉ cần gửi thông điệp được định dạng đến trước để yêu cầu dịch

vụ mà không cần biết thông điệp đó sẽ được xử lý như thế nào.
Các dịch vụ tự hoạt động
 Các dịch vụ cần được triển khai và hoạt động như một thực thể độc
lập mà không phụ thuộc vào các dịch vụ khác.
8




Dịch vụ phải có tính bền vững cao, nghĩa là nó không bị sụp đổ khi có



sự cố.
Để thực hiện điều này, các dịch vụ cần duy trì đầy đủ thông tin cần
thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động
trong trường hợp dịch vụ cộng tác của nó bị hỏng, đồng thời sử dụng
các biện pháp bảo mật để tránh các cuộc tấn công ồ ạt từ bên ngoài

-

vào như gửi thông điệp lỗi hoặc thông điệp ồ ạt.
Các dịch vụ chia sẻ lược đồ

 Các dịch vụ nên cung cấp thành phần giao tiếp(Interface) của nó ra


-

bên ngoài
Hỗ trợ chia sẻ cấu trúc thông tin, các rang buộc dữ liệu thông qua các

lược đồ dữ liệu chuẩn.
 Hệ thống sẽ có tính dễ liên kết và dễ dàng mở rộng.
Tính tương thích của các dịch vụ dựa trên chính sách
• Một dịch vụ muốn tương tác với các dịch vụ khác thì thỏa mãn các


chính sách, các yêu cầu của dịch vụ đó như: mã hóa, bảo mật.
-> Để thực hiện điều này,mỗi dịch vụ phải cung cấp công khai chính
sách và các yêu cầu bảo mật của mình.

II. KIẾN TRÚC CỦA MÔ HÌNH HƯỚNG DỊCH VỤ
Kiến trúc hướng dịch vụ (Service Oriented Architecture) là một hướng tiếp
cận với việc thiết kế và tích hợp các phần mềm, chức năng hệ thống theo dạng
module, trong đó mỗi module đóng vai trò là một “dịch vụ có tính loose coupling”
và có khả năng truy cập thông qua môi trường mạng. Một cách đơn giản thì một hệ
thống SOA là tập hợp các dịch vụ được chuẩn hóa trên mạng, trao đổi với nhau
trong ngữ cảnh một tiến trình nghiệp vụ.

9


2.1.Kiến trúc tổng quan của SOA

Service
Registry
Fin Register
Service Bind, Service
d
Consumer
Provider
Execute

Sơ đồ cộng tác trong SOA.
Trong SOA có ba thành phần chính:


Service Provider: Cung cấp stateless service phục vụ cho một nhu

cầu nào đó. User (service consumer) không cần quan tâm đến vị trí thực sự mà
service họ cần sử dụng đang hoạt động.


Serive Consumer: User sử dụng service được cung cấp bởi Service

Provider.


Service Registry:

Nơi lưu trữ thông tin về các service của các

Service Provider khác nhau, Service Consumer dựa trên những thông tin này để
tìm kiếm và lựa chọn Service Provider phù hợp.

Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp
(các chức năng có thể cung cấp, khả năng của hệ thống (resource, performance),
giá cả dịch vụ, ...) vào Service Registry. Service Consumer khi có nhu cầu về một
service nào đó sẽ tìm kiếm thông tin trên Service Registry. Ngoài chức năng hỗ trợ
tìm kiếm, Service Registry còn có thể xếp hạng các Service Provider dựa trên các
tiêu chí về chất lượng dịch vụ, bầu chọn từ các khách hàng đã sử dụng service, ...
Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer.
10


Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lập
kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành
thương lượng thêm (về mặt giá cả, resource sử dụng, ...).
2.2.Kiến trúc chi tiết
Hiện nay chưa có một mô hình chính thức nào của SOA. Thật sự SOA là
một phương pháp luận giúp chúng ta tận dụng sức mạnh của các nguồn lực, nguồn
tài nguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất. Mỗi
một công ty có một mô hình SOA khác nhau. Nhìn chung mô hình SOA có các đặc
điểm sau:



Tầng Connectivity: đây là tầng thấp nhất của SOA, có nhiệm vụ giao

tiếp trực tiếp với các thành phần khác như cơ sở dữ liệu, giao tiếp với các ứng dụng
khác, các web service,… Vì vậy có thể coi đây là tầng vật lý của SOA.
Mục đích của tầng kết nối là kết nối các ứng dụng enterprise hoặc tài nguyên
bên dưới và cung cấp chúng thành dạng những dịch vụ.Tùy vào ứng dụng cụ thể
mà bộ chuyển đổi tương ứng được sử dụng. Về cơ bản, tầng này có thể được dùng
để thực hiện kết nối đến các hệ CSDL.Những ngôn ngữ lập trình hiện đại cung cấp

11


các tập hàm API cho phép truy cập đến hầu hết các hệ CSDL thông dụng.Với các
ứng dụng enterprise thì lại khác vì mỗi nhà cung cấp tập hàm API khác nhau.


Tầng Orchestration: là các dịch vụ xử lý các quy trình nghiệp vụ và

dộc lập với tầng vật lý phía bên dưới.
Tầng Orchestration chứa các thành phần đơn đóng vai trò vừa là những dịch
vụ sử dụng, vừa là những dịch vụ cung cấp. Những dịch vụ này sử dụng dịch vụ
của tầng kết nối và các dịch vụ orchestration khác để kết hợp những chức năng cấp
thấp hơn thành những dịch vụ hoạt động ở cấp cao hơn, có hành vi gần với chức
năng nghiệp vụ thực hơn.
-

Simple composite service
Là những dịch vụ đơn thuần kết hợp với những lời triệu gọi tới các dịch vụ
bên dưới, hoạt động như một mẫu mặt tiền. Chúng giúp đơn giản hóa quy trình
tương tác với các dịch vụ cấp thấp và che dấu đi tính phức tạp với những người sử

-

dụng dịch vụ ở tầng cao.
Process servise
Là những dịch vụ định ra một tiến trình kết nối các dịch vụ ở cấp thấp hơn.
Điều này rất hữu dụng với việc thiết kế các dịch vụ kết nối đến nhiều hệ
thống enterprise bên dưới sau đó thực thi nhưn một tiến trình.
Ví dụ, dịch vụ “Submit New Order” có thể được xem như một process

service thực hiện tương tác với CSDL khách hàng để lấy thông tin khách hàng,
quyết định dựa trên thông tin tài khoản của khách hàng, tương tác hệ thống lưu kho
và hệ thống tài chính để hoàn tất đơn đặt hàng.
Process service có rất nhiều đặc tính phù hợp quy trình nghiệp vụ của doanh
nghiệp nên có rất nhiều nỗ lực để chuẩn hóa cách thức định nghĩa ra chúng. Tổ
chức OASIS đã đưa ra chuẩn WS-BPEL ( Web Service Business Process

-

Execution Language) cho process service.
Data service

12


Là những dịch vụ cung cấp dữ liệu thu thập được từ nhiều nguồn dữ liệu
khác nhau. Trong nhiều trường hợp, dữ liệu cùng tồn tại trên nhiều CSDL và ứng
dụng khác nhau.Ví dụ thường thấy là thông tin về khách hàng.Doanh nghiệp
thường lưu thông tin về khách hàng trong một hệ thống đặt hàng, hệ thống tài
chính và hệ thống CRM.Mỗi hệ thống chỉ chứa một phần dữ liệu trong toàn bộ dữ
liệu về khách hàng.
Data service thường không chỉ được xem như một dịch vụ orchestration
mà nó còn chịu trách nhiệm tương tác trực tiếp với CSDL bên dưới thông qua
những phương thức truy cập phi dịch vụ (non-service oriented access) như JDBC
hoặc J2CA. Chúng cung cấp dữ liệu từ những ứng dụng độc lập và kết hợp dữ liệu
từ nhiều nguồn khác nhau.
Data service thường sử dụng một số ngôn ngữ truy vấn và cơ chế mô tả
khác nhau để xác định quan hệ giữa những lược đồ dữ liệu (data schema). Các
công nghệ phổ biến hiện nay là SQL, XSLT và Xquery trong đó XSLT và Xquery
là hai công nghệ thuần về việc truy vấn dữ liệu trong bối cảnh Web service vì

chúng xử lý và kết xuất dữ liệu dạng XML.


Tầng Composite Application: là các ứng dụng tổng hợp nhằm mục

đích trình diễn (presentation) và hiển thị thông tin cho người dùng cũng như cung
cấp một giao diện cho người dùng tương tác với hệ thống như là một phần mềm
duy nhất. Tầng này có thể là các website, portal, các ứng dụng client mở rộng (rich
client), các thiết bị di động thông minh (smart device),…
-

Dữ liệu truyền qua lại giữa những dịch vụ cuối cùng cũng định hướng
đến người sử dụng theo nhiều dạng giao diện khác nhau. Tầng này được
xem là tầng tích hợp cuối cùng của quá trình tích hợp.

-

Tầng ứng dụng tổng hợp là tầng đơn thuần sử dụng các dịch vụ, nó cung
cấp các ứng dụng cho người dùng cuối. Nhờ tính linh hoạt của SOA và
đặc tính của các dịch vụ được tổng hợp từ tầng orchestration, các ứng
13


dụng có khả năng biểu diễn mọi loại thông tin từ mọi nguồn thông tin,
thậm chí cho phép người dùng gửi thông tin tổng hợp mà thông tin đó sẽ
được phân phối lại cho các hệ thống bên dưới.
-

Tầng ứng dụng tổng hợp chia làm hai tầng nhỏ hơn là portlet và portal.
Một Portlet được định nghĩa như một ứng dụng chạy trong một cửa sổ

thành phần trong một ngữ cảnh với sự tách biệt rõ ràng giữa Portlet và
ngữ cảnh của nó. Portlet là thành phần cung cấp và sử dụng dịch vụ.CÓ
điều là chúng cung cấp một dạng dịch vụ giao diện đặc biệt được thiết kế
đặc biệt để dử dụng bởi một bộ UI Framework consumer (một portal).
Mỗi Portlet sử dụng một số dịch vụ liên quan của tầng orchestration bên
dưới và cho phép người sử dụng gửi thông tin bổ sung. Công nghệ web
hiện nay như Java Server Faces (JSF) và ÁP.NET đều hỗ trợ xây dựng
portlet.Portal là một bộ khung tích hợp sử dụng các Portlet, trang bị cho
chúng một vẻ ngoài thống nhất và thể hiện chúng thành một giao diện
hoàn chỉnh cho người dùng cuối.



Các thành phần khác: gồm có quy trình phát triển (development),

quản lý các dịch vụ (service management), và quản lý con người (governance).
Như vậy có thể thấy SOA không chỉ đơn thuần là về mặt công nghệ mà nó là tổng
hòa của rất nhiều yếu tố: công nghệ, cơ sở hạ tầng, con người và quy trình nghiệp
vụ.

14


2.3.SOA và Web service
Chúng ta có thể thấy mô hình trên của rất giống với của mô hình Web service:

15


SOA và Web service là hai khái niệm tách biệt nhau. SOA chỉ đặc tả một mô

hình phát triển các ứng dụng dựa trên dịch vụ, Còn Web service tập trung vào công
nghệ để thực hiện điều đó dựa trên nền tảng Web. Nói ngắn gọn, Web service là
một mô hình cụ thể hóa của SOA. Web service được sử dụng phần lớn trong các
ứng dụng SOA. Chúng ta cần chú ý là khái niệm “service” của SOA không chỉ là
Web service mà nó bao hàm cả các dịch vụ khác mà chúng ta có thể tìm thấy và sử
dụng chúng trong một mạng máy tính.
2.4.Mô hình giao tiếp bằng thông điệp (message) trong SOA
So với kiểu thiết kế Component-Based, điểm khác biệt chính của SOA là
cung cấp khả năng giao tiếp giữa các thành phần trong hệ thống (service) sử dụng
thông điệp (message) dựa trên các chuẩn giao tiếp đã được chuẩn hóa (HTTP, FTP,
SMTP, ...). Chính nhờ đặc điểm này, hệ thống SOA trở nên độc lập với platform
(platform independent). Các service hoạt động trên nền các platform khác nhau vẫn
có thể giao tiếp với nhau nhờ vào các interface giao tiếp đã được chuẩn hóa để
cộng tác xử lý một tác vụ nào đó.
Sử dụng thông điệp (message) để giao tiếp có các lợi thế sau:
• Cross-platform: thông điệp (message) trở thành ngôn ngữ chung của các

platform và các ngôn ngữ lập trình khác nhau. Điều này đảm bảo các service
trên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù của
platform đó.
• Asynchronous communications: hoạt động gởi nhận thông điệp được thực

hiện theo cơ chế Fire-and-Forget. Sender và Receiver không cần phải chờ
thông điệp trả lời sau khi đã gởi đi một thông điệp. Điều này giúp cho
Sender và Receiver tiếp tục xử lý công việc sau khi gởi thông điệp mà không
cần dừng thực thi để chờ thông điệp trả lời.

16



• Reliable communication: các thông điệp từ Sender có thể được gởi đến một

service trung gian có nhiệm vụ lưu trữ (store) các thông điệp. Service trung
gian sẽ gởi (forward) thông điệp cho Receiver khi Receiver có thể xử lý yêu
cầu tiếp theo. Cơ chế Store-and-Forward này đảm bảo các thông điệp sẽ
không bị thất lạc trong trường hợp Receiver bị quá tải và không thể nhận
thêm yêu cầu mới.
• Thread management: Việc trao đổi thông điệp theo cơ chế bất đồng bộ

giúp ứng dụng không cần ngừng thực thi để chờ một tác vụ kết thúc mà có
thể tạo ra các thread xử lý các công việc khác nhau.
• Remote communication: Các thông điệp lưu trữ thông tin về các đối tượng

dữ liệu dưới dạng đặc tả hình thức thay thế việc phải serialization and
deserialization các đối tượng dữ liệu truyền qua mạng khi ứng dụng thực
hiện remote call một ứng dụng khác.
• End-to-end security: Thông điệp có thể lưu trữ thông tin về security

context của kênh giao tiếp. Điều này cung cấp khả năng điều khiển liên quan
đến security như authentication and authorization.
III.CÁCH THỨC HOẠT ĐỘNG CỦA MÔ HÌNH HƯỚNG DỊCH VỤ.

SOA hoạt động theo một chu trình khép kín bao gồm các giai đoạn sau:
develop -> intergrate -> orchestrate -> deploy -> manage ->secure ->access.
3.1.Devolop

Giai đoạn này tập trung phát triển các service và tạo ra web service.
Mô hình webservice <=> myservice . trong đó webservice để bên ngoài
tương tác với service chúng ta. Myservice để thực hiện service bằng Java class
hoặc EJB.

Trong quá trình thực hiện myservice thì có thể service của chúng ta cần
giao tiếp với cơ sở dữ liệu. Bình thường thì chúng ta có thể tự mở CSDL và query
17


sau đó đóng gói dữ liệu vào trong class Java. Điều này dễ dàng thực hiện trong các
ứng dụng nh. Vì người làm database và ứng dụng rất gần với nhau, đôi khi chỉ là
một. Nhưng với những vấn đề lớn, thì hầu như là người phát ứng dụng không biết
hoặc biết rất ít về database. Do đó chúng ta nên mapping giữa CSDL và đối tượng
Java, khi bạn mapping xong thì bạn chỉ cần read hoặc write 1 đối tượng thì hệ
thống runtime sẽ lo công việc query CSDL.
3.2.Intergrate
Bạn có thể tích hợp compenent hoặc tích hợp rule. Rule nhằm để tách giữa
ứng dụng và nghiệp vụ, do đó bạn có thể thay đổi nghiệp vụ 1 cách dễ dàng mà
không cần phải code lại chương trình.
3.3.Orchestrate
Đây là giai đoạn tích hợp các service, khi mà có đầy đủ các service thì chúng ta
phải tích hợp lại. Công việc tích hợp này chúng ta dung ngôn ngữ BPEL để tích
hợp các service. Bạn có thể sử dụng BPEL của IBM hoặc của Oracle.
3.4.Deploy
Khi các service đã được tạo xong. Bạn test nó cẩn thận và đạt rồi thì chúng ta tiến
hành đóng gói các service và sau đó deploy nó lên server đích.
3.5.Manage và Secure
Đối với các hệ thống phát triển theo mô hình SOA thì hệ thống ngày càng phức tạp
dần, và ngày càng có nhiều service hơn do đó thì yêu cầu quản lí và bảo mật các
web service được đặt ra. Hiện nay bạn có thể sử dụng Oracle Web service Manager
cho công việc bảo mật này
3.6.Access
Chúng ta bắt đầu truy xuất vào hệ thống.


18


IV.LỢI ÍCH VÀ HẠN CHẾ CỦA VIỆC PHÁT TRIỂN MÔ HÌNH HƯỚNG
DỊCH VỤ
1.1.
Lợi ích.
Sử dụng mô hình SOA trong việc thiết kế hệ thống mang lại nhiều lợi ích về
mặt kinh tế và kỹ thuật.
• Lợi ích kinh tế:
o Doanh nghiệp có điều kiện tập trung thời gian để tìm kiếm các giải

pháp cho các bài toán liên quan đến kinh tế.
o Thúc đẩy sự phát triển của hệ thống hiện có cũng như cung cấp khả

năng mở rộng hệ thống trong tương lai.
• Lợi ích kỹ thuật:
o Hệ thống xây dựng theo mô hình SOA đảm bảo các service trong hệ

thống có tính độc lập cao (độ kết dính thấp) (autonomous và loose
coupling). Đồng thời có thể tận dụng tối đa các nguồn tài nguyên như
CPU, storage, database… với chi phí hợp lý.
o Ở góc nhìn người sử dụng, vị trí các service có tính trong suốt

(transparency), việc di dời các service đến một máy tính khác không
ảnh hưởng khả năng phục vụ yêu cầu khách hàng.
o Hoạt động của các service có tính linh động cao, hành vi của các

service tùy thời đểm, tùy yêu cầu cần xử lý mà có sự khác nhau (late
binding).

o Tái sử dụng phần mềm. Nếu gói mã mà tạo thành một dịch vụ có quy

mô và kích thước phù hợp sau đó nó có thể được tái sử dụng cho lần
kế tiếp. Một đội phát triển cần chức năng cụ thể đó cho một ứng dụng
phần mềm mới mà nó mong muốn xây dựng, họ không cần biết bất cứ
thứ gì về việc mã được gói chặt như thế nào hay nó có nguồn gốc từ
19


đâu. Tất cả những thứ mà họ cần làm đó là xây dựng một sự kết nối
đến dịch vụ đó.
1.2.

Hạn chế

-

Hệ thống phức tạp

-

Khó miêu tả dữ liệu không cấu trúc trong header của message.

4.3 So sánh mô hình SOA với các mô hình truyền thống
Mô hình SOA co ưu thế hơn các mô hình truyền thống (như mô hình hướng
ứng dụng hoặc mô hình hướng lập trình) ở điểm mô hình SOA chủ yếu tập trung
nguồn lực phát triển vào c ác chức năng và tính năng phục vụ hoạt động và quy
trình nghiệp vụ. Điều này cho phép các nhà quản lý chỉ cần dựa trên đặc điểm
mang tính nghiệp vụ rà soát, xác định rõ chi tiết, thành phần cần thêm, sửa đổi
hoặc loại bỏ. Do đó, các hệ thống phần mềm phát triển phía sau có thể được thiết

kế nhằm đáp ứng những quy trình nghiệp vụ (thay vì quy trình nghiệp vụ phải thay
đổi để tận dụng những tính năng phần mềm như trong các mô hình thường thấy ở
nhiều cơ quan tổ chức với hạ tầng cơ sở ứng dụng Công nghệ thông tin được phát
triển từ trước ).
• Mô hình SOA và OOP (mô hình hướng đối tượng)

SOA sử dụng cùng một số nguyên lý như OOP, tuy nhiên triết lí SOA có
khác biệt đáng kể so với OOP. SOA có thể thực hiện với cả chương trình theo
hướng đối tượng (OO) và các chương trình không hướng đối tượng.
SOA hỗ trợ việc kết nối lỏng lẻo các service, OOP dựa nhiều trên lớp được
định nghĩa sẵn, kết quả là đối tượng kết nối chặt chẽ với nhau.
Service orieted sử dụng các message để miêu tả thông tin về service để thực
hiện chức năng của mình OOP lại sử dụng các hàm APIs để miêu tả các đối tượng
của mình.

20


Phạm vi hoạt động của các service trong SOA rộng lớn hơn là các đối tượng
của OOP.
SOA khuyến khích các service được thiết kế phi trạng thái càng nhiều càng
tốt còn OOP thi lại liên kết dữ liệu một cách logic từ đó tạo ra các đối tượng có
trạng thái.
• Mô hình SOA và Web

Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch
vụ. Điều này làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây:
Dịch vụ Web. Dịch vụ Web cho phép truy cập thông qua định nghĩa giao thức- và giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhưng chúng không
phải là một.
Về cơ bản, SOA là kiến trúc phần mềm xuất từ định nghĩa giao tiếp và xây

dựng toàn bộ mô hình ứng dụng như mô hình các giao tiếp, thực hiện giao tiếp và
phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này;
thực ra tên gọi kiến trúc định hướng giao tiếp thích hợp hơn cho SOA. Dịch vụ và
modul phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách
thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ một chiều thì nó vẫn là yêu
cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một
tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch
vụ và khách hàng sử dụng dịch vụ.
4.4. Bảo mật trong SOA.
Với việc phát triển không ngừng của công nghệ web service đã tạo nên
những ảnh hưởng nhất định trong việc xây dựng các mô hình tính toán phân tán.
Các kiến trúc phân tán hướng đối tượng DOA sử dụng các công nghệ như là
CORBA, DCOM, DCE và JAVA RMI đang nhanh chóng chuyển sang các kiến
trúc hướng dịch vụ với những công nghệ mới như SOAP, HTTP, XML.

21


Việc thay đổi kiến trúc hệ thống như thế đã dẫn đến những thay đổi nhất
định trong việc đưa ra những giải pháp cho vấn đề bảo mật của hệ thống. Hầu hết
các giải pháp bảo mật đang được sử dụng ngày nay đều dựa trên thực trạng là cả hệ
thống máy khách và cả máy chủ đều đặt tại cùng một mạng vật lý(ví dụ như là
mạng LAN) hay mạng logic (như VPN). Những giải pháp này đảm bảo an toàn cho
hệ thống thắt chặt vấn đề an ninh thông qua việc giám sát, điều khiển tất cả mọi
ngõ vào và ngõ ra của mạng. Thế nhưng, một hệ thống SOA với các đặc tính mở
của nó, đã thật sự làm cho các giải pháp này không còn thích hợp nữa.
Giới thiệu kiến trúc bảo mật hướng dịch vụ
Yêu cầu đặt ra của kiến trúc.
 Chứng thực: Hầu hết các nhà cung cấp dịch vụ đều yêu cầu các bên sử dụng
-


dịch vụ phải được chứng thực trước khi yêu cầu dịch vụ được chấp nhận.
Các đối tượng sử dụng dịch vụ cũng phải được chứng thực nhà cung cấp


dịch vụ khi nhận được kết quả trả về.
Phân quyền: các đối tượng sử dụng dịch vụ phải có một quyền nhất định nào
đó, việc kiểm tra phân quyền này thông qua các chính sách (ví dụ như đối
tượng nào được phân quyền sử dụng các dịch vụ nào, và trong điều kiện
gì…). Một số mô hình phân quyền: DAC kiểm soát việc truy cập thông qua
ID, mô hình MAC thì bảo vệ thông tin bằng cách gán cho mọi thông tin một
giá trị “nhạy cảm” và sẽ so sánh giá trị này với giá trị nhạy cảm của người



truy cập.
Độ tin cậy: phải có cơ chế để bảo vệ môi trường truyền dữ diệu cũng như



các thông điệp và tài liệu được truyền trên môi trường đó.
Toàn vẹ dữ liệu: bảo vệ dữ liệu không bị xâm hại trong suốt quá trình



truyền.
Cơ chế định danh: nhằm đảm bảo các đối tượng tham gia trong quá trình
tương tác không thể phủ nhận vai trò của mình (người gửi không thể phủ

22



nhận những gì mình đã gửi và người nhận không thể chối bỏ những gì mình


-

đã nhận)
Các yêu cầu khác: cần có một cơ chế quản lý, cơ chế ghi nhận, xử lý bảo

mật liên miền, khả năng liên kết cao….
Khái niệm kiến trúc bảo mật hướng dịch vụ: mô hình SOSA không hướng đến
việc thay thế hoàn toàn các kiến trúc bảo mật hiện có mà muốn đưa ra một giải
pháp để liên kết các cơ sở hạ tầng sẵn có dựa trên những nguyên tắc của SOA để
tạo nên một kiến trúc bảo mật hướng dịch vụ mới,

-

Giới thiệu một số chuẩn bảo mật trong XML
WS- Security: là chuẩn được đề xuất bởi hãng IBM, microsoft và Verisign.

Đây là một chuẩn an toàn bao trùm cho SOAP và cả những phần mở rộng của
SOAP.
+ Sử dụng các sercurity token trong phần đầu của các thông điệp SOAP để hỗ trợ
cho việc định danh và chứng thực.
+ Sử dụng XML –Encryption để đảm bảo độ tin cậy cho dữ liệu
+ Sử dụng XML –Signtures đảm bảo tính toàn vẹn và xác thực của dữ liệu.

23



XML –Signtures: được chứng thực bởi tổ chức W3C , chuẩn này quan tâm
tới cú pháp và việc chứng thực một thành phần nào đó trong tài liệu XML bằng các
công nghệ chứng thực khóa đồng bộ hay bất đồng bộ.
XML –Encryption
Sercurity Assertion Markup Language (SAML): chuẩn này được đưa
ra bởi OASIS.
SAML là định nghĩa một nền tảng cho việc trao đổi các thông tin bảo mật dưới
dạng XML. Những thông tin bảo mật này có thể là thông tin chứng thực, các quyết
định phân quyền, hoặc là đối tượng được lưu trữ ở dạng XM L và được cấp phát
bởi nơi cung cấp chứng thực SAML,
SAML cũng định nghĩa các giao thức, quy tắc trong quá trình vận chuyển các
thông tin bảo mật

V. KẾT LUẬN
Xây dựng hệ thống sử dụng mô hình hướng dịch vụ SOA đưa lại những hiệu
quả:
Tập trung vào xây dựng những tính năng nghiệp vụ trong quá trình phát
triển phần mềm .
Giảm thiểu chi phí trong quá trình phát triển.
Giảm thiểu yêu cầu về đào tạo kỹ năng .
Chi phí bảo trì thấp.
Chu trình phát triển phần mềm nhanh chóng hơn.
Có khả năng tái sử dụng.
Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay đổi về
yêu cầu giao dịch .
Cho phép dễ dàng triển khai chương trình, môi trường chạy và quản lý
service dễ dàng hơn.

24



TÀI LIỆU THAM KHẢO
- Bài giảng môn công nghệ phần mềm 2- GV . Phạm Thủy Vân.
- Websire: />- />-

/3174351.cw/index.html
........

25


×