Kiến thức hướng dịch vụ và ứng dụng phát triển phần mềm chứng khoán

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
• • •
TRẦN ĐÌNH CHÍ
KIÉN TRÚC HƯỞNG DỊCH vụ VÀ ỨNG DỤNG PHÁT TRIỂN PHẦN
• • •
MÈM CHỨNG KHOÁN
Ngành: CÔNG NGHỆ THÔNG TIN
Chuyên ngành: CÔNG NGHỆ PHÀN MÈM
Mã số: 60 48 10
LUẬN VĂN THẠC sĩ
NGƯỜI HƯỚNG DẲN KHOA HỌC: TS. TRÀN THỊ MINH CHÂU
Hà Nội-2011
4
CHƯƠNG 1 - TÓNG QUAN VỀ SOA 12
1 1 Một số mô hình kiến trúc phân tán hiện tại và sự ra đời của SOA

12
1.1.1 DCOM
.

.

.

.
12
1.1.2 .NET Remoting 13
1.1.3 RMI

.

.


14
1 .1 .4 . C O R B A


15
11.2 Kiến trúc hướng dịch vụ 16
1.2.1 Kiến trúc hướng dịch vụ là gì? 16
1.2.2 Mô hình cơ bản của SOA 16
1.2.3 Kiến trúc phân tầng chi tiết của SOA
16
1.3 Các nguyên tắc thiết kế hệ thống SOA 18
1.3.1 Khớp nối lỏng lẻo dịch vụ (Service Loose Coupling) 18
1.3.2 Sự trừu tượng hóa dịch vụ (Service Abstraction)
19
1.3.3 Tái sử dụng dịch vụ (Service Reusability) 19
1.3.4 Khả năng tự phục hồi (Self-healing) ] 9
1.3.5 Sự tự trị cùa dịch vụ (Service Autonomy)
20
1.3.6 Giảm thiếu tiêu thụ tài nguyên dịch vụ (Service Statelessness) 20
1.3.7 Khả năng dò tìm dịch vụ (Service Discoverability)
20
1.3.8 Khả năng tổng hợp (Composite) 20
1.4 Các đặc điểm cúa SOA 21
1.4.1 Hướng nghiệp vụ (Business-Driven) 21
1.4.2 Trung lập nhà cung cấp (Vendor-Neutral) 21

1.4.3 Trung tâm doanh nghiệp (Enterprise-Centric) 21
1.4.4 Trung tâm tổng hợp (Composition-Centric) 21
1.5 Quy trình xây dựng một hệ thống SOA 21
1.6 Các chiến lược thiết kế hệ thống SOA 23
1.6.1 Chiến lược thiết kế top-down 23
1.6.2 Chiến lược thiết kế bottom-up 24
1.7 SOA và vấn đề tích hợp 26
1.7.1 Nhu cầu giải quyết bài toán tích họp 26
1.7.2 Chuyển đổi sang ứng dụng dịch vụ
27
1.8 SOA và hiệu năng 27
1.8.1 Phân tích vấn đề hiệu năng trong hệ thống SOA 27
1.8.2 Các ràng buộc lời gọi 29
1.9 SOA và bảo mật 29
1.9.1 Các yêu cầu bảo mật 29
1.9.2 Sự thỏa thuận với các yêu cầu bảo mật 30
1.9.3 Bảo mật, hiệu năng và trạng thái 34
1.9.4 Bảo mật trong thực tế

.
35
1.9.5 Bảo mật với XML và Web Service 36
1.9.6 Khi nào vấn đề bảo mật cần được xem xét
40
MỤC LỤC
5
CHƯƠNG 2 - VAI TRÒ CỦA ENTERPRISE SERVICE BUS TRONG SOA

41
2.1 Khái niệm Enterprise Service Bus 41

2.2 Vai trò cùa ESB trong SOA 41
2.3 Các mẫu Enterprise Service Bus 42
2.3.1 Kết nối điểm tới điểm 42
2.3.2 Kiểu lá chắn (Interceptors) 44
CHƯƠNG 3 - ỨNG DỤNG WCF VÀO SOA 47
3.1 Giới thiệu về WCF 47
3.2 Kiến trúc WCF 48
3.2.1. Hợp đồng (Contracts) 48
3.3.2. Dịch vụ Runtime (Service Runtime)
49
3.2.3. Thông điệp (Message)
.
49
3.2.4. Kích hoạt và Chứa (Activation and Hosting )

49
CHƯƠNG 4 - NGHIỆP v ụ PHÀN MÈM 51
4.1 Quy trình nhập lệnh môi giới
51
4.1.1 Mô tả khái quát 51
4.1.2 Sơ đồ nghiệp vụ 51
4.1.3 Các bước thực hiện 52
4. 2 Quy trình hủy lệnh 54
4.2.1 Mô tả khái quát 54
4.2.2 Sơ đồ nghiệp vụ 54
4.2.3 Mô tả chi tiết các bước 54
4.3 Quy trình sửa lệnh 55
4.3.1 Mô tả khái quát 55
4.3.2 Sơ đồ nghiệp vụ 56
4.3.3 Các bước thực hiện 56

CHƯƠNG 5 - THIẾT KẾ VÀ CÀI ĐẶT HỆ THỐNG 58
5.1 Lý do lựa chọn SOA cho việc phát triển phần mềm chứng khoán 58
5.2 Thực trạng của hệ thống phần mềm công ty chứng khoán StockMart Việt Nam 58
5.3 Thiết kế hệ thống phần mềm mới theo kiến trúc SOA

61
5.3.1 Phân tích dịch vụ 61
5.3.2 Thiết kế các thành phần dịch vụ 63
5.3.3 Phát triển các dịch vụ 68
5.4 Một sổ bảng chính trong cơ sở dữ liệu
68
5.5 Giới thiệu một số màn hình giao diện chính 73
KẺT LUẬN 77
TÀI LIỆU THAM KHẢO 78
6
Hình 1.1: DCOM mở rộng COM bằng cách cho phép các thành phần COM giao tiếp
thông qua các đường biên vật lý 12
Hình 1.2: Kiến trúc phân tầng của .NET Remoting

13
Hình 1.3: Mô hình cơ bản của SOA 16
Hình 1.4: Mô hình logic các thành phần của hệ thống SOA 17
Hình 1.5: Các bước xây dựng một hệ thống SOA

2 1
Hình 1.6: Các bước xây dựng hệ thống theo chiến lược top-down

23
Hình 1.7: Các bước xây dựng hệ thống theo chiến lược bottom-up

25
Hình 1.8: Biểu đồ tuần tự của một cuộc gọi dịch vụ 27
Hình 1.9: Nhiều bước nhảy ngắn giữa người dùng cuối và các hệ thống backend

32
Hình 1.10: Các tầng bảo mật cho XML và các web service

36
Hình 2.1: Một Enterprise Service Bus 42
Hình 2.2: Một ESB cung cấp các kết nối điểm tới điểm 43
Hình 2.3: Một kết nối hòa giải của ESB [SOA in Practice] 43
Hình 2.4: Một ESB với một bộ cân bằng tải cho các dịch vụ được cung cấp

45
Hình 2.5: Một ESB sử dụng các bộ chắn 46
Hình 3.1: Mô hình chương trình thống nhất đã được thiết lập bởi WCF

47
Hình 3.2: Kiến trúc của WCF 48
Hình 4.1: Sơ đồ quy trình nhập lệnh môi giới 52
Hình 4.2: Sơ đồ quy trình hủy lệnh môi giới 54
Hình 4.3: Sơ đồ nghiệp vụ quy trình sửa lệnh môi giới

56
Hình 5.1: Mô hình các thành phần của hệ thống phần mềm hiện tại 59
Hình 5.2: Các thành phần phần mềm được thiết kế theo kiến trúc SOA

62
Hình 5.3: ESB được triển khai để hỗ trợ cơ chế cân bằng tải và khắc phục lỗi 67
Hình 5.4: Màn hình giao diện đặt lệnh cho khách hàng 74

