Tìm hiểu Lập trình hướng dịch vụ

ĐẠI HỌC QUỐC GIA TPHCM
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN


Bài Khóa Luận Môn học
Nguyên Lý và Phương Pháp Lập
Trình
Tên đề tài: Tìm hiểu về Lập Trình Hướng Dịch Vụ – ServiceOriented Programming

GVHD
HV
Lớp

Thái Hoàng Danh – CH0901009

TS.Nguyễn Tuấn Đăng
CH0901009
Cao Học K4


Tìm hiểu Lập trình hướng dịch vụ

Mục Lục
Danh mục bảng...........................................................................................................................3
Danh mục hình............................................................................................................................5
Lời giới thiệu...............................................................................................................................5
CHƯƠNG 1: GIỚI THIỆU VỀ LẬP TRÌNH HƯỚNG DỊCH VỤ...........................................6
CHƯƠNG 2: CÁC PHẦN TỬ VÀ ĐẶC TRƯNG CỦA LẬP TRÌNH HƯỚNG DỊCH VỤ....7
2.1 Các phần tử (element) của lập trình hướng dịch vụ.........................................................7

2.2 Các đặc trưng của SOP.....................................................................................................8
2.3 Ngôn ngữ mô tả kiến trúc – ADL.....................................................................................8
2.4 Các mẫu hỗ trợ cho SOP................................................................................................10
2.4.1 Mẫu Java.................................................................................................................10
2.4.1 Mẫu Jini..................................................................................................................12
2.4.1 Mẫu Openwings......................................................................................................14
2.5 Xử lí các hư hỏng của dịch vụ........................................................................................18
2.5.1 Giải pháp không làm gì “DO-NOTHING”.............................................................19
2.5.2 Truyền các ngoại lệ (exception).............................................................................20
2.5.3 Xác định các dịch vụ khác......................................................................................20
2.5.4 Sử dụng sự ủy quyền dịch vụ..................................................................................22
CHƯƠNG 3: CÔNG NGHỆ CHO LẬP TRÌNH HƯỚNG DỊCH VỤ....................................22
3.1 Microsoft .NET..............................................................................................................23
3.2 HP Cooltown..................................................................................................................24
3.3 Jini..................................................................................................................................25
3.4 Openwings......................................................................................................................26
CHƯƠNG 4: BÀI TOÁN SỬ DỤNG MÔ HÌNH LẬP TRÌNH HƯỚNG DỊCH VỤ.............26
4.1 Giới thiệu bài toán..........................................................................................................27
4.2 Giải pháp theo SOP cho bài toán....................................................................................27
4.3 Lợi ích khi tiếp cận bài toán theo SOP...........................................................................31
CHƯƠNG 5: KẾT LUẬN........................................................................................................32
Tài liệu tham khảo.....................................................................................................................33

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Danh mục bảng
Bảng 1: Mẫu Contracts.........................................................................................................12

Bảng 2: Mẫu Mobility..........................................................................................................1213
Bảng 3: Mẫu Code Security...................................................................................................14
Bảng 4: Mẫu Lease................................................................................................................14
Bảng 5: Mẫu Discovery.........................................................................................................14
Bảng 6: Mẫu Lookup...........................................................................................................14-15
Bảng 7: Mẫu Service Security...............................................................................................15
Bảng 8: Mẫu Service User Interfaces....................................................................................15
Bảng 9: Mẫu Components....................................................................................................16
Bảng 10: Mẫu Connectors..................................................................................................16-17
Bảng 11: Mẫu Container......................................................................................................17
Bảng 12: Mẫu Context.......................................................................................................17-18
Bảng 13: Mẫu Installer........................................................................................................18
Bảng 14: Mẫu Policy.........................................................................................................18-19
Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Bảng 15: Mẫu Proxy..........................................................................................................19
Bảng 16: Mẫu Management...............................................................................................19
Bảng 17: .NET Component cho SOP.................................................................................24
Bảng 18: .NET Element cho SOP......................................................................................24
Bảng 19: Các đặc tính SOP trên .NET...............................................................................25
Bảng 20: Các HP Cooltown Element................................................................................25
Bảng 21: Các đặc tính của HP Cooltown.........................................................................25-26
Bảng 22: Các Element của Jini..........................................................................................26
Bảng 23: Các đặc trưng của SOP trong Jini......................................................................26
Bảng 24: Các phần tử SOP trong Openwings....................................................................27
Bảng 25: Các đặc trưng SOP trong Openwings................................................................27


Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Danh mục hình
Hình 1: Ví dụ về ADL.............................................................................................................11
Hình 2: ADL cho hệ thống MP3..............................................................................................30
Hình 3: Hệ thống MP3..............................................................................................................31

Lời giới thiệu
Do nhu cầu phát triển phần mềm con người đã phát triển ra nhiều ngôn ngữ lập trình khác
nhau. Từ C cho đến C++ rồi C# và Java. Các ngôn ngữ này phát triển dựa trên nhiều mô hình
lập trình khác nhau từ lập trình thủ tục cho đến lập trình hàm và lập trình hướng đối tượng. Và
mỗi mô hình lập trình này được sử dụng trong các bài toán đặc thù của nó. Tuy nhiên các mô
hình lập trình hiện tại không giúp cho lập trình viên giảm bớt công việc phát triển phần mềm
vì khả năng sử dụng lại rất thấp. Với mục đích sử dụng lại càng nhiều càng tốt một mô hình
lập trình mới ra đời dựa trên nền tảng của của lập trình hướng đối tượng đó là lập trình hướng
dịch vụ. Nội dung trình bày trong các chương bên dưới sẽ cung cấp cho người đọc có cái nhìn
tổng thể về lập trình hướng dịch vụ – SOP.

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

