TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
=====o0o=====
TIỂU LUẬN
ĐỀ TÀI: MÔ HÌNH TÍNH TOÁN HƯỚNG DỊCH VỤ
(SERVICE-ORIENTED COMPUTING)
NHÓM 09
Giáo viên giảng dạy: TS. Vũ Thị Hương Giang
Sinh viên thực hiện: Vũ Thị Thùy Như
Phạm Thị Nhung
Nguyễn Thị Thi
Lớp: 12BCNTT2
Hà Nội, tháng 1/2013
MỤC LỤC
1. Tổng quan mô hình tính toán hướng dịch vụ
1.1 Các khái niệm và đặc trưng
1.1.1 Khái niệm
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).
Tính toán hướng dịch vụ (SOC) dùng để chỉ tập hợp các khái niệm, nguyên
lý và các phương thức dùng để tính toán trong mô hình kiến trúc hướng dịch vụ

Service-Oriented
Computing
Phương pháp ứng dụng được xây dựng
bởi các lớp, kiến trúc ứng
dụng là sự phân cấp và sự
kế thừa
Ứng dụng được xây dựng
bởi các dịch vụ lỏng lẻo và
tạo thành các ứng dụng thực
thi
Trừu tượng hóa
và liên kết
Việc phát triển ứng dụng là
một đội chịu trách nhiệm
cho toàn bộ vòng đời của
ứng dụng. các nhà phát
triển phải có kiến thức về
các lĩnh vực ứng dụng và
lập trình
Việc phát triển ứng dụng
được chia ra làm 3 phần độc
lập: người xây dựng ứng
dụng, nhà cung cấp dịch vụ,
kết nối ứng dụng. Người
xây dựng ứng dụng phải hiểu
biết về ứng dụng và không
cần biết các dịch vụ sẽ được
thực hiện như thế nào. Các
nhà cung cấp dịch vụ có thể
lập trình nhưng không cần

ứng dụng đã được tích hợp.
tính này cho phép một ứng
dụng có thể được tích hợp lại
trong thời gian chạy
Bảo trì hệ thống Người dùng phải thường
xuyên nâng cấp phần mềm.
ứng dụng phải dừng khi ta
tiến hành nâng cấp
Các mã dịch vụ ở thuộc tính
dịch vụ của các nhà cung
cấp. Dịch vụ có thể được cập
nhật mà không cần sự tham
gia của người sử dụng
1.2. Các nguyên lý của mô hình tính toán hướng dịch vụ
1.2.1 Tình huống sử dụng (Use Cases)
Tính toán hướng dịch vụ cung cấp các công cụ để mô hình hóa thông tin và
sự liên hệ giữa các mô hình, xây dựng quy trình hệ thống, bảo đảm các giao
dịch, thêm các quyết định hỗ trợ, quan hệ giữa các chức năng của thành phần
phần mềm đến các tổ chức mà họ đại diện.
Tính toán theo định hướng dịch vụ cho phép chỉnh sửa các ứng dụng mới
bằng cách cung cấp một giao diện dịch vụ Web loại bỏ vấn đề tin nhắn và cung
cấp một cơ sở ngữ nghĩa để tùy chỉnh các chức năng của ứng dụng.
Tính toán hướng dịch vụ có thể cho phép tự do lựa chọn các đối tác kinh
doanh dưa trên các tiêu chi chuẩn chất lượng của mỗi dịch vụ mà mỗi bên có thể
tùy chỉnh nó.
Tính toán theo định hướng dịch vụ cung cấp hỗ trợ lựa chọn động của các đối
tác như trừu tượng hóa, các trạng thái giao dịch sẽ được ghi và thao tác linh
hoạt, theo cách này, lựa chọn động được khai thác để mang lại khả năng chịu lỗi
cấp ứng dụng
Tính toán theo định hướng dịch vụ cho phép sử dụng hiệu quả các nguồn tài