Hình 5.5: Màn hình giao diện vấn tin lệnh đặt của khách hàng 74
Hình 5.6: Giao diện vấn tin tổng hợp tài khoản khách hàng
75
Hình 5.7: Giao diện mở tài khoản khách hàng 75
Hình 5.8: Giao diện quản lý nhóm người dùng và phân quyền 76
Hình 5.9: Giao diện quản lý người dùng
76
DANH MỤC HÌNH VẼ
7
Bang 4.1: Mô tả chi tiết các bước của quy trình nhập lệnh
54
Bang 4.2: Mô tả chi tiết các bước của quy trình hủy lệnh

55
Báng 4.3: Mô tả chi tiết các bước của quy trình sửa lệnh

57
Bang 5.1: Danh sách các hàm chức năng cho dịch vụ TradingService

64
Báng 5.2: Danh sách các hàm chức năng cho dịch vụ CoreService

66
Bàng 5.3: Mô tả thông tin cho bảng Customers
69
Bảng 5.4: Mô tả thông tin bảng GlStockCode 69
Bảng 5.5: Mô tả thông tin bảng StockPrice 70
Bảng 5.6: Mô tả thông tin bảng StockOrder 70
Bảng 5.7: Mô tả thông tin bảng TradingOrder
71

Bảng 5.8: Mô tả thông tin bảng TradingResult 72
Bảng 5.9: Mô tả thông tin bảng Balance 73
Bảng 5.10: Mô tả thông tin bảng Securities 73
DANH MỤC BẢNG BIÉƯ
8
BẢNG CÁC KÝ HIỆU VIẾT TẮT
Ký hiệu viết tắt
r \ • X t 7 •
Diên giai
CK
Chứng khoán
CORBA
Common Object Request Broker Architecture
DCOM
Distributed Component Object Model
DMZ Demilitarized Zone
Dos Denial-of-Service - Tấn công từ chối dịch vụ
EAI
Enterprise Application Integration - Tích hợp ứng dụng doanh
nghiệp
ESB Enterprise Service Bus
HNX
Sở giao dịch chứng khoán Hà Nội
HSX Sở giao dịch chứng khoán thành phố Hồ Chí Minh
IIS Internet Information Services
KH Khách hàng
RMI Remote Method Invocation
SMS Short Message Services - Dịch vụ tin nhắn ngắn
SOA
Service Oriented Architecture - Kiến trúc hướng dịch vụ

SOAP Simple Object Access Protocol
SSL Secure Sockets Layer
TK Tài khoản
TTGD
Trung tâm giao dịch
WAS
Windows Activation Service
WCF Windows Communication Foundation
ws
Web Service
WSDL Web Service Definition Language
XML
Extensible Markup Language
9
TÙ ĐIÉN THUẬT NGŨ s ử DỤNG TRONG LUẬN VĂN
• • •
Coarse
grained
Mô tả mức độ gom nhóm xử lý của một thành phân xử lý thông tin.
Các thành phần có tính coarse-grained thường truyền nhận và xử lý
theo tùng khối dữ liệu có thông tin ngừ cảnh lớn và số lần trao đổi
thông tin trong một giao tác là ít.
Enterprise
application
Một sản phâm phân mêm được thiêt kê đê tích hợp các phân mêm con
bên trong doanh nghiệp lại với nhau. Mục tiêu là để tích hợp các xử lý
nghiệp vụ chính.
Fine-grained Các thành phân có tính fine-grained truyên nhận và xử lý theo từng
đon vị nhỏ và có ngữ cảnh ngầm định, cần nhiều lần trao đổi thông tin
trong một giao tác dẫn đến tăng băng thông sử dụng và kéo dài thời

gian hồi đáp.
Granularity Khái niệm mô tả độ phức tạp của tiên trình hoặc dịch vụ. Granularity
được chia làm hai loại là “fine-grained” và “coarse-grained”. Khái
niệm granularity được hiểu một cách trừu tượng không phân biệt hai
loại trên và tùy ngữ cảnh mà có cách hiếu khác nhau.
Legacy
system
Hệ thông ứng dụng được cài đặt từ trước nhưng vân còn được sử dụng.
Thông thường dây là những hệ thống sử dụng công nghệ đã lỗi thời
nhưng vẫn quan trọng và còn hoạt động tốt. Đây là thành phần nền
tảng cung câp xử lý cho các dịch vụ hoạt động ở câp cao hơn.
Loose
coupling
Một sản phâm phân mêm được thiêt kê đê tích hợp các phân mêm con
bên trong doanh nghiệp lại với nhau. Mục tiêu là đế tích hợp các xử lý
nghiệp vụ chính.
Middleware Là thành phân trung tâm liên kêt các phân mêm khác lại.
Orchestration Sự sắp xếp tự động, điều phối và quản lý hệ thống máy tính phức tạp,
lớp giữa và các dịch vụ.
Service
Consumer
Người sử dụng dịch vụ ở đây có thê là một ứng dụng, một dịch vụ hoặc
là các module phần mềm khác yêu cầu sử dụng dịch vụ.
Service
contract
Một hợp đông (contract) là một đặc tả vê cách thức bên sử dụng dịch
vụ trao đổi liên lạc với bên cung cấp dịch vụ. Nó chỉ rõ ra định dạng
yêu cầu và đáp trả của dịch vụ.
Service
provider

Nhà cung câp dịch vụ là một dịch vụ châp nhận và xử lý những yêu
cầu từ người sử dụng dịch vụ.
Tight
coupling
Ngược lại vói Loose coupling.
10
LÒÌ MỞ ĐẦU
Trong thập kỷ qua, kiến trúc hướng dịch vụ đã chuyển từ sơ khai đến phổ biến trong
thế giới phần mềm và bằng nhiều cách nó cho phép các mô hình thông tin tiếp theo
cua công nghệ điện toán đám mây. Mô hình “Phần mềm + Dịch vụ” đã trở thành
chuẩn mực, các doanh nghiệp định hướng theo kiến trúc SOA sẽ có một cách dễ dàng
đê chuyến đối sang điện toán đám mây, SOA cho phép mở rộng quy mô tốt hơn và tiết
kiệm chi phí do các tính chất của nó đem lại. Kiến trúc hướng dịch vụ là sự kỳ diệu
đàng sau rất nhiều ứng dụng dựa trên Internet và các dịch vụ tích họp thông tin và dừ
liệu từ nhiều nguồn thành một nguồn duy nhất. Việc thiết kế một cách lỏng léo của
SOA cho phép các nhà phát triển tái sử dụng các dịch vụ hiện có để xây dựng các ứng
dụng của họ, tự động thích ứng với thay đối trong những dịch vụ, và cung cấp các dịch
vụ riêng của họ đế phát triển ứng dụng khác. Triết lý của SOA là “Đừng tốn công chế
tạo lại bánh xe, hãy kết hợp những linh kiện (dịch vụ) có sẵn và bổ sung nhũng gì cần
thiết để lắp ráp nhanh chóng chiếc xe đưa bạn đến đích”. SOA phép các nhà phát triên
để làm điều đó bởi sự tập trung vào xây dựng các bộ phận duy nhất của các ứng dụng
cua họ bằng cách cho phép họ sử dụng lại các dịch vụ hiện có của những người khác
đã viết để giải quyết các vấn đề chung.
Để phát triển, định hướng dịch vụ cung cấp một mô hình công nghệ có tiềm năng
cho việc tạo ra và duy trì có hiệu quả sự tiến hóa của các ứng dụng, các ứng dụng có
thề được thay đổi tốt hơn và được mở rộng hơn với các nghiệp vụ. Nhờ ứng dụng
SOA, ta có thể định hướng dịch vụ để cung cấp các chiến lược và các công cụ đế phát
triển các ứng dụng công nghệ thông tin hiện có và trong khi đồng thời đẩy mạnh phát
triển các chức năng mới. Chiến thuật “Trích xuất và thay thế” của quá khứ để đối phó
với việc thay đổi các công nghệ và nhu cầu nghiệp vụ đã không còn thích ứng với sự

phát triển mạnh mẽ về hạ tầng công nghệ thông tin cũng như các yêu cầu của khách
hàng.
Như vậy SOA là một kiến trúc khá phổ biến hiện tại, vậy thật sự SOA là gì? Một hệ
thống SOA có các tính chất gì?, Kiến trúc của nó ra sao và các mẫu thiết kế nó như thế
nào, ? Đó chính là các câu hỏi mà đề tài nghiên cứu và trả lời.
11
Kết cấu của Luận văn, ngoài phần mở đầu và kết luận bao gồm 5 chương:
Chuoìig 1 - Tổng quan về SOA
Nội dung: Chương này trình bày khái niệm về SOA, mô hình kiến trúc SOA, các
nguyên tắc thiết kế hệ thống SOA, quy trình xây dựng hệ thống SOA, đồng thời tìm
hiểu một số vấn đề về hiệu năng và bảo mật của hệ thống SOA.
Chuong 2 - Vai trò của Enterprise service bus (ESB) trong SOA
Nội dung: Chương này tìm hiểu khái niệm về ESB, vai trò của ESB trong SOA và một
số mẫu thiết kế ESB phổ biến.
Chưoìig 3 - ủng dụng Windows Communication Foundation (WCF) vào SOA
Nội dung: Chương này giới thiệu về công nghệ WCF trong .NET Framework, như
khái niệm WCF, mô hình kiến trúc WCF
Chuong 4 - Nghiệp vụ phần mềm
Nội dung: Chương này trình bày một số quy trình nghiệp vụ trong giao dịch chứng
khoán như quy trình đặt lệnh, sửa lệnh, hủy lệnh.
Chương 5 - Thiết kế và cài đặt hệ thống
Nội dung: Chương này trình bày việc phân tích hệ thống phần mềm cũ và xây dụng lại
phần mềm theo kiến trúc hướng dịch vụ.
12
CHƯƠNG 1 - TÓNG QUAN VỀ SOA
ỈSI Nội dung của chương I trình bày về lý do lựa chọn kiến trúc hướng dịch vụ, từ đỏ
đi vào tìm hiểu các nội dung chi tiết về kiến trúc hướng dịch vụ như: Mỏ hình kiên trúc
hướng dịch vụ, quy trình thiết kế của kiến trúc hướng dịch vụ, vấn đề tích hợp, vấn đe
về hiệu năng và bào mật trong hệ thong hướng dịch vụ.
1.1 Một số mô hình kiến trúc phân tán hiện tại và sự ra đòi của SOA

1.1.1 DCOM
COM (Component Object Model) hỗ trợ việc đóng gói các hệ thống hướng đối
tượng thành các thành phần nhị phân, nó hồ trợ đóng gói bằng cách ngăn chặn việc lộ
ra các chi tiết thực hiện, và đóng gói logic trong các thành phần COM để nó chỉ có thê
truy cập được nếu nó đã được lộ ra thông qua một interface chung. DCOM mơ rộng
COM để cho phép giao tiếp giữa các máy tính khác nhau.
DCOM đã thiết lập một giao thức bảo mật từ xa qua đó thúc đẩy framework báo
mật đã được cung cấp bởi hệ điều hành của Windows. Ví dụ, nó được sử dụng danh
sách điều khiển truy cập để các thành phần bảo mật mà sau đó có thể được cấu hình
bằng cách sử dụng các công cụ DCOMCNFG.
c o r / ỉLrtirre
c o r / ru r tirre
t
c o r /
corrporert
protocol sta ck protocol stack
♦
D C O M
re t w ork proto col
'Hình 1.1: DCOM mở rộng COM bằng cách cho phép các thành phần COM giao tiếp
thông qua các đường biên vật lý
Ưu điểm của DCOM:
- Dcom là một mô hình phân tán dễ triển khai, chi phí thấp.
- Quản lý kết nối hiệu quả và dễ dàng mở rộng.
Nhu’O’c điểm của DCOM:
[SOA With .NET and windows Azure]
13
- Phụ thuộc vào nền tảng Window do đó chỉ sử dụng được với các máy tính cùng sử
dụng hệ điều hành Window.
- DCOM có một sổ nhược điểm, bao gồm cả việc sử dụng cách ping “keep-alive” (còn

được gọi là bộ thu gom rác phân tán), nó yêu cầu client định kỳ ping đối tượng phân
tán. Nếu đối tượng phân tán không nhận được một thông điệp trong một khoảng thời
gian xác định, nó bị ngừng hoạt động và cuối cùng bị phá hủy. Bộ thu gom rác phân
tán là dễ bị lỗi, tăng lưu lượng mạng, và quy mô không vượt ra ngoài mạng nội bộ.
DCOM do đó không thích hợp cho mạng WAN.
- DCOM thông qua trực tiếp kết nổi TCP trên cổng cụ thể, làm cho nó phức tạp đế cấu
hình trên nhiều máy tính và tường lửa, và thậm chí kém thích hợp cho truyền thông
qua Internet.
NET Enterprise Services có một vài giới hạn khi thiết kế dịch vụ với DCOM. Ví dụ,
giao tiếp là phụ thuộc vào DCOM và proxy của client bị gắn chặt với server. Điều này
gây khó khăn để thiết kế theo nguyên tắc chuẩn hóa các hợp đồng dịch vụ và tính
loose coupling của dịch vụ.
ỉ.1.2 .N E T Remoting
Tương tự như các công nghệ phân tán khác, .NET Remoting sử dụng một đối tượng
proxy cho giao tiếp. Lớp proxy đóng vai đối tượng từ xa tại nội bộ và trừu tượng hóa
ra bên ngoài cho quá trình giao tiếp, về bản chất, các lớp proxy chặn cuộc gọi và giao
tiếp với đối tượng từ xa trên đại diện cho client.
2Hình 1.2: Kiến trúc phản tầng của .NET Remoting
2 [SOA With .NET and windows Azure]
14
Gói đối tượng giao tiếp với bộ định dạng đế các gói mà client yêu cầu và server đáp
ứng được định dạng phù hợp. Bộ định dạng chuyển các thông điệp tới SOAP hoặc
định dạng nhị phân. Bộ định dạng sau đó giao tiếp với các kênh truyền vận nhàm sử
dụng thích hợp giao thức truyền vận để truyền tải dữ liệu. Kiến trúc phân tầng của
•NET Remoting này được mở rộng và cho phép các định dạng mới và các kênh được
giới thiệu. Kênh này và bộ định dạng cho một ứng dụng .NET hiện tại có thể được
thay đối tập tin cấu hình ứng dụng mà không cần biên dịch lại mã. Khả năng cấu hình
một ứng dụng phân tán bằng cách sử dụng một file cấu hình rất hiệu quả. Điều này đã
được áp dụng sau đó với ASP.NET web service và sau đó là WCF.
Ưu điểm của .NET Remoting:

- .NET Remoting đã được giới thiệu chủ yếu để giải quyết những hạn chế trong COM
và DCOM. Như với DCOM, nó cung cấp một cơ chế phân tán giữa các máy tính cho
phép các client nhanh chóng cấu hình trên máy tính từ xa. Tuy nhiên, nó cho phép các
thành phần client và server được cấu hình bằng cách sử dụng một file cấu hình XML,
về cơ bản cho phép. NET Remoting đề thực hiện giao tiếp từ xa bằng cách gưi thông
điệp nhị phân và thông điệp XML dựa trên SOAP.
Nhược điểm của .NET Remoting:
- .NET Remoting là công nghệ độc quyền của .NET, nó chỉ được sử dụng trong các hệ
thống .NET và do đó không được thiết kế để hỗ trợ khả năng tương tác giữa các dịch
vụ. Đối tượng .NET Remoting chỉ có thể được sử dụng với các client .NET khác và
chủ yếu được sử dụng như là một phần của giải pháp phân tán đóng rằng không cần
phải công bổ các hợp đồng hoặc các API. Nó chủ yếu được thiết kế để phù hợp giao
tiếp trong các hệ thống . NET với nhau.
- .NET Remoting thiếu khả năng chia sẻ hợp đồng vì nó không viện dẫn một cơ chế
cho sự khám phá interface.
- Nó không tương thích với Web Service và WCF ngay cả khi cấu hình để sử dụng
định dạng SOAP và HTTP như một giao thức truyền vận. Điều này là bới vì .NET
Remoting dựa vào RPC/Encoded SOAP, trong khi WCF và Web Service sử dụng các
thông tin cơ bản trên Web Service.
- Nó hạn chế việc áp dụng nguyên tắc tự trị dịch vụ. Với .NET remoting, người tiêu
dùng kết hợp chặt chẽ với dịch vụ và tham chiếu với giao diện hoàn thành đã được
chuyển đến người tiêu dùng dịch vụ để nó có thể được sử dụng. Việc gắn kết chặt này
dẫn đến một sự mất mát đáng kể của tiềm năng tự trị dịch vụ.
- Nó có một số giới hạn về hosting và không đưa ra một mô hình bảo mật.
1.1.3 RMI
RMI là một phương pháp tiếp cận nơi mà một phương thức trên một máy từ xa viện
dẫn một phương thức khác trên một máy tính khác để thực hiện một vài tính toán và
trả về kết quả tới lời gọi phương thức, RMI được sử dụng để tương tác với các phương
thức của những đối tượng trong những máy từ xa khác sử dụng JVM.
15