CHƯƠNG 1: GIỚI THIỆU VỀ LẬP TRÌNH HƯỚNG DỊCH VỤ
Với sự phát triển vượt bậc của công nghệ mạng, con người trở nên gần gủi nhau hơn
thông qua những kết nối rộng lớn. Mọi người có thể gửi email hay những tin nhắn tới gia
đình hay chia sẽ dữ liệu qua hệ thống web. Trên các trang web, chúng ta có thể sử dụng rất

nhiều dịch vụ như: điện thoại internet miễn phí, phiên dịch văn bản, so sánh giá cả, đấu giá
trực tuyến. Các dịch vụ này bản thân nó rất hữu ích, nhưng Internet thì vẫn phát triển không
ngừng; việc kết nối các dịch vụ lại với nhau để tạo ra các dịch vụ mạnh mẽ hơn là một điều
hết sức khó khăn. Ví dụ, một dịch vụ có thể tự động gọi điện thoại cho một người nào đó khi
món hàng mà họ muốn mua hay đấu giá thỏa mức giá ban đầu. Việc sử dụng các dịch vụ
internet không theo cách làm của người tạo ra là một điều rất khó khăn. Nguyên nhân dẫn đến
việc này có thể là các giao tiếp [interface] không được định nghĩa đầy đủ hay thiếu tài liệu
mô tả về các interface. Sức mạnh của hệ thống mạng internet được đánh giá một cách đầy đủ
khi ta có thể tích hợp các dịch vụ để tạo ra dịch vụ mới với kiến trúc mạnh mẽ hơn.
Để hiểu về lập trình hướng dịch vụ (Service-Oriented Programming), chúng ta cần có kiến
thức về một vài mô hình lập trình ra đời trước nó bao gồm: lập trình hướng đối tượng (ObjectOriented Programming , OOP), lập trình khách chủ (Client-Server), mô hình các thành phần
(Component Models). Như chúng ta biết, OOP được xây dựng trên những vấn đề lập trình có
thể được mô hình hóa bằng những khái niệm của đối tượng. Lập trình hướng đối tượng có
một vài đặc trưng của nó như: thừa kế (inheritance), bao đóng (encapsulation) và đa xạ
(polymorphism), trừu tượng (abstraction). Còn lập trình hướng dịch vụ (Service-Oriented
Programming) được xây dựng dựa trên OOP, thêm vào đó những tiền đề giúp cho chúng ta
có thể mô hình hóa các bài toán bằng những khái niệm của dịch vụ (Services) cái mà được
cung cấp và sử dụng bởi các đối tượng.
Sau đây chúng ta sẽ tìm hiểu về khái niệm dịch vụ:
Dịch vụ (Service) là một hành vi (behavior) mang tính hợp đồng đã được định nghĩa trước.
Các hành vi này có thể được hiện thực bởi bất kì thành phần (component) nào, nó cũng có thể
được cung cấp bởi thành phần nào, dựa trên một hợp đồng duy nhất. Dịch vụ này có thể sử
Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

dụng bởi dịch vụ khác.
Mô hình thành phần (component models) qui định rằng những bài toán về lập trình có thể
được xem như những hộp đen, chúng được triển khai một cách độc lập và giao tiếp với nhau

thông qua những hơp đồng.
Mô hình client-server truyền thống không không định nghĩa trước những hợp đồng
công cộng (public contract) giữa client và server. Việc hiện thực của client và server cũng
không thể độc lập nhau. Một client chỉ có thể kết nối hay giao tiếp với một client duy nhất.
Trong mô hình SOP thì có sự khác biệt, một client không bị bó buột với bất kì server nào.
Thay vào đó, vai trò người cung cấp dịch vụ có thể thay đổi qua lại giữa client và server.

CHƯƠNG 2: CÁC PHẦN TỬ VÀ ĐẶC TRƯNG CỦA LẬP
TRÌNH HƯỚNG DỊCH VỤ
2.1 Các phần tử (element) của lập trình hướng dịch vụ
Hợp đồng (Contract): là một giao diện (interface) định nghĩa cú pháp và ngữ nghĩa của một
hành vi (behavior) đơn lẽ.
Thành phần (Component): là các phần tử tính toán có khả năng triển khai, có khả năng sử
dụng lại do tính độc lập của nó với các platform, giao thức (protocol), và môi trường triển
khai.
Bộ nối hay đầu nối (Connector): là một bản đóng gói cho phần chi tiết về phương thức vận tải
(transport) đặc thù của một contract cụ thễ nào đó. Đây cũng là một phần tử có khả năng triển
khai được.
Bộ chứa (Container): là môi trường cho việc thực thi các component. Nó chịu trách nhiệm
quản lí tính sẵn sàng (availability) và bảo mật.
Ngữ cảnh (Context): là môi trường cho việc triển khai các thành phần (bao gồm plug và play).
Nó mô tả chi tiết việc cài đặt, bảo mật, khám phá và tìm kiếm.

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

2.2 Các đặc trưng của SOP
Tính liên kết (conjunctive): Điều này nói đến khả năng sử dụng hoặc kết hợp các dịch vụ theo

những cách khác với các cách thức đã tạo ra chúng. Nó hàm ý rằng những dịch vụ đó đã tạo
ra những interface cái mà chúng ta có thể dễ dàng nhận ra.
Khả năng triễn khai (deployable): Điều này nói đến khả năng triển khai hoặc sử dụng lại các
thành phần trong bất kì môi trường nào. Điều này đòi hỏi sự độc lập về môi trường bao gồm
sự độc lập về vận tải (transport), sự độc lập về nền tảng (platform) và sự độc lập về ngữ cảnh.
Tính lưu động (mobile): Điều này nói đến khả năng di chuyển mã xung quanh mạng. Nó được
sử dụng để di chuyển các proxy, giao diện người dùng và các dịch vụ di động.
Tính sẵn sàng (available): Là một trong những tiền đề quan trọng của lập trình hướng dịch vụ
nghĩa là những mạng lưới nguồn tài nguyên dư thừa sẽ đảm bảo sự sẵn sàng cao cho SOP.
Đây cũng là mục tiêu của SOP để xử lí các lỗi xảy ra trong tính toán phân bố.
Sự bảo mật – Security: Những khái niệm của mã di động và những mạng lưới dịch vụ có khả
năng khám phá đã đưa đến những thách thức về mặt bảo mật. Trong khi SOP cho phép giới
hạn sử dụng các dịch vụ rộng hơn, nó không thể thành công nếu thiếu việc bảo vệ các dịch vụ
trước việc sự dụng không đúng đắn.

2.3 Ngôn ngữ mô tả kiến trúc – ADL
Chỉ giống như lập trình hướng đối tượng có ngôn ngữ mô hình riêng đó chính là UML,
lập trình hướng dịch vụ cũng định nghĩa ra một ngôn ngữ cho việc hô hình hóa dựa trên ngôn
ngữ mô tả cấu trúc (architecture description language). ADL bao gồm các khái niệm về các
thành phần (components), các đầu nối (connectors), các vai trò (roles), và các cổng (ports).
ADL là một kí hiệu chuẩn cho việc biểu diễn các kiến trúc giúp nâng cấp việc giao
tiếp, hình mẫu cho các thiết kế ban đầu, cho việc tạo ra sự trừu tượng cho các hệ thống có thể
chuyển nhượng, trong quá khứ việc sử dụng các hình vẽ như các hình hộp các đường để biểu
diễn các thành phần, các thuộc tính, ngữ nghĩa của các kết nối, hành vi của toàn bộ hệ thống.

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ


ADL là kết quả của việc các tiếp cận mang tính ngôn ngữ cho việc biểu diễn chính thức kiến
trúc của hệ thống. ADL tập trung vào việc biểu diễn các thành phần của hệ thống
Các điểm mạnh và điểm yếu của ADL
•

ADL là một công cụ chính thức cho việc biểu diễn hệ thống

•

Con người và máy đều có khả năng đọc được ADL

•

ADL hỗ trợ việc mô tả hệ thống ở cấp độ cao hôn trước đây

•

ADL cho phép phân tích các kiến trúc – bao gồm sự đầy đủ, nhất quán, nhập nhằng,
hiệu năng

•

ADL hỗ trợ việc tạo tự động các hệ thống phần mềm.

•

Không có thỏa thuận chung cho việc ADL nên biểu diễn gì, đặc biệt là các hành vi của
các bản kiến trúc

•


Cách biểu diễn hiện tại đang được sử dụng thật sự rất khó để phân tích cú pháp, và
không có công cụ thương mại nào hỗ trợ việc phân tích này.

•

Đa số các ADL đều được tối ưu theo chiều dọc một dạng đặc biệt của phân tích.
Sau đây là một ví dụ về ADL

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Hình 1: ví dụ về ADL

2.4 Các mẫu hỗ trợ cho SOP
Một phần quan trọng của SOP là việc định nghĩa và sử dụng các mẫu. Đa số các mẫu
áp dụng cho lập trình hướng dịch vụ đều thừa kế từ các mẫu của JAVA, Jini, và Openwings.
Sau đây là các mẫu áp dụng cho SOP:

2.4.1 Mẫu Java
Jini phát triển hầu hết sức mạnh của nó từ JAVA, vì vậy, những mẫu liên quan tới
JAVA được trình bày dưới đây. Để tiết kiệm thời gian, đối với các mẫu chúng ta chỉ phân tích
trên các khía cạnh chính sau:
•

Tên

•


Bài toán mà mẫu có thể giải quyết được

•

Ngữ cảnh

•

Giải pháp mà mẫu sử dụng để giải quyết bài toán

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Tên mẫu: Các hợp đồng (contracts)
Bài toán: Làm thế nào các hành vi (behaviors) có thể định nghĩa độc lập với
hiện thực (implementation)
Ngữ cảnh (context): Bất cứ nơi nào cần che dấu độ phức tạp
Giải pháp (solution): Khái niệm về một ý tưởng giao diện đã được bổ sung
vào Java để mô tả một hành vi cả trong cú pháp và ngữ nghĩa. Các phương
thức (method), các kiểu phương thức, các kiểu tham số của phương thức, và
kiểu của các trường (fields) qui định cú pháp của các giao diện (interface).
Các chú thích (comments), tên phương thức, và tên trường mô tả ngữ nghĩa
của giao diện. Trong mô hình này bất kì đối tượng (object) có thể hiện thực
giao diện và các giao diện có thể sử dụng tính thừa kế bao gồm cả đa thừa
kế.
Bảng 1: Mẫu Contracts
Tên mẫu: Tính di động (mobility)

Bài toán: Làm thế nào để có thể di chuyển các mã thực thi thông qua hệ
thống mạng?
Ngữ cảnh (context): Việc chuyển mã có thể có lợi hơn so với việc di chuyển
dữ liệu cho việc bảo mật, hiệu suất và khả năng tương tác.
Giải pháp (solution): Bằng cách làm cho mã trở nên khả chuyển, nó có thể
được di chuyển một cách dễ dàng từ máy này sang máy khác. Java hỗ trợ cà
khả năng di động cho mã và khả năng di động cho các trạng thái. Khả năng
di động của các trạng thái được cung cấp thông qua tuần tự hóa
(serialization). Khã năng di động của mã được cung cấp thông qua mã độc
lập với nền tảng, nó được JAVA đưa ra trong những gói được gọi là JAR.
Chúng ta có thể sử dụng JAR với bất kì hình thức chuyển file nào.
Bảng 2: Mẫu Mobility
Tên mẫu: Bảo mật mã (Code security)
Bài toán: Khi tải dữ liệu và chạy mã từ nhiều nguồn, làm thế nào nó có thể

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

được đảm bảo phần mềm sẽ không làm tổn hại đến hệ thống đích?
Ngữ cảnh (context): Bất cứ nơi nào mã di động được cung cấp từ nhiều
nguồn với độ tin cậy khác nhau.
Giải pháp (solution): Java cung cấp một hôp cát (sandbox) bảo mật, chứng
thực dựa trên quyền truy cập và việc gán các quyền riêng lẻ.
Bảng 3: Code Security

2.4.1 Mẫu Jini
Cũng giống như Java các mẫu Jini chỉ được khảo sát trên các thuộc tính gồm:
•


Tên

•

Bài toán mà mẫu có thể giải quyết được

•

Ngữ cảnh

•

Giải pháp mà mẫu sử dụng để giải quyết bài toán
Mục đích của phần này là đưa ra mô tả cho các mẫu được phát sinh từ công nghệ Jini

cua Java. Jini khắc phục những vấn đề mà tính toán phân tán đang phải đối đầu, không giống
như nhiều mô hình tính toán phân tán trước đây. Ví dụ, tính toán phân tán tồn tại hàng loạt
các vấn đề như: hư hỏng từng phần (partial failure), tính cục bộ của việc thực thi, giao diện
không đối xứng. Hư hỏng từng phần có thể xảy ra khi các phần tử như các hệ thống mạng, hư
hỏng giữa các nút. Tính cục bộ của việc thực thi nói đến những câu hỏi của việc gọi bằng
tham chiếu đối với việc gọi bằng tham trị. Trong tính toán phân tán, điều này trở thành sự so
sánh giữa việc triệu gọi từ xa với tuần tự hóa các đối tượng (object serialization). Những vấn
đề về khả năng công tác xảy ra khi các phần tử được triển khai tại nhiều thời điểm khác nhau
có những giao diện không tương thích. Thông qua việc sử dụng của mã di động,Jini loại bỏ
những vấn đề cộng tác này. Trong phần này chúng ta sẽ mô tả những mẫu sau đây: cho thuê
(lease), khám phá (discovery), tìm kiếm, bảo mật các dịch vụ, và dịch vụ giao diện người
dùng.

Thái Hoàng Danh – CH0901009



Tìm hiểu Lập trình hướng dịch vụ

Tên mẫu: Cho Thuê (Lease)
Bài toán: Làm thế nào các hư hỏng tài nguyên có thể được tìm thấy?
Ngữ cảnh (context): Trong một môi trường phân tán nào đó, nơi mà các hư
hỏng từng phần có thể xảy ra ví dụ như các mạng ngừng hoạt động chẳng
hạn.
Giải pháp (solution): Cả hai bên đồng ý việc cho thuê tài nguyên trong một
một khoảng thời gian. Việc hết hạn cho thuê được nhận biết được cả hai bên,
bất chấp việc máy tính hay mạng bị hư hỏng, vì thế các hư hỏng từng phần
đảm bảo được tìm thấy một cách đúng đắn bởi các bên
Bảng 4: Mẫu Lease
Tên mẫu: Sự phát hiện (discovery)
Bài toán: Làm thế nào phần cứng và phần mềm có thể đạt được mục tiêu
“cắm vào là chạy”, tức là theo kiểu plug và play?
Ngữ cảnh (context): Trong bất kì hệ thống nào cần giảm thiểu công việc
quản trị và tính dễ sử dụng của hệ thống được cho là quan trọng.
Giải pháp (solution): Một giao thức bootstrapping được sử dụng để tìm kiếm
các dịch vụ một cách tự động. Khi dịch vụ được tìm thấy, mọi thứ khác có
thể được tìm thấy một cách dễ dàng. Chừng nào mà kĩ thuật bootstrapping
vẫn còn thì phần mềm tương tự có thể tham gia vào trong một plug và vận
hành môi trường.
Bảng 5: Mẫu Discovery
Tên mẫu: Tìm kiếm (lookup)
Bài toán: Làm thế nào để các dịch vụ có thể được xuất bản (publish) và phát
hiện dựa vào các hợp đồng và thuộc tính của chúng?
Ngữ cảnh (context): Được sử dụng ở nơi mà việc xuất bản các dịch vụ cho
mục đích dùng chung.

Giải pháp (solution): Cho phép việc xuất bản và tìm kiếm các dịch vụ dựa
trên các hợp đồng và thuộc tính của chúng. Không giống với mô hình đường

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

ống (pipe) trong client-server, các giao diện dịch vụ được xuất bản và có thể
sử dụng bởi bất kì thành phần nào.
Bảng 6: Mẫu Look up
Tên mẫu: Bảo mật dịch vụ (Service security)
Bài toán: Làm thế nào để có thể bảo mật các dịch vụ nhằm ngăn chặn những
truy xuất trái phép?
Ngữ cảnh (context): Bất cứ nơi đâu các dịch vụ được xuất bản
Giải pháp (solution): Việc bảo mật các truy cập tới các dịch vụ tìm kiếm của
Jini và tới chính các dịch vụ đã được xuất bản là một công việc đang tiến
triển.
Bảng 7: Mẫu Service Security
Tên mẫu: Giao diện người dùng dịch vụ (Service User Interface)
Bài toán: Làm thế nào để các giao diện người dùng có thể gắn liền với các
dịch vụ?
Ngữ cảnh (context): Bất cứ khi nào có một giao diện người dùng kiểu đồ họa,
âm thanh hay một dạng nào khác cần được cung cấp bởi một dịch vụ nào đó.
Giải pháp (solution): Jini sử dụng khái niệm của một giao diện dịch vụ
(ServiceUI), ServiceUI có thể gắn với bất kỳ dịch vụ nào. Các factory được
định nghĩa cho mỗi loại giao diện người dùng (giọng nói, đồ họa,...). Những
factory được sử dụng để lấy các mã di động, các mã di động này đảm nhận
việc cung cấp giao diện người dùng. Điều này sẽ tạo ra thuận lợi cho các phần
mềm client và server bởi vì chúng luôn được đồng bô hóa.

Bảng 8: Mẫu Service User Interfaces

2.4.1 Mẫu Openwings
Jini và Java cung cấp những tính năng giúp chúng ta có thể phát huy sức mạnh của
SOP. Tuy nhiên, một vài phần tử đã bị bỏ qua, điều đó sẽ cho phép sự phát triển của các hệ
thống hướng dịch vụ qui mô lớn. Openwings tập trung vào việc khắc phục các lỗ hỏng và

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

cung cấp cho chúng ta một tập đầy đủ các phần tử và các khía cạnh bên trong của SOP. Trong
phần này những mẫu sau đây sẽ được trình bày: thành phần (component), bộ nối (connector),
bộ chứa (container), ngữ cảnh (context), bộ cài đặt (installer), chính sách (policy), proxy
Tên mẫu: Thành phần (component)
Bài toán: Thành phần nhỏ nhất (đơn vị) của việc triển khai dịch vụ là gi?
Ngữ cảnh (context): Bất kì hệ thống nào bao gồm các thiết bị phần cứng và
phần mềm cần trừu tượng hóa thành các dịch vụ.
Giải pháp (solution): Một thành sẽ đóng gói từng đơn vị triển khai của phần
cứng hay phần mềm. Các thành phần chính là đơn vị triển khai cơ bản cho
các dịch vụ (một thành phần có thể cung cấp hay sử dụng nhiều dịch vụ).
Các dịch vụ là các hợp đồng cụ thể, được cung cấp và sử dụng bởi các thành
phần. Xét trong ngữ cảnh của việc triển khai thì các thành phần là các đơn vị
hoàn toàn độc lập. Ngoài ra các thành phần cũng phải là các đơn vị độc lập
của các nền tảng (platform), giao thức vận tải (transport protocol), và chi tiết
về môi trường triển khai chẳng hạn như mô hình mạng.
Bảng 9: Mẫu Components
Tên mẫu: Bộ nối (connector)
Bài toán: Làm thế nào để các thành phần có giao thức vận tải khác nhau có

thể phối hợp và cộng tác với nhau?
Ngữ cảnh (context): Bất kì nơi nào khả năng cộng tác và hiệu quả sử dụng
băng thông được cho là quan trọng.
Giải pháp (solution): Các bộ nối cung cấp một sự trừu tượng hóa cho tính
độc lập về vận tải. Các bộ nối được phân thành hai loại đồng bộ và bất đồng
bộ. Các bộ nối bao gồm một proxy người dùng và một proxy người cung
cấp. Một proxy người dùng cung cấp một đối tượng, nó sẽ hiện thực một hợp
đồng còn proxy người cung cấp nắm giữ đối tượng này. Các bộ nối có thể
gắn lại với nhau thành một chuỗi một cách tự nhiên. Chúng cũng cung cấp
những chổ chèn vào cho việc bảo mật vận tải và chất lượng của dịch vụ. Các

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

bộ nối có thể được bọc lại trong các thành phần.
Bảng 10: Mẫu Connectors
Tên mẫu: Bộ chứa (Container)
Bài toán: Làm thế nào để quản lí tính bảo mật, tính sẵn sàng, tính di động
của việc thực thi các thành phần?
Ngữ cảnh (context): Mẫu này được sử dụng khi các dịch vụ được triển khai
như những component.
Giải pháp (solution): Một máy chủ ứng dụng (application server) là một ví
dụ của bộ chứa. Một bộ chứa của Java sẽ thực thi việc bảo mật mã bằng cách
cấu hình cho Java Security Manager. Bô chứa này có khả năng khắc phục
những thiếu xót của Java, đó là khả năng ánh xạ nhiều tiến trình với một
máy ảo Java (Java Virtual Machine – JVM). Điều này giúprút ngắn thời gian
khởi động các chương trình Java. Mẫu này có thể quản lí các bô quét của
Java và đưa ra các quyết định cân bằng tải. Các bô chứa có thể kết hợp với

nhau để tạo thành các cụm, chúng đảm bảo các dịch vụ đã được gom cụm có
thể duy trì hoạt động. Các bô chứa còn cung cấp một môi trường để hỗ trợ
cho các dịch vụ di động.
Bảng 11: Mẫu Container
Tên mẫu: Ngữ cảnh (Context)
Bài toán: Làm thế nào để tạo ra và quản lí một ngữ cảnh về sự hình thành hệ
thống và việc phát hiện các dịch vụ?
Ngữ cảnh (context): Mẫu này hữu ích trong môi trường tính toán phân bố.
Trong môi trường này các hệ thống cần phải tự hình thành và tự hồi phục.
Giải pháp (solution): Một ngữ cảnh cung cấp một môi trường cho việc tự
hình thành và tự phục hồi của hệ thống. Một ngữ cảnh sẽ thực thi một ranh
giới hệ thống, cung cấp cho việc cài đặt tự động các thành phần (xem các mô
hình trình cài đặt- installer pattern), cung cấp
dịch vụ lõi cho sự hình thành hệ thống, và quy định cách thưc để xuất bản

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

các dịch vụ và phát hiện chúng ra ngoài nhóm làm việc (workgroup). Mẫu
ngữ cảnh dựa trên thành phần có tính độc lập về môi trường (xem mẫu chiến
lược - Policy).
Bảng 12: Mẫu Context
Tên mẫu: Trình cài đặt (Installer)
Bài toán: Làm thế nào để cài đặt các phần mềm một cách an toàn và tư động
Ngữ cảnh (context): Mẫu này hữu ích cho các hệ thống có sử dụng mẫu ngữ
cảnh.
Giải pháp (solution): Mẫu “trình cài đặt” đã đảo ngược cách tiếp cận cài đặt
truyền thống. Thông thường phần mềm được cung cấp kèm với trình cài đặt

riêng của nó. Bởi vì trình cài đặt được đóng gói không có kiền thức về ngữ
cảnh triển khai, người dùng phải trả lời nhiều câu hỏi về nơi và cách thức cài
đặt phần mềm. Trong môi trường hướng dịch vụ mã di động rất phổ biến,
nhưng điều này lại khó chấp nhận. Thay vào đó, các thành phần được phân
phối cùng như các gói cùng với một ngữ cảnh của việc chạy một trình cài đặt.
Dịch vụ chuẩn bị cài đặt có thể xác nhận xem các thành phần có nên được cài
đặt hay không (bằng chữ kí).
Bảng 13: Mẫu Installer
Tên mẫu: Điều khoản (Policy)
Bài toán: Làm thế nào để trừu tượng hóa các chi tiết của môi trường từ mã
(code).
Ngữ cảnh (context): Một điều khoản sẽ hữu ích bất cứ nơi nào đã sử dụng
một file cấu hình trước đó.
Giải pháp (solution): Các chính sách hay điều khoản là các file cấu hình có
thể được tìm thấy. Ví dụ, mẫu ngữ cảnh sử dụng các plolicy để mô tả cho các
thành phần đã triển khai thông tin về môi trường triển khai của chúng. Các
điều khoản bao gồm cả hai dạng: dạng có thể đọc được và dạng các đối
tượng. Một đối tượng kiểu “điều khoản” tự bản thân chúng có thể biết được

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

cách thức để lưu trữ và phục hồi từ các file cấu hình dạng XML.
Bảng 14: Mẫu Policy
Tên mẫu: Proxy
Bài toán: Làm thế nào một giao diện có chương trình có thể được cung cấp
dưới hình thức di động nào đó.
Ngữ cảnh (context): Các proxy có thể được sử dụng với bất kì giao diện nào

để thêm một tính năng vào một đối tượng.
Giải pháp (solution): Các proxy có thể cung cấp một đối tượng, nó hiện thực
một hợp đồng hay các proxy sẽ giữ đối tượng này. Các proxy thành phần chủ
yếu được sử dụng để tạo ra các bô nối và các proxy thông minh. Các proxy
thông minh cho phép người dùng thêm vào một lớp các tính năng bổ sung
cùng với một giao diện.
Bảng 15: Mẫu Proxy
Tên mẫu: Quản lí (management)
Bài toán: Làm thế nào để xây dựng một hệ thống mà không cần bất kì sự
quản trị nào?
Ngữ cảnh (context): Bất kì môi trường nào cần tối thiểu hóa chi phí của việc
quản trị hệ thống.
Giải pháp (solution): Mỗi thành phần có một bộ khung quản lí, bộ khung này
cho phép thêm vào các khía cạnh quản lí khác nhau trong thời gian chạy đó
chính là Management Beans (Mbeans). MBeans xuất bản các giao diện phần
nhiều giống như một dịch vụ, nhưng chúng cung cấp quản lí dịch vụ hậu
cảnh. Tính năng quản lí là một phần tương đối nhẹ nhàng vì có thể tự động
hóa thông qua việc sử dụng các policy.
Bảng 16: Mẫu Management

2.5 Xử lí các hư hỏng của dịch vụ
Một khía cạnh của lập trình hướng dịch vụ xứng đáng xem xét chặt chẽ hơn là làm thế

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

nào có thể đạt được tính sẵn sàng ở mức component. Các thành phần sử dụng các dịch vụ phải
giải quyết tính chính xác của tính toán phân bố. Cụ thể là các dịch vụ trong hệ thống phân bố

có thể hư hỏng theo một cách duy nhất. Trong những kĩ thuật phân tán như Java RMI, Jini, và
Openwings, có sự thống nhất cho các developer là mỗi phương thức của giao diện dịch vụ
phải phát sinh ra các exception java.rmi.RemoteException khi dịch vụ bị hư hỏng. Làm thế
nào để một thành phần giải quyết các hư hỏng dịch vụ hoàn toàn là quyết định của các lập
trình viên. Nói một cách nghiêm chỉnh, không có giới hạn về số lượng cách để xử lí các hư
hỏng dịch vụ. Tuy nhiên, sẽ là hữu ích để xem xét số lượng chiến lược có thể cho việc xử lí
các biệt lệ.

2.5.1 Giải pháp không làm gì “DO-NOTHING”
Cách tiếp cận đơn giản nhất là giải pháp không làm gì: các đối tượng dịch vụ bị hư
hỏng sẽ được bỏ qua, và không có cố gắng tạm thời nào được thực hiện để phục hồi hoặc xác
định những dịch vụ tương đương khác. Các thành phần tiếp tục làm các việc khác và tránh các
hoạt động liên quan đến việc sử dụng dịch vụ.
try
{
service.doSomething();
}
catch (RemoteException e)
{
service = null;
// log the error
System.out.println(e.toString());
}

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

// continue…

Ví dụ về giải pháp Do-nothing

2.5.2 Truyền các ngoại lệ (exception)
Giải pháp “không làm gì” thì hoàn toàn không phù hợp với hầu hết các trường hợp.
Như một sự lựa chọn, RemoteException có thể được truyền lại và được xự lí ở mức cao hơn:
•

Các thành phần có giao diện người dùng có thể đưa vào một trạng thái nơi mà các giao
diện chờ một vài hành động người dùng, các hành động này khởi tạo dịch vụ tìm kiếm
và dịch vụ khác

•

Các thành phần sử dụng các dịch vụ hướng phiên giao dịch nơi mà thông tin phù hợp
với việc các dịch vụ của các thành phần, các thông tin này được ghi nhớ thông qua
một chuỗi các lời gọi thay gì thông qua trong mỗi lời gọi. Việc khôi phục trong trường
hợp này đòi hỏi mã cố gắng quay trở lại một trạng thái tốt nơi này sẽ thích hợp với
việc tìm và sử dụng một dịch vụ khác.

2.5.3 Xác định các dịch vụ khác
Một cách tiếp cận khác là cố gắng khôi phục bằng cách xác định một dịch vụ tương
đương khác. Mã sử dụng dịch vụ có thể đặt vào một vòng lặp để cố gắng xác định dịch vụ
tương đương khác. Nếu một dịch vụ thích hợp được tìm thấy, thành phần có thể tiếp tục các
thao tác bình thường.
boolean success = false;
int tries = 0;
while (!success && tries<3)
{
tries++;


Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

try
{
service.doSomething();
success = true;
}
catch (RemoteException e)
{
// log the error
System.out.println(e.toString());
// attempt to locate a new service
service = ...
}
}
Mã ví dụ về một khôi phục đơn giản
•

Đoạn mã cố gắng giới hạn số lần cố gắng đã thực hiện để xác định một dịch vụ mới để
mã không đi tới một vòng lặp vô tận. Có một vài sự khác biệt trong phương pháp này:

•

Số lần cố gắng khôi phục có thể khác nhau. Đoạn mã trên đã thực hiện 3 lần cố gắng

•


Một cố gắng khôi phục có thể bị ngăn chặn bởi khoảng thời gian hết hạn (timeout)
thay gì thông qua số lần đã thực hiện. Điều này đòi hỏi cách tiếp cận đa tiến trình
(multi-thread)
Cách tiếp cận này có thể đạt được lợi ích từ phương pháp lập trình hướng phương diện

(Aspect-Oriented Programming), phương pháp lập trình này được cung cấp trong ngôn ngữ
lập trình Java thông qua công nghệ AspectJ. Điều này cho phép các khối xử lí lỗi thông dụng
có thể áp dụng cho toàn bộ ứng dụng
Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

2.5.4 Sử dụng sự ủy quyền dịch vụ
Một kĩ thuật để tránh việc đưa vào các khối mã phụ là phải sử dụng một tầng trừu
tượng hóa để ẩn đi các hư hỏng dịch vụ càng nhiều càng tốt. Cách tiếp cận này sử dụng mẫu
“ủy quyền” (proxy). Mã bên phía khách (client) sẽ nhận một ủy quyền của một đối tượng dịch
vụ thực sự. Proxy này là một đối tượng cục bô và khi một trong các phương thức của đối
tượng này được gọi, proxy sẽ lần lượt gọi cùng một phương thức trên đối tượng dịch vụ, bắt
lỗi RemoteException. Nếu dịch vụ từ xa bị hỏng, proxy sử dụng chiến lược được phát thảo
như trên để xác định và sử dụng một dịch vụ tương đương. Nếu proxy không thể thành công
trong việc hoàn thành cuộc gọi sử dụng một vài đối tượng dịch vụ, nó phát sinh một biệt lệ
RemoteException.
Cách tiếp cận này có thể hiện thực một cách khá đơn giản. Phiên bản 1.3 của ngôn ngữ
lập trình Java bao gồm một tính năng được gọi là các proxy động. Việc sử dụng khả năng ánh
xạ của ngôn ngữ, máy ảo Java JVM có thể tạo động các đối tượng, các đối tượng này hiện
thực một hoặc nhiều giao diện. Những proxy động này truyền lời gọi phương thức tới các đối
tượng chịu trách nhiệm xử lí các lời gọi phương thức. Đối tượng xử lí phương thức phải hiện
thực lớp java.lang.reflect.InvocationHandler. Một đối tượng kiểu InvocationHandler sẽ được
sử dụng để ánh xạ những lời gọi phương thức với một hay nhiều đối tượng dịch vụ. Ngoài ra

nó còn có nhiệm vụ bắt các exception

CHƯƠNG 3: CÔNG NGHỆ CHO LẬP TRÌNH HƯỚNG DỊCH
VỤ
Công nghiệp phần mềm đang đưa ra những thông điệp mạnh mẽ rằng tương lai của
tính toán phân bố sẽ là hướng dịch vụ. Những thông điệp này được đưa ra bởi những tập đoàn
công nghệ lớn như: Microsoft, Hewlett Packard (HP), Sun Microsys (Oracle), Motorola. Việc
đánh giá thông điệp này củng gặp nhiều khó khăn do mỗi công ty quan niệm mô hình hướng
dịch vụ hướng theo những công nghệ của chính công ty họ, Microsoft thì có .NET,
HP lại có Cooltown, Sun thì Java/Jini và Openwings
Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Lập trình hướng dịch vụ là một mô hình lập trình cho tính toán phân bố, một phần bổ sung
cho lập trình hướng đối tượng. Nếu như OOP tập trung vào việc trả lời câu hỏi “làm gì”, “làm
như thế nào” thì SOP sẽ tập trung trả lời câu hỏi “có thể làm gì”.

3.1 Microsoft .NET
Các thành phần cơ bản của MS hỗ trợ cho SOP
Các thành phần

Mô tả

.NET™ Internet

Cung cấp các dịch vụ cần thiết như bảo

Operating System


mật, lưu trữ các file, quản lí người dùng,

Services

quản lí thời khóa biểu,...

.NET™

Chúng bao gồm MS Visual Studio, .NET

Development

Framework,Windows .NET

Infrastructure
.NET™ Device

Framework cho các thiệt bị tham gia vào

Software

hệ thống

.NET™ User

Cung cấp các cổng thông tin có thể được

Experience
truy xuất từ bất kì thiết bị mạng nào

Bảng 17: .NET Component cho SOP
Các phần tử của SOP được hỗ trợ bởi .NET
Phần tử - Element

.NET

Hợp đồng - contract

Ngôn ngữ hợp đồng dịch vụ – Service
Contract Language (SCL)

Thành phần - component

Nhà cung cấp các dịch vụ Web – Web
Service Provider

Các bộ chứa - container
Máy chủ .NET
Bảng 18: .NET Element cho SOP
Các đặc trưng của MS .NET hỗ trợ cho SOP

Thái Hoàng Danh – CH0901009


Tìm hiểu Lập trình hướng dịch vụ

Các khía cạnh của SOP

.NET


Conjunctive

Các dịch vụ có thể được kết hợp theo
nhiều cách mới mẽ

Interoperable

SCL và SOAP cung cấp khả năng cộng
tác cho .NET

Secure

C# là một cố gắng trong việc cung cấp
một ngôn ngữ bảo mật

Available

Trình phát hiện DISCO là một công cụ
quan trọng thệ hiện tính sẵn sàng của

SOP trên .NET
Bảng 19: Các đặc tính SOP trên .NET

3.2 HP Cooltown
Các Elementc của SOP trong Cooltown
Các phần tử - Element

Cooltown

Thành phần - Component


Con người, nơi chốn,..

Bộ chứa - Container
Máy chủ web (web server)
Bảng 20: Các HP Cooltown Element
Các đặc trưng của SOP trong Cooltown
Tính chất, các góc nhìn của SOP

Cooltown

Tính di động - mobility

Phân phối các trang web và mã Java
trên các web cung cấp khả năng di
động

Khả năng phát hiện - discoverable Việc nhân ra các thẻ và các tín hiệu
là một cơ chế phát hiện
Khả năng tương tác - Interoperable HTTP là một chuẩn của khả năng
cộng tác trên HP Cooltown
Tính sẵn sàng - Available

Thái Hoàng Danh – CH0901009

Khả năng phát hiện dựa trên vị trí


Tìm hiểu Lập trình hướng dịch vụ


của Cooltown cho phép người dùng
có thể chuyển từ đối tượng này sang
đối tượng khác một cách dễ dàng
Bảng 21: Các đặc tính của HP Cooltown

3.3 Jini
Các phần tử của SOP trong Jini
Các phần tử
Contracts
Bảng 22: Các Element của Jini

Jini
Các giao diện dịch vụ

Các đặc trưng của SOP trong Jini
Các đặc trưng

Jini

Tính di động - Mobility

Việc phân phát các đối tượng ủy
quyền dịch vụ và các mã phụ trợ
thông qua mạng internet

Tính kết nối - Conjunctive

Các dịch vụ được cung cấp qua hệ
thống mạng có thể được tích hợp với
nhau để thực hiện nhiệm vụ mới


Tính tương tác - Interoperable

Ngôn ngữ lập trình Java là một
chuẩn của khả năng tương tác

Tính sẵng sàng - Available

Các dịch vụ tương đương với nhau
có thể kết hợp trong trường hợp dịch
vụ bị hư hỏng

Bảo mật - Secure

Sẽ được hiện thực trong tương lai,

dựa trên RMI security
Bảng 23: Các đặc trưng của SOP trong Jini

Thái Hoàng Danh – CH0901009