TIỂU LUẬN MÔ HÌNH TÍNH TOÁN HƯỚNG DỊCH VỤ

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ụ

(SOA) với các phần mềm ứng dụng được xây dựng dựa trên các thành phần độc
lập với một chuẩn giao diện.
SOC phát triển phần mềm thành 3 phần độc lập: người xây dựng ứng dụng
(Service providers), người cung cấp ứng dụng (Application builders), kết nối
ứng dụng (Service brokers)
Người cung cấp ứng dụng: Họ sử dụng các ngôn ngữ lập trình như Java, C#,
… để viết chương trình. Các thành phần sẽ được tính hợp với nhau theo một
giao diện chuẩn, gọi là dịch vụ hay mạng dịch vụ nếu các dịch vụ sử dụng trên
internet.
Kết nối ứng dụng: các dịch vụ có thể đăng ký và công bố cho việc truy nhập
chung, giúp người xây dựng ứng dụng tìm hiểu các dịch vụ mà họ cần.
Người xây dựng ứng dụng: thay vì xây dựng phần mềm từ đầu bởi các ngôn
ngữ lập trình cơ bản, người xây dựng ứng dụng đại diện cho người sử dụng cuối
để xác định ứng dụng logic của ứng dụng, sử dụng các dịch vụ chuẩn như là các
thành phần.
3
1.1.2 Đặc trưng và lợi ích
SOC được sử dụng bởi những người dùng lớn như ngân hàng (web dịch vụ
của ngân hàng). Hàng không (web dịch vụ của hàng không), cơ quan du lịch
(web dịch vụ hỗn hợp liên kết với dịch vụ hàng không, khách sạn, tàu xe…)
SOC tạo điều kiện cho các doanh nghiệp làm việc cùng nhau: các công việc
trong quá trình kinh doanh hoặc cung cấp sản phẩm sẽ dễ dàng hơn với các nhà
cung cấp ở bên ngoài.
Mục tiêu hàng đầu của SOC là tạo sự liên kết của việc truy nhập dịch vụ
phần mềm thông qua giao thức chuẩn, các chức năng có thể tự động cập nhật và
tích hợp vào ứng dụng hoặc được tích hợp vào các dịch vụ phức tạp hơn.
Lợi ích của việc sử dụng tính toán hướng dịch vụ với mô hình tính toán đối
tượng
Tính năng Object-Oriented
Computing

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

hiểu rõ về ứng dụng sẽ sử
dụng dịch vụ nào
Chia sẻ code và
tái sử dụng
Tái sử dụng code được thể
hiện ở tính kế thừa giữa các
lớp thông qua hàm thư
viện. các hàm thư viện sẽ
được cập nhập lại trong quá
trình biên dịch và có nền
tảng phụ thuộc
Tái sử dụng code là ở các
mức dịch vụ. các dịch vụ có
giao diện chuẩn và được
công bố trên các kho lưu trữ
internet. Đó là các nên tảng
độc lập có thể được tìm kiếm
và truy nhập từ xa. Các dịch
vụ môi giới cho phép chia sẻ
hệ thống dịch vụ
Liên kết động Ta phải gắn tên cho một Liên kết một dịch vụ là yêu
4
và tái cấu hình phương thức trong quá
trình chạy. các phương
thức phải liên kết đến mã
thực thi trước khi ứng dụng
được tích hợp
cầu dịch vụ đó trong thời
gian chạy. Các dịch vụ có
thể được tìm thấy sau khi

ứ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

nguyên lưới.
Tính toán theo hướng dịch vụ tạo điều kiện cho Utility Computing, đặc biệt
server dự phòng được sử dụng để đạt được khả năng chịu lỗi.
Tính toán hướng dịch vụ cung cấp một mô hình ngữ nghĩa phong phú và linh
hoạt tính toán đơn giản hoá việc phát triển phần mềm.
5
1.2.2 Mô hình kiến trúc hướng dịch vụ (SOA)
Kiến trúc hướng dịch vụ (Service Oriented Architecture) là một hướng tiếp
cận với việc thiết kế và tích hợp các phần mềm, chức năng hệ thống theo dạng
module, trong đó mỗi module đóng vai trò là một “dịch vụ có tính loose
coupling” và có khả năng truy cập thông qua môi trường mạng. Một cách đơn
giản thì một hệ thống SOA là tập hợp các dịch vụ được chuẩn 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:
Hình 1: 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.
SOA 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.
6
2. Lộ trình nghiên cứu mô hình tính toán hướng dịch vụ
2.1. Tổng quan về lộ trình nghiên cứu mô hình tính toán hướng dịch vụ

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ị

cầm tay, qua mạng Internet, mạng di động, và các hạ tầng mạng khác.
Kết quả nghiên cứu hiện tại
Hạ tầng cho Web service và SOC được xây dựng dựa trên khái niệm
Enterprise Service Bus (ESB) với hai ý tưởng chính: kết nối lỏng lẻo (loosely
couple) các hệ thống tham gia cung cấp dịch vụ, và phân rã hệ thống thành các
thành phần đơn lập dễ quản trị.
Hình 3: Enterprise Service Bus kết nối nhiều ứng dụng và công nghệ khác nhau
ESB là một mạng trao đổi thông điệp (message backbone) được thiết kế dựa
trên các chuẩn mở nhằm cho phép cài đặt, triển khai, và quản trị các hệ thống
SOA. Một mô hình khá thích hợp và thành công cho ESB là mô hình container.
Với mô hình này, việc cài đặt dịch vụ được thực hiện dựa trên các container
đảm nhận:
- Tạo kết nối và quy cách trao đổi thông điệp (Message Exchange Patterns).
- Hỗ trợ quản lý giao dịch, bảo mật, đo lường hiệu năng.
- Hỗ trợ cấu hình động.
8
- Giám sát hoạt động và trạng thái bên trong của hệ thống.
- Thực hiện chuyển đổi giao thức và dữ liệu.
- Hỗ trợ khai phá dịch vụ.
Các thách thức và vấn đề cần nghiên cứu
o Cấu hình động cho kiến trúc thực thi (run-time architecture)
o Khả năng kết nối động
o Định tuyến dựa trên chủ đề và nội dung
o Giải pháp bảo mật end-to-end
o Hỗ trợ tích hợp tiến trình, thông tin, và ứng dụng
o Cơ chế khai phá dịch vụ
2.2.2 Tích hợp dịch vụ
Lớp tích hợp dịch vụ là lớp đảm nhận việc tích hợp nhiều dịch vụ riêng rẽ
thành một dịch vụ phức hợp. Thành phần thực hiện công việc này gọi là bộ tích
hợp dịch vụ. Một mặt nó hấp thụ, sử dụng các dịch vụ đã được phát triển và

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

Trên hình 4, các tài nguyên có thể quản lý bao gồm phần mềm và phần cứng,
như phần mềm ứng dụng, thiết bị phần cứng, server,… cài đặt các giao diện
quản lý và được mô tả bằng đặc tả Web Service Distributed Management
(WSDM).
Các thách thức và vấn đề cần nghiên cứu
- Khả năng tự quản lý: Dịch vụ quản lý có khả năng tự cấu hình để thích
nghi với các môi trường khác nhau mà nó được cài đặt.
- Khả năng tự thích nghi: Dịch vụ quản lý có thể tự thích nghi theo sự thay
đổi của môi trường, tuân theo các policy định trước.
- Khả năng tự sửa lỗi: Dịch vụ quản lý có thể tự tìm, phân tích và phản ứng
với các lỗi hệ thống bằng cách thực hiện các hoạt động sửa lỗi theo policy
đã định mà không làm gián đoạn dịch vụ.
- Khả năng tự tối ưu hóa: dịch vụ có thể tự giám sát và tối ưu hóa việc sử
dụng tài nguyên hệ thống.
- Khả năng tự bảo vệ: dịch vụ có thể tự phát hiện, tìm kiếm, và bảo vệ trước
các nguy cơ tiềm tàng.
2.2.4 Thiết kế và phát triển dịch vụ
Phương pháp luận thiết kế dịch vụ SOA là rất cần thiết để thiết kế ứng dụng
SOA phù hợp với nghiệp vụ của doanh nghiệp.
Nghiên cứu hiện tại
10
- Một cách tiếp cận trực quan là porting các component đã có bằng cách sử
dụng wrapper để tạo ra SOA component.
- Phát triển hướng thành phần (component-based development)
Các thách thức và vấn đề cần nghiên cứu
- Thách thức
o nguyên lý thiết kế ứng dụng hướng dịch vụ
o các phương pháp gap analysis linh hoạt
o cơ chế quản lý (governance) dịch vụ
o nguyên lý thiết kế cho thích ứng hóa dịch vụ

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:

- Tính sẵn sàng: là sẵn sàng để sử dụng ngay lập tức hoặc sẵn sàng khi nó
cần thiết.
- Khả năng truy cập: là khả năng dịch vụ trả lời một yêu cầu tại một thời
điểm nhất định
- Tính toàn vẹn: đề cập đến thực hiện tốt các giao dịch để chống sự thay đổi
hoặc hủy dữ liệu.
- Hiệu suất: được đánh giá qua thông lượng và độ trễ. Thông lượng là số
lượng các yêu cầu dịch vụ trong một khoảng thời gian nhất định. Độ trễ là
thời gian gửi yêu cầu và nhận phản hổi
- Độ tin cậy: tỉ lệ nghịch với số lượng dịch vụ thất bại trong một khoảng
thời gian.
- Tuân thủ: theo pháp luật, theo tiêu chuẩn và thỏa thuận dịch vụ.
- An toàn an ninh: cung cấp bảo mật chống chối bỏ bằng cách chứng thực
các bên liên quan, mã hóa thông tin và duy trì hệ thống kiểm soát.
- Trung thực: chất lượng dịch vụ phải tương ứng với chất lượng quảng cáo
- Giá: bao gồm giá đăng ký sử dụng dịch vụ, duy trì dịch vụ, sửa đổi và cập
nhật.
3.1.3 Xây dựng Ontology
Ontology là một mô hình dữ liệu biểu diễn một lĩnh vực và được sử dụng để
suy luận về các đối tượng trong lĩnh vực đó và mối quan hệ giữa chúng.
Ontology cung cấp một bộ từ vựng chung bao gồm các khái niệm, các thuộc tính
quan trọng và các định nghĩa về các khái niệm và các thuộc tính này. Ngoài bộ
từ vựng, Ontology còn cung cấp các ràng buộc, đôi khi các ràng buộc này được
coi như các giả định cơ sở về ý nghĩa mong muốn của bộ từ vựng, nó được sử
dụng trong một miền mà có thể được giao tiếp giữa người và các hệ thống ứng
dụng phân tán hỗn tạp khác
Ở đây ta chỉ xem xét các khía cạnh về kỹ thuật và phương pháp xây dựng
Ontology.
Các bước để tạo ra một Ontology:
12

- 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:

- Tìm kiếm chuyển tiếp từ trạng thái đầu đến trạng thái mục tiêu để liệt kê
các trình tự kế tiếp của các trạng thái trung gian.
- Tìm ngược lại từ trạng thái mục tiêu đến trạng thái bắt đầu.
- Tinh chỉnh mô tả một quá trình trừu tượng thành một quá trình cụ thể.
13
- Xác định các hoạt động cần thiết để chuyển đổi trạng thái ban đầu vào
trạng thái cuối cùng hoặc mục tiêu.
3.1.5 Thiết kế và xây dựng Agent-Based
Có 3 bước để thiết kế Agent-Based
- Bước 1: lập bản đồ vai trò các loại Agent và khởi tạo các Agent của từng
loại
- Bước 2: tạo các mô hình dịch vụ
- Bước 3: tạo ra các mô hình định nghĩa các đường dẫn truyền thông giữa
các loại đại lý
Khi thiết kế Agent-Based ta phải quan tâm đến kỹ thuật hợp tác (Engineering
Cooperation) và tính đa dạng với độ phức tạp.
Để xây dựng một Agent hoặc một hệ thống Multiagent cách đơn giản nhất là
sử dụng một môi trường phát triển có sẵn như: Jade, Zeus, FIPA-OS, và
CoABS.
3.1.6 Làm thế nào để thiết lập dịch vụ
Việc xây dựng một ứng dụng bằng cách thiết lập dịch vụ đầu tiên đòi hỏi phải
tồn tại dịch vụ, các chức năng dịch vụ cung cấp, được định nghĩa. Khi các dịch
vụ thiết yêu bị thiếu, họ phải được xây dựng bởi nhà phát triển ứng dụng hoặc
out-sourced. Bước tiếp theo là để lựa chọn, lập kế hoạch, hoặc chỉ định sự kết
hợp mong muốn của các dịch vụ.Các thành phần của dịch vụ được thực hiện và
giám sát cho sự thành công hoặc lỗi.
Để thể hiện các thủ tục của thiết lập dịch vụ ta xây dựng đồ thị luồng công
việc miêu tả từng bước một cách đơn giản
Thiết lập dịch vụ này đòi hỏi sự trừu tượng hóa và có công cụ miêu tả các
thuộc tính cần thiết. khi có các yêu cầu, nó sẽ được đánh dấu khả năng vi phạm.

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

mục sản phẩm của công ty và cung cấp sản phẩm trên một trang web.
- Mục tiêu: giảm chi phí bán hàng
- Nhược điểm: khách hàng không thể so sánh các sản phẩm của các nhà cung
cấp khác nhau.
* Mô hình eProcurement
- Mô hình: tập trung vào khía cạnh mua của doanh nghiệp, cung cấp danh
mục nhà cung cấp để người dùng lựa chọn theo tiêu chuẩn công ty và ngoài ra
còn hỗ trợ mời đấu thầu qua web.
- Mục tiêu: tiết kiệm chi phí về hoạt động mua bán
15
- Nhược điểm: không hỗ trợ năng động
* Mô hình eAuction
- Mô hình: áp dụng mọi tình huống, nơi có biến động của cung và cầu
- Mục tiêu: tăng hiệu quả, giảm chất thải và giảm thiểu chi phí tổng thể
- Nhược điểm: khi có các nhà cung cấp trung gian thì mô hình này không
đáp ứng được.
Cả 3 mô hình trên đều bộc lộ những hạn chế, một mô hình quan trọng và đầy
hứa hẹn là eMarketplace
- Mô hình: hỗ trợ tích hợp chuỗi giá trị và dự phòng trong cấu trúc (1), (2)
dịch vụ như quảng cáo, xây dựng thương hiệu, (3) tiếp thị, (4) tài trợ, (5)
quản lý rủi ro, và (6) đóng gói sản phẩm.
- Mục tiêu: sự kết hợp của lệ phí đăng ký, phí giao dịch và phí dịch vụ.
3.2.2 Các yêu cầu kiến trúc eMarketplace
Một số yếu tố quan trọng của một eMarketplace là:
- Khả năng được tích hợp vào một môi trường mở.
- Khả năng tương tác mở rộng về tính thanh khoản, hiệu quả mạng nhưng
không nên bỏ qua khả năng của một eMarketplace là rất cụ thể cho các
nút dây chuyền cung cấp hoặc một nhóm khách hàng mục tiêu mà nó phục
vụ.
- Mô hình này kết hợp những lợi thế của bên bán, bên mua, và các mô hình

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

[02] Martin Bichler and Kwei-Jay Lin, Service-Oriented Computing

[03] Michael Huhns and Munindar P. Singh, Service-Oriented Computing:
Key Concepts and Principles, IEEE Internet Computing January •
February 2005
19
/>article=1034&context=csce_facpub&sei-redir=1&referer=http%3A%2F
%2Fscholar.google.com.vn%2Fscholar%3Fq%3Dservice-oriented
%2Bcomputing%253A%2Bsemantics%2Bprocesses%2Bagents%26btnG%3D
%26hl%3Dvi%26as_sdt%3D0%26as_vis%3D1#search=%22service-oriented
%20computing%3A%20semantics%20processes%20agents%22
[04] Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, Frank
Leymann, Service - Orientedcomputing: Aresearch Roadmap,
International Journal of Cooperative Information Systems Vol. 17, No. 2
(2008) 223–255

[05] W.T. Tsai and Yinong Chen and Gary Bitter and Dorina Miron,
Introduction to Service-Oriented Computing.

20