ưu điểm RMI:
- Dễ dàng cài đặt dẫn tới các ứng dụng mạnh mẽ, dễ báo trì và mềm déo hơn.
Nhược điểm RMI:
- Kém hiệu quả hơn các đối tượng socket.
- Không thể sử dụng mã ra khỏi phạm vi của Java.
- Các vấn đề về an ninh cần được theo dõi một cách chặt chẽ hơn.
- Không hồ trợ cho việc tái sử dụng các hệ thống cũ.
1.1.4. CORBA
CORBA là một chuẩn được định nghĩa bởi Object Management Group (OMG) I1Ó
cho phép các thành phần phần mềm được viết với nhiều ngôn ngừ và chạy trên nhiều
máy tính đe làm việc cùng nhau, CORBA hồ trợ nhiều nền tảng. CORBA nằm ớ tầng
giữa cho các đối tượng phân tán
Ưu điểm:
- Hướng đối tượng.
- Định vị/truy cập trong suốt.
- Độc lập ngôn ngữ.
- Độc lập phần cứng.
- Độc lập hệ điều hành.
- Chuẩn mở, kiến trúc độc lập với nhà cung cấp.
- Đa dạng trong việc thiết lập các dịch vụ.
- HỖ trợ nhiều ngôn ngữ lập trình, nền tảng phần cứng, giao thức mạng và công nghệ
để phát triển mà vẫn thoả các tính chất của CORBA.
- Có thể tích hợp với các hệ thống cũ viết bằng các ngôn ngữ khác nhau nhưng cùng
tuân theo kiến trúc của CORBA.
Nhưọc điểm:
- CORBA là ngôn ngừ lập trình cấp thấp, rất phức tạp, khó học và cần có một đội ngũ
phát triển có kinh nghiệm.
- Các đối tượng CORBA khó có thể tái sử dụng.
Nhận xét chung:
Các kiến trúc phân tán như RMI, DCOM,.Net Remoting, CORBA đa phần là các

chuẩn đóng, chúng hầu như không thể kết họp với các chuẩn khác dẫn tới việc khó có
thế tích hợp và tái sử dụng lại các hệ thống khác chuẩn với nhau. Ví dụ như bắt đối
tượng Java trao đổi dừ liệu trực tiếp với một đối tượng DCOM là không thể.
Như vậy bài toán đặt ra đối với các nhà phát triển phần mềm là phải tạo ra được một
kiến trúc mới nhằm có thể tận dụng được các ưu điểm của các kiến trúc phân tán trôn
đồng thời còn có khả năng dễ dàng tích họp với các hệ thống khác, dễ dàng mở rộng,
nâng cấp, và các nhà phát triển phần mềm đã tạo ra một kiến trúc mới thỏa mãn
các tính chất trên đó là kiến trúc hướng dịch vụ (SOA).
16
1.2 Kiến trúc hướng dịch vụ
1.2.1 Kiến trúc hướng dịch vụ là gì?
Kiến trúc hướng dịch vụ (SOA) là một phương pháp luận được sứ dụng trong phát
triển phần mềm để xây dựng các hệ thống phân tán. Phân phát các chức năng dưới
dạng các dịch vụ và các dịch vụ được người dùng cuối sử dụng vào ứng dụng cùa
mình hoặc được sử dụng để xây dựng một dịch vụ khác. Giống như khái niệm đổi
tượng là trung tâm của kiến trúc hướng đối tượng thì khái niệm dịch vụ là trung tàm
của SOA.
Dịch vụ (Service) là các hàm chức năng, mô đun phần mềm thực hiện một qui trình
nghiệp vụ nào đó.
1.2.2 Mô hình cơ bản của SOA
Service
prov ider
service request
service response
Hình 1.3: Mô hình cơ bản của SOA
Trong đó:
Service provider
Một service provider cung cấp các dịch vụ phục vụ cho một nhu cầu nào đó. Người
dùng (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần sử
dụng đang hoạt động, họ chỉ cần quan tâm dịch vụ đó là gì.

Service consumer
Người dùng sử dụng dịch vụ được cung cấp bởi Service Provider
1.2.3 Kiến trúc phân tầng chỉ tiết của SOA
Hiện tại không có một mô hình thống nhất cho các thành phần của hệ thống SOA,
mồi công ty khác nhau khi phát triển một hệ thống SOA có thể đưa ra mô hình các
thành phần của SOA khác nhau, đây là mô hình các thành phần của hệ thống SOA
theo quan điểm của công ty IBM và đây cũng là một mô hình khá phổ biến cho kiến
trúc cùa hệ thống SOA.
1 [Building S O A-based Solutions for IBM System i Platform ]
[http ://w ww .serv ice-architecture.com ]
4
17
Vi
a;
X
*-> i
Ui .
<r. V
ttợ
G.
o
X
>

c
g
Q tj
ẩ Sfl
G
u. u

Ê ỗ
n
ai
re u
Husiness services
h xp loil the SO A foundatio n ta deliver a co m p o rte ni busin ess m odel
Bus n es s innovation & optimization services
Provifle for better decision-making with real-time business
Interaction services
UfQb'e COQoợỷtfon
t'.eợ'A'fợ f?/i peopfe
cvoce-sscs 5 :r?iTc.*r??ỷi.'ỷfù
process services
Ifc/icsfrcjfc.' //èCè ôjuiorr/tift:
business processes
Information services
Mỷnự'ầfỷ diverse ỹỷtc
and contfin* in H iớivirt
manner
Enterprise service bus Enable inter-conneclivty between services
a r r e r s e'Vices
CMnect with trỡrtm<7
partners
Business application
services
Biii Of? (i robust
scafabie. and secure
set Vices tớtv/ot(W \
A cces s se 'Vi ces
Facibt&iv mtuructiofis v*ttt:

existing information -3/10
upphcutiotf assets
infrastructure services
Optimize throughput, availability and utilization
:
c
0
L'
V
*%
lớ>
1
u
C
u:
o
l
0
c
U
V
)
:
T '
<D
r j
c
\r.
a
<J>

i-
T ớ
c
ề
r
Ml
n
c:
T
c c
. )
P3
*
ế!
C l
c
a j
r
y r
Hỡnh 1.4: Mụ hỡnh logic cỏc thnh phõn ca h thụng SOA
Trong ú:
Enterprise Service Bus (ESB): L thnh phn c bn ca SOA cung cp kh nng kt
ni cn thit cho nhng dch v trong ton b h thng, bao gm c dch v liờn quan
ti thc hin giao vn (transport), qun lý tỡnh hung (event) v iu phi (mediation).
ESB cho phộp nh phỏt trin tn dng giỏ tr ca phng thc giao tip qua gi nhn
thcng ip m khụng phi thc hin vit nhng on mó chuyờn bit.
Dch v tng tỏc (interaction services) cú trỏch nhim trỡnh by cỏc mụ hỡnh nghip
v Núi cỏch khỏc, õy l nhng thnh phn giỳp cỏc ng dng v ngi dựng cui
giao tip vi nhau, õy ngi dựng cui (enduser) khụng ch l con ngi, m cng
cú th l cm bin, robot,

Dch v quy trỡnh (Process services) chu trỏch nhim cho logic thnh phn. Thnh
phin l tp hp cỏc dch v m c to mt lung tin trỡnh nghip v. V cỏc dch
v quy trỡnh to ra cỏc c ch thnh phn.
Dch v thụng tin (Information services) chu trỏch nhim v tớnh logic ca d liu,
dch v ny cung cp cỏc chc nng tp hp, thay th v chuyn i nhiu ngun d
lii khỏc nhau c thc hin bi nhiu cỏch thc khỏc nhau. Nhng dch v ny cú
mt hai cp : cp bờn ngoi m bo vic cung cp truy cp vo cỏc d liu cựa
doinh nghip v cp bờn trong m bo lung d liu trong t chc.
AI HC QUC GIA H NI
TRUNG TM THễNG IN TH VI N
I o o o a p o o o w -
18
Dịch vụ đôi tác (Partner services) có trách nhiệm thu thập thông tin về đối tác (ví dụ
như các chính sách và hạn chế) và cung cấp tài liệu, giao thức, các chức năng quản lý
đối tác cho những quy trình nghiệp vụ có yêu cầu tương tác với đối tác bên ngoài và
nhà cung cấp.
Dịch vụ ứng dụng nghiệp vụ (Business application services) chịu trách nhiệm về logic
nghiệp vụ cốt lõi. Đây là những dịch vụ được tạo ra đặc biệt để thực hiện các mô hình
nghiệp vụ. Chúng đại diện cho các khối xây dựng cơ bản cho việc thiết kế quy trình
nghiệp vụ . Những dịch vụ này không thể bị phân hủy, thay vì kết nối với các dịch vụ
khác để tạo thành một quy trình nghiệp vụ.
Dịch vụ truy cập (Access services) có trách nhiệm để kết nối các ứng dụng và chức
năng vào kiến trúc hướng dịch vụ. Cung cấp các chức năng bắc cầu cho những ứng
dụng cũ (legacy applications), kho dừ liệu chính, và ESB nhằm kết họp dịch vụ có
trong những ứng dụng hiện tại vào hệ thống SOA.
Dịch vụ đoi mới và tối ưu hóa nghiệp vụ (Business innovation and optimization
services) có trách nhiệm cung cấp các công cụ và các cấu trúc siêu dữ liệu đê đại diện
cho thiết kế nghiệp vụ, bao gồm cả chính sách và mục tiêu nghiệp vụ.
Dịch vụ phát triển (Development services) cung cấp môi trường tích hợp cho thiết kế
và tạo ra giải pháp.

Dịch vụ cơ sở hạ tầng (Infrastructure services) Những dịch vụ này có trách nhiệm để
lưu trữ các ứng dụng SOA và giúp cung cấp sử dụng hiệu quả các nguồn tài nguyên đế
tối ưu băng thông, sẵn sàng và hiệu năng.
Đây chỉ là một tổng quan về các thành phần chính của mô hình SOA. Như đã đề
cập, các công ty khác nhau cung cấp cách nhìn khác nhau trên cùng một vấn đề. Tuy
nhiên, các nguyên tắc chính vẫn như cũ. SOA là một kiến trúc đó là dựa trên dịch vụ,
đóng gói, tái sử dụng và khớp nối lỏng lẻo. Đây là dịch vụ tạo ra giá trị kinh doanh, hỗ
trợ tin học và thế giới nghiệp vụ để giao tiếp một cách thích hợp. Dịch vụ có thế được
truy cập và sử dụng từ bên trong tổ chức với sự giúp đỡ của dịch vụ ESB.
61.3 Các nguyên tắc thiết kế hệ thống SOA
1.3.1 Khớp nối lỏng lẻo dịch vụ (Service Loose Coupling)
Coupling đề cập đển một kết nối hay mối quan hệ giữa hai thành phần. Một biện
pháp của các khớp nối có thể so sánh được với một mức độ phụ thuộc. Nguyên tắc này
ủng hộ việc tạo ra một loại hình cụ thể của mối quan hệ bên trong và bên ngoài địa
giới dịch vụ, với sự nhấn mạnh liên tục giảm sự phụ thuộc giữa các hợp đồng dịch vụ,
sự thi hành, và người tiêu dùng dịch vụ của nó. Nguyên tắc của dịch vụ “Loose
coupling” thúc đẩy thiết kế và đánh giá độc lập logic của một dịch vụ và thực hiện
trong khi vẫn đảm bảo khả năng tương tác với người tiêu dùng. Có rất nhiều loại cua
các khớp nối có liên quan đến trong thiết kế của một dịch vụ, mỗi trong số đó có thể
ảnh hưởng đến nội dung và chi tiết các hợp đồng của nó. Để đạt được mức độ thích
6 [SOA Principles o f Service D esign]
19
hợp của các khớp nối yêu cầu xem xét thực tế được cân đối với các ưu đãi dịch vụ
thiết kế khác nhau.
1.3.2 Sự trừu tượng hóa dịch vụ (Service Abstraction)
Các hợp đồng dịch vụ chỉ chứa đựng thông tin cần thiết và các thông tin về dịch vụ
được giới hạn bởi những gì đã được công bố trong các hợp đồng dịch vụ. Mối quan hệ
trừu tượng vào nhiều khía cạnh của định hướng dịch vụ. Ở mức độ cơ bản, nguyên tắc
này nhấn mạnh sự cần thiết phải ẩn càng nhiều các chi tiết cơ bản của một dịch vụ
càng tốt. Làm như vậy trực tiếp cho phép và duy trì mối quan hệ “loose coupling” như

phần mô tá trước. Sự trừu tượng hóa dịch vụ cũng đóng một vai trò quan trọng trong
việc định vị và thiết kế các thành phần dịch vụ, các hình thức khác nhau của siêu dừ
liệu vào hình ảnh khi đánh giá mức độ trừu tượng thích hợp. Mức độ trừu tưọng áp
dụng có thể ảnh hưởng đến tính granularity của hợp đồng dịch vụ và tiếp tục có thê
ảnh hưởng đến chi phí và nỗ lực cuối cùng của quản lý dịch vụ.
1.3.3 Tái sử dụng dịch vụ (Service Reusability)
Tái sử dụng dịch vụ là nhấn mạnh trong định hướng dịch vụ, vì thế nó sẽ trở thành
một phần cốt lõi của phân tích dịch vụ, các quá trình thiết kể, và cũng tạo cơ sở CỈ10
các mô hình dịch vụ quan trọng. Sự tiến triển của công nghệ dịch vụ đã cung cấp co
hội đế tối đa hóa tiềm năng tái sử dụng dịch vụ đa mục đích trên một mức độ chưa
từng có. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lặp và
tăng tốc độ vững chắc trong cài đặt, nó còn giúp đơn giản hóa việc quản trị.
1.3.4 Khả năng tự phục hồi (Self-healing)
Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục
hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ thống tự
hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà
không cần sự can thiệp của con người. Độ tin cậy (reliability) là mức độ đo khả năng
một hệ thống xử lý tốt như thế nào trong tình trạng hỗn loạn. Trong kiến trúc hướng
dịch vụ, các dịch vụ luôn có thể hoạt động hay ngừng bất kỳ lúc nào, nhất là đối với
những ứng dụng tồng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy
phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi. Hạ tầng mạng phải cho
phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một
khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên để xây dựng ứng
dụng. Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục
hồi hơn một hệ thống không hỗ trợ những tính năng trên. Thêm vào đó, bởi vì những
hệ thống dựa trên dịch vụ yêu cầu sự tách biệt giữa giao diện (interface) và cài đặt nèn
có thể có nhiều cài đặt khác nhau cho cùng một giao diện. Nếu một thể hiện dịch vụ
nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách
hàng mà không bị ảnh hưởng gì. Khả năng này chỉ có được khi khách hàng chí tương
tác với giao diện (interface) của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch

vụ. Đây là một trong những tính chất cơ bản của các hệ thống hướng dịch vụ.
20
1.3.5 Sự tự trị của dịch vụ (Service Autonomy)
Đối với dịch vụ để thực hiện khả năng của mình một cách nhất quán và đáng tin
cậy, giải pháp logic cơ bản để có một mức độ đáng kê của việc kiểm soát môi trường
và tài nguyên của nó. Nguyên tắc tự trị dịch vụ hồ trợ khi mà các nguyên tắc thiết kế
khác có hiệu quả thực hiện trong môi trường sản xuất thực, bằng cách bố sung các đặc
điểm thiết kế làm tăng độ tin cậy của dịch vụ và khả năng dự đoán hành vi. Nguyên tấc
nàv đặt ra các vấn đề khác nhau mà liên quan đến các thiết kế logic dịch vụ cùng
như môi trường thực hiện thực tế của dịch vụ. Mức cô lập và xem xét bình thường hóa
dịch vụ được đưa vào để đạt được một biện pháp phù hợp với quyền tự trị, đặc biệt cho
các dịch vụ tái sử dụng thường xuyên chia sẻ.
1.3.6 Giảm thiểu tiêu thụ tài nguyên dịch vụ (Service Statelessness)
Dịch vụ giảm thiểu tiêu thụ tài nguyên bằng cách trì hoãn việc quản lý thông tin
trạng thái khi cần thiết. Việc quản lý thông tin trạng thái quá mức có thể làm suy yếu
khả năng mở rộng của nó. Dịch vụ lý tưởng thiết kế để duy trì trạng thái khi có yêu
cầu.
1.3.7 Khả năng dò tìm dịch vụ (Service Discoverability)
Khi một client cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số
tiêu chí. Client chỉ cần hỏi một đăng ký (registry) về một dịch vụ nào thởa yêu càu tìm
kiếm rồi trả về cho client một dịch vụ thích hợp.
1.3.8 Khả năng tổng hợp (Composite)
Chức năng phần mềm có thể được đóng gói như là các dịch vụ có mức độ trừu
tượng khác nhau trong một nghiệp vụ. Các dịch vụ có thể được tống hợp đê cài đặt các
dịch vụ có mức độ trừu tượng cao hơn. Ví dụ, việc tổng hợp một quy trình nghiệp vụ
từ các dịch vụ, sau đó quy trình được kết xuất như là một dịch vụ. Khả năng tổng hợp
của dịch vụ liên quan tới cấu trúc đặc tả của dịch vụ. cấu trúc đặc tả cho phép các dịch
vụ có khả năng tổng họp, lắp ráp vào các ứng dụng mà lập trình viên tích hợp không
quan tâm đến dịch vụ đó được thiết kế như thế nào. Bằng việc sử dụng các dịch vụ đã
được kiểm thử và xây dựng hoàn chỉnh làm gia tăng chất lượng của hệ thống phần

mềm. Xây dựng các hệ thống theo kiến trúc hướng dịch vụ là đầu tư cho hiện tại và cả
tương lai. Vì các dịch vụ dễ dàng dùng lại, dễ dàng tổng họp vào các ứng dụng khác.
Với khả năng tổng hợp của dịch vụ làm cho hệ thống phần mềm có thế thích ứng
nhanh chóng với các thay đổi, dễ dàng cải tiến, tái cấu trúc hệ thống phần mềm và
thêm mới các chức năng cho nó một cách nhanh nhất có thể có. Một dịch vụ có thê
được tổng hợp theo 3 cách: ứng dụng tổng hợp, các dịch vụ liên quan, dịch vụ tống
hợp. Một ứng dụng thường là sự lắp ráp, tổng hợp từ các dịch vụ, các thành phần với
nhau cho một mục đích xác định. Dịch vụ liên quan là tập các dịch vụ được quan lý
trong một dịch vụ lớn hơn. Ví dụ, dịch vụ kiểm tra tài khoản, dịch vụ đăng kí tài
khoản, dịch vụ quản lý thông tin khách hàng. Có thể được tổng hợp vào dịch vụ lớn là
dịch vụ khách hàng. Dịch vụ tổng họp là dịch vụ thực thi một nghiệp vụ, tương tác với
21
nhiều dịch vụ hệ thống để tạo ra bản thân nó, thường được gọi là quy trình nghiệp vụ.
Quy trình nghiệp vụ gồm một hay nhiều bước thực hiện, mỗi bước thực hiện là một tác
vụ nghiệp vụ, mỗi tác vụ nghiệp vụ thực hiện gọi dịch vụ đế hoàn thành tác vụ.
71.4 Các đặc điểm của SOA
1.4.1 Hướng nghiệp vụ (Business-Driven)
Kiến trúc công nghệ phù hợp với kiến trúc nghiệp vụ hiện tại. Bối cảnh này sau đó
được duy trì liên tục để các kiến trúc công nghệ phát triển song song với nghiệp vụ
theo thời gian.
1.4.2 Trung lập nhà cung cấp (Vendor-Neutral)
Mô hình kiến trúc không chỉ dựa vào một nền tảng nhất định, cho phép các công
nghệ của các nhà cung cấp khác nhau được kết họp hoặc thay thế theo thời gian đê tối
đa hóa các yêu cầu nghiệp vụ.
1.4.3 Trung tâm doanh nghiệp (Enterprise-Centric)
Phạm vi của kiến trúc đại diện cho một phân đoạn có ý nghĩa của doanh nghiệp, cho
phép tái sử dụng và tống hợp các dịch vụ, đồng thời cho phép các giải pháp hướng
dịch vụ để mở rộng ứng dụng truyền thống.
1.4.4 Trung tâm tổng hợp (Composition-Centric)
Kiến trúc vốn đã hỗ trợ khả năng của việc lặp lại sự tổng hợp dịch vụ, cho phép nó

đế thích ứng với thay đổi liên tục thông qua khả năng nhanh chóng lắp ráp các thành
phần dịch vụ.
1.5 Quy trình xây dựng một hệ thống SOA
Xây dựng một hệ thống SOA trải qua các bước như hình sau:
i
1
f
Service-or »en tod
analysis
Service
development
Service
deployment
1
r
1
f
1
Ỉ
Service oriented
design
Service
testing
Service
administration
i
1
8Hình 1.5: Các bước xảy dựng một hệ thống SOA
Bưóc 1: Service-oriented analysis (Phân tích hướng dịch vụ)
7 [SO A Design Patterns]

8 [Service-Oriented Architecture: C oncepts, T echn ology, and D esign]
22
Đây là pha đầu tiên trong tiến trình xây dựng hệ thống SOA. Pha này có nhiệm vụ
xác định rõ các yêu cầu nghiệp vụ của một hệ thống SOA đồng thời nó quyết định
phạm vi của hệ thống SOA. Các mục tiêu tổng thể thực hiện một phân tích hướng dịch
vụ như sau:
- Xác định một tập hợp sơ bộ của các dịch vụ trong hệ thống.
- Xác định miền dịch vụ:
+ Làm sao gom nhóm các dịch vụ thành các miền luận lý (logic domain).
+ Việc phân loại gom nhóm các dịch vụ thành các miền luận lý sẽ đơn giản hóa kiến
trúc bơi sẽ giảm được sổ lượng các thành phần cần xây dựng.Việc định nghĩa các miền
như thế cũng ảnh hưởng đến nhiều khía cạnh khác của kiến trúc hệ thống như cân
bằng tải, điều khiến truy cập, sự phân chia theo chiều sâu hay chiều rộng cua xử lý
nuhiệp vụ.
- Xác định ranh giới dịch vụ sơ bộ để chúng không trùng với bất kỳ dịch vụ hiện cỏ
hoặc dự kiến.
- Xác định logic đóng gói với tiềm năng tái sử dụng.
- Đảm bảo rằng bối cảnh của logic đóng gói phù họp cho mục đích sử dụng của nó.
- Xác định bất kỳ mô hình thành phần ban đầu được biết đến.
Bưó'c 2: Service-oriented design (Thiết kế hướng dịch vụ)
Thiết kế theo định hướng dịch vụ là một quá trình cụ thể thiết kế dịch vụ vật lý
được dẫn xuất từ các ứng viên dịch vụ hợp lý và sau đó lắp ráp thành các thành phần
trừu tượng mà thực hiện một quy trình nghiệp vụ.
Các cáu hỏi chính đã được trả lời trong pha này là:
- Làm thế nào đế xác định giao diện dịch vụ vật lý có thể được bắt nguồn từ các ứng
viên dịch vụ theo mô hình trong giai đoạn phân tích hướng dịch vụ?
- Những đặc điểm gì của SOA mà ta muốn nhận ra và hỗ trợ?
- Chuẩn công nghiệp gì và phần mở rộng sẽ được yêu cầu bởi SOA để thực hiện thiết
kế các dịch vụ và các đặc tính của SOA?
Các mục tiêu trong giai đoạn này là:

- Xác định các thiết lập cốt lõi của phần kiến trúc mở rộng.
- Thiết lập ranh giới của kiến trúc.
- Xác định các chuẩn thiết kế yêu cầu.
- Xác định giao diện dịch vụ trừu tượng.
- Xác định các thành phần dịch vụ tiềm năng.
- Đánh giá hồ trợ cho các nguyên tắc hướng dịch vụ.
- Khám phá hỗ trợ cho các đặc điểm của SOA hiện tại.
Bưóc 3: Service development (Phát triển dịch vụ)
Giai đoạn này bao gồm việc lựa chọn ngôn ngừ lập trình và môi trường phát triên
các thành phần dịch vụ trong hệ thống SOA, đây là bước xây dựng thực tế hệ thống
SOA dựa trên việc phân tích và thiết kế yêu cầu như ở trên.
23
Buóc 4: Service testing (Kiếm thử dịch vụ)
Đây là pha kiểm thử lại những dịch vụ đã được phát triển xem nó có phù hợp với
đặc tả yêu cầu không.
Buóc 5: Service deployment (Triển khai dịch vụ)
Sau khi kết thúc việc kiểm thử dịch vụ thì đây là giai đoạn cài đặt và cấu hình các
thành phần cua hệ thống SOA.
Bước 6: Service administration (Quản trị dịch vụ)
Sau khi triển khai các dịch vụ thì vấn đề quản trị dịch vụ là mối quan tâm hàng đầu,
việc quản trị các dịch vụ để biết được các dịch vụ có làm việc tốt khi kết hợp với nhau
trong môi trường phân tán không, việc quản trị dịch vụ cho phép ta ghi lại các thông sổ
khi thực thi của các dịch vụ như thời gian đáp ứng, khả năng bảo mật, và dựa vào
những thông số này ta có thể có những quyết định về nâng cấp hoặc thay đổi cấu hình
các dịch vụ để cho hệ thống làm việc tốt hơn.
1.6 Các chiến lược thiết kế hệ thống SOA
1.6.1 Chiến lược thiết kế top-doyvn
Chiến lược thiết kế top-down là chiến lược lấy xuất phát điểm là các yêu cầu nghiệp
vụ, sau đó phân tích xác định các yêu cầu chức năng, các tiến trình nghiệp vụ, các user
case và đi tới việc xác định các thành phần, dịch vụ của hệ thống. Chiến lược thiết kế

top-down là phù hợp nhất khi ta cài đặt một hệ thống mới từ đầu.
Chiến lược top-down bao gồm các bước như hình dưới đây. Chú ý ràng phương pháp
tiếp cận này giả sử rằng các yêu cầu nghiệp vụ đã có sẵn và đã được định nghĩa.
9 ' '
Hình 1.6: Các bước xảy dựng hệ thông theo chiên lược top-down
- Bước 1: Define relevant ontology.
Những gì một ontology thiết lập là một sự phân loại các tập thông tin đã được xư lý
bới một tổ chức. Các kết quả này là các từ vựng phổ biến, như sự định nghĩa mối quan
hệ giữa các tập thông tin này với tập thông tin khác là như thế nào. Các tố chức lớn với
l) [Service-Oriented Architecture: C oncepts, T ech n ology, and D esign]
24
nhiều vùng nghiệp vụ có thế có vài ontology, quản lý một bộ phận cụ thể của nghiệp
Nếu như một từ vựng nghiệp vụ không tồn tại cho bất cứ các tập thône tin nào mà
một giải pháp được yêu cầu để thực hiện, thì sau đó bước này yêu cầu rằng nó đà được
xác định. Một số lượng đáng kể các tập thông tin trước và kết quá phân tích nghiệp vụ
ở mức cao có thể được yêu cầu.
- Bước 2: Align relevant business models
Sau khi ontology được thiết lập, sự tồn tại các mô hình nghiệp vụ có thê cần thay
đôi (hay tạo ra) để đại diện thích hợp cho từ vựng đã được cung cấp bởi ontology trong
các điều khoản mô hình nghiệp vụ. Mô hình thực thể chi tiết rất quan trọng.
- Bước 3: Perform service-oriented analysis
Xác định các dịch vụ và hướng tiếp cận cho các dịch vụ, mô hình hóa các dịch vụ.
- Bước 4: Perform service-oriented design
Thực hiện thiết kế hướng dịch vụ.
- Bước 5: Develop services
Phát triển các dịch vụ theo yêu cầu. Các dịch vụ được phát triển theo những bán
thiết kế kỹ thuật tương ứng với các đặc tả dịch vụ được tạo ra ở bước 4.
- Bước 6: Test service operations
Giai đoạn kiểm thử được yêu cầu cho tất cả quá trình hoạt động của dịch vụ và quá
trình kiểm tra phải thực hiện đảm bảo chất lượng. Các dịch vụ vượt qua được sụ kiêm

tra coi như đạt chất lượng và có thể tái sử dụng sau này.
- Bước 7: Deploy service
Quan tâm tới vấn đề thực thi, xác định tiềm năng tương lai sử dụng lại cùa dịch vụ.
Để tạo điều kiện cho nhiều người yêu cầu dịch vụ, các dịch vụ sử dụng lại có thể mơ
rộng năng lực xử lý và cần có sự bảo mật. Đồng thời, cần phải cung cấp cả khả năng
truy cập cho dịch vụ.
1.6.2 Chiến lược thiết kế bottom-up
Cách tiếp cận này về cơ bản khuyến khích việc tạo ra các dịch vụ như một phương
tiện thực hiện các yêu cầu ứng dụng trung tâm. Các web service được xây dựng trên eo
sở "khi cần thiết" và mô hình hóa để đóng gói logic ứng dụng, để phục vụ tốt nhất các
yêu cầu trước mắt của giải pháp. Tích hợp là động lực chính của kịch bản bottom-up,
chiến lược này dựa trên việc phân tích các tài nguyên có sẵn của hệ thống hiện có và
tái sử dụng lại những thành phần này trong việc xây dựng các dịch vụ mới nơi mà cần
phài tận dụng lợi thế khuôn khổ mở của giao thức SOAP để có thể gắn thêm các dịch
vụ như sự bao bọc cho các hệ thống cũ. Sau khi có được các dịch vụ từ những thành
phần đó, ta có thể cải tiến chất lượng dịch vụ hoặc tổ họp các dịch vụ lại đế tạo ra
những dịch vụ cao cấp hơn hay còn gọi là các dịch vụ tổ hợp.
Trong hướng tiếp cận này, ta thừa nhận các yêu cầu nghiệp vụ đã tồn tại.
25
10Hình 1.7; Các bước xây dựng hệ thống theo chiến lược bottom-up
- Bước 1 : Model application services
Kết quả của giai đoạn này là sự định nghĩa cùa các yêu cầu ứng dụng được thoa
mãn thông qua việc sử dụng Web service. Các yêu cầu này bao gồm những thiết lập
lèn các kênh tích hợp point-to-point giữa hệ thống cũ (legacy system) hoặc giải pháp
B2B (Business-to-Business). Các yêu cầu phổ biến khác sẽ dần xuất hiện để thay công
nghệ truyền thông truyền thống bằng những framework truyền thông điệp SOAP.
Các dịch vụ ứng dụng cũng sẽ được mô hình hóa bao gồm các logic và quy tắc cho
nghiệp vụ cụ thể.
- Bước 2: Design applicaion services
Một vài các dịch vụ ứng dụng được mô hình hóa trong bước 1 có thể được trinh bày

thành bản thiết kế. Các dịch vụ có thể cung cấp thêm vào cho thiết kế.
Các dịch vụ ứng dụng tùy chọn, mặc dù sẽ cần trải qua quá trình thiết kế mà trong dó
các tiêu chuẩn thiết kế hiện tại được áp dụng để đảm bảo một mức độ của sự nhất
quán.
- Bước 3: Deploy application service
Các dịch vụ ứng dụng được phát triển theo sự mô tả dịch vụ và bản thiết kế chi tiết
ứng dụng.
- Bước 4: Test service
Các dịch vụ, môi trường kết họp của chúng, và logic của những hệ thống cũ sẽ được
kiểm thử để đảm bảo chẳc chắn rằng xử lý các yêu cầu là phù hợp. Hiệu năng và các
độ đo kiếm thử đã được sử dụng để thiết lập các tham số xử lý của các hệ thống cũ đã
được lộ ra thông qua các dịch vụ bao bọc. Kiểm thử bảo mật cũng là phần quan trọng
của giai đoạn này.
- Bước 5: Deploy services
'° [Service-Oriented A rchitecture: Concepts, T echn ology, and Design]
2 6
Giai pháp và các dịch vụ ứng dụng của nó đã được triền khai thành sán phâm. Sụ
cân nhấc cài đặt cho các dịch vụ ứng dụng thường xuyên viện dần các yêu cầu về hiệu
năng và bảo mật.
Nhăn xét:
•
Hiện nay phát triển phần mềm theo kiến trúc SOA đang phát triển mạnh. Và cả hai
chiến lược xây dựng hệ thống top-down và bottom-up đều được áp dụng rộng rãi, tùy
vào hiện trạng của hệ thống hiện tại cũng như các yêu cầu về thời gian, chi phí phái
triển mà ta cỏ thể vận dụng một chiến lược thiết kế thích hợp. Ví dụ, một so hệ thống
cù muốn nâng cap hay tích hợp thêm một sổ dịch vụ hoặc tô hợp lại với nhau thành
một hệ thống lớn, thường sử dụng chiến lược bottom-up đê tận dụng cơ sở hạ tâng có
sẵn và tiết kiệm chi phí. Còn hầu hết những hệ thống lớn hiện nav đi vào xảy dựng đều
theo định hướng SOA và áp dụng chiến lược top-down, nham mục đích đam bao kha
năng mở rộng và thường xuyên thay đổi các yêu cầu với hệ thong. Người ta cũng có

thể vận dụng mềm dẻo trong sự kết hợp cả hai chiến lược thiết kế top-down và bottom-
up vào trong văn cảnh cùa từng bài toán để cho việc thiết kế hệ thống SOA được linh
hoạt hơn.
"1.7 SOA và vấn đề tích họp
Lý do chủ yếu cho việc thúc đẩy các hoạt động ứng dụng mô hình SOA chính là
nhằm giải quyết bài toán tích hợp. Đối với nhiều nhà quản lý, mô hình SOA giữ một vị
trí quan trọng trong việc xóa bỏ các mô hình tích hợp truyền thống khá quen thuộc với
họ, thông qua các tiêu chuẩn công nghiệp và ứng dụng hiện đại. Một số phân tích đã
ước lượng khoảng 30% chi phí Công nghệ thông tin thông thường được sử dụng trong
các hoạt động tích hợp. Hiệu quả của nghiệp vụ sẽ phụ thuộc vào tính tích hợp, từ tích
hợp quy trình, tích hợp các thành phần của cơ quan, tổ chức, đến tích họp các vấn đề
liên quan đến tách nhập các khối chức năng. Hay nói cách khác, chính giá trị về đây
mạnh tính cạnh tranh của cơ quan, tổ chức đã mang lại nhu cầu về tích hợp.
/. 7.1 Nhu cầu giải quyết bài toán tích hợp
Các nghiên cứu gần đây cho biết công tác hỗ trợ tính tương thích ngược và bảo trì
hệ thống chiếm khoảng 80 đến 90% chi phí đầu tư Công nghệ thông tin, thay vì dành
cho hoạt động đầu tư vào các hệ thống mới. Đây là vấn đề gây trớ ngại cho hầu hết các
giám đốc Công nghệ thông tin khi phân bổ kinh phí đầu tư Công nghệ thông tin và
cũng chính là một trong các lý do cho việc thiếu các chiến lược đầu tư Công nghệ
thông tin theo chiều sâu như hiện nay. Nhu cầu về tích hợp Công nghệ thông tin và
quy trình được chi phối bới các yêu cầu về nghiệp vụ, bao gồm:
- Nâng cao hoạt động tách nhập (M&A actitivity).
- Phối họp tổ chức và cấu trúc lại mô hình tổ chức.
' Củng cố ứng dụng và hệ thống.
- Sáng kiến về tích hợp dữ liệu và kho dữ liệu (data warehousing).
11 [h ttp://ww w.diap.gov.vn]
27
- Xõy dung chiờn lirgc nghiờp vu nhm tõn dung cõc hờ thụng hiờn tai dõp irng quy
trinh mai.
- Dat duge su tuõn thự vờ quy dinh.

- Gõn kờt cõc quy trinh nghiờp vu dờ nõng cao hiờu nõng.
1.7.2 Chuyờn dụi sang irng dung dich vu
Phuong an chung cho viờc tich hop hiờn tai l kờt hap sir dung cõc giõi phõp lụp
giựa, k thuõt tich hop diờm-diờm riờng biờt, v cõc giõi phõp huụng tich hop chien
lucre (d thõt bai ngay tựr khi mai dờ xuõt). Cõc giõi phõp ny thung khụng cụ duac
tinh bờn vCrng cao, trong khi lai yờu cõu chi phi bõo tri ngy mot tng.
Do võy, giõi phõp tich hgp mai cõn phõi loai trir tõt cõ cõc kờt nụi tich hop truc tiờp
diờm-diờm v cõu truc lai viờc tich hgp giCra cõc hờ thụng, dan vi cụ nhu cõu dua tien
quan diờm mụ hinh SOA. Chi phi Cụng nghờ thụng tin sở duge tinh toõn dờ dõm bõo
kinh phi cho nhựng giõi phõp, du õn, bao gụm cõ chi phi cho cõn bụ chuyờn trõch, chi
phi bõo tri v dõu tu, duy tri ha tõng Cụng nghờ thụng tin. Dụng thi su gim bõt khụi
lirgng cụng viờc dnh cho viờc tich hgp sở phõi duge uục lugng thụng qua su dung cõc
dich vu cụ thờ sir dung lai duge trong mụ hinh SOA v phõn tich phn img cua ngui
su dung dụi vai viờc tich hgp ny. Tuy rng viờc tich hgp thụng qua huụng dich vu sờ
yờu cõu nhiờu quy dinh cỹng nhu kờ hoach han cõc mụ hinh tich hgp truục dụ, kờt quõ
thu duge hon ton tuang xirng dờ quyờt dinh dõu tu.
1.8 SOA v hiỗu nõng
1.8.1 Phõn tich võn dờ hiờu nõng trong hờ thụng SOA
Ta cụ thờ xem xột tien trinh xir l thụng diờp cỹa nhợmg ỷng dung SOA qua sa dụ
truyờn thụng diờp nhu sau:
Consumer ESB P rovider
Lan se rvice
R e st I:
Serialize
__
j re ct e s :
S e rc re u te s :
ftct:e reỗ u e s :
De serialize
re c c e s :

A c c es s
reỗ u e s :
Serialize
reỗ u e s :
S e rc r e s p e rse
R c i:e resper-se
| Desenalize
resper se
12
1 \ * ' X *
Hinh 1.8: Biờu dụ tuõn tu cua mot cuục goi dich vu
12 [SOA in Practice]