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Í

K IÉ N T R Ú C H Ư ỞN G D ỊC
H
•

vụ VÀ ỨNG
•

DỤNG
P H Á T T R IỂ N PHẦN
•

M È M C H Ứ N G 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
MỤC LỤC

CHƯƠNG 1 - TÓNG QUAN VỀ SOA...........................................................................
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 D CO M .......................................................... .........................................................
1.1.2 .NET Remoting......................................................................................................
1.1.3 RMI....... ....... ....................................... ........................... ......................................
1 . 1 . 4 . C O R B A . . . . .................................................................................

12
12
12
13
14

.................................................................................. 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 SO A ...................................................................................... 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 SO A ....................................................................................................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 S O A ..........................................................................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 S O A .................................................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


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 B u s ...................................................................................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....................................................................................... 5 1
4.1.1 Mô tả khái quát.......................................................................................................5 1
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ện h .........................................................................................................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Ệ T H Ố N G ..................................................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 N am .. 58
5.3 Thiết kế hệ thống phần mềm mới theo kiến trúc SO A ............................................. 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 L U Ậ N .......................................................................................................................... 77
TÀI LIỆU THAM K HẢ O .................................................................................................. 78


6
DANH M Ụ C HÌNH VẼ

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 S O A ................................................................................... 16
Hình 1.4: Mô hình logic các thành phần của hệ thống SO A ........................................ 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
Hình
Hình
Hình
Hình
Hình

2.2:

2.3:
2.4:
2.5:
3.1:
3.2:

Một ESB cung cấp các kết nối điểm tới điểm ..................................................43
Một kết nối hòa giải của ESB [SOA in Practice]..............................................43
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
Một ESB sử dụng các bộ chắn............................................................................. 46
Mô hình chương trình thống nhất đã được thiết lập bởi W CF........................ 47
Kiến trúc của W CF............................................................................................... 48

Hình
Hình
Hình
Hình
Hình
Hình

4.1:
4.2:
4.3:
5.1:
5.2:
5.3:

Sơ đồ quy trình nhập lệnh môi giới.....................................................................52
Sơ đồ quy trình hủy lệnh môi giới.......................................................................54
Sơ đồ nghiệp vụ quy trình sửa lệnh môi g iớ i.................................................... 56

Mô hình các thành phần của hệ thống phần mềm hiện tạ i...............................59
Các thành phần phần mềm được thiết kế theo kiến trúc S O A ........................ 62
ESB được triển khai để hỗ trợ cơ chế cân bằng tải và khắcphục lỗi...............67

Hình
Hình
Hình
Hình

5.4:
5.5:
5.6:
5.7:

Màn hình
Màn hình
Giao diện
Giao diện

giao diện đặt lệnh cho khách hàng.....................................................74
giao diện vấn tin lệnh đặt của khách hàng........................................74
vấn tin tổng hợp tài khoản khách hàng............................................. 75
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


7
DANH M Ụ C BẢNG BIÉƯ

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
Bảng
Bảng
Bảng

5.3:
5.4:
5.5:
5.6:

Mô
Mô
Mô
Mô

tả
tả
tả
tả

thông
thông
thông
thông

tin
tin
tin
tin

cho bảng Customers................................................................. 69
bảng GlStockCode.....................................................................69
bảng StockPrice......................................................................... 70
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


8

BẢNG CÁC KÝ HIỆU V IẾT TẮT
X t7 •
Diên giai

r \ •

Ký hiệu viết tắt
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

W CF

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
TRO N G 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ý

Middleware

nghiệp vụ chính.
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.
C huong 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 - ủ n g 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
C huong 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

C H Ư Ơ N G 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

p ro to col s ta c k

c o r / r u r t ir r e

c o r/

t

corrporert

p ro to c o l s ta c k

♦

DCOM

r e t w o rk p ro to c o l

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

[SO A With .NET and w indow s 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 w indow s 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
p ro v id e r

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 [B u ild in g S O A -b a se d S o lu tio n s for IB M S y ste m i P latform ]
4

[h ttp ://w w w .ser v ice -a rc h ite c tu r e .c o m ]


17

H u sin ess services
h x p lo il the S O A fo u n d a tio n ta d e live r a c o m p o rte n i b u s in e s s m o d e l

Bus n e s s inn ovation & o p tim iza tio n s e rvices
Provifle for better decision-m aking with real-tim e business

Interaction services
Vi
X

UfQb'e COQoợỷtfon
t'.eợ'A'fợ f?/i peopfe

a;


*-> i
Ui


.
V

Info rm ation services

p ro cess services

Mỷnự'ầfỷ diverse ỹỷtc
and contfin* in H iớivirt

Ifc/icsfrcjfc.' //èCè ôjuiorr/tift:

business processes

manner

cvoce-sscs 5 :r?iTc.*r??ỷi.'ỷfù

g

Qtj
ẩ
Sfl
G
G. u. u
oÊỗ
X
> n
c ai
re u
ttợ

E n terprise s ervice bus Enable inter-conneclivty betw een services

a r r e r s e 'V ices

CMnect with trỡrtm <7
partners

B u sin ess application
s e rvices
Biii Of? (i robu st

A c c e s s s e 'Vi ces

lớ>
u
l

0
)
T'
iề
Ml
n
c
P3

:
c
L'
*%
1
C
u:
c
U
:
rj
c
\r.
Tớ
r
c:
c
*
ế!
c

0
V
o
V
a
<J>
c
T
)

.

Cl
aj

Facibt&iv mtuructiofis v*ttt:
existing information -3/10
upphcutiotf assets

scafabie. and secure
set Vices tớtv/ot(W \

infrastru ctu re s e rvices
O ptim ize throughput, availability and utilization

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

1f

Service-or »entod
analysis

Service
development

Service
deployment

1r

1f

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 [S O A D esig n Patterns]
8 [S ervice-O rien ted A rchitecture: C o n cep ts, T e c h n o lo g y , and D esig n ]


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) [S erv ice-O rien ted A rchitecture: C o n cep ts, T e c h n o lo g y , and D esig n ]

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

'° [S ervice-O rien ted A rchitecture: C o n cep ts, T e c h n o lo g y , and D esig n ]


26

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à bottomup 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 ://w w w .d ia p .g o v .v n ]


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

ESB

P ro vid e r

Lan s e rv ic e
Se rialize

__ j re c te s:
S e rc re u te s :
ftc t:e r e ỗ u e s :
D e se rialize
re cce s:
A ccess
re ỗ u e s :
Se rialize
re ỗ u e s :
S e rc re s p e rse
R c i:e resper-se
| D e sen alize
resper se
R e s t I:

\
* ' X
*

Hinh 1.8: Biờu dụ tuõn tu cua mot cuục goi dich vu

121

12 [SOA in Practice]