Lộ trình nghiên cứu mô hình tính toán hướng dịch vụ đưa ra một kiến trúc
dựa trên dịch vụ được phân tầng logic, để tạo ra một môi trường IT có khả năng
tương tác và thích nghi. Môi trường này có khả năng biểu diễn các chính sách
nghiệp vụ được chi tiết hóa và các luật trừu tượng hóa. Mục đích của nó là cung
cấp tính năng để bảo đảm tính nhất quán trong tổ chức, tính sẵn sàng cao của
dịch vụ, bảo mật các dịch vụ và thông tin không công khai, kết hợp nhiều dịch
vụ như là một phần của ứng dụng phức hợp.
Sơ đồ trong hình dưới đây chỉ ra các hướng nghiên cứu SOC.
Hình 2: Các hướng nghiên cứu SOC
Về cơ bản, lộ trình nghiên cứu được chỉ ra trên 3 mức:
- Thiết lập dịch vụ (service foundation): là mức thấp nhất sử dụng các service
middleware cơ bản và thành phần kiến trúc (architectural constructs and
functionality) để mô tả, xuất bản, và khám phá (discover) dịch vụ.
- Tích hợp dịch vụ (service composition): tích hợp nhiều service nhỏ riêng lẻ để
xây dựng service phức hợp. Các service phức hợp này lại có thể được sử dụng
như một ứng dụng hoàn thiện, hay góp phần xây dựng nên các service phức hợp
mức cao hơn.
7
- Quản lý và giám sát dịch vụ (service management and monitoring): quản lý và
giám sát ứng dụng SOA trong suốt vòng đời của nó, bao gồm từ cài đặt, cấu
hình, cho tới thu thập thông tin hoạt động và tối ưu hóa dịch vụ.
- Thiết kế và phát triển dịch vụ (service-oriented engineering): quá trình thiết kế
và phát triển ứng dụng SOC.
2.2. Các hướng cụ thể trên lộ trình nghiên cứu mô hình tính toán hướng
dịch vụ
2.2.1 Thiết lập dịch vụ
Lớp dưới cùng của mô hình phát triển ứng dụng SOC là bước thiết lập dịch
vụ (service foundation) nhằm cung cấp hạ tầng middleware hướng dịch vụ có
khả năng kết nối các thành phần và hệ thống không đồng nhất, đồng thời cho
phép cung cấp dịch vụ trên nhiều kênh truy nhập như thiết bị di động, thiết bị

cung cấp sẵn. Mặt khác, nó cũng trở thành thành phần cung cấp dịch vụ bằng
cách xuất bản mô tả dịch vụ của các dịch vụ phức hợp nó tạo ra.
Kết quả nghiên cứu hiện tại
Hiện đã có một số dự án xây dựng đặc tả cho việc mô tả tiến trình nghiệp vụ,
nhằm định nghĩa và quản lý các tiến trình và tương tác nghiệp vụ, còn được gọi
là “orchestration”. Orchestration mô tả các thức các dịch vụ tương tác với nhau
ở mức thông điệp và thứ tự thực hiện tương tác dưới các góc nhìn khác nhau.
Các thách thức và vấn đề cần nghiên cứu
- Phân tích khả năng có thể phối hợp của các service
- Khả năng tự phối hợp các dịch vụ
- Phối hợp dịch vụ có quan tâm tới QoS
- Phối hợp dịch vụ hướng nghiệp vụ
- Phối hợp tài nguyên, nhân lực, và tổ chức dưới dạng dịch vụ
2.2.3 Quản lý và giám sát dịch vụ
Quản lý các dịch vụ được liên kết lỏng lẻo với nhau trong SOA là một yêu
cầu rất quan trọng. Quá trình phát triển các dịch vụ phức hợp yêu cầu cho phép
theo dõi “sức khỏe” của các dịch vụ thành phần, tránh trường hợp một thành
phần bị lối hoặc thay đổi dẫn đến gián đoạn hoạt động của một loạt dịch vụ liên
quan.
Quản lý và giám sát dịch vụ SOA bao gồm một loạt hoạt động như cài đặt và
cấu hình dịch vụ, cho tới thu thập các tham số đánh giá hiệu năng và tối ưu hóa
hệ thống để đảm bảo cung cấp dịch vụ với tốc độ đáp ứng yêu cầu.
Kết quả nghiên cứu hiện tại
9
Hình 4 mô tả một mô hình kiến trúc quản lý, kết hợp quản lý dịch vụ với một
kênh ứng dụng theo SOA. Kiến trúc này cung cấp kết nối liên tục giữa kênh ứng
dụng Web service và chuyển hướng nó tới kênh quản lý. Ví dụ về ứng dụng
quản lý bao gồm quản lý tính sẵn sàng và hiệu năng, quản lý cấu hình, lập kế
hoạch dung lượng, quản lý job, phát hiện lỗi.
Hình 4: Kiến trúc quản lý Web service

3. Xây dựng ứng dụng mô hình tính toán hướng dịch vụ
3.1 Vấn đề khi xây dựng mô hình tính toán hướng dịch vụ
3.1.1 Các yếu tố khi thiết kế SOC
Có sáu nguyên tắc thiết kế quan trọng khi hệ thống hướng dịch vụ được xây
dựng và triển khai
- Vai trò: Mỗi dịch vụ phải tương ứng với một vai trò thương mại và phải
gói gọn các khả năng của vai trò đó.
- Khả năng: Các chức năng được hỗ trợ bởi các dịch vụ phải tương ứng với
khả năng của các vai trò mà nó thực hiện.
- Tương tác: nó là tương tác giữa dịch vụ và người sử dụng, tương tác
thẳng có tác dụng:
+ Tránh các khớp nối không cần thiết để dễ dàng phát triển một trong các
bên mà không ảnh hưởng đến bên kia.
+ Cải thiện hiệu suất của toàn hệ thống
- Cấu hình lại: khi thiết kế phải chú ý đến việc phân bổ tài nguyên để khi
di dời 1 dịch vụ thì không phải cấu hình lại hệ thống đảm bảo tính trong
suốt về vị trí.
- Chú ý: Dịch vụ được triển khai trong mô trường mở nên phải đối phó với
nhiều mối đe dọa. Điều này đỏi hỏi khi thiết kế SOC phải chú ý đến vấn đề
an toàn. Để thực hiện được điều đó cần phải:
+ Sử dụng kỹ thuật của phần mềm như kiểm tra đầu vào trước khi bắt đầu
xử lý hay xác thực hoặc ủy quyền.
+ Giữa các bên tương tác phải có niềm tin lẫn nhau.
+ Có phương tiện để xác minh việc tuân thủ của các bên
- Giao diện hẹp: giao diện nên được giữ thu hẹp càng tốt
Ngoài ra khi xây dựng mô hình tính toán hướng dịch vụ cần quan tâm tới
chất lượng dịch vụ (Quality of Service -QoS).
11
3.1.2 Chất lượng dịch vụ
Chất lượng dịch vụ được đánh giá thông qua các tiêu chí sau:

- Xem xét các câu hỏi để tổ chức ý tưởng như: Ontology hỗ ứng dụng nào?;
làm thế nào để sử dụng và duy trì Ontology?; Có thể tái sử dụng và nâng
cấp Ontology không?; khái niệm quan trọng trong Ontology là gi?
- Xây dựng một hệ thống các khái niệm chính theo bậc.
- Xây dựng hệ thống các quan hệ và xác định thuộc tính.
Các hướng dẫn và quy ước để xây dựng Ontology
- Các lớp nên được đặt tên rõ ràng
- Các lớp phải tương ứng với thuộc tính nội tại của các đối tượng quan tâm.
- Lựa chọn gữa vệc tạo ra một lớp con hoặc tạo ra một thuộc tính và cho
phép nó có một loạt các giá trị.
- Các lớp và phân lớp được sát nhập thành một lớp con
- Các lớp phụ sát nhập thành một lớp con, số lượng lớn lớp con sát nhập
thành lớp.
- Anh chị em nên có mức độ tổng quát.
- Thuộc tính có thể có giá trị mặc định.
- Lớp khác nhau có các thuộc tính khác nhau.
Khi xây dựng Ontology thì ta có thể sử dụng RDF (Resource Description
Framework) hoặc OWL (Web Ontology Language).
RDF là một “bộ khung” được sử dụng để mô tả các nguồn tài nguyên trên
Internet. RDF cung cấp một mô hình dữ liệu, và một cú pháp đơn giản sao cho
các hệ thống độc lập có thể trao đổi và sử dụng nó. RDF mô tả các nguồn tài
nguyên bởi các thuộc tính (properties) và các giá trị của thuộc tính (property
values), và dùng các định danh Web (URI) để định danh các nguồn tài nguyên.
OWL là ngôn ngữ đánh dấu được sử dụng để xuất bản và chia sẻ dữ liệu sử
dụng các ontology trên Internet. OWL là một bộ từ vựng mở rộng của khung mô
tả tài nguyên (RDF) và được kế thừa từ ngôn ngữ DAML+OIL Web ontology –
một dự án được hỗ trợ bởi W3C.
Khi xây dựng một ứng dụng cụ thể ta sẽ đi tìm hiểu sâu về RDF và OWL.
3.1.4 Xây dựng các quy trình
Quy trình được tạo ra bởi 4 chiến lược sau:

ví dụ như, các chế độ lỗi của thiết lập
Thiết lập dịch vụ yêu cầu có các biểu mẫu và các liên kết rằng buộc trong việc
làm sao phục vụ các thành phần tham gia khác nhau. Nó cũng đòi hỏi công cụ để
giúp từ chối các cấu tạo không phù hợp để xây dựng hệ thống
Một khía cạnh quan trọng trong việc thiết lập dịch vụ hoặc một hệ thống đa
tác tử là để duy trì sự gắn kết toàn cầu, thường không kiểm soát toàn cầu rõ
14
ràng. Điều này đòi hỏi một phương tiện để xác định mục tiêu chia sẻ, xác định
nhiệm vụ phổ biến trên dịch vụ, và tránh những xung đột không cần thiết. Kết
quả là một sự hợp tác.
3.1.7 Xử lý ngoại lệ
Vì mô hình tính toán hướng dịch vụ rất đa dạng, phân phối và có các thành
phần tự trị nên có thể xảy ra các trường hợp ngoại lệ. Nó sẽ là tốt nếu các trường
hợp ngoại lệ đã được dự đoán trước, điều đó đỏi hỏi chương trình phải sẵn sàng
xử lý một số trường hợp ngoại lệ.
Để hiểu các trường hợp ngoại lệ, dự đoán trước các trường hợp ngoại lệ và xử
lý người ta phân loại các trường hợp ngoại lệ như sau:
- Lập trình: phát sinh từ các công cụ lập trình
- Hệ thống: xảy ra do hệ thống mạng hoặc do hệ điều hành
- Quản lý: do vấn đề quản lý tài nguyên
- Ngữ nghĩa: xảy ra khi một điều kiện tiên quyết của dịch vụ không được
đáp ứng hoặc các điều kiện thu được vi phạm một số dàng buộc ngoại lệ.
- Thực tế: phát sinh từ một hành vi vi phạm các cam kết, có thể gây ra bởi
các sự kiện ở bên ngoài phạm vi quản lý trực tiếp của hệ thống tính toán.
Từ phân loại các trường hợp ngoại lệ đó với mỗi trường hợp sẽ có phương
pháp xử lý tương ứng.
3.2 Ứng dụng thương mại điện tử - eBusiness Applications
3.2.1 Mô hình cho ứng dụng thương mại điện tử
* Mô hình eShop
- Mô hình: một cửa hàng tự phục vụ cho khách hàng bằng cách hiển thị danh

chuỗi giá trị.
- Kiến trúc eMarketplace đại diện cho một cơ quan tổng hợp của người, hệ
thống, thông tin, quy trình, dịch vụ, và các sản phẩm.
3.3 Ứng dụng xây dựng hệ thống bán hàng tự động
Hệ thống này có thể được đáp ứng một hệ thống đa tác tử, có thể tự động hoá
việc phát triển và triển khai các đại lý cần thiết để thực hiện một chuỗi cung
ứng.
16
Hình 5: Sơ đồ trình tự thể hiện sự tương tác giữa các tổ chức trong một thương mai
điện tử với một chuỗi cung ứng
Hình 5 thể hiện việc trao đổi giữa các thành phần, Tương tác giữa B2B, BOD
là các thông điệp, người gửi yêu cầu người nhận đánh giá các đơn đặt hàng và
thông báo cho người gửi các kết quả. ProcessPO sẽ được gửi bởi khách hàng.
Người gửi sẽ được nhận lại một thông điệp AckPO hoặc một DeclinePO.
17
Hình 6: Sơ đồ thể hiện các tác tử
Hình 7: Sơ đồ luồng của của chuỗi cung ứng.
18
Hình 8: Sơ đồ thể hiện quy trình và hành vi của chuỗi cung ứng
Tài liệu tham khảo
[01] Munindar P. Singh and Michael N. Huhns, Service-Oriented Computing:
Semantics, Processes, Agents, John Wiley & Sons, Ltd.
/>%D1%82%D0%B5%D1%80%D1%8B
%D0%98%D1%81%D0%B5%D1%82%D0%B8/%D0%A1%D0%B5%D1%80
%D0%B2%D0%B8%D1%81%D0%BD%D0%BE%D0%9E
%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE
%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F
%20%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA
%D1%82%D1%83%D1%80%D0%B0/Service-Oriented%20Computing-
Semantics,%20Processes,%20Agents.pdf