luận văn công nghệ sinh học Tìm hiểu công nghệ microsoft connected services framework xây dựng giải pháp thực hiện tích hợp hệ thống cung cấp dịch vụ

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
──────── * ───────
ĐỒ ÁN
TỐT NGHIỆP ĐẠI HỌC
NGÀNH CÔNG NGHỆ THÔNG TIN
TÌM HIỂU CÔNG NGHỆ MICROSOFT
CONNECTED SERVICES FRAMEWORK
XÂY DỰNG GIẢI PHÁP THỰC HIỆN TÍCH
HỢP HỆ THỐNG CUNG CẤP DỊCH VỤ
Sinh viên thực hiện : Phạm Xuân Toàn
Lớp: CNPM - K48
Giáo viên hướng dẫn: PGS. TS. Huỳnh Quyết Thắng
Hà nội, tháng 6 - 2008
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Mục đích nội dung của ĐATN
Tìm hiểu nghiên cứu Nền cung cấp dịch vụ và các vấn đề liên quan. Đồng thời tìm hiểu về
Microsoft Connected Services Framework – một Nền cung cấp dịch vụ phát triển bởi hãng
Microsoft, từ đó nghiên cứu đưa ra giải pháp và xây dựng thử nghiệm hệ thống tích hợp
ứng dụng cho hệ thống, giải pháp lưu trữ và hỗ trợ cộng tác trực tuyến (Hosted messaging
and collaboration).
2. Các nhiệm vụ cụ thể của ĐATN
– Phân tích đánh giá sự phát triển của Kiến trúc hướng dịch vụ và nhu cầu về Nền
cung cấp dịch vụ.
– Nghiên cứu về Nền cung cấp dịch vụ: về mặt Kiến trúc tổng quan, công nghệ sử
dụng
– Tìm hiểu, nghiên cứu bài toán Lưu trữ và hỗ trợ cộng tác trực tuyến từ đó đề
xuất giải pháp tích hợp ứng dụng.
– Thiết kế, xây dựng và triển khai thử nghiệm giải pháp trên.
3. Lời cam đoan của sinh viên:
Tôi - PHẠM XUÂN TOÀN cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới

sự hướng dẫn của thầy giáo PGS. TS. Huỳnh Quyết Thắng.
Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ
công trình nào khác.
Hà Nội, ngày 17 tháng 05 năm 2008
Tác giả ĐATN
Phạm Xuân Toàn
4. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo
vệ:
Hà Nội, ngày tháng 05 năm2008
Giáo viên hướng dẫn
PGS. TS. Huỳnh Quyết Thắng
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP
Kiến trúc hướng dịch vụ đưa ra một cách tiếp cận mềm dẻo và hiểu quả cho vấn đề tích
hợp hệ thống hơn các Kiến trúc công nghệ thông tin truyền thống. Kiến trúc hướng dịch vụ
là nền tảng cơ bản sử dụng trong ngành công nghiệp viễn thông cũng như kiến trúc của các
phần mềm trung gian (mildware) trong thời gian tới. Ở khía cạnh này, nó là được xem xét
như là một sự hội tụ về mặt công nghệ, giao thức và kiến trúc đem lại nhiều lợi ích cho các
doanh nghiệp.
Thực tế để duy trì và nâng cao cạnh tranh, các doanh nghiệp ngày càng phải đưa ra nhiều
dịch vụ mới một cách nhanh nhất, có tính chất phức hợp (có sự kết hợp của nhiều yếu tố
khác nhau), ví dụ như tin nhắm đa phương tiện, Internet TV, các dịch vụ hỗ trợ, cộng tác
trực tuyến. Tuy nhiên để làm được như vậy, các doanh nghiệp gặp rất nhiều khó khăn. Các
khó khăn đó xuât phát từ nhiều yếu tố khác nhau, vè mặt hệ thống tin học, trở ngại lớn nhất
là sự rời rạc, thiếu tính liên kết giữa cá ứng dụng. Kiến trúc hướng dịch vụ được xem xét
như là một giải pháp hội tụ - một nền tảng qua đó giúp doanh nghiệp giải quyết các khó
khăn này. Ở khía cạnh này, Kiến trúc hướng dịch vụ đóng vai trò như là Nền tảng để tích
hợp hệ thống tạo nên sự liên kết, thống nhất trong toàn bộ hệ thống IT của doanh nghiệp.
Đồng thời, quá trình nghiên cứu cũng đã xem xét, kế thừa các công nghệ tích hợp mới như
XML, dịch vụ web, vai trò của các công nghệ nền tảng này trong mạng dịch vụ.
Như vậy các nhà điều hành mạng và các nhà phát triển dịch vụ cần phát triển và chuyển

giao các dịch vụ đa phương tiện, nhiều thể loại khác nhau đến người dùng. Để hỗ trợ các
dịch vụ mới cho người dùng trên các hạ tầng Công nghệ thông tin hiện có đồng thời có thể
cung cấp các tài nguyên và dịch vụ khác nhau đáp ứng nhu cầu người dùng. Để đáp ứng
được các nhu cầu này chúng ta cần các cơ chế phát triển, cài đặt dịch vụ độc lập với các hạ
tầng IT cũng như cơ chế phân phối, chuyển giao, quản lý các dịch vụ này. Nền cung cấp
dịch vụ là một nền tảng như vậy. Tuy nhiên nó chưa được chuẩn hóa, thống nhất giữa các
nhà phát triển khác nhau, đồng thời nó cũng không phải là một vấn đề cụ thể về công nghệ.
Qua tham khảo, và xem xét một số nghiên cứu và sản phẩm chúng tôi tổng quát hóa lên
kiến trúc chung của một nền cung cấp dịch vụ.
Đồ án này đóng góp trên ba khía cạnh chính: trước hết, là việc phân tích, đánh giá và kế
thừa các công nghệ sử dụng cho Mạng hướng dịch vụ. Ở đây chúng tôi xem xét khía cạnh
sử dụng Kiến trúc hướng dịch vụ như là một nền tảng để tích hợp ứng dụng, tầng kết nối
dịch vụ cho doanh nghiệp. Qua việc xem xét và phân tích nhu cầu của các hệ thống cung
cấp dịch vụ từ đó đề xuất một kiến trúc tổng quát cho Nền cung cấp dịch vụ. Thứ hai,
chúng tôi đã giành thời gian cho việc nghiên cứu xem xét CSF – Nền cung cấp dịch vụ
phát triển bởi hãng Microsoft. Quá đó đánh giá khả năng, các trường hợp, môi trường có
thể áp dụng CSF. Và cuối cùng là nghiên cứu thực trạng và đưa ra giải pháp cho bài toán
cung cấp dịch vụ lưu trữ và hỗ trợ cộng tác trực tuyến. Để minh chứng cho kết quả nghiên
cứu, chúng tôi đã xây dựng và thử nghiệm giải pháp này cho Công ty cổ phần dịch vụ giá
trị gia tăng GNET.
ABSTRACT OF THESIS
Service-oriented architectures offer more effective and flexible approach to integrating
technology with business processes than traditional information technology (IT)
architectures. Service-oriented architectures are foundation for both next-generation
telecommunications and middleware architectures, which are rapidly converging on top of
commodity transport services. The service such as triple/quadruple play, multimedia
messaging, and presence are enabled by the emerging service-oriented IP Multimedia
Subsystem, and allow telecommunications service providers to maintain, if not improve,
their position in the marketplace. Service-oriented architectures are aggressively leveraged
in next-generation middleware systems as the system model of choice to interconnect

service consumers and providers within and between enterprises.
We leverage previous research in active, overlay, and peer-to-peer networking
technologies, along with recent advances in XML and Web Services, to create the
paradigm of service oriented networking (SON). SON is an emerging architecture that
enables network devices to operate at the application layer to provide functions such as
service-based routing, content transformation, and protocol integration to consumers and
providers. By adding application awareness into the network fabric, SON can act as a next-
generation federated enterprise service bus that provides vast gains in overall performance
and efficiency, and enables the integration of heterogeneous environments.
In another hand, Telecommunication network operators and service developers need to
develop and deliver a variety of single and multimedia based services to customers. To
support these new customer services the underlying telecommunications infrastructure
must provide various resources and capabilities that are reused in customer service
development. These capabilities ensure customer service implementations are independent
of the underlying infrastructure technologies and distribution mechanisms. In addition,
these capabilities are offered to a variety of external customer service developers. To
satisfy these requirements, the Service Delivery Platform (SDP) concept is proposed. The
SDP is not standardised and current architectural representations are technology-specific.
This research contributes to the standardisation of the SDP by defining a technology
independent SDP architecture (a general architecture of SDP – chapter I). In our approach
to define the architecture, and how it meets the requirements of Telecomunication
Enviroment.
As the results of this research, we contribute in threefold: first, we formalize SON as an
architecture and discuss the challenges in building SON devices. We discuss issues in
interconnecting SON devices to create large-scale service-oriented middleware and
telecommunications systems; in particular, we discuss the concept of federations of
enterprise service buses, and present two protocols that enable a distributed service registry
to support the federation and propose a general architecture of SDP. Second, we explore
CSF – a SDP developed by Microsoft Corporation in detail and depth. Finally, we study
and specify how CSF meets the requirements of Enterprise in two aspect: as a platform for

Enterprise Application Integration and as a Service Delivery Platform for rapidly develop
and delivery services to customer. In order to demonstrate our research, we propose a
solution for Application Integration in Hosted Messaging and Collaboration, develop and
test it on GNET’s Service Delivery System.
MỤC LỤC
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP i
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP i
ABSTRACT OF THESIS iii
DANH MỤC CÁC HÌNH VẼ
DANH MỤC CÁC BẢNG
DANH MỤC CÁC TỪ VIẾT TẮT
STT Từ viết tắt Giải nghĩa
1. CBD
Phát triển hướng thành phần
Component-Based Development
2. CSF
Nền phân phối dịch vụ phát triển bởi Microsoft
Connected Services Framework
3. CORBA
Kiến trúc môi giới yêu cầu đối tượng chung
Common Object Request Broker Architecture
4. DCOM
Mô hình đối tượng thành phần phân tán
Distributed Component Object Model
5. EAI
Tích hợp ứng dụng doanh nghiệp
Enterprise Application Integration
6. ESB
Tuyến dịch vụ doanh nghiệp
Enterprise Services Bus

7. IDL
Ngôn ngữ đặc tả giao diện
Interface Description Language
8. JINI
Hạ tầng mạng thông minh cho Java
Java Intelligent Network Infrastructure
9. JMS
Dịch vụ thông điệp Java
Java Message Service
10. HTTP
Giao thức truyền siêu văn bản
HyperText Transfer Protocol
11. NASSL
Ngôn ngữ đặc tả dịch vụ có khả năng truy cập qua mạng
Network Accessible Service Specification Language
12. Provision Thiết lập dịch vụ
13. RMI
Triệu gọi phương thức từ xa
Remote Method Invocation
14. SDL
Ngôn ngữ đặc tả dịch vụ
Service Description Language
15. SDP Nền cung cấp dịch vụ
STT Từ viết tắt Giải nghĩa
Services Delivery Platform
16. SOA
Kiến trúc hướng dịch vụ
Service-Oriented Architecture
17. SOAP
Giao thức truy cập đối tượng đơn giản

Simple Object Access Protocol
18. UDDI
Mô tả, tích hợp và tìm kiếm toàn cầu.
Universal Description Discovery and Integration
19. WSDL
Ngôn ngữ đặc tả Web service
Web Service Description Language
20. XML
Ngôn ngữ đánh dấu mở rộng
eXtensible Markup Language
21. WAP
Giao thức truy cập không dây
Wireless Application Protocol
LỜI CẢM ƠN
Để có thể hoàn thành tốt đồ án này, trước hết cho tôi gửi lời cảm ơn chân thành nhất
đến thầy giáo, PGS. TS. Huỳnh Quyết Thắng – Trưởng bộ môn Công nghệ phần
mềm, Phó trưởng khoa Công nghệ thông tin, Trường đại học Bách khoa Hà nội –
người đã dành nhiều tâm huyết, thời gian hướng dẫn, chỉ bảo tôi trong suốt thời
gian thực tập và làm đồ án.
Tôi xin gửi lời cảm ơn chân thành đến TS. Nguyễn Việt Hải – giám đốc Công ty
dịch vụ giá trị gia tăng Gnet, người trực tiếp hướng dẫn kỹ thuật, giải pháp trong
thời gian tôi thực tập, làm đồ án và xây dựng giải pháp tại Công ty.
Qua quá trình làm việc với Nền cung cấp dịch vụ CSF, tôi nhận được nhiều hướng
dẫn, hỗ trợ hữu ích của ông Mukesh Naik – chuyên gia Kiến trúc hướng dịch vụ, tư
vấn giải pháp CSF, công ty Microsoft Singapore. Cho phép tôi được gửi lời cảm ơn
tới ông và luôn mong muốn nhận được nhiều sự giúp đỡ kịp thời, quý báu từ ông
trong thời gian phát triển đề tài sau này.
Thời gian làm việc tại eDT, Gnet là một khoảng thời gian đẹp đối với tôi. Tôi luôn
nhận được nhiều sự giúp đỡ, hỗ trợ nhiệt tình từ nhiều anh, chị, em trong hai Công
ty. Cho tôi gửi lời cảm ơn chân thành đến họ, đặc biệt tới anh Ngô Anh Dũng, anh

Chu Anh Tuấn.
Cuối cùng cho tôi gửi lời cảm ơn đến bố mẹ - gửi đã nuôi dạy tôi trưởng thành, anh
chị em luôn sát cánh động viên tôi, các bạn trong lớp CNPM đã đóng góp ý kiến
cho đồ án này.
MỞ ĐẦU
Ngày nay, để hấp dẫn và giữ chân khách hàng, các nhà cung cấp và điều hành dịch
vụ di động cũng như dịch vụ mạng đều phải cung cấp các dịch vụ mới nhất, sinh
động nhất, bao gồm cả âm thanh, hình ảnh, dữ liệu một cách nhanh chóng tới bất kỳ
loại thiết bị nào. Ví dụ, một người dùng nào đó thích nhận được các tin nhắn thông
báo khi đội bóng yêu thích của họ ghi bàn thắng, ngược lại một người dùng khác lại
thích xem phim trên internet qua điện thoại di động của họ. Các người dùng khác lại
thích sử dụng điện thoại di động của họ để xem giá các mặt hàng trực tuyến mà họ
quan tâm., nếu thích họ cũng có thể yêu cầu các mặt hàng đó ngay từ thiết bị di
động của họ.
Trên là ví dụ về các dịch vụ trên các thiết bị di động, các nhà cung cấp này mặt
khác cũng sử dụng các hệ thống hỗ trợ hoạt động tác nghiệp, cũng như các chức
năng dịch vụ từ các bên thứ ba nào đó. Vậy làm thế nào các hệ thống này có thể
tương tác với nhau ?
Một khi yêu cầu triển khai các dịch vụ mới, vậy làm thế nào chúng ta có thể nhanh
chóng xây dựng, triển khai nó ? Để giải quyết các vấn đề trên Microsoft cung cấp
một giải pháp gọi là “Microsoft Connected Services Framework”. Không những
đáp ứng các yêu cầu trên, giải pháp còn cho phép quản lý, kiểm soát và triển khai
dịch vụ ra nhiều miền quản trị khác nhau, cung cấp một môi trường phát triển và
thực thi cho phép nhanh chóng xây dựng các ứng dụng theo Kiến trúc hướng dịch
vụ một cách nhanh chóng.
Giải pháp này đã được áp dụng thành công và mang lại nhiều giá trị lợi nhuận to
lớn ở nhiều hãng, tập đoàn khác nhau trên thế giới. Ví dụ, Bristish Telecom (Tập
đoàn Viễn thông Vương Quốc Anh), SonyPE (Sony Picture Entertainment),
StarFusion (Tập đoàn Viễn thông ở Malaysia). Không những cho phép xây dựng
các ứng dụng theo Kiến trúc hướng dịch vụ mà bản thân CSF cũng theo kiến trúc

hướng dịch vụ.
Trong giai đoạn làm đồ án này, người viết luận văn đã giành thời gian và công sức
tìm hiểu, nghiên cứu về Kiến trúc hướng dịch vụ, và CSF. Bên cạnh đó phục vụ cho
quá trình xây dựng và phát triển ứng dụng trên nền CSF tôi cũng đã nghiên cứu
Khung chuẩn bị và thiết lập tài nguyên của Microsoft gọi là Microsoft Provisioning
Framework và giải pháp về “Lưu trữ trên nền Windows” gọi là Microsoft Windows
Based Hosting Solution. Qua các nghiên cứu, tổng hợp đó đề xuất giải pháp tích
hợp hệ thống cho Hệ thống cung cấp dịch vụ lưu trữ và hộ trợ cộng tác. Với nội
dung như trên, bố cục của báo cáo như sau:
Chương I. Sự phát triển của các hệ thống phức hợp và nhu cầu về một Nền
cung cấp dịch vụ
Chương này sẽ giới thiệu tổng quan về kiến trúc hướng dịch vụ và các nền tảng tích
hợp, chuyển giao dịch vụ. Sau khi đọc xong chương này chúng ta sẽ thấy được vai
trò và sự cần thiết của các nền tảng tích hợp, phân phối và chuyển giao dịch vụ.
CSF là một hệ thống như vậy.
Chương II. Nền tảng phân phối, chuyển giao dịch vụ - Microsoft Connected
Services Framework
Chương này sẽ cho chúng ta thấy CSF là gì, kiến trúc của nó, mô hình lập trình,
cũng như các thành phần cơ bản của nó. Sau khi đọc xong chương này chúng ta sẽ
nắm được các nguyên lý của sản phẩm – giải pháp CSF, cách thức sử dụng CSF để
xây dựng các ứng dụng theo Kiến trúc hướng dịch vụ.
Chương III. Giải pháp tich hợp hệ thống cung cấp dịch vụ lưu trữ và hỗ trợ
cộng tác.
Chương này sẽ trinh bày bài toán tích hợp hệ thống cho doanh nghiệp cung cấp dịch
vụ lưu trữ và hỗ trợ cộng tác. Đề xuất giải pháp tổng thể để tích hợp các ứng dụng,
nền tảng IT hiện có nhằm mở rộng hệ thống và đáp ứng yêu cầu thay đổi dịch vụ,
cung cấp phát triển dịch vụ mới sau này. Đồng thời với giải pháp này, em trình bày
thiết kế hệ thống, các dịch vụ để hiện thực hóa giải pháp.
Chương IV. Cài đặt, triển khai thử nghiệm giải pháp.
Chương này trình bày cách cài đặt, triển khai giải pháp và một số kết quả, đánh giá

giải pháp.
Chương V. Đánh giá và hướng phát triển của đề tài
Chương này đánh giá tổng thể các kết quả đã đạt được của đề tài, các hạn chế cần
khắc phục, cần cải thiện. Đồng thời, đề xuất hướng phát triển trong thời gian tới.
CHƯƠNG I. SỰ PHÁT TRIỂN CỦA CÁC HỆ THỐNG PHỨC HỢP VÀ
NHU CẦU VỀ MỘT NỀN CUNG CẤP DỊCH VỤ - SDP
Sự phát triển không ngừng của các hệ thống tin học đã làm thay đổi,
tiến hóa và nhu cầu vê những cách tiếp cận mới:
- Sự phát triển và tiến hóa của Kiến trúc hướng dịch vụ.
- Nhu cầu vê một Nền cung cấp dịch vụ.
- So sánh đánh giá một số sản phẩm nỗi bật.
1. Tổng quan về Kiến trúc hướng dịch vụ
1.1. Kiến trúc hướng dịch vụ
Kiến trúc hướng dịch vụ là một hướng tiếp cận để xây dựng các hệ thống phân
tán cung cấp chức năng ứng dụng dưới dạng các dịch vụ tới các ứng dụng người
dùng cuối hoặc các dịch vụ khác:
• SOA là một kiến trúc dùng các chuẩn mở để biểu diễn các thành phần
phần mềm như là các dịch vụ.
• Cung cấp một cách thức chuẩn hoá cho việc biểu diễn và tương tác
với các thành phần phần mềm.
• Các thành phần phần mềm riêng lẻ trở thành các khối cơ bản có thể sử
dụng lại để xây dựng các ứng dụng khác.
• Được sử dụng để tích hợp các ứng dụng bên trong và bên ngoài tổ
chức.
Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức
năng (mô đun phần mềm) thực hiện quy trình nghiệp vụ nào đó. Các dịch vụ
trong SOA có các đặc điểm sau [1]:
• Các dịch vụ là có thể tìm kiếm được.
• Các dịch vụ có tính liên thông.
• Các dịch vụ không được gắn kết chặt chẽ với nhau.

• Các dịch vụ là phức hợp, bao gồm nhiều thành phần, được đóng gói ở
mức cao.
• Các dịch vụ trong suốt về vị trí.
• Các dịch vụ có khả năng tự hàn gắn.
Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối “mềm dẻo” với nhau
(nghĩa là một ứng dụng có khả năng giao tiếp với một ứng dụng khác mà không
biết các chi tiết kỹ thuật, cài đặt bên trong), có giao diện được định nghĩa rõ ràng
và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn
của phát triển ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao diện
chuẩn để che giấu sự phức tạp kỹ thuật bên dưới.
Thiết kế SOA 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ụ. Thay vì xây dựng
các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn
hơn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này
cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự mềm dẻo vì nhà phát
triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng sử dụng
dịch vụ.
Ưu điểm lớn nhất của SOA là khả năng kết nối mềm dẻo và tái sử dụng. Các
dịch vụ có thể được sử dụng trên nền tảng bất kỳ và được viết với ngôn ngữ bất
kỳ (ví dụ, ứng dụng Java có thể liên kết với Web service .NET và ngược lại).
SOA dựa trên hai nguyên tắc thiết kế quan trọng:
• Mô đun: tách vấn đề lớn thành nhiều vấn đề nhỏ
• Đóng gói: che giấu dữ liệu và logic trong từng mô đun đối với truy
cập từ bên ngoài
Một thiết kế kiến trúc phù hợp với khái niệm của SOA cần tuân theo những tính
chất sau [1]:
• Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có
tính tự chứa đựng và mức độ đóng gói cao (coarse-grained).
• Một dịch vụ có thể dùng lại được, cho phép có thể xây dựng được một

dịch vụ mới từ các dịch vụ hiện có. Do đó, việc quan sát các hàm ý có
thể có của các thuộc tính phi chức năng như tính giao dịch là rất quan
trọng.
• Một giao diện dịch vụ là một điểm cuối mạng (network endpoint) đảm
bảo tính độc lập và trong suốt về vị trí.
• Một dịch vụ cần có khả năng được phát hiện ra một cách công khai
bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên
kết động tới dịch vụ.
• Một dịch vụ cần đảm bảo tính liên thông bằng cách hỗ trợ các giao
thức truyền thông được chuẩn hoá và các định dạng dữ liệu rõ ràng.
Các đặc điểm trên đảm bảo cho một kiến trúc hướng dịch vụ khả năng gắn kết
lỏng lẻo của các dịch vụ phân tán và có tính mô đun bằng cách sử dụng các giao
ước dịch vụ để mô tả các định dạng thông điệp cần thiết.
Ở trên chúng ta đã có các sự nhìn nhận về dịch vụ và kiến trúc hướng dịch vụ.
Tuy nhiên, đứng dưới góc độ kiến trúc hệ thống chúng ta có thể xem dịch vụ
như là các khái niệm trừu tượng mà chúng phải được cài đặt bởi các tác tử cụ
thể. Tác tử ở đây là một thực thể cụ thể (một thành phần của phần mềm) nó gửi
và nhận các thông điệp trong khi đó các dịch vụ là một tập trừu tượng các chức
năng mà nó cung cấp.
Chúng ta có thể phân loại dịch vụ thành các loại sau [17]:
• Dịch vụ nội dung: Các dịch vụ thông tin, giải trí, ứng dụng, đa
phương tiện,…
• Các dịch vụ mạng: Các dịch vụ này được đưa ra từ các phần tử mạng
• Các dịch vụ thiết bị: Cung cấp quản lý và điều khiển thiết bị.
• Các dịch vụ hỗ trợ điều hành tác nghiệp (OSS/BSS Services): Tích
hợp với các hệ thống điều hành, tác nghiệp trong doanh nghiệp.
Giao diện dịch vụ: Một dịch vụ phải đảm bảo có hai tập giao diện sau:
Hình 1. 1 – Hai tập giao diện của một dịch vụ
Các giao diện quản lý: Giao diện này cho phép các hoạt động FCAPS (Fault,
Configuration, Accouting, Performance, và Security) được quản lý như là một

thực thể. Giao diện này thích hợp nhất là được cài đặt bởi dịch vụ web.
Giao diện tiêu thụ (Consumption Interface): Giao diện này cho phép thuê bao
tiêu thụ các chức năng cung cấp bởi dịch vụ. Ví dụ, POP3 là giao diện tiêu thụ
của dịch vụ thông điệp. Giao diện này chúng ta không nhất thiết cài đặt bằng
dịch vụ web.
1.2. Các nguyên lý thiết kế hướng dịch vụ
Việc tiếp cận xây dựng các hệ thống dựa trên mô hình hướng dịch vụ phải tuân
theo bốn nguyên tắc sau [3]:
• Nguyên tắc 1: Giao diện của dịch vụ phải rõ ràng. Các dịch vụ tương
tác qua việc truyền đi các thông điệp tường minh. Chúng ta không cần
biết về không gian nằm sau giao diện của dịch vụ. Vượt qua các giao
diện của dịch vụ có thể tốn nhiều công sức và chi phí. Các giao diện
rõ ràng cho phép cài đặt các tương tác độc lập – nghĩa là không cần
biết về nền tảng hay các ngôn ngữ lập trình được lựa chọn để cài đặt
các dịch vụ.
• Nguyên tắc 2: Dịch vụ là tự trị. Các dịch vụ hoạt động như là các
thực thể độc lập. Không có quyền làm chủ trong một môi trường
hướng dịch vụ. Các dịch vụ được triển khai, thay đổi, quản lý một
cách độc lập.
• Nguyên tắc 3: Các dịch vụ chia sẻ giao diện và giao ước không chia
sẻ cài đặt. Các dịch vụ tương tác với nhau chỉ dựa vào giao diện và
giao ước sử dụng dịch vụ. Giao ước của dịch vụ mô tả cấu trúc của
thông điệp và các ràng buộc giữa các thông điệp, điều này cho phép
chúng ta bảo toàn được tính toàn vẹn của dịch vụ. Các giao ước và
giao diện phải được duy trì tính ổn định với thời gian. Vì vậy việc xây
dựng chúng một cách mềm dẻo là rất quan trọng.
• Nguyên tắc 4: Tính tương thích của dịch vụ dựa trên chính sách. Cả
người cung cấp và người dùng dịch vụ sẽ phải có các chính sách để
tương tác qua các giao diện của dịch vụ. Một ví dụ đơn giản về chính
sách phía người cung cấp là một dịch có thể đỏi hỏi người gọi phải có

một tài khoản hợp lệ với người cung cấp dịch vụ. Về phía người dùng
dịch vụ, một tổ chức có thể đòi hỏi các lời gọi qua Internet phải được
mã hoá.
1.3. Các nguyên lý dịch vụ hóa
Dịch vụ hóa là yêu cầu then chốt trong việc phát triển các dịch vụ web quản lý
được, sinh lợi. Đối với nhà cung cấp dịch vụ thì dịch vụ hóa cho phép chúng ta
thiết lập (provision) động các dịch vụ web mới và đo mức độ sử dụng các dịch
vụ đã triển khai. Đối với nhà cung cấp dịch vụ lưu trữ email hay website, nó cho
phép chúng ta lưu trữ (host) nhiều dịch vụ khách hàng trên cùng một hạ tầng
chung duy nhất, và do vậy cho phép chúng ta thiết lập và giám sát mức độ thỏa
thuận dịch vụ với khách hàng. Đối với nhà khai thác dịch vụ di động (mobile
operator) nó cho phép chúng ta nhanh chóng triển khai các dịch vụ đa dạng, đa
người dùng. Trên là các ví dụ về các lợi ích mà dịch vụ hóa mang lại cho chúng
ta.
Có năm thành phần then chốt trong việc dịch vụ hóa. Có nghĩa là chúng ta phải
nắm rõ bản chất các thành phần này từ đó chúng ta có thể nhận diện các dịch cấn
đề mà chúng ta cần phải giải quyết khi triển khai các dịch vụ sinh lợi (profit-
generating) [8]:
• Các dịch vụ web có khả năng thiết lập (provision):
Các dịch vụ web phải có khả năng chuẩn bị các tài nguyên, thiết lập cấu
hình tài nguyên cho người sử dụng. Nó là quá trình khởi tạo, thiết lập ví
dụ như tạo miền (domain), danh sách địa chỉ trong kịch bản Host
Exchange, cung cấp hộp thư cho người dùng mới… Nó cũng có thể là các
quá trình không liên quan đến phần mềm như thiết lập máy chủ và cấu
hình chúng. Chúng ta phải xem xét khả năng chuẩn bị (provision) khi đưa
ra các dịch vụ web mới.
• Có khả năng multi-ternat:
Chúng ta nên tạo ra các ứng dụng dịch vụ Web mà có khả năng cung cấp,
hỗ trợ cho nhiều người dùng, tổ chức khác nhau. Để đạt được điều này
chúng ta phải xem xét các khía cạnh sau khi thiết kế ứng dụng dịch vụ

Web:
 Cung cấp đầy đủ các tài nguyên: cho mỗi tổ chức như danh bạ
địa chỉ, các thư mục, Sharepoint site, cơ sở dữ liệu logic,… Ngoài
ra chúng ta cũng phải xác định các cơ chế bảo mật để, quản trị các
tài nguyên này. Ví dụ như tổ chức này không thể truy nhập, nhìn
thấy các tài nguyên của tổ chức khác nếu không được phép; người
quản trị của mỗi tổ chức có thể quản trị các tài nguyên của họ một
cách hiệu quả.
 Ủy nhiệm quản trị: Chúng ta phải bảo mật tất cả các tài nguyên
và cho phép bản thân mỗi tổ chức tự định nghĩa và phân quyền
quản trị cho các tài nguyên.
 Khả năng quản lý tài nguyền tổng thể: Chúng ta có thể quản lý
các tài nguyên một cách tổng thể, thay đổi các chính sách đối với
các tài nguyên thì nó có hiệu lực với tất cả các tổ chức khác nhau
mà không cần phải thiết lập cho mỗi đơn vị tổ chức cụ thể nào.
Tuy nhiên sự thay đổi phải phù hợp với cam kết dịch vụ trước đó.
 Khả năng dự đoán dịch vụ: cho các tổ chức sử dụng dịch vụ
khác nhau. Như vậy yêu cầu của một tổ chức nào đó không gây
ảnh hưởng tới các tổ chức khác. Ví dụ, trong ứng dụng cho thuê
hosting, khi một đơn vị yêu cầu thêm dung lượng hoặc bandwitch
thì không gây ảnh hưởng đến chất lượng của các đơn vị khác.
 Khả năng thay đổi thuộc tính dịch vụ: theo đối tượng người
dùng, đơn vị tổ chức, phòng ban.Chúng ta phải đưa ra các tùy
chọn dịch vụ khác nhau, để các đơn vị tổ chức phòng ban khác
nhau, thậm chí là người dùng khác nhau có đều đáp ứng được yêu
cầu của họ.
 Khả năng rộng lớn: dịch vụ của chúng ta phải có khả năng hỗ trợ
cho toàn bộ tổ chức.
• Có khả năng kết hợp được:
Dịch vụ phải có khả năng kết hợp tương tác với các dịch vụ khác trong hệ

thống phức hợp (heterogeneous system).
• Có khả năng đo được:
Dịch vụ phải có khả năng theo dõi mức độ, cách thức sử dụng nó. Khách
hàng tương tác với hệ thống và sinh ra các sự kiện nghiệp vụ, các sự kiện
này sinh ra khi người dùng thực hiện các hành động trên hệ thống ví dụ
như người dùng tải một tệp tin lên hệ thống website mà họ lưu trữ (host)
trên đó. Các sự kiện này giúp chúng ta (dịch vụ) đưa ra các báo cáo,
thống kê, quản lý giao kèo dịch vụ (SLA), thông báo, tính cước phí,…
• Có khả năng định nghĩa bởi một SLA:
Chúng ta phải định nghĩa dịch vụ trong SLA, đảm bảo sự hấp dẫn đối với
người dùng và giảm chi phí dịch vụ. SLA là một thỏa thuận hay hợp đồng
được thiết lập giữa khách hàng và nhà cung cấp dịch vụ hoặc giữa các
nhà cung cấp dịch vụ với nhau. SLA ghi rõ những thỏa thuận ở mức độ
dịch vụ giữa 2 bên về loại hình dịch vụ, mức độ ưu tiên, trách nhiệm, bảo
hành, đặc tính liên quan đến QoS, SLA thường mang tính thương mại
trong khi đó các chi tiết về mặt kỹ thuật thì được miêu tả bởi SLS
(Service Level Specification). Để chuyển tải (delivery) một dịch vụ với
SLA chúng ta cần xem xét các vấn đề sau:
 Ứng dụng dịch vụ web phải cung cấp đủ các công cụ để đo hiệu
năng. Công cụ này phải có khả năng truy vấn từ xa để cung cấp
thông tin sử dụng, đánh giá hiệu năng hệ thống để có các chiến
lược nâng cấp, thiết lập, kiểm tra hệ thống.
 Các ứng dụng dịch vụ web phải có trạng thái phục vụ rõ ràng để
thao tác viên (operator) có thể dễ dàng quản trị được.
 Ứng dụng dịch vụ web phải cơ chế thông báo hành động, cảnh báo
lỗi chính xác rõ ràng.
 Xác định một quy trình xây dựng phát triển ứng dụng dịch vụ
Web. Quá trình này phải phù hợp với thư viện thông tin IT (IT
information library) hoặc các nguyên tắc như trong Khung hoạt
động của Microsoft (Microsoft Operation Framework) và bao gồm

quá trình xác định phạm vi, kiểm thử, quản lý thao đổi, lập kế
hoạch xử lý sử cố, hợp đồng dịch vụ, hỗ trợ, thiết lập các kế hoạch
hoạt động…
2. Sự phát triển và tiến hóa của Mạng dịch vụ, nhu cầu về một nền Cung cấp
dịch vụ.
2.1. Tích hợp các dịch vụ trong Kiến trúc hướng dịch vụ
Khi phát triển một ứng dụng theo kiến trúc hướng dịch vụ, chúng ta có thể tạo
các XML - Web service tổ hợp, tái sử dụng được để thực hiện các tác vụ khác
nhau của ứng dụng. Mặc dù cách tiếp cận này có thể áp dụng cho bất kỳ loại hệ
thống hay ứng dụng nào, tuy chúng được áp dụng thích hợp nhất để xây dụng
các ứng dụng phân tán. Kiến trúc hướng dịch vụ (SOA) cho phép tái sử dụng
hoặc tạo mới các XML Web service mà không phụ thuộc vào nền tàng công
nghệ (Java, .Net,…), cách thức cài đặt (implement). Do vậy, các ứng dụng có
thể thêm mới hoặc loại bỏ các chức năng khi cần mà không gây ảnh hưởng các
đến các chức năng khác.
Khi sử dụng các tiêu chuẩn Web service như UDDI (Universal Discovery
Description and Integration – Chuẩn mô tả tích hợp và tìm kiếm toàn cầu),
SOAP (Simple Object Access Protocol – Giao thức truy cập đối tượng đơn
giản), WSDL (Web Service Description Language – Ngôn ngữ đặc tả dịch vụ
Web) chúng ta có thể tạo ra nền tảng (platform) tích hợp dịch vụ Web dựa trên
kiến trúc hướng dịch vụ. Một hạ tầng và nền tảng tích hợp như vậy giúp Web
hóa các công nghệ ứng dụng bên trong cũng như bên ngoài doanh nghiệp. Nền
tảng (plaform) này giúp loại bỏ sự phụ thuộc về mặt công nghệ, ngôn ngữ, nền
tảng ứng dụng thương mại khác nhau.
Khi triển khai một nền tảng tích hợp như vậy thì công việc khó nhất là làm thế
nào để tạo ra nó. Nền tảng này phải có đủ độ mềm dẻo để hỗ trợ các kế hoạch
nghiệp vụ, dịch vụ ứng dụng hiện tại cũng như với các kế hoạch nâng cấp, thay
đổi, thêm mới các nghiệp vụ. dịch vụ trong tương lai. Để đạt được điều đó khi
thiết kế một nền tảng như vậy chúng ta cần phải tuân thủ nghiêm ngặt các
nguyên lý thiết kế hướng dịch vụ.

Có hai pha trong quá trình tạo ra một hạ tầng tích hợp dịch vụ như yêu cầu ở
trên theo mô hình Kiến trúc hướng dịch vụ. Pha đầu tiên của tích hợp dịch vụ,
chuẩn bị các yêu cầu, điều kiện cho các dự án sau này là để cung cấp một nền
tảng hạ tầng bên trong mềm dẻo, đủ lớn đáp ứng các yêu cầu nghiệp vụ hiện tại
cũng như tương lai.
Pha thứ hai là mở rộng nền tảng của chúng ta ra khỏi tưởng lửa (firewall) mạng
doanh nghiệp chúng ta để nó có thể liên kết hỗ trợ với các nhà cung cấp, khác
hàng, đối tác. Các ứng dụng tích hợp dịch vụ web đưa ra cơ hội cộng tác cho các
ứng dụng bên ngoài bằng cách sử dụng cùng một kiến trúc như hệ thống bên
trong của chúng ta. Thay vì xây dựng các kết nối điểm đến điểm (point-to-point)
giữa các hệ thống khách hàng với hệ thống của chúng ta, chúng ta có thể sử
dụng duy nhất một kết nối dựa trên nền tảng tích hợp kiến trúc hướng dịch vụ.
Ví dụ, khách hàng muốn kết nối với hệ thống của chúng ta để xem tình trạng sản
xuất, yều cầu đặt hàng và cập nhật thông tin giao dịch mua bán. Với cách tiếp
cận truyền thống, chúng ta phải tạo ra ít nhất ba giao diện, có thể trên ba nền
tảng công nghệ khác nhau. Sau một thời gian khách hàng muốn xem xét tình
trạng quản lý vòng đời sản phẩm, trong khi đó chúng ta không thể tái sử dụng
các giao diện, kết nối đã có do vậy chúng ta phải thêm một giao diện nữa. Mặt
khác khi các khách hàng khác muốn kết nối sử dụng các chức năng như trên thì
khả năng tái sử dụng các giao diện kết nối trên cũng rất thấp.
Hình 1. 2 – Nền tảng kết nối dịch vụ web [9]
Nền tảng tích hợp dịch vụ cho phép hệ thống của chúng ta kết nối với hệ thống
bên ngoài thông qua một bộ tiếp hợp (adapter) duy nhất, do vậy khách hàng có
thể truy nhập vào tất cả các hệ thống yêu cầu bên trong thông qua bộ tiếp hợp
(adapter) này. Các khách hàng khác cần thiết lập kết nôi có thể xây dựng một bộ
tiếp hợp như vậy hoặc cũng có thể tái sử dụng bộ tiếp hợp này. Hệ thống tưởng
lửa sẽ đảm nhận vấn đề bảo mật và xác thực (authenticate) truy nhập.
Một hạ tầng như trên nên cung cấp các chức năng đáp ứng các yêu cầu cơ bản,
chung của nhiều hệ thống. Các chức năng này bao gồm quản lý nhận dạng
(identity) (xác nhận nhận dạng, quyền truy nhập, liên hợp các nhận dạng

(identity) qua các miền (domain) khác nhau), quản lý tiểu sử người dùng
(profile management), định tuyến nội dung (content-based routing), bảo mật
thông điệp (như mã hóa, chữ ký số), cung cấp khả năng rút khỏi hoặc tái
tham gia ứng dụng khi cần thiết.
2.2. Sự cần thiết của tầng điều khiển kiểm soát dịch vụ
Tiếp nối sự hình thành và phát triển của của giao thức Internet (Internet
Protocol) đã được chấp nhận rộng rãi và trở thành một phương tiện truyền thông
giao tiếp toàn cầu giữa các thiết bị máy tính, sự phát triển mạnh mẽ và chấp
nhận rộng rãi của dịch vụ web đã tạo điều kiện thuận lợi cho các hệ phức hợp
dịch vụ phát triển và duy trì. Hệ phức hợp này có thể gọi ngắn gọn lại là mạng
dịch vụ.
Hình 1. 3 – Mạng dịch vụ [9]
Trong mạng giao thức IP truyền thống, sự truyền tải dữ liệu giữa các nút mạng
được quản lý bởi một tầng điều khiển – nó quản lý sự tương tác giữa các nút
mạng, liên kết và dữ liệu. Tầng điểu khiển này trừu tượng hóa sự phức tạp của
hạ tầng mạng bên dưới nó và cho phép quản lý các đặc tính chung như sự thay
đổi của môi trường mạng, sự khác nhau giữa các nền tảng (platform), cũng như
có các cơ chế khắc phục, phục hồi lỗi (nếu xẩy ra). Những tầng như vậy chúng
ta có thể lấy ví dụ điển hình như SS7 (System Signalling 7) dùng trong mạng
thư thoại truyền thống và IMS (IP Multimedia Subsystem) dùng trong môi
trường truyển thông đa phương tiện.
Mạng dịch vụ bao gồm các dịch vụ kết nối lỏng lẽo với nhau và các tài nguyên
hoạt động trong môi trường phức hợp (nhiều dịch vụ, hệ thống tương tác với
nhau), chúng được quản lý bởi nhiều miền quản trị khác nhau, giao tiếp với nhau
thông qua các sự kiện bất đồng bộ. Sự phức tạp và hỗn hợp của các hành vi dịch
vụ có thể so sánh như sự phức tạp của các hành vi mạng truyền thống. Do vậy,
yêu cầu cần thiết cho một tầng điều khiển (giống như tầng điều khiển trong
mạng truyền thống) trừu tượng hóa sự phức tạp của các tầng dịch vụ web dưới
nó.
Tầng điều khiển mạng dịch vụ cung cấp các chức năng sau [6]:

• Định nghĩa và quản lý các ngữ cảnh cộng tác động.
• Quản lý nhận dạng xuyên suốt các miền quản trị khác nhau.
• Quản lý tài nguyên của các dịch vụ được công bố.
• Áp dụng các chính sách bảo mật xuyên suốt các miền phức hợp khác
nhau.
• Định tuyến các thông điệp dựa trên nội dung và thông tin điều khiển
của chúng.
• Thực hiện các quản lý mức dịch vụ.
• Cung cấp các cơ chế phân phối dịch vụ chịu lỗi.
Hình dưới đây sẽ minh họa sự giống nhau và tính chất của tầng điều khiển dịch
vụ cũng như tầng điều khiển trong mạng truyền thống.
Hình 1. 4 – Tầng điều khiển, kiêm soát dịch vụ [6]
Mạng dịch vụ đưa ra một loạt các kiến trúc, cách thức phát triển, triển khai phức
tạp cũng như các thách thức quản lý; làm cản trở các doanh nghiệp, tổ chức
trong việc triển khai, đấu tranh giành các lợi ích từ mạng dịch vụ. Một trong
những thách thức đó lớn nhất đó là sự không đồng nhất giữa các miền quản trị,
sự phức tạp, không tương thích giữa các mạng có sự tương tác giữa các dịch vụ
web.
Do vậy cần một nền tảng cung cấp một môi trường phát triển và thực thi cho
phép nhanh chóng tạo và kết hợp các dịch vụ web trong mạng dịch vụ. Nó cung
cấp các tính năng cần thiết như điều hòa, môi giới và điều đình cho sự tương tác,
kết hợp giữa các dịch vụ web từ các ứng dụng, miền quản trị khác nhau. Trong
nền tảng đó, sự phụ thuộc lẫn nhau giữa các dịch vụ web hết sức lõng lẻo, để
giảm thiểu sự phụ thuộc lẫn nhau giữa các dịch vụ web đó. Như vậy cần đưa
thêm một tầng mới gọi là tầng cộng tác nhằm quản lý sự tương tác, cộng tác
giữa các dịch vụ web. Điều này làm tăng tính mềm giẻo cho kiến trúc ứng dụng
hướng dịch vụ.
3. Nền cung cấp dịch vụ (Service Delivery Platform)
3.1. Tổng quan [9]
Ngày nay, hầu hết các hệ thống (phần mềm, phần cứng) của chúng ta đều tồn tại

và hoạt động trong môi trường hỗn hợp, tương tác qua nhiều miền quản trị khác
nhau. Do vậy hầu hết môi trường phân phối chuyển giao dịch vụ đều đối mặt với
các thách thức sau:
• Các nhà cung cấp dịch vụ đều thực hiện thiết kế, xây dựng và triển
khai các dịch vụ trong nội bộ mạng của họ và rất khó khăn khi thực
hiện chúng rộng rãi ra ngoài, qua các miền quản trị khác nhau, môi
trường khác nhau.
• Chưa có một quy trình chuẩn hóa cho phép quản lý vòng đời dịch vụ,
cũng như xây dựng và quản lý các ứng dụng dịch vụ phức tạp.
• Tích hợp với các hệ thống vận hành, tác nghiệp (OSS/BSS –
Operation Support System/Business Support System) một cách chuẩn
hóa, cho phép với tương tác với tất cả các dịch vụ khác trong môi
trường phân phối, chuyển giao dịch vụ. Hầu hết các hệ thống vận
hành, tác nghiệp chúng ta tích hợp thông qua các giao diện lập trình
ứng dụng (API) thương mại cung cấp bởi nhà cung cấp hệ thống phần
mềm tương ứng (không mềm dẻo, dễ đổ vỡ khi thay đổi hệ thống mới,
cài đặt mới).
• Sử dụng các giao diện lập trình ứng dụng (API) làm hạn chế sự đóng
góp của cộng đồng.
• Mỗi khi có các phát triển mới đều tốn chi chi phí cho việc tích hợp.
Với các thách thức như vậy, sự ra đời của một nền tảng phân phối, chuyển giao
dịch vụ là cần thiết. Với mỗi dịch vụ trong môi trường phân phối, chuyển giao
dịch vụ thường có vòng đời như sau:
• Nhà phát triển dịch vụ đăng ký phát triển dịch vụ với nhà cung cấp,
điều hành dịch vụ. Khi đăng ký thành công họ sẽ được cung cấp các
cộng phát triển dịch vụ (SDK) và các tài liệu liên quan. Mối quan hệ
giữa người phát triển dịch vụ và nhà cung cấp điều hành dịch vụ được
quản lý thông qua hệ thống Quản lý quan hệ đối tác (Partner
Relationship Management - PRM), hệ thống này sẽ xác định các cơ
chế, mô hình thông tin, chứng thực và quyền truy nhập cho mỗi người

phát triển.
• Nhà phát triển dịch vụ tiến hành phát triển và kiểm thử dịch vụ thông
qua truy nhập vào môi trường kiểm thử cung cấp sẵn bởi nhà cung
cấp, điều hành dịch vụ. Trong quá trình phát triển nếu dịch vụ được
kiểm thử và xác nhận đảm bảo các tiêu chí yêu cầu, nó được chuyển
vào môi trường sản xuất.
• Sau khi dịch vụ hoàn thành triển khai, nó được thương mại hóa bằng
cách chuyển giao nó tới các thuê bao dịch vụ thông qua các hệ thống
vận hành, tác nghiệp (OSS/BSS). Khi dịch vụ được tiêu thụ bởi khách
hàng, hệ thống Quản lý quan hệ đối tác sẽ tính toán và phân chia các
lợi nhuận từ dịch vụ cho các bên liên quan (đối tác, nhà phát triển,…).
Trong quá trình đóng góp xây dựng dịch vụ của mình, các nhà phát triển có thể
gặp phải các vấn đề sau:
• Quản lý nhận dạng
• Nhận dạng, xử lý sự phức tạp của các ứng dụng phức hợp.
• Sự phức tạp của các thành phần mạng, giao thức và mô hình hoạt
động của các hệ thống OSS/BSS
Từ các yêu cầu, thách thức và vấn đề trên, nhu cầu về một nền tảng, hệ thống
cho phép làm đơn giản hóa, chuẩn hóa vòng đời dịch vụ bằng cách cung cấp các
chức năng sau:
 Giảm thiểu sự phức tạp của các giao thức mạng thông qua mô hình
provision đồng nhất, các giao diện lập trình API.
 Dễ dàng tương tác, tích hợp với các hệ thống OSS/BSS với các dịch vụ
web chuẩn hóa
 Một mô hình lập trình đơn giản, dễ dàng cho nhiều lập trình viên khác
nhau: dịch vụ web là một chuẩn như vậy.
Một trong những lợi ích khác của việc đơn giản hóa vòng đời dịch vụ là giảm
chi phí phát triển các dịch vụ mới. Bằng cách chuẩn hóa các dịch vụ cho phép
chúng ta tạo ra các dịch vụ mới trên cơ sở kết hợp các dịch vụ đã có. Các dịch
vụ này có thể được triển khai, cung cấp qua nhiều miền quản trị khác nhau, tuy

nhiên khi cung cấp chúng một cách rộng rãi như vậy chúng ta phải giải quyết
được các thách thức sau:
Kiểm soát, quản trị: Với một môi trường mở, các dịch vụ có thể hoạt động trên
các hệ thống của các bên thứ ba (bên ngoài môi trường dịch vụ của nhà cung cấp
vận hành dịch vụ). Do đó các dịch vụ này không thể kiểm soát, quản lý, quản trị
bởi nhà cung cấp dịch vụ được. Hậu quả là các thuê bao có thể yêu cầu các dịch
vụ tới một nhà vận hành dịch vụ mà dịch vụ đó không thuộc tầm kiểm soát của
họ. Điều đó gây bất tiện cho nhà cung cấp dịch vụ. Để giải quyết vấn đề này, các
bên liên quan dịch vụ (nhà cung cấp dịch vụ, nhà vận hành dịch vụ, đối tác, nhà
phát triển,…) cần nhất quán với nhau thông qua một bản giao kèo dịch vụ
(SLA).
Quản lý chất lượng của dịch vụ và tài nguyên: Theo như trên, để đảm bảo
chất lượng dịch vụ tới người tiêu dùng, các bên liên quan phải thống nhất cách
thức quản lý tài nguyên và giao kèo dịch vụ với nhau. Các đặc tính này phải có
khả năng truy nhập thông qua giao diện lập trình và có khả năng điều khiển bởi
nhà cung cấp dịch vụ. Một trong các nhiệm vụ quan trọng đối với việc đảm bảo
chất lượng dịch vụ và điều tiết, ưu tiên các tài nguyên cũng như có các cơ chế
quản lý, kiểm soát các tài nguyên (do vậy phải có cơ chế đo mức tiêu thụ tài
nguyên, kiếm soát, định ngưỡng).
Mô hình quản lý nhận dạng phức tạp: Một trong các mô hình nhận dạng cần
phải xây dựng trong môi trường phân phối, chuyển giao dịch vụ là hỗ trợ nhận
dạng người dùng trong mỗi dịch vụ và các miền quản trị sau đó gián tiếp cho
phép nhận dạng các người dùng này khi các dịch vụ đó kết hợp thành các dịch
vụ mới (dịch vụ phức hợp). Tuy nhiên, trong thực tế một người dùng có thể
thuộc vào một tổ chức, miền nào đó nhưng lại không thuộc vào miền tổ chức
khác, do vậy. cần có cơ chế liên mình xác thực.