Các ứng dụng khi sử dụng dịch vụ này chỉ cần gửi thông điệp yêu cầu đến một dịch vụ service 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
Trang 1TRƯỜNG ĐẠI HỌC SƯ PHẠM HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
VÀ GIẢI PHÁP CỦA ORACLE
GIÁO VIÊN HƯỚNG DẪN: NGUYỄN MẠNH HÙNG SINH VIÊN THỰC HIỆN: PHÙNG THỊ THAO
K54A-CNTT-ĐHSPHN
HÀ NỘI, THÁNG 4 – 2008
Trang 2Em xin chân thành cảm ơn khoa CNTT trường ĐHSPHN đã tạo điều kiện giúp em
hoàn thành khoá luận này
Em xin gửi lời biết ơn sâu sắc đến Tiến sĩ Nguyễn Mạnh Hùng Thầy đã tận tình
hướng dẫn và chỉ bảo cho em trong suốt quá trình học tập và nghiên cứu thực hiện đề
tài
Em xin chân thành cảm ơn tới các quý thầy cô trong khoa CNTT đã tận tình giảng
dạy và trang bị kiến thức cho em và các bạn sinh viên khác trong suốt thời gian học tập
tại khoa
Xin chân thành cảm ơn bạn bè và gia đình đã ủng hộ rất lớn về mặt tinh thần để em
có thêm quyết tâm hoàn thành đề tài này
Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi cho phép, nhưng do kiến thức
và thời gian còn thiếu nên đề tài chắc chắn sẽ còn nhiều thiếu sót Vì vậy kính mong các
thầy cô và các bạn tận tình đóng góp và chỉ bảo để em hoàn thiện đề tài hơn nữa
Một lần nữa em xin chân thành cảm ơn và mong luôn nhận được tình cảm chân
thành của tất cả mọi người
Hà Nội, tháng 4 năm 2008
Phùng Thị Thao
Trang 3Chương 1: Tổng quan về SOA
1.1 Thực trạng hiện tại và một số mô hình trong hệ thống phân tán
1.1.1 Thực trạng
1.1.2 Một số mô hình trong hệ thống phân tán
1.2 Giới thiệu kiến trúc hướng dich vụ SOA
1.2.1 Kiến trúc hướng dịch vụ là gì?
1.2.2 Các nguyên tắc chính của hệ thống SOA
1.2.3 Các tính chất của hệ thống SOA
1.2.4 Lợi ích của SOA
1.2.5 Kiến trúc phân tầng chi tiết của SOA
1.2.6 Một số mô hình triển khai SOA
1.4.2 Giới thiệu một số kiến trúc hướng dịch vụ
1.4.3 Giới thiệu một số chuẩn trong XML
1.5 Vấn đề tích hợp trong SOA
1.6 Quản lý tiến trình nghiệp vụ
Trang 4Chương 2: Bộ giải pháp về SOA của Oracle
2.1 Oracle SOA Suite hiện thực Web service với Jdeveloper
2.2 Giới thiệu về SOA Suite
2.2.1 Ứng dụng của SOA Suite
2.2.2 Service Bus
2.2.3 BPEL engine
2.2.4 BPEL Designer
2.3 Kết luận
Chương 3: Thử nghiệm thực tế phần mềm BPEL của Oracle
Thử nghiệm phần mềm SOA suite
Xây dựng một số service trong website bán hàng cho một book_cafe
Chương 4 Kết luận chung
Trang 5Ngày nay, công nghệ thông tin đang ngày càng phát triển, trở thành ngành mũi nhọn
trong chiến lược phát triển kinh tế của mỗi quốc gia Đối tượng phục vụ chủ yếu hiện
nay của CNTT là các tổ chức, các cơ sở doanh nghiệp Với sự phát triển của Internet và
với xu thế hội nhập chung của toàn thế giới, các tổ chức, doanh nghiệp cần bắt tay, phối
hợp hoạt động và chia sẻ tài nguyên với nhau để nâng cao hiệu quả hoạt động Khi đó
các sản phẩm sẽ ngày càng phức tạp, kéo theo chi phí sản xuất, quản lý và bảo trì Đặc
biệt, ngành công nghệ phần mềm còn đối mặt với vấn đề hóc búa là bảo mật, và tái sử
dụng lại các hệ thống sẵn có, vấn đề không tương thích về hệ thống giữa các tổ chức
hợp tác với nhau
Để giải quyết vấn đề trên người ta đã đưa ra nhiều giải pháp và hiện nay, một giải
pháp đang được quan tâm là kiến trúc hướng dịch vụ (Service Oriented Architecture –
SOA)
Các ứng dụng khi sử dụng dịch vụ này chỉ cần gửi thông điệp yêu cầu đến một dịch
vụ (service) 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ư các dịch vụ WEB hiện nay chẳng hạn, nó 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 em thực hiện đề tài:
Kiến trúc hướng dịch vụ (Service Oriented Architecture - SOA)
và giải pháp của Oracle
Trang 61 Đề tài tập trung vào việc nghiên cứu một cách tổng quan về SOA
- Nghiên cứu cơ sở lý thuyết của kiến trúc SOA, các tính chất và lợi ích của kiến
trúc này
- Tìm hiểu những vấn đề liên quan đến xây dựng hệ thống SOA và các nguyên tắc
thiết kế hệ thống này
- Ứng dụng vấn đề bảo mật trong kiến trúc hướng dịch vụ Tìm hiểu một số chuẩn
bảo mật trong XML và Web Service
- Khả năng tích hợp hệ thống và quản lý các quy trình nghiệp vụ
2 Giải pháp của Oracle, cụ thể với phần mềm SOA Suite
- Tìm hiểu thực tế phần mềm SOA Suite và các thành phần liên quan
- Môi trường phát triển và cách thiết kế, xây dựng ứng dụng, thực thi và quản lý các
Trang 72 Chương 1: Tổng quan về SOA
1.1 Thực trạng hiện tại và một số mô hình trong hệ thống phân tán
1.1.1 Thực trạng
Phần mềm ngày nay đang dần trở nên phức tạp và dường như đang vượt quá sự
kiểm soát của các mô hình hiện có Theo Albert Einstein: “Mọi việc nên thực hiện theo
cách đơn giản đến mức có thể… ” Hiện nay, có nhiều hệ thống phần mềm đang được
xây dựng với kiến trúc khá phức tạp với chi phí phát triển và bảo trì cao, đặc biệt là
những phần mềm cao cấp Độ phức tạp của các hệ thống kiến trúc phần mềm ngày một
tăng do một số nguyên nhân sau:
Sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất trong
khi nhu cầu chia sẻ, tương tác, trao đổi của các hệ thống không thể tiến hành trong môi
trường như thế Giải quyết vấn đề này nghĩa là các doanh nghiệp cần phải thay đổi hệ
thống theo một chuẩn thống nhất chung nào đó Điều chủ yếu là hệ thống cũ cần được
sử dụng lại chứ không phải là gỡ bỏ thay mới bởi vấn đề chi phí cho thiết lập một hệ
thống quản lý mới tốn kém hơn nhiều so với chuyển đổi cái cũ Vấn đề này đưa đến
một khái niệm là “Tích hợp hệ thống ” (Enterprise Architecture Intergration - EAI) –
đang được nhiều tổ chức quan tâm đầu tư với mức chi phí cao dẫn đầu hiện nay cho các
dự án dạng này
Vấn đề lập trình dư thừa và tái sử dụng Chẳng hạn, một doanh nghiệp có nhiều chi
nhánh khác nhau, mỗi chi nhánh lại có một hệ thống tách biệt và xây dựng ở những thời
điểm khác nhau và cần kết nối lại với nhau sẽ không tránh khỏi việc sử dụng dư thừa tài
nguyên, dữ liệu không đồng nhất…
Hầu như mọi tổ chức đều phải đối mặt với vấn đề tích hợp vì nhiều lí do như mở
rộng thêm chi nhánh, thêm hệ thống bạn hàng mới, hoặc là cần kết nối các hệ thống có
sẵn… Vấn đề kéo theo là chi phí thay đổi mã nguồn cũ, kiểm thử, bảo trì…
Thực trạng này tạo thêm một áp lực nặng nề với các doanh nghiệp và tổ chức, các
nhà phát triển phần mềm
Trang 81.1.2 Một số mô hình trong hệ thống phân tán
Ba kiến trúc phân tán phổ biến nhất hiện nay là DCOM, CORBA và EJB
Các kiến trúc này là sự mở rộng của hệ thống hướng đối tượng bằng cách cho phép
phân tán các đối tượng trên mạng Đối tượng đó có thể không nằm trong vùng không
gian ứng dụng, hoặc nằm trên một máy khác không chứa ứng dụng nhưng vẫn được
tham chiếu sử dụng như một phần ứng dụng
• CORBA - Common Object Request Broker Architecture
CORBA được định nghĩa bởi Object Managerment Group (OMG), là một kiến
trúc phân tán mở, độc lập nền tảng và độc lập ngôn ngữ
CORBA Common Model (CCM) định nghĩa ra qui trình thiết kế, phát triển,
đóng gói, triển khai và thực thi các thành phần phân tán CCM định nghĩa khái
niệm Ports cho các thành tố Các Ports này được dùng để kết nối các thành phần
có sẵn với nhau, tạo các hệ thống phân tán phức tạp hơn
Ưu điểm của CORBA: có thể thoả mãn mọi ngôn ngữ, nền tảng phần cứng,
giao thức mạng và công nghệ để phát triển CORBA
Nhược điểm: là ngôn ngữ lập trình cấp thấp, khó học và cần đội ngũ phát triển
có kinh nghiệm Các đối tượng CORBA khó có thể tái sử dụng
• DCOM – Distributed Component Object Model
DCOM là mô hình phân tán dễ dàng triển khai với chi phí thấp, hỗ trợ tigh
coupling giữa các ứng dụng và hệ điều hành Mô hình Component Object
Model (COM) định nghĩa cách thức các thành phần clien liên lạc và trao đổi với
nhau trên một máy DCOM mở rộng COM bằng cách sử dụng các giao thức
mạng chuẩn khi cần trao đổi dữ liệu với các máy khác trong mạng
Ưu điểm: tính ổn định, không phụ thuộc vị trí địa lý, quản lý kết nối hiệu quả và
dễ dàng mở rộng Thuận lợi cho các doanh nghiệp sử dụng các ứng dụng cùng
chạy trên nền Windows
Trang 9Nhược điểm: tất nhiên các công nghệ này chỉ chạy được trên nền windows
Hình 1: Mô hình tương tác của các đối tượng trong kiến trúc DCOM
• EJB – Enterprise Java Bean
Là kiến trúc dùng bên phía máy chủ dùng cho việc triển khai các ứng dụng
phân tán hướng đối tượng cỡ vừa và lớn
Kiến trúc EJB có 3 tầng với tầng đầu là tầng trình diễn, tầng thứ hai là tầng xử
lý nghiệp vụ, tầng thứ 3 là các tài nguyên như cơ sở dữ liệu máy chủ
EJB là một kiến trúc tốt cho tích hợp hệ thống vì nó độc lập trên nền tảng,
nhưng nó không phải là một chuẩn mở và khả năng giao tiếp với các chuẩn
khác còn hạn chế
Trang 10Hình 2: Mô hình tương tác của các đối tượng trong kiến trúc EJB
Tóm lại, các kiến trúc trên đều hướng đến vấn đề xây dựng kiến trúc hướng dịch vụ
nhưng chúng còn gặp phải một số vấn đề như:
Tigh coupling: kiến trúc triển khai cài đặt phía nhà cung cấp và phía sử dụng dịch vụ
phải giống nhau
Những chuẩn trên đa phần là những chuẩn đóng Ví dụ: đối tượng java trong mô
hình EJB chỉ trao đổi được với các đối tượng cùng mô hình và không thể trao đổi được
với các đối tượng DCOM
Lượng thông tin trong mỗi lần giao dịch là ít, được thực hiện nhiều lần vì vậy dẫn
đến chiếm dụng băng thông sử dụng và thời gian đáp trả dữ liệu nhanh
Một vấn đề đặt ra là làm thế nào để các hệ thống phân tán phát triển trên các công
nghệ khác nhau có thể giao tiếp được với nhau? Cách tiếp cận mới này đáp ứng được
yêu cầu đó Đó là cách tiếp cận theo kiểu “kiến trúc hướng dịch vụ.”
Trang 11Kiế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 hoá trên mạng, trao đổi với nhau trong ngữ cảnh một tiến trình
nghiệp vụ
SOA có ba đối tượng chính minh hoạ trong hình sau:
2 Hình 3: Sơ đồ cộng tác trong SOA hiện nay
Nhà cung cấp dịch vụ (Service Provider) cần cung cấp thông tin về những dịch vụ
của mình trong một dịch vụ lưu trữ thông tin dịch vụ (Service Registry) Người sử dụng
(Service Consumer) tìm kiếm thông tin về dịch vụ cần thiết trong Service Regisstry sau
đó xây dựng kênh giao tiếp với nhà cung cấp
Trang 12SOA cung cấp các giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện
nay như: phức tạp, không linh hoạt và không ổn định Một hệ thống triến khai theo mô
hình SOA có khả năng dễ mở rộng, liên kết tốt Đây chính là điều kiện cơ sở, nền tảng
để tích hợp, tái sử dụng những tài nguyên hiện có
Thật ra, tư tưởng về một kiến trúc hướng dịch vụ không phải là mới mà CORBA,
DCOM (mô hình của Microsoft), EJB (mô hình của java) đã thực hiện từ lâu, tuy nhiên
cách tiếp cận này còn gặp nhiều hạn chế (như đã nói ở trên) SOA không chỉ cải tiến
đáng kể mà còn đem đến nhiều ưu điểm nổi trội hơn
1.2.2 Các nguyên tắc chính 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:
• Sự phân định rạch ròi giữa các dịch vụ
Do có sự tách biệt giữa 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 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 nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý Và đây chính
là cách 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
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
Trang 13Cá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 và
hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ
liệu (Schema) chuẩn Như thế 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ì phải thoả mãn các chính
sách (Policy), các yêu cầu (Requirements) của dịch vụ đó như: mã hoá, bảo mật Mỗi
dịch vụ phải cung cấp công khai các chính sách và các yêu cầu bảo mật của mình
1.2.3 Các tính chất của hệ thống SOA
• Loose coupling
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 module có tính loose coupling có một số ràng buộc
được mô tả rõ ràng, trong khi các module 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ụ thoả 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 gỡ bỏ những ràng buộc điều khiển giữa những hệ thống
đầu cuối Mỗi hệ thống có thể tự quản lý độc lập 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
Trang 14Nhữ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ỏ thành phần trùng lặp,
tăng độ vững chắc trong cài đặt và đơn giản hoá việc quản trị
• Sử dụng dịch vụ bất đồng bộ
Phương thức triệu gọi 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 và 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, tuỳ 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à tuỳ 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 vi 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ụ 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
SOA nhấn mạnh đến khả năng cộng tác (interoperability), 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ông ngữ khác nhau Mỗi dịch vụ
Trang 15cung 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 là interoperable 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 của dữ liệu tuỳ thuộc vào hệ thống Ví dụ
Wrb 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ụ thoả mãn yêu cầu của họ
Ví dụ, một hệ thống chuyển khoản (Consumer) 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 tin thoả
mãn yêu cầu Các entry chứa thông tin về dịch vụ bao gồm cả phí dịch vụ Bên sử dụng
sẽ chọn một dịch vụ có chi phí thấp nhất 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 này là 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
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
Trang 16Một hệ thống tự hồi phục (Self - healing) 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 Đây là một yếu tố
quan trọng trong các ứng dụng hệ thống phân tán
Độ tin cậy (reliability) 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ậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi gặp lỗi
Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến
trong khi chạy Một kiến trúc hỗ trợ kết nối và thực thi động như thế sẽ có khả năng tự
phục hồi cao hơn kiến trúc không hỗ trợ tính năng này
Một tính chất cơ bản khác của hệ thống hướng dịch vụ là: có sự tách biệt giữa
interface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho một interface Nếu một
thể hiện dịch vụ nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao
dịch cho khách hàng mà không bị ảnh hưởng gì Khả năng này có được nghĩa là client
chỉ tương tác với interface của dịch vụ chứ không tương tác trực tiếp tới cài đặt của dịch
vụ
1.2.4 Lợi ích của SOA
(a) SOA là một giải pháp hiệu quả và tiết kiệm chi phí
• Sử dụng lại những thành phần có sẵn
Một trong những lợi ích rõ ràng nhất của SOA là giúp công ty sử dụng lại được
những tài nguyên có sẵn, kết quả là giảm chi phí cho phần kiến trúc và tích hợp Ngoài
ra nó còn giúp giảm chi phí mua phần mềm mới
Việc tái sử dụng có lợi ích to lớn, thứ nhất là giảm tính dư thừa, thứ hai là sử
dụng lại được những thành phần sẵn có để thiết kế phần mềm mới, giảm chi phí phát
triển cho từng phần độc lập của mỗi tính năng mới chưa có Với SOA, thay vì phải
“thay đổi”, chúng ta chỉ cần tạo các cầu nối liên hệ giữa các ứng dụng và hệ thống trên
môi trường khác nhau
Trang 17SOA mang đến khả năng tổng hợp một lớp các ứng dụng mới bằng cách kết hợp
chức năng từ các hệ thống có sẵn, cung cấp cho người cuối những chức năng liên kết
Tức là một số tiến trình cũ có khả năng được kết hợp với nhau bên trong một cổng
thông tin (portal) giúp cho người dùng có thể truy cập một lần mà vẫn có thể có hàng
loạt thông tin về các sản phẩm của các doanh nghiệp Với SOA, một ứng dụng tổng hợp
có thể được tổng hợp dễ dàng bất kể sự khác nhau về địa lý hoặc công nghệ phát triển
dịch vụ đó Điều này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi
phí và tăng hiệu quả kinh doanh
• Tăng tính linh hoạt và triển khai cài đặt nhờ tính loose coupling
Tính loose coupling đem lại lợi ích cho SOA là phía triệu gọi dịch vụ không cần
quan tâm đến địa chỉ hay công nghệ cài đặt dịch vụ Việc triệu gọi dịch vụ thông qua
một giao diện chuẩn nên giúp cho các lập trình viên tránh được việc phải lặp lại các
công việc tạo mới các service có khả năng hiểu được mọi công nghệ sử dụng trong cùng
một hệ thống
Lợi ích thứ hai mà Loose coupling đem lại là với một hệ thống SOA, các doanh
nghiệp dễ dàng cung cấp các dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng Đối
tác đó không cần biết cách thức cài đặt và công nghệ của dịch vụ như thế nào Tương
tự, nếu đối tác đó cũng cài đặt hệ thống SOA thì việc tích hợp và sử dụng các dịch vụ
cũng dễ dàng hơn nhiều
Cuối cùng, tính loose coupling tăng khả năng triển khai Chỉ cần bọc những thành
phần sử dụng interface ứng dụng lại thành một dịch vụ, ta đã có một thành phần dịch vụ
độc lập trong hệ thống SOA như những dịch vụ khác
• Thích ứng với những thay đổi trong tương lai
• Hỗ trợ đa thiết bị và đa nền tảng
SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới Điều này
cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau như các Browser, thiết bị di động
như điện thoại, pager, PDA… sử dụng cùng một chức năng mà vẫn có thông tin trả về
tuỳ theo dạng thiết bị Tính chất độc lập về công nghệ này của SOA tiết kiệm rất nhiều
Trang 18cho các công ty về mặt chi phí, đặc biệt là giai đoạn các công nghệ phát triển đa dạng
như hiện nay
• Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp
Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách
thêm nhiều thể hiện (instance) của một service Công nghệ chia tải (load - balancing) tự
động tìm và định tuyến yêu cầu đến thể hiện service thích hợp Tương tự, SOA có thể
chuyển tiếp các yêu cầu đến một thể hiện khác khi cần, nhờ đó tăng khả năng sẵn sàng
phục vụ
1.2.5 Kiến trúc phân tầng chi tiết của SOA
Ở tầng thấp nhất, tầng kết nối (Connectivity), những dịch vụ được mô hình hoá
dựa trên những ứng dụng enterprise bên dưới Tầng này chứa các dịch vụ như “lấy
thông tin chi tiết sản phẩm” hoặc “cập nhật thông tin khách hàng”, chúng tương tác trực
tiếp với các hệ thống phi dịch vụ bên dưới các dịch vụ này là đặc trưng cho mỗi ứng
dụng enterprise
Phía bên trên tầng kết nối là một số dịch vụ Orchestration được thêm vào để tạo
ra các dịch vụ thật sự xử lý các chức năng nghiệp vụ độc lập dựa trên những ứng dụng
enterprise bên dưới Những dịch vụ này còn gọi là những dịch vụ tổng hợp (Composite
service)
Tầng trên cùng của service orchestrstion là tầng ứng dụng tổng hợp sử dụng các
service và cung cấp giao diện cụ thể cho người sử dụng
(b)
Trang 19Mụ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ầng này là tầng chuyên giao tiếp
với các nhà cung cấp, hoạt động như một bộ chuyển đổi (adapter) giữa các ứng dụng
phi dịch vụ và mạng các dịch vụ khác Tuỳ 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 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 cung cấp tập hàm API khác nhau
• Tầng Orchestration
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 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 hoá 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 service
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ư một tiến trình
Trang 20Ví 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 hoá 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
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 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
để 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 ứng dụng tổng hợp