Ứng dụng kiến trúc hướng dịch vụ trong điện toán đám mây
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 (2.35 MB, 66 trang )
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------
LÊ THANH HẢI
LÊ THANH HẢI
ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ
TRONG ĐIỆN TOÁN ĐÁM MÂY
LUẬN VĂN THẠC SĨ KỸ THUẬT
…......................................
TRUYỀN THƠNG VÀ MẠNG MÁY TÍNH
TRUYỀN THƠNG VÀ MẠNG MÁY TÍNH 2015B
HÀ NỘI _ NĂM 2018
1
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
--------------------------------------LÊ THANH HẢI
ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ
TRONG ĐIỆN TỐN ĐÁM MÂY
CHUN NGÀNH: TRUYỀN THƠNG VÀ MẠNG MÁY TÍNH
LUẬN VĂN THẠC SĨ KỸ THUẬT
…......................................
TRUYỀN THƠNG VÀ MẠNG MÁY TÍNH
NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. TRẦN HỒNG HẢI
HÀ NỘI – NĂM 2018
2
LỜI CAM ĐOAN
Những kiến thức trình bày trong luận văn là do tơi tìm hiểu, nghiên cứu và trình
bày theo những kiến thức tổng hợp của cá nhân. Kết quả nghiên cứu trong luận văn này
chưa từng được công bố tại bất kỳ cơng trình nào khác. Trong q trình làm luận văn,
tơi có tham khảo các tài liệu có liên quan và đã ghi rõ nguồn tài liệu tham khảo. Tơi xin
cam đoan đây là cơng trình nghiên cứu của tôi và không sao chép của bất kỳ ai.
Tôi xin chịu hồn tồn trách nhiệm, nếu sai, tơi xin chịu mọi hình thức kỷ luật
theo quy định.
Học viên
Lê Thanh Hải
3
LỜI CẢM ƠN
Trước tiên, tơi xin bày tỏ lịng biết ơn sâu sắc tới TS. Trần Hoàng Hải và các thầy
cô Viện CNTT-TT, Trường Đại học Bách Khoa Hà Nội. TS đã nhiệt tình hướng dẫn,
đào tạo và tạo mọi điều kiện thuận lợi cho tôi nghiên cứu khoa học, đồng thời giúp tơi
có thể hồn thành luận văn một cách tốt nhất.
Cuối cùng tôi xin gửi lời cám ơn đến gia đình, bạn bè, những người đã ln bên
tơi, động viên và khuyến khích tơi trong q trình thực hiện đề tài nghiên cứu của
mình.
Học viên
Lê Thanh Hải
4
MỤC LỤC
LỜI CAM ĐOAN .........................................................................................................................3
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT ...........................................................................6
DANH MỤC CÁC HÌNH ẢNH ....................................................................................................8
MỞ ĐẦU .................................................................................................................................... 10
PHẦN I: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ ................................................... 12
1.1 Tìm hiểu về kiến trúc hướng dịch vụ. .......................................................................................... 12
1.2 Bốn nguyên tắc chính khi xây dựng một hệ thống kiến trúc hướng dịch vụ................................ 13
1.3 Ngôn ngữ đánh dấu mở rộng (XML) trong kiến trúc hướng dịch vụ. ......................................... 14
1.4 Tính chất của một hệ thống kiến trúc hướng dịch vụ ................................................................... 18
1.5 Ích lợi khi sử dụng kiến trúc hướng dịch vụ ................................................................................ 21
PHẦN II: ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ TRONG CLOUD COMPUTING ..... 23
2.1 Mối quan hệ giữa kiến trúc hướng dịch vụ và điện toán đám mây .............................................. 23
2.1.1 Điện toán đám mây là gì?...................................................................................................... 23
2.1.2 Mối quan hệ giữa điện tốn đám mây và kiến trúc hướng dịch vụ. ...................................... 23
2.2 Lớp kiến trúc kiến trúc hướng dịch vụ trong điện toán đám mây ................................................ 25
PHẦN III: GIỚI THIỆU VỀ ORACLE SOA SUITE VÀ ỨNG DỤNG TRONG TRIỂN KHAI 33
3.1 Giới thiệu về Oracle SOA Suite. .................................................................................................. 33
3.1.1 ServiceBus ............................................................................................................................ 36
3.1.2 BpelEngine ............................................................................................................................ 39
3.1.3 BPEL Designer...................................................................................................................... 42
3.2 Thiết kế một kiến trúc hướng dịch vụ đơn giản ........................................................................... 47
3.2.1 Thiết lập môi trường Oracle SOA Suite ................................................................................ 47
3.2.2 Thiết kế ứng dụng ................................................................................................................. 48
PHẦN IV: HƯỚNG PHÁT TRIỂN CHO ĐỀ TÀI ........................................................................... 63
PHẦN V: KẾT LUẬN ......................................................................................................................... 64
TÀI LIỆU THAM KHẢO ................................................................................................................... 65
5
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT
Từ viết tắt
Giải nghĩa
API
Application Programming Interface.
BPEL
Business Process Execution Language.
CICS
Customer Information Control System.
CNTT
Công Nghệ Thông Tin.
CORBA
Common Object Request Broker Architecture.
CRM
Customer-relationship Management.
CSDL
Cơ Sở Dữ Liệu.
DCOM
Distributed Component Object Model.
EDI
Electronic Data Interchange.
EIS
Enterprise Information Systems.
EJB
Enterprise Java Beans.
FTP
File Transfer Protocol.
HTTP
The Hypertext Transfer Protocol.
IMS
IP Multimedia Subsystem.
IT
Information Technology.
JCA
Java Connector Architecture.
JDBC
Java Database Connectivity.
JMS
Java Message Service.
JSF
Java Server Faces.
6
MSMQ
Microsoft Message Queuing.
ROI
Return on Investment.
SCA
Service Component Architecture.
SDO
Service Data Objects.
SLA
Service-level Agreement.
SMTP
Simple Mail Transfer Protocol.
SOA
Service-Oriented Architecture.
SOAP
Simple Object Access Protocol.
SOCCA
Service-Oriented Cloud Computing Architecture.
SQL
Structured Query Language.
UDDI
Universal Description, Discovery and Integration.
WSBPEL
Web Services Business Process Execution Language.
WSDL
Web Services Description Language.
XML
Extensible Markup Language.
XSLT
XSL Transformations.
7
DANH MỤC CÁC HÌNH ẢNH
Hình ảnh
Trang
Hình 1.1 Sơ đồ cộng tác trong kiến trúc hướng dịch vụ.
12
Hình 1.2 Ngơn ngữ đánh dấu mở rộng trong tích hợp hệ thống.
15
Hình 1.3 Tính chất ít kết dính trong kiến trúc hướng dịch vụ.
18
Hình 1.4 Tính chất sử dụng lại dịch vụ trong kiến trúc hướng dịch vụ.
19
Hình 1.5 Khả năng cộng tác trong kiến trúc hướng dịch vụ.
20
Hình 2.1 Điện tốn đám mây kết hợp kiến trúc hướng dịch vụ.
24
Hình 2.2 Kiến trúc kiến trúc hướng dịch vụ trong điện toán đám mây.
25
Hình 2.3 Kiến trúc phân tầng hệ thống kiến trúc hướng dịch vụ.
28
Hình 3.1 Mơ hình Oracle SOA Suite.
33
Hình 3.2 Đa kênh trên Oracle SOA Suite.
34
Hình 3.3 Tiêu chuẩn Oracle SOA Suite.
34
Hình 3.4 Oracle ServiceBus.
37
Hình 3.5 BPEL Process.
39
Hình 3.6 Mơ hình tổng quát BPEL Engine.
40
Hình 3.7 Giao diện màn hình chính.
42
Hình 3.8 Application Navigator.
42
Hình 3.9 Application View.
43
Hình 3.10 Log Window.
44
Hình 3.11 Thành phần Palette.
44
Hình 3.12 Giao diện WebLogic Server.
45
Hình 3.13 Middleware Control Manager.
46
8
Hình 3.14 ServiceBus Control.
46
Hình 3.15 Cài đặt Oracle Fusion Middleware.
48
Hình 3.16 Các dịch vụ trong demo.
50
Hình 3.17 Biến yêu cầu vào ra trong xác thực thanh tốn.
51
Hình 3.18 Thiết lập điều kiện thanh tốn.
52
Hình 3.19 Mã nguồn tự sinh ra trong BPEL.
53
Hình 3.20 BPEL của ServiceBus xác thực thanh tốn.
54
Hình 3.21 Thơng tin u cầu lược đồ.
54
Hình 3.22 Biến u cầu vào ra trong xử lý đơn hàng.
56
Hình 3.23 Mối quan hệ điều kiện trong tiếp nhận đơn hàng.
56
Hình 3.24 Thiết lập điều kiện trong xử lý đơn hàng.
57
Hình 3.25 Kiểm tra điều kiện đơn hàng.
58
Hình 3.26 BPEL của ServiceBus xử lý đơn hàng.
59
Hình 3.27 Chi tiết của ServiceBus xử lý đơn hàng.
59
Hình 3.28 Lựa chọn dịch vụ phù hợp cho kênh tạo mới.
60
Hình 3.29 BPEL thêm kênh tạo mới yêu cầu ProcessPS_File.
60
Hình 3.30 Cấu hình proxy cho dịch vụ mới.
61
Hình 3.31 Nhà quản trị kiểm tra lại trạng thái dịch vụ.
61
9
MỞ ĐẦU
Lý do lựa chọn đề tài:
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, các cơ sở 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. Lúc này các sản phẩm sẽ có độ phức tạp lớn hơn,
từ đó kéo theo các vấn đề liên quan như chi phí sản xuất, chi phí quản lý và bảo trì.
Đồng thời, 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
khi chia sẻ, tương tác, giao tiếp giữa các thiết bị khác nhau.
Để giải quyết vấn đề này, doanh nghiệp cần phải thay đổi theo một chuẩn thống
nhất chung nào đó. Có nhiều giải pháp đã được đưa ra, trong đó kiến trúc hướng dịch
vụ là một giải pháp đem lại nhiều kết quả khả quan giúp giải quyết các thách thức nêu
trên.
Mục đích nghiên cứu của luận văn, đối tượng, phạm vi nghiên cứu:
Tìm hiểu các vấn đề liên quan dến xây dựng kiến trúc hướng dịch vụ, các tính chất
cùng với những lợi ích đạt được của hệ thống theo mơ hình kiến trúc hướng dịch vụ
trong điện tốn đám mây. Xây dựng ứng dụng Oracle SOA Suite nhằm hỗ trợ việc thiết
kế, xây dựng và triển khai hệ thống kiến trúc hướng dịch vụ dễ dàng hơn. Cung cấp
môi trường quản lý linh hoạt thông qua những dịch vụ web đã được xây dựng sẵn mà
không cần nhiều mã lệnh.
Phương pháp nghiên cứu:
Tiếp cận các bài báo nghiên cứu về điện toán đám mây và kiến trúc hướng dịch vụ.
So sánh ưu nhược điểm khi ứng dụng kiến trúc hướng dịch vụ. Tìm hiểu các cơng ty
triển khai dịch vụ đám mây lớn đang sử dụng mơ hình kiến trúc hướng dịch vụ như
Microsoft Azure, Amazon EC2, Oracle SOA Suite, … để đánh giá tính ứng dụng thực
tế của kiến trúc hướng dịch vụ trong điện toán đám mây.
10
Cấu trúc luận văn gồm 5 phần:
Chương I: Tổng quan về kiến trúc hướng dịch vụ:
• Giới thiệu về kiến trúc hướng dịch vụ và các nguyên tắc khi xây dựng
một hệ thống theo kiến trúc hướng dịch vụ.
Chương II: Ứng dụng kiến trúc hướng dịch vụ trong điện toán đám mây:
• Trình bày mối liên quan giữa kiến trúc hướng dịch vụ và điện toán
đám mây giúp cùng tồn tại, bổ xung và hỗ trợ mật thiết với nhau.
Chương III: Giới thiệu Oracle SOA Suite và ứng dụng trong triển khai:
• Giới thiệu tổng quát về ứng dụng Oracle SOA Suite. Trình bày tổng
qt về ba thành phần chính ServiceBus, BpelEngine và BpelDesigner.
• ServiceBus cung cấp mơi trường quản lý các dịch vụ dựa trên cơ chế
thông điệp. BpelEngine cung cấp mơi trường triển khai cho các tiến
trình. BpelDesigner cung cấp môi trường trực quan cho người dùng.
Chương IV: Hướng phát triển cho đề tài.
Chương V: Kết luận.
Đóng góp của luận văn:
Nghiên cứu, tìm hiểu về ưu nhược điểm kiến trúc hướng dịch vụ trong điện toán
đám mây. Đây là một kiến trúc lý tưởng cho các hệ thống quản lý của các tổ chức
doanh nghiệp. Với kết cấu mở, linh hoạt, dễ mở rộng, và tính liên kết cao giúp các hệ
thống doanh nghiệp xây dựng theo kiến trúc hướng dịch vụ kết hợp điện toán đám mây
giảm được các chi phí xây dựng, bảo quản, triển khai, tránh những rủi ro về sự thay đổi
xẩy ra trong môi trường hoạt động nghiệp vụ của các tổ chức.
11
CHƯƠNG I: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ
1.1 Tìm hiểu 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 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 liên kết mềm dẻo
(loose coupling), và có khả năng truy cập thơng qua mơi trường mạng. Hiểu một cách
đơn giản thì một hệ thống kiến trúc hướng dịch vụ là một tập hợp các dịch vụ được
chuẩn hoá trên mạng trao đổi với nhau thơng qua ngữ cảnh một quy trình nghiệp vụ.
Xương sống của kiến trúc hướng dịch vụ đó là các dịch vụ. Các dịch vụ là các
thành phần phần mềm có thể dễ dàng tái sử dụng, mỗi dịch vụ sẽ thực thi một tác vụ cụ
thể giúp nhà phát triển có thể dễ dàng sử dụng nó trên nhiều nền tảng.
Sơ đồ cộng tác trong kiến trúc hướng dịch vụ (Hình 1.1) có ba đối tượng chính:
Nhà cung cấp (service provider) cần cung cấp thông tin về dịch vụ của mình cho
một dịch vụ lưu trữ thơng tin dịch vụ (service registry). Người sử dụng (service
requestor) thông qua lưu trữ thơng tin dịch vụ để tìm kiếm thơng tin mơ tả về dịch vụ
cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp.
Hình 1.1 Sơ đồ cộng tác trong kiến trúc hướng dịch vụ. [1], [10]
12
Kiến trúc hướng dịch vụ cung cấp 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 kiến trúc hướng dịch vụ được tổ chức theo các dạng module
nên nó dễ mở rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử
dụng những tài nguyên hiện có.
1.2 Bốn nguyên tắc chính khi xây dựng một hệ thống kiến trúc hướng dịch vụ.
Tríêt lý kiến trúc hướng dịch vụ khơng hồn tồn mới, DCOM (Mơ hình đối tượng
có thành phần phân tán) và CORBA (Kiến trúc môi giới yêu cầu đối tượng chung)
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 thoả
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 DCOM này.
Ưu điểm lớn nhất của kiến trúc hướng dịch vụ là khả năng kết nối mềm dẻo và tái
sử dụng. Nguyên nhân là do kiến trúc hướng dịch vụ 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ụ. Để
làm được điều này, hệ thống kiến trúc hướng dịch vụ khi xây dựng cần đảm bảo các
nguyên tắc sau:
Phân định rạch rịi ranh giới giữa các dịch vụ:
• Các dịch vụ thực hiện q trình tương tác chủ yếu thơng qua thành phần giao
tiếp. Thành phần giao tiếp qui định về những định dạng thơng điệp sử dụng
trong q trình trao đổi và là cách duy nhất để các đối tượng bên ngồi có
thể truy cập thơng tin và chức năng của dịch vụ.
• Ta chỉ cần gửi các thơng điệp theo các định dạng đã được định nghĩa trước
mà không cần phải quan tâm đến cách xử lý của dịch vụ như thế nào.
13
Các dịch vụ tự hoạt động:
• Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc
lập mà không lệ thuộc vào một dịch vụ khác.
• Dịch vụ phải có tính bền vững cao để tránh các cuộc tấn cơng từ bên ngồi
(như gửi thơng điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các kỹ
thuật về an toàn, bảo mậ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 của nó ra bên ngồi, 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 (độc lập ngơn ngữ, độc lập hệ nền).
• Hệ thống sẽ có tính liên kết và khả năng dễ mở rộng.
Tương thích của dịch vụ dựa trên chính sách:
• Một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các
chính sách và u cầu của dịch vụ đó như là mã hóa, bảo mật, v.v.
• Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp cơng khai các u cầu,
chính sách đó.
1.3 Ngơn ngữ đánh dấu mở rộng (XML) trong kiến trúc hướng dịch vụ.
Kiến trúc hướng dịch vụ dựa trên tiêu chuẩn mở, và là trung gian cho các nền tảng
khác nhau, khơng phải phụ thuộc lẫn nhau. Chính vì thế, kiến trúc hướng dịch vụ cần
sử dụng một loại ngôn ngữ giúp dễ dàng truyền tải giữ liệu giữa các nền tảng với nhau.
Ngôn ngữ đánh dấu mở rộng là sự lựa chọn phù hợp trong kiến trúc hướng dịch vụ vì
các lý do sau:
• Ngơn ngữ đánh dấu mở rộng là một ngôn ngữ độc lập nền tảng, giúp các hệ
thống khác nhau có thể hiểu được nhau. Ngôn ngữ đánh dấu mở rộng là nền
14
tảng tiêu chuẩn của các dịch vụ web như XML schema, SOAP, WSDL, và
UDDI (Hình 1.2).
• Ngơn ngữ đánh dấu mở rộng được sử dụng để giao tiếp trên giao thức
HTTP. Giao thức truyền siêu văn bản HTTP là một trong các giao thức
chuẩn về mạng Internet, được dùng để liên hệ thông tin giữa bên cung cấp
dịch vụ (Web server) và bên sử dụng dịch vụ (Web client), là giao thức
Client/Server dùng cho World Wide Web.
Hình 1.2 Ngơn ngữ đánh dấu mở rộng trong tích hợp hệ thống.
Tiêu chuẩn xây dựng ngôn ngữ đánh dấu mở rộng trong kiến trúc hướng dịch vụ
bao gồm:
• WSDL (Web Service Description Language) ngôn ngữ mô tả các dịch vụ web:
định nghĩa cách mô tả dịch vụ Web theo cú pháp tổng quát của ngôn ngữ đánh
dấu mở rộng, bao gồm các thông tin:
15
o Tên dịch vụ, giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm
của dịch vụ Web.
o Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện
của dịch vụ Web cộng với tên cho giao diện này).
o Một ngôn ngữ mô tả các dịch vụ web hợp lệ gồm hai phần: phần giao
diện (mô tả giao diện và phương thức kết nối) và phần thi hành mô tả
thông tin truy xuất CSDL. Cả hai phần này sẽ được lưu trong 2 tập tin
ngôn ngữ đánh dấu mở rộng tương ứng là tập tin giao diện dịch vụ và tập
tin thực thi dịch vụ. Giao diện của một dịch vụ Web được miêu tả trong
phần này đưa ra cách thức làm thế nào để giao tiếp qua dịch vụ web. Tên,
giao thức liên kết và định dạng thông điệp yêu cầu để tương tác với dịch
vụ web được đưa vào thư mục của ngơn ngữ mơ tả các dịch vụ web.
• UDDI (Universal Description, Discovery, and Integration): Để có thể sử
dụng các dịch vụ, trước tiên bên khách hàng phải tìm dịch vụ, ghi nhận
thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ.
UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép
bên khách hàng truy tìm và nhận những thông tin được yêu cầu khi sử dụng
dịch vụ Web. Cấu trúc UDDI:
o Trang trắng (white pages): chứa thông tin liên hệ và các định dạng
chính yếu của dịch vụ web, chẳng hạn tên giao dịch, địa chỉ, thông
tin nhận dạng ... Những thông tin này cho phép các đối tượng khác
xác định được dịch vụ.
o Trang vàng (yellow pages): chứa thông tin mô tả dịch vụ Web theo
những loại khác nhau. Những thông tin này cho phép các đối tượng
thấy được dịch vụ web theo từng loại với nó.
o Trang xanh (green pages): chứa thông tin kỹ thuật mô tả các hành vi
và các chức năng của dịch vụ web ...
16
• SOAP (Simple Object Access Protocol) giao thức truy cập đối tượng đơn
giản.
o Giao thức truy cập đối tượng đơn giản là một giao thức giao tiếp có
cấu trúc như ngơn ngữ đánh dấu mở rộng. Nó được xem là cấu trúc
xương sống của các ứng dụng phân tán được xây dựng từ nhiều ngôn
ngữ và các hệ điều hành khác nhau. Giao thức truy cập đối tượng đơn
giản là giao thức thay đổi các thông điệp dựa trên ngôn ngữ đánh dấu
mở rộng qua mạng máy tính, thơng thường sử dụng giao thức HTTP.
o Một client sẽ gửi thông điệp yêu cầu tới server và ngay lập tức server
sẽ gửi những thông điệp trả lời tới client. Cả SMTP và HTTP đều là
những giao thức ở lớp ứng dụng của giao thức truy cập đối tượng
đơn giản nhưng HTTP được sử dụng và chấp nhận rộng rãi hơn bởi
ngày nay nó có thể làm việc rất tốt với cơ sở hạ tầng Internet.
Tóm lại, cơng nghệ dịch vụ web nói chung và ngơn ngữ đánh dấu mở rộng nói
riêng có thể được dùng để xây dựng cầu nối giao tiếp cho các hệ thống xây dựng trên
những hệ nền, sử dụng những công nghệ hay chuẩn khác xa nhau, như là .NET, J2EE,
CORBA, WebSphere MQ ...
Một trong các ưu điểm của một cầu nối giao tiếp được định nghĩa tốt đó là nó có
thể được mở rộng để có thể bổ sung thêm các đặc tính mới của dịch vụ web hay tích
hợp thêm các hệ thống cũ. Khi đó, các hệ thống cũ sẽ được dịch vụ hóa bằng cách định
nghĩa thêm các đặc tả dịch vụ cho chúng và xây dựng thêm các bộ xử lý thông điệp
giao thức truy cập đối tượng đơn giản. Các bộ xử lý thông điệp giao thức truy cập đối
tượng đơn giản này có khả năng nhận các thơng điệp giao thức truy cập đối tượng đơn
giản và chuyển đổi chúng sang dạng thông điệp hay lời gọi phương thức đặc thù của hệ
thống cũ. Lợi ích đạt được của cách làm này là vơ cùng lớn, nó cho phép các tổ chức
có thể tái sử dụng lại các giá trị sẵn có và khơng phải thực hiện cơng việc gỡ bỏ, thay
thế đầy tốn kém và rủi ro.
17
Một số dạng hệ thống cũ có khả năng dịch vụ hóa, bao gồm:
• Các hệ thống mainframe (ví dụ như CICS và IMS).
• Các ứng dụng phân tán hướng đối tượng (như CORBA, DCOM, EJB).
• Các hệ thống xử lý giao tác (như Tuxedo và Encina).
• Các ứng dụng đóng gói (như các ứng dụng của SAP, PeopleSoft, Oracle).
• Các hệ quản trị cơ sở dữ liệu (như Oracle, Sybase, DB2, SQL Server).
• Các hệ thống B2B và xử lý thông điệp (như SWIFT, EDIFACT, X12, HL7,
WebSphere MQ, JMS, MSMQ).
1.4 Tính chất của một hệ thống kiến trúc hướng dịch vụ
Dịch vụ kết nối mềm dẻo:
Hình 1.3 Tính chất ít kết dính trong kiến trúc hướng dịch vụ. [9]
• Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh
sửa hệ thống của chính nó trong tương lai. Tính ít kết dính của kiến trúc
hướng dịch vụ là cách các dịch vụ được triển khai mà không ảnh hưởng đến
các dịch vụ khác. Sự tương tác duy nhất giữa ứng dụng và dịch vụ là thông
18
qua các giao diện. Vì thế giúp tăng tính linh hoạt và khả năng triển khai cài
đặt vì phía u cầu dịch vụ không cần quan tâm đến địa chỉ hoặc công nghệ
nền tảng của dịch vụ công nghệ
Sử dụng lại dịch vụ:
Hình 1.4 Tính chất sử dụng lại dịch vụ trong kiến trúc hướng dịch vụ. [9]
• Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi
nhất định nên chúng dễ dàng được tìm thấy và tái sử dụng.
• Tái sử dụng lại các dịch vụ giúp loại bỏ những thành phần trùng lặp, tăng độ
vững chắc trong cài đặt, đơn giản hố việc quản trị.
Dễ kiểm tra và sửa lỗi:
• Vì các dịch vụ là tách biệt nhau nên người phát triển dễ dàng kiểm tra và
sửa lỗi theo từng dịch vụ riêng lẻ.
19
Khả năng cộng tác cao:
Hình 1.5 Khả năng cộng tác trong kiến trúc hướng dịch vụ. [17]
• Các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và 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, chứa bên trong nó một giao thức và một định dạng dữ liệu
mà mỗi khách hàng kết nối đến nó đều hiểu.
• Kiến trúc hướng dịch vụ có thể chuyển tiếp nội dung 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ụ.
Sử dụng lại các thành phần sẵn có:
• Nó giúp các công ty thu được giá trị nhiều hơn bằng cách sử dụng lại những
tài ngun sẵn có.
• Giảm chi phí cho phần kiến trúc và tích hợp; giảm chi phí mua phần mềm
mới. Giảm chi phí phát triển và kiểm thử, và tránh công việc trùng lặp.
20
• Kiến trúc hướng dịch vụ 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ừ những hệ thống có sẵn, cung cấp cho
người cuối những chức năng liên kết.
1.5 Ích lợi khi sử dụng kiến trúc hướng dịch vụ
Xây dựng các ứng dụng kinh doanh nhanh hơn và dễ dàng hơn:
• Khi các ứng dụng kinh doanh được xác định chính xác, doan nghiệp sẽ lựa
chọn đúng các dịch vụ phù hợp, đồng thời làm giảm việc viết code cho ứng
dụng. Việc mà nguồn ứng dụng ít hơn thì xác suất lỗi cũng giảm thiểu, đồng
nghĩa với việc dễ dàng kiểm tra lỗi và quá trình phát triển ứng dụng được rút
ngắn.
Dễ dàng bảo trì và cập nhật phần mềm:
• Do các dịch vụ đã được xác định nên mã nguồn ứng dụng cũng giảm đáng
kể, từ đó người phát triển dễ dàng bảo trì ứng dụng hơn. Hơn nữa, người sử
dụng các dịch vụ web cũng sẽ không bị ảnh hưởng bởi sự thay đổi bên trong
dịch vụ web. Ví dụ việc thêm mới cơ sở dữ liệu vào dữ liệu, dịch vụ web chỉ
việc thay đổi các thông tin từ CSDL mới mà nó phản hồi mà khơng cần nhà
phát triển ứng dụng dừng hoạt động của CSDL cũ. Ở cấp độ cao hơn, nếu
tiến trình doanh nghiệp bị thay đổi thì các dịch vụ tương đương sẽ được biên
soạn lại để thích ứng với các thay đổi đó và nó cũng nhất quán trong suốt
ứng dụng của doanh nghiệp.
Dễ dàng mở rộng kinh doanh:
• Trong bối cảnh hiện nay, sự thay đổi cực kỳ nhanh chóng, chính vì thế sự
thay đổi kịp thời của doanh nghiệp để phản úng lại những thay đổi nhanh
chóng này có ý nghĩa rất lớn. Các thành phần dịch vụ đóng vai trị quan
trọng trong khía cạnh này, điều này được chứng minh khi yêu cầu của một
21
dịch vụ được thay đổi, tất cả những gì cần làm là thay thế các dịch vụ cấu
thành liên quan để cập nhật lại tiến trình dịch vụ. Đồng thời việc thiết kế ứng
dụng cho doanh nghiệp cũng phải dễ dàng mở rộng kinh doanh khi một dịch
vụ hoàn toàn mới xuất hiện, những gì cần làm là kết nối các dịch vụ liên
quan đã có sẵn mà khơng cần phải sửa đổi mã nguồn quá nhiều.
Giảm chi phí cho doanh nghiệp:
• Doanh nghiệp sẽ tiết kiệm chi phí đáng kể khi không phải đầu tư quá nhiều
vào việc sở hữu hạ tầng CNTT, thay vào đó là việc sử dụng các dịch vụ từ
bên thứ 3. Đồng thời dễ dàng nhận thấy việc phát triển sản phẩm nhanh cũng
giúp rút ngắn thời gian sản phẩm doanh nghiệp được đưa ra thị trường và
tăng lợi nhuận cho doanh nghiệp.
Trên đây là phần trình bẩy tổng quan và đặc trưng nhất về kiến trúc hướng dịch vụ.
Với đặc tính trên, kiến trúc hướng dịch vụ có rất nhiều ưu việt trong việc thiết kế hệ
thống phần mềm doanh nghiệp nói chung và doanh nghiệp sử dụng dịch vụ điện toán
đám mây nói riêng gồm: dễ dàng chỉnh sửa, mở rộng, nâng cấp hệ thống và nhanh
chóng tạo ra các tiến trình nghiệp vụ từ các dịch vụ sẵn có trước đó.
Vậy áp dụng kiến trúc hướng dịch vụ ấy vào giải pháp điện toán đám mây như thế
nào? Phần tiếp theo sẽ đi sâu hơn về mơ hình kiến trúc hướng dịch vụ trong điện toán
đám mây.
22
CHƯƠNG II: ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ TRONG ĐIỆN
TOÁN ĐÁM MÂY
2.1 Mối quan hệ giữa kiến trúc hướng dịch vụ và điện toán đám mây.
Hiện nay, điện toán đám mây là một giải pháp được nhiều doanh nghiệp lựa chọn
sử dụng trong hệ thống CNTT doanh nghiệp nhằm giảm chi phí đầu tư ban đầu về cơ
sở hạ tầng, bên cạnh đó những chi phí như máy móc và nguồn nhân lực cũng sẽ được
giảm đến mức thấp nhất.
Ở chương này sẽ giới thiệu mơ hình điện tốn đám mây khi ứng dụng kiến trúc
hướng dịch vụ. Chương sau sẽ giới thiệu một dịch vụ điện toán đám mây cụ thể áp
dụng mơ hình kiến trúc hướng dịch vụ này.
2.1.1 Điện tốn đám mây là gì?
Điện tốn đám mây là một giải pháp cho phép cung cấp các tài nguyên công nghệ
thông tin như một dịch vụ và có khả năng thay đổi linh hoạt theo nhu cầu của người sử
dụng. Điện toán đám mây cho phép truy cập dễ dàng vào một hệ thống mạng đồng
nhất, theo nhu cầu đến một kho tài nguyên điện toán dùng chung (ví dụ: mạng, máy
chủ, lưu trữ, ứng dụng và dịch vụ), các tài nguyên này có thể được cung cấp và thu hồi
một cách nhanh chóng với yêu cầu tối thiểu về quản lý hay sự can thiệp từ phía nhà
cung cấp dịch vụ.
2.1.2 Mối quan hệ giữa điện toán đám mây và kiến trúc hướng dịch vụ.
Kiến trúc hướng dịch vụ và điện tốn đám mây có mối liên quan mật thiết với
nhau.
Kiến trúc hướng dịch vụ là kiến trúc hướng dẫn các giải pháp kinh doanh nhằm tạo
ra, quản lý, và sử dụng các thành phần tính tốn. Trong khi đó, điện tốn đám mây là
một bộ giải pháp công nghệ giúp cung cấp cho một nền tảng lớn hơn, phức tạp hơn cho
doanh nghiệp để tạo ra các giải pháp kiến trúc hướng dịch vụ của chính họ (Hình 2.1).
Nói cách khác, kiến trúc hướng dịch vụ và điện toán đám mây cùng tồn tại, bổ
xung và hỗ trợ mật thiết với nhau.
23
Hình 2.1 Điện tốn đám mây kết hợp kiến trúc hướng dịch vụ. [16]
Ưu điểm của điện tốn đám mây:
• Giảm chi phí đầu tư và cân đối giá thành.
• Tăng tính mở rộng.
• Tăng tính sẵn có và độ tin cậy.
Ưu điểm của kiến trúc hướng dịch vụ:
• Tăng ROI (Tỷ suất hồn vốn).
• Tăng độ linh hoạt của tổ chức bộ máy doanh nghiệp.
• Giảm chi phí đầu tư cơ sở hạ tầng, đáp ứng tốt các thay đổi nghiệp vụ.
• Thúc đẩy sự phát triển của hệ thống sẵn có cũng như cung cấp khả năng mở
rộng hệ thống trong tương lai và tăng khả năng tích hợp cao với các hệ
thống bên ngồi.
• Hệ thống xây dựng theo mơ hình kiến trúc hướng dịch vụ đảm bảo các dịch
vụ trong hệ thống có tính độc lập cao (độ kết dính thấp) do 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.
24
2.2 Lớp kiến trúc kiến trúc hướng dịch vụ trong điện tốn đám mây
Hình 2.2 Kiến trúc kiến trúc hướng dịch vụ trong điện toán đám mây. [6], [7]
Lớp nhà cung cấp đám mây (Individual Cloud Provider Layer):
Mỗi nhà cung cấp điện toán đám mây xây dựng trung tâm dữ liệu riêng của mình
để cung cấp cho các dịch vụ đám mây. Mỗi đám mây có thể có cơng nghệ ảo hóa riêng
hoặc sử dụng cơng nghệ ảo hóa mã nguồn mở như Eucalyptus. Sự khác biệt từ việc
triển khai điện toán đám mây hiện tại so với triển khai điện toán đám mây trên nền tảng
kiến trúc hướng dịch vụ đó là các tài ngun điện tốn đám mây trong SOCCA
(Service-Oriented Cloud Computing Architecture) được chia thành các dịch vụ độc lập
như dịch vụ lưu trữ (Storage Service), dịch vụ máy tính (Computing Service) và dịch
vụ truyền thơng (Communication Service) dựa trên nền tảng mở, do đó nó có thể kết
hợp với các dịch vụ từ các nhà cung cấp đám mây khác để xây dựng nền tảng máy tính
ảo trên các đám mây.
25
