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

Để 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

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ• • •

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 D C O M 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 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

M ỤC LỤC

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 a m 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

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 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 W C F 47

Hình 3.2: Kiến trúc của W CF 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 g iớ 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 S O A 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 àn g 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 àn g 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ù n g 76

DANH M Ụ C HÌ NH VẼ

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ÉƯ

BẢNG CÁC KÝ HIỆU V IẾT TẮT

Ký hiệu viết tắt r \ • Diên giaiX t 7 •

CORBA Common Object Request Broker Architecture

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

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ụ

TÙ ĐIÉN THU ẬT NGŨ s ử DỤNG T R O 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ý 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ụ

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

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ụ

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

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

'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 in dow s Azure]

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

2Hình 1.2: Kiến trúc phản tầng của NET Remoting

2 [SOA With NET and w in d ow s Azure]

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

ư u điểm RM I:

- 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ềumá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ư 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)

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 consum er

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 SOAtheo 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ếntrúc cùa hệ thống SOA

1 [B u ild in g S O A -b a s e d S o lu tio n s for IB M S y ste m i P latform ]

[h ttp ://w w w s e r v ic e -a r c h ite c tu r e c o m ]

4

h x p lo il th e S O A fo u n d a tio n ta d e liv e 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 o v a tio n & o p tim iza tio n s e rv ic e s Provifle for b etter decision-m aking with real-tim e business

Interaction se rv ic e s

UfQb'e COỈÍQÙoîûtfon t'.eî'A'fî f?/i p e o pfe cvoce-sscs 5 :r?iTc.*‘r??ûi.'ûfï

E n terp ris e s e rv ic e bus Enable inter-conneclivỉty betw een services

Biiiỉơ Of? (i robu st

scafabie and secure set Vices títỉv/ĩotỉ(ĨW Ỉ \ĩ

u: o

l

0 cU V Ư) :

T '

<D

r j c

n c : Tỉ

c c ) P3 Ư*

Enterprise Service Bus (ESB): Là thành phần cơ bản của SOA cung cấp khà năng kết

nối cần thiết cho những dịch vụ trong toàn bộ hệ thống, bao gồm cả dịch vụ liên quan tới thực hiện giao vận (transport), quản lý tình huống (event) và điều phối (mediation) ESB cho phép nhà phát triển tận dụng giá trị của phương thức giao tiếp qua gửi nhận thcng điệp mà không phải thực hiện viết những đoạn mã chuyên biệt

Dịch vụ tương tác (interaction services) có trách nhiệm trình bày các mô hình nghiệp

vụ Nói cách khác, đây là những thành phần giúp các ứng dụng và người dùng cuối giao tiếp với nhau, ở đây người dùng cuối (enduser) không chỉ là con người, mà cũng

có thể là cảm biến, robot,

Dịch vụ quy trình (Process services) chịu trách nhiệm cho logic thành phần Thành

phin là tập hợp các dịch vụ mà được tạo một luồng tiến trình nghiệp vụ Và các dịch

vụ quy trình tạo ra các cơ chế thành phần

Dịch vụ thông tin (Information services) chịu trách nhiệm về tính logic của dừ liệu,

dịch vụ này cung cấp các chức năng tập hợp, thay thế và chuyển đổi nhiều nguồn dừ liệi khác nhau được thực hiện bởi nhiều cách thức khác nhau Những dịch vụ này có mệt ở hai cấp độ: cấp độ bên ngoài đảm bảo việc cung cấp truy cập vào các dừ liệu cùa doinh nghiệp và cấp độ bên trong đảm bảo luồng dữ liệu trong tổ chức

ĐAI HỌC QUỐC GIA HẢ NỘI

■ TRUNG TẤM THÔNG ỈIN THƯ VIẺ N

I o o o a p o o o w

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 [SO A Principles o f Service D esign ]

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ụ

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

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:

Service-or »en tod analysis

Service development

Service deployment

Service oriented design

Service testing

Service administration

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 e sig n Patterns]

8 [S erv ice-O rien ted A rch itectu re: C o n cep ts, T e c h n o lo g y , and D e sig n ]

Đâ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

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 adm inistration (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

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 er v ic e -O r ie n te d A rch itectu re: C o n cep ts, T e c h n o lo g y , and D e sig n ]

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êmtra 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 ranhữ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

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 erv ice-O rien ted A rch itectu re: C o n c e p ts, T e c h n o lo g y , and D e sig n ]

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

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

- Xây dung chiên lirgc nghiêp vu nhàm 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 này thuàng không cô duac tinh bên vCrng cao, trong khi lai yêu câu chi phi bâo tri ngày mot tàng

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 thài su giàm bât khôi lirgng công viêc dành 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 phàn img cua nguài

su dung dôi vai viêc tich hgp này Tuy ràng 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 hoàn toàn tuang xirng dê quyêt dinh dâu tu

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:

Lan s e rv ic e

R e s t I:

Se rialize _ _ j r e c t e s :

Hinh 1.8: Biêu dô tuân tu cua mot cuôc goi dich vu

12 [SOA in Practice]

Theo biểu đồ này, đầu tiên phải serialize cuộc gọi dịch vụ tới giao thức định dạng cua ESB Sau đó gửi yêu cầu qua ESB tới Provider, tiếp theo Provider thực hiện deserialize lại yêu cầu gửi tới để thực hiện xử lý yêu cầu rồi lại bắt đầu một quá trinh gửi phản hồi tới consumer tương tự như việc gửi yêu cầu tới Provider Như vậy ta thấy

có những bước có thể ảnh hưởng tới tốc độ xử lý một cuộc gọi dịch vụ là:

- Việc gửi yêu cầu và phản hồi thông qua trung gian là ESB

- Deserializing lại yêu cầu hoặc phản hồi

- Ọuá trình xử lý yêu cầu

Ta chú ý rằng SOA là một ý niệm chung cho các hệ thống không đồng nhất Bơi lý

do này, chúng ta không đon giản để gửi dữ liệu nhị phân giữa các hệ thống (mã cua COBOL không khớp với mã byte của Java, và thậm chí mã họp ngừ của C++ ở những chương trình biên dịch khác nhau cũng không nhất thiết khớp với nhau) Ta cần một giao thức trung gian mà consumer và provider có thể sử dụng để trao đối dữ liệu

Việc sử dụng một giao thức trung gian có thể cũng có ảnh hưởng tới hiệu năng cua hệ thống vì quá trình deserialization Điều này là một hạn chế, bởi vì nó có thế mất thời gian đế thông dịch một chuồi byte tới dữ liệu phức tạp Tuy nhiên, sự nhận thức của ta trong việc chấp nhận so với không chấp nhận độ trễ phụ thuộc vào các yêu cầu và các công cụ của ta

Có một trường hợp nơi băng thông và quá trình deserialization là có nhiều khả năng trở thành vấn đề: Nếu ta phải xử lý dữ liệu trong khi các yêu cầu đang truyền thòng trong ESB Ví dụ, nếu ta phải ánh xạ dữ liệu giữa những giao thức khác nhau hoặc muốn kiểm chứng bên trong ESB của ta dù các cuộc gọi dịch vụ đã được hình thành, điều này có thể làm chậm đáng kể thời gian chạy của một cuộc gọi dịch vụ Việc thêm vào mức độ bảo mật thông điệp cũng có thể ảnh hưởng tới thời gian chạy

Thực tế, lý do chính của sự chậm này là những cài đặt của chúng làm mất thời gian Điều đó là, bên cung cấp dịch vụ cần thời gian để xử lý yêu cầu và phản hồi lại kết quả Trong trường hợp này, ta phải nhìn vào thời gian trả lời thông thường cho một dịch vụ và xem xét như thế nào tốt cho mức thời gian trả lời này Nếu nhà cung cấp dịch vụ đã giới hạn tài nguyên hoặc sự tắc nghẽn, quá trình xử lý nhiều cuộc gọi dịch

vụ ở thời gian như nhau dẫn tới sự bất lợi đáng kể về hiệu năng Vì lý do này, một hợpđồng dịch vụ nên viện dẫn sự thỏa thuận mức dịch vụ chỉ rõ cả thời gian trả lời trunghình và số các cuộc gọi tới được trả lời trong một chu kỳ thời gian Nếu thời gian phan hồi của một dịch vụ là quá chậm cho người dùng và ta không thế cải thiện hiệu năng bằng cách nâng cấp cấu hình một hệ thống mạnh hơn hoặc băng thông lớn hơn, ta thường phải tách ra những thành phần trên khía cạnh người tiêu dùng Điều đó là, dịch

vụ tiêu dùng không phải đồng bộ chờ đợi cho một trả lời tới cuộc gọi dịch vụ của nó Chú ý sự truyền thông bất đồng bộ đó có thể làm tăng đáng kể sự phức tạp của hệ thống, đồng thời những mạng không tin cậy và những giao thức có thế cũng có một

anh hưởng với hiệu năng hệ thống cua ta Mặc dù không phải xem nó trong các API dịch vụ của ta, một yêu cầu dịch vụ phải được gửi qua ESB hơn một lần trước khi nó phân phát thành công.

Nói chung, nó là một ý tưởng tốt để tập hợp các số liệu thống kê về thời gian chạy cua những yêu cầu dịch vụ khác nhau và giám sát các con số theo thời gian Điều này

có thể giúp ta xác định các vấn đề ngắn hạn và các xu hướng dài hạn

1.8.2 Các ràng buộc lời gọi

Một vấn đề với hiệu năng là nó khó để dự đoán Ta luôn luôn phải đo Nhưng đề đo,

ta cần một phần mềm để sử dụng Khi ta cài đặt một dịch vụ mà được cung cấp cho hai người tiêu dùng khác nhau, ta phải tìm thấy bên ngoài tại một giai đoạn muộn cua sụ phát triển mà phải tách dịch vụ mới này vào trong hai dịch vụ vì các lý do về hiệu năr.g Tuy nhiên, việc thêm một dịch vụ mới ở giai đoạn muộn của sự phát triển hệ thống phân tán có thề là một vấn đề của chính nó (các giao diện thay đôi, và ta phải đi qu£ tất cả các bước của vòng đời cho các dịch vụ bên dưới sự phát triển

Đế tránh chi phí này, chúng ta đưa ra khái niệm “các ràng buộc cuộc gọi” Khi một dịci vụ mới nhận được bản thiết kế, nó luôn luôn nhận được một sự thêm vào chuỗi các thuộc tính gọi là các ràng buộc lời gọi (callConstraints) Sau đó, nếu vấn đề đã được khám phá tại thời điểm chạy và nó là quá muộn để chỉnh sửa chúng trong một gia} diện dịch vụ, nhà cung cấp và những người tiêu dùng có thế đồng ý dựa vào một

cờ đặc biệt đó là băng qua trong các thuộc tính này để vận dụng trường hợp đặc biệt hoặc đe thực hiện một vài sự tối ưu hóa Đây là một tính năng tương lai rất hữu ích, nhưng chú ý nên cân nhắc nó với một cách giải quyết khác cho phép ta đôi khi để sứa chữa vấn đề trong một phiên bản trong tương lai (mặc dù, như chúng ta đã biết, một cách giải quyết tạm thời thường có thời gian sống lâu nhất trong thực tế)

Sỉhư vậy hiệu năng cũng là một vẩn đề của hệ thống SOA, vậy khi nào thì chủng ta né) sử dụng SOA? Đó là khi thiết kế hệ thong đặt ra một câu hỏi lớn là việc cân nhác giũa khả năng tái sử dụng lại các dịch vụ và hiệu năng cùa hệ thống Trường hợp hệ thõìg cần chạy nhanh cho một ứng dụng đặc biệt thì RMỈ, CORBA, DCOM là sự lựu chtn tốt, tuy nhiên việc phát triển phản mềm theo các kiến trúc đó có nhược điểm lù các hệ thống đó khó cỏ thể thay đổi hoặc tái sử dụng lại trong tương lai Trường hợp

hệ fhống dự định thay đổi thường xuyên mà không yêu cầu quá cao về tốc độ thì SOA

là ỉhương pháp tiếp cận tốt nhất.

1.9 SOA và bảo mật

1.91 Các yêu cầu bảo mật

Chi thảo luận về bảo mật trong các hệ thống phân tán, nhiều khía cạnh khác nhau bêi trong các kịch bản, và thường thường có nhiều cách khác nhau để phân loại chúng

Nỏ chung, các hạng mục sau đây là chính:

Xá: thực (Authentication)

Xác thực phải làm với sự kiếm tra lại một nhận dạng Một sự nhận dạng có thể là nhận dạng một người dùng, 1 thiết bị vật lý hoặc một sự yêu cầu dịch vụ bên ngoài Đôi với SOA, điều này có nghĩa là tìm ra người đang gọi dịch vụ

Uy quyền (Authorization)

ủ y quyền phải làm với sự quyết định những gì một nhận dạng đã được cho phép dê làm Đối với SOA, điều này có nghĩa là sự kiểm tra có hay không các lời gọi đã được cho phép để gọi các dịch vụ và trả về kết quả

Sự tin cân (Confidentiality)

C’ho dù dừ liệu vẫn còn bí mật trong khi truyền hoặc lưu trữ là khía cạnh quan trọng khác của bảo mật Đối với các dịch vụ, điều này có nghĩa là đảm bảo rằng không có ai bên ngoài các cuộc gọi dịch vụ có thể thấy dữ liệu dịch vụ trong khi nó đang được truyền thông giữa các nhà cung cấp và người tiêu dùng

Tính toàn vẹn (Integrity)

Chìa khóa ở đây là đảm bảo ràng dừ liệu không thể được chế tác hoặc làm giả, chăng hạn hoặc dữ liệu chỉ đơn giản là sai, hoặc thậm chí tệ hơn, khả năng xác thực và uy quyền đã được làm giả đế ai đó có thể truy cập dữ liệu mặc dù không được phép

Tính sẵn sàng (Availabilityj

Nó có thể tấn công "lù" một hệ thống theo cách như vậy, trong khi dừ liệu không bị mất hoặc bị hỏng, hệ thống chỉ đơn giản là trở thành không thế hoạt động Một hình thức điển hình của lũ lụt là một tấn công từ chối dịch vụ

Sự tính toán (Accounting)

Chìa khóa ở đây là để theo dõi mức tiêu thụ các nguồn tài nguyên, về SOA, điều này

có nghĩa là theo dõi các cuộc gọi dịch vụ cho quy hoạch, quản lý, thanh toán, hoặc các mục đích khác

“kiểm định” Ví dụ vì lý do pháp lý

1.9.2 S ự thỏa thuận với các yêu cầu bảo mật

Sự thỏa thuận với bảo mật là không có gì mới Đối với tất cả các khía cạnh đà đề cập ở trên về tính bảo mật, SOA sử dụng các phương pháp tiếp cận tương tự được sứ dụng với các hệ thống phân tán:

- Đối với sự xác thực và ủy quyền, thường cần thông tin về mã người dùng và mật khẩu (mặc dù có những chuẩn xác thực khác, như Kerberos, certificates, hardware

tokens, ) Đối với mã người dùng, đặc trưng ở đây là một vài dạng của hành động gián tiếp bởi vậy những người dùng có thể được gán các quyền; các quyền như là kha năng đề gọi một dịch vụ hoặc khả năng để thấy một kết quả đã được kết hợp với các quvên khác Neu có một dịch vụ trung tâm để quán lý các người dùng và các thông tin

cơ bán của người dùng, điều này thường được gọi là một sự cung cấp nhận dạng

- Đôi với sự tin cân và tính toàn vẹn, các nội dung thông thường như sự mã hóa và chù

ký điện tử đã được sử dụng

Đối với các nội dung này, bảo mật SOA là không khác bảo mật trong một vài dạng khác của sự sử dụng máy tính phân tán Tuy nhiên, có một vài khía cạnh đặc biệt của SOA dưới đây

□ Khá năng cộng tác đối vói bảo mật

Một khái niệm quan trọng của SOA là khả năng cộng tác cao Đối với các khái niệmcủa tích hợp ứng dụng doanh nghiệp (EAI), nó nên được dễ dàng để kết nối tới các hệthống khác Trong SOA, ý tưởng là để thay thế các giải pháp kết nối cá nhân cho mồi cặp của hệ thống với một ESB chung, bởi vậy một vài hệ thống đã được kết nối tới ESB này để được kết nối tới mồi hệ thống khác mà cũng được kết nối tới nó

Như một hệ quả của phương pháp tiếp cận này, các bức tường lửa tự nhiên đã được tạo

ra bằng cách sử dụng những kênh truyền thông khác nhau và các giao thức khác nhau

là không sẵn dùng Khi được kết nối tới một ESB, bởi mặc định hệ thống là mở Do

đó, để bảo vệ dữ liệu dễ hỏng, ta phải hạn chế các khả năng của người tiêu dùng đế gợi tất cả các dịch vụ và xem tất cả các kết quả trả về Điều này thường là một sự thúc đây cho khái niệm bảo mật bên trong một ESB

□ Tính không đồng nhất và bảo mật

SOA là một khái niệm cho sự thỏa thuận với các quy trình nghiệp vụ đã được phân tán trên các hệ thống không đồng nhất khác nhau Các công nghệ bảo mật hiện có và các chính sách cho các hệ thống này là có khả năng khác nhau Do đó, ta đương đầu với thách thức của sự giới thiệu một khái niệm bảo mật chung trên nhiều khái niệm bảo mật khác nhau hiện có Quy trình này bắt đầu với sự khác nhau của mà người dùng và trả về kết quả trong sự trừu tượng khác nhau và các quy trình để giới thiệu các quyền và các thông tin cơ bản người dùng

□ Các quy trình phân tán và nhiều tầng của sự trừ u tượng

Vấn đề quan trọng nhất là SOA dẫn tới nhiều tầng khác nhau của sự trừu tượng Khi mồi dịch vụ trừu tượng chức năng nghiệp vụ của một tầng thấp hơn, nó cũng phái trừu tượng danh tính người dùng từ ứng dụng bên dưới

Kết hợp với nội dung bảo mật không đồng nhất của các backend riêng lẻ, điều này dẫn tới một thực tế rằng đó là một chặng đường dài từ yêu cầu ban đầu cho một quy trình nghiệp vụ tới các hệ thống để thỏa thuận với yêu cầu này

Hình dưới đây chỉ ra một ví dụ có thể: một khách hàng phải bắt đầu một tiến trình

sử dụng một cổng dịch vụ, tiến trình đó phải chạy trên các tầng khác nhau (các dịch vụ

tiến trình, các dịch vụ tông hợp, các dịch vụ cơ bán) và các backend khác nhau; ngoài

ra một trung tâm cuộc gọi hoặc tác tử văn phòng phía sau phải được liên quan trong sự thực hiện một vài bước của tiến trình này

o r s u r r e r

Forte! Server

*P'Ciess

"X"

T Basil

^ jr

13Hình 1.9: Nhiều bước nhảy ngan giữa người dùng cuối và các hệ thống backend

Có nhiều tầng dẫn tới hai thành phần quan trọng:

- Nó là không rõ ràng cái nào hệ thống xác thực và ủy quyền một người dùng

- Sự tin cẩn phải được chắc chắn qua không chỉ một mà nhiều kết nối và các nút bôn trong

Thảo luận đầu tiên là tại sao nó không rõ ràng cái nào hệ thống xác thực một người dùng và ủy quyền các hành động Trách nhiệm này là của hệ thống backend, írontend, hoặc cả hai? Một mặt, nó là tầm quan trọng của hệ thống backend để quyết định người dùng nào đã được cho phép để thực hiện các chức năng và truy vấn dữ liệu Lý do là mỗi backend chịu trách nhiệm cho dữ liệu của nó, và thường thường không phải tất cả các người dùng đã được cho phép để thực hiện tất cả các chỉnh sửa hoặc đế xem tất ca

dữ liệu Mặt khác nó là tầm quan trọng của hệ thống ííontend để ủy quyền các chức năng của người dùng, cung cấp hoàn toàn tính nhất quán và tránh những người dùng không được cho phép để gọi

1 ’ [SO A in Practice]

Đe có thể bao phủ cả hai tầm quan trọng, ý tưởng là cả hệ thống frontend và backend phải chia sẻ các sự nhận dạng tương tự (như mã người dùng) và những thông tin cơ bán được kết hợp của chúng và các quyền Điều này hàm ý rằng những nhận dạng và những thông tin cơ bản phải được vượt qua tới hệ thống backend.

Bây giờ chúng ta đến vấn đề thứ hai, vấn đề phải làm với sự tin cẩn và tính toàn vẹn Neu nhiều hệ thống đã được liên quan giữa hệ thống frontend và backend, nó là không

đủ đế tạo kết nối vật lý giữa hai hệ thống bảo mật Khi có nhiều kết nối với các nút liên quan, ta cần để đảm bảo sự bảo mật “end-to-end” của dừ liệu cụ thể Ví dụ, nếu truyền dừ liệu như mật khẩu, số thẻ tín dụng, hoặc các chi tiết tài khoản, thường chi hệ thống frontend và backend nên được cho phép để xem thông tin này Một vài quy trình thỏa thuận với dữ liệu này có thể băng qua nó nhưng không nên thực sự xem nó Vì lý

do này, các kỹ thuật bảo mật thỏa thuận với tầng truyền vận là thường không đu Thực

tế, phương pháp tiếp cận internet thông thường như tầng bảo mật socket (Secure Sockets Layer) cho web service là không đủ

□ Thỏa thuận về tính tin cậy và tính toàn vẹn

Trong thực tế có thể thỏa thuận với tính tin cậy và tính toàn vẹn của dừ liệu truyền thông bởi các dịch vụ dựa trên tầng truyền vận hoặc tầng thông điệp

Bảo mật ở tầng truyền vận

Một ví dụ điển hình là mã hóa các cuộc gọi web service thông qua SSL (sử dụng giao thức https thay vì http) Cách tiếp cận này là dễ dàng và rẻ, tuy nhiên nó chỉ trợ giúp khi dữ liệu nhận được truyền thông từ hệ thống tới hệ thống Đây là một mã hóa điếm tới điểm thay vì một mã hóa từ điểm đầu tới điểm cuối Bên trong các nút và giữa các tầng khác nhau, dữ liệu là vẫn dễ đọc

Bảo mật tầng thông điệp

Bảo mật tầng thông điệp là bảo mật bên trong những thông điệp thực sự đang được gửi Điều đó là, ta sử dụng giao thức của cơ sở hạ tầng trong một cách mà không ai cỏ thể đọc được thông điệp hoặc chỉnh sửa chúng mà không bị phát hiện Với phương pháp tiếp cận này, ta phải định nghĩa một vài ràng buộc đặc biệt trong định dạng thông điệp của ta bởi vậy tất cả các endpoint đó có thể truyền thông với mỗi cái khác Trong khi gửi thông điệp phải được mã hóa hoặc chứng thực tất cả dừ liệu hoặc các phần cua

nó, bên nhận giải mã thông điệp và kiểm tra lại chứng chỉ Một ví dụ điến hình là mã hóa của web service với các thuộc tính thêm vào đã được định nghĩa bởi các chuấn như WS-Security

Chú ý rằng ta vẫn có thể gửi thông điệp theo nhiều hướng Vì lý do này, ta thường

mã hóa chỉ dừ liệu nghiệp vụ của thông điệp Một vài thông tin để làm với việc gưi dừ liệu bên trong cơ sở hạ tầng đã được viện dẫn như một cách rằng nó có thế được xứ lý phân biệt từ một trọng tải Các thông tin được định vị trong phần đầu của thông điệp Như thảo luận dễ dàng hơn, bảo mật tầng thông điệp thường thích hợp hơn bởi vì I1Ó dẫn tới bảo mật từ điểm cuối tới điểm cuối (end-to-end), trong khi báo mật tầng truyền

tham gia m ột mình với các câu hỏi bảo mật, là m ột phương pháp rất kém và nguy

hiểm

1.9.3 Bảo mật, hiệu năng và trạng thái

Chi phí bảo mật Việc gọi các dịch vụ hoặc chức năng truyền thống phục vụ cho việc ra quyết định, mã hóa và giải mã dừ liệu, kiểm tra sự sẵn sàng và xác nhận tính toàn vẹn tiêu tốn thời gian và tài nguyên của hệ thống Tuy nhiên những công việc trên

là bẳt buộc để giúp hệ thống tránh khỏi những nguy cơ trong tương lai v ề bản chất, bảo đảm an toàn cho hệ thống là phải tìm ra cách cân bàng giữa các nguy cơ hiện hữu

và hiệu năng Do sự an toàn của hệ thống ảnh hưởng tới hiệu năng, nên nó cũng có thế ảnh hưởng tới trạng thái của dịch vụ Xuất phát từ khung nhìn của công việc kinh doanh, dường như các dịch vụ là không có trạng thái Tuy nhiên, khi một dịch vụ yêu cầu thì cần phải xác định xem dịch vụ đó được chấp nhận thực hiện yêu cầu và nhìn thấy kết quả hay không Để có thể ra quyết định cho việc này, người phát triển cần một

sổ dữ liệu mà không thường xuyên được truyền đi khi một dịch vụ tiến hành cuộc gọi yêu cầu Kết quả là, một ứng dụng backend có thể lấy dừ liệu nhận dạng đầu vào và sứ dụng nó để tải thông tin cá nhân của người dùng và quyền được truy cập cua người dùng với dữ liệu đó Thực hiện việc này có thể tốn một khoảng thời gian nhất định Thêm vào đó, nếu dịch vụ được định tuyến đến các hệ thống cung cấp khác nhau, hệ thống sẽ phải tải thông tin cá nhân và quyền của người dùng trên mỗi yêu cầu, hoặc ít nhất với yêu cầu đầu tiên bên trong mỗi hệ thống cung cấp Thông tin cá nhân và quyền của dịch vụ có thể được lưu trữ để khi có yêu cầu được chuyển đến cùng một hệ thống về mặt vật lý một lần nữa, dữ liệu phải được nạp từ yêu cầu đầu tiên Trong trường hợp này, hệ thống có thể trả về một mã thông báo (token) được sử dụng với mồi yêu cầu thêm Tuy nhiên, sau đó việc xác định xem sau bao lâu dừ liệu lưu trừ đó vẫn còn hợp lệ cần được thực hiện, cần chú ý rằng có nhiều cách khác nhau đê giải quyết vấn đề trạng thái và dịch vụ Ví dụ, ta có thể chỉ giải quyết vấn đề trạng thái

trong các ứng dụng backend và sử dụng một mã phiên làm việc trả về với yêu cầu dịch

vụ đầu tiên và gửi nó đi với tất cả các lời gọi dịch vụ thêm vào

/ 9.4 Bảo mật trong thực tế

Neu người viết có thể miêu tả nội dung của việc bảo mật đã được chứng kiến trong thực tế, thì tất cả những gì có thể nói sẽ là một công việc rất phức tạp: nó có thê liên quan đến việc quản lý tập trung người sử dụng, một số người sử dụng có kỳ thuật, sự

mã hóa trên các tầng ứng dụng khác nhau, Một sự kết hợp hỗn độn cua những nội dung về bảo mật, nhận dạng nhà cung cấp và những giải pháp bảo mật khác được su dựng ngày nay Ngoài ra, thường có ít nhất một phần nào đó không liên quan đến bao mật về mặt lý thuyết, điều này hoàn toàn có thể xảy ra và đôi khi thực sự gây lo lắng

Ví dụ một khu vực phi quân sự (DMZ) là vùng mà mỗi hệ thống tin tưởng các hệ thống khác và sự bảo mật chỉ đóng vai trò khi có dữ liệu được gửi ra khỏi vùng đó Điều này có nghĩa rằng tất cả các ứng dụng backend bên trong vùng đó tin tưởng tất ca các ứng dụng ở vùng biên, được coi như một bức tường lửa cho công ty ( ví dụ như máy chủ cổng thông tin, các ứng dụng yêu cầu, ) Rõ ràng là những ứng dụng biên phai chia sẻ chung chính sách an toàn và triển khai các chính sách này một cách chính xác Ví dụ, thay vì chú trọng khả năng xử lý nhiều cuộc gọi từ các client trên mỗi ứng dụng backend, bây giờ tất cả người sử dụng bên trong vùng an toàn (DMZ) có thê được chấp nhận lấy dừ liệu Sau đó điều cần thực hiện là bảo đảm ràng tất cá ứng dụng cũng như người sử dụng bên ngoài vùng an toàn sẽ chỉ nhìn thấy dừ liệu tương ứng với công ty hay phạm vi miền của họ Thật không may, nhà cung cấp dịch vụ (cũng là người sở hữu dữ liệu) không thể hoàn toàn bảo đảm rằng vai trò công việc sẽ liên quan tương ứng đến quyền truy cập dữ liệu, vì việc triển khai các điều luật đó yêu cầu sự hợp tác của nhiều nhà sử dụng dịch vụ Điều này có thể làm cho công việc kiểm soát rất phức tạp, nếu không muốn nói là không thể

Phương pháp tiếp cận DMZ đã từng được sử dụng cho những dữ liệu nhạy cảm Ví dụ, khi gọi một dịch vụ trả lại dữ liệu cho từng người sử dụng Do dữ liệu của những nhà quản lý hay những nhân vật quan trọng cần chỉ được truy cập bởi một số ít người đặc biệt, cách tiếp cận này mang lại nhiều rủi ro Để giảm bớt rủi ro, trong một số trường họp có thể áp dụng chính sách mã hóa dữ liệu bằng cách gán tên giả cho khách hàng

và chỉ cung cấp cho một số ít người cần thiết danh sách nối giữa tên giả và tên thật Có thể thấy đây là một ví dụ rất thú vị trong việc xử lý vấn đề an toàn trong tầng nghiệp

vụ doanh nghiệp

Việc kiểm toán (auditing) cũng đóng vai trò quan trọng trong việc bảo mật cho hệ thống Khi người quản lý hệ thống có khả năng theo dõi và đối chiếu luồng dừ liệu thì sau này họ sẽ có khả năng tìm hiểu xem người nào hoặc điều gì là nguyên nhân gây ra mất an ninh cho hệ thống cũng như những mối đe dọa tới hệ thống Hiêu theo một cách khác, bằng cách quản lý truy nhập, theo dõi và kiếm soát dòng thông tin, người quản trị có thể khuyến khích những lập trình viên chịu trách nhiệm nhiều hơn hoặc

Trong phần này, một số gợi ý liên quan đến vấn đề bảo mật với XML và các web service sẽ được trình bày v ề nguyên tắc, người quản trị có thể sử dụng những chuấn khac nhau, bao gồm những chuẩn sau:

- Chuẩn bảo mật thông thường

- Chuẩn bảo mật dành cho XML

- Chuân bảo mật giành cho các web service

Web Services Security S tan d a rd s

'.V S-S ecLriry '.v s -P o lic y VVS-_r L s :

General XML-based Security S tan d ard s

SAMLXACML

XML Security S tandard s

XML En cry p tio n ,X M L S ig nature

General Security S tan d ard s

K erberos PKI X S 09, SSI

Security A lg o rith m s

A E S D E S R S A

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

Cá; chuẩn bảo mật thông thường bao gồm những thuật toán nổi tiếng như RSA, AES, DES và các chuẩn an toàn cơ bản cho cho việc mã hóa và bảo đảm an toàn cho việc tĩra) đồi thông tin như SSL, Kerberos, Ngoài ra, có một số chuẩn đặc biệt dành cho tái liệu XML Điểm thuận lợi là các chuẩn này cho phép đọc và ghi lên các file XML, mhor đó việc mã hóa chữ ký có thể được tiến hành bằng cách sử dụng chuồi XML tlhcng thường Cuối cùng, tại đỉnh của sơ đồ các tầng bảo mật là các chuẩn bảo mật tlhcng thường của XML, ví dụ như SAML và các chuẩn dành cho web service như WS-Security Phần tiếp theo sẽ trình bày tóm lược về một sổ chuẩn quan trọng,

n Security Assertion Markup Language (SAML)

Một chuẩn chung quan trọng, được duy trì và phát hành bởi OASIS SAML là một mgìn ngừ dựa trên XML dành cho việc quản lý và trao đổi thông tin bảo mật giữa các

h ệ thống khác nhau Nó cho phép một bên có thể xác nhận thông tin bao mật về một chi đề (ví dụ như một sự nhận dạng thường xuyên cho người sử dụng hoặc có thế là

1,4 [)O A in P ractice]

các nhân viên kỹ thuật, hệ thống hoặc một công ty) Các thuộc tính khác cũng có thê được xác nhận bô sung như địa chi email của khách hàng hoặc vai trò của người dùng

Ví dụ, một sự xác nhận có thể như sau: “Đó là Nicolai Smiths, có địa chỉ email là n.sa)somedomain.de, là người được phép chỉnh sửa nội dung của quyên sách này”

Sự xác nhận có thể được quản lý và trao đổi trong môi trường phân tán Ví dụ, giao thức cho phép nhận dạng người cung cấp để xác định một chủ đề, thông qua sự xác nhận, ánh xạ giữa các sự nhận dạng khác nhau, và thực hiện việc thoát khỏi hệ thống phản tán (single logouts hay SLO) Kết quả là người quản trị có thế quản lý và kết hợp các thông tin cá nhân của nhiều người sử dụng khác nhau bằng cách sử dụng nhận dạng nhà cung cấp trên các tiến trình phân tán Điều này bao gồm cả việc hồ trợ của đăng nhập một lần (single sign on)

□ XML và các chuẩn an toàn cho các web service

Có một số chuẩn đặc biệt tồn tại đối với XML và các web service Những chuấn nàv không giới thiệu công nghệ hay thủ tục bảo mật mới, mà tập trung vào việc định nghĩa làm cách nào đe áp dụng các công nghệ và các thù tục đang tồn tại vào việc trao đổi dừ liệu thông qua các file XML hay các web service

Ví iụ, các chuẩn giành XML như:

- XML Signature (XML DSig): Cho phép các tài liệu XML sẽ được ký để đảm báo trim toàn vẹn và tính xác thực của dữ liệu

- XML Encryption (XML Enc): Cho phép các tài liệu XML có thế được mã hóa toàn

hộ hoặc một phần Ví dụ, người sử dụng có thể mã hóa toàn bộ tài liệu XML, hoặc chi rmâ hóa một số dữ liệu trong tài liệu đó, như số thẻ tín dụng hoặc mă hóa toàn bộ thông tĩin ngoại trừ tên người dùng

- XML Key Management: Hỗ trợ chính cho việc quản lý chuẩn XML Signature

Các chuân quan trọng cho các web service như:

- V^S-Security: Định nghĩa cách áp dụng các kỹ thuật bảo mật khác nhau cho việc xác tỉhực, toàn vẹn, và các quyền riêng tư cho web service (SOAP): Miêu tả theo tiêu

C:hiẩn cách nhúng các thông tin an toàn như thẻ, mã hóa, chữ ký, SAML, Kerberos, tircng một tiêu đề SOAP

- VS-Security Policy: Cho phép người dùng có thể tìm ra các chuấn báo mật mà một mhi cung cấp dịch vụ hỗ trợ Như là một phần của việc định nghĩa các web service tiroig WSDL hay ƯDDI, một nhà cung cấp có thể định nghĩa đó, như là chấp nhận X.509 và Kerberos, và yêu cầu một số chừ ký xác định

- VS-Trust: Cho phép thay đổi, làm mới và xác nhận thẻ bảo mật

- VS-SecureConversation: Cho phép thiết lập một nội dung chia sẻ bảo mật trên nhiều tihíng điệp được gửi đi Mục tiêu chính của chuẩn này là cải thiện hiệu năng bằng cách gian các yêu cầu được gửi đi

- WS-Federation: Định nghĩa cơ chế và cho phép thiết lập các sự toàn vẹn và hợp tác trên nhiều lĩnh vực bảo mật khác nhau, bằng cách cho phép và trao đổi một cách tin tưởng các nhận dạng, thuộc tính và xác thực

Thông thường đối với các web service, các chuẩn này không cần thiết phái tương thích

vì có quá nhiều phiên bản và nhiều cách khác nhau đế phiên dịch các chuân Ket qua là

sự ra đời của WS-I Basic Security Profile nhằm ngăn ngừa một số phiên ban nào đó của các chuẩn an ninh nhằm bảo đảm sự tương thích cho hệ thống

□ XML và việc tấn công các web service

Trong tất cả các hệ thống phân tán đều tồn tại nguy cơ bị tấn công từ bên ngoài, ví

dụ như tấn công DoS Quá nhiều yêu cầu, hợp lệ hoặc không, có thề phá vỡ một nhà cur.g cấp dịch vụ, và sau đó các tấn công độc hại có thể được sử dụng Do đó, người quan trị sẽ cần phải có khả năng dò ra và phản ứng với các cuộc tấn công Tuy nhiên, mộ: số loại tấn công cũng có thế xảy ra với XML và các web service Hãy cùng điêm qua một số ví dụ như sau:

XML bombs: XML là một ngôn ngữ thô sơ và đệ quy và trong một số trường hợp, cú

pháp của XML có thể mở rộng ra từ một số ít đến nhiều tài liệu XML Có thế xét ví dụ

v ấ i đề ở đây là đối tượng được tham chiếu đến đã mở rộng ra rất nhiều đối tượng

<díta>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo

foo foo foo foo foo foo foo foo</data>

Và như vậy bây giờ sẽ có 10 sự mở rộng đến 10 thực thể Mặc dù không có quá nhiều

mã code được yêu cầu, nhưng điều này dẫn đến việc cú pháp của XML sẽ cố gang mớ rộrg đến một chuồi gồm 10.000.000.000 lần sự xuất hiện của foo, dần đến việc tiêu ton thời gian và tài nguyên của hệ thống Thậm chí quá trình này có thể dần đến phá vỡ:hương trình

M(t điểm cần chú ý là đây cũng là một dạng tấn công từ chối dịch vụ (DoS) mà không thể dò ra được bằng tường lửa, vì vấn đề không phải chỉ nằm ở số lượng thông điệp, mồcòn nằm ở nội dung của thông điệp Nếu như tồn tại nguy cơ này cho hệ thống hay

ứng dụng, người phát triển nên cân nhắc sử dụng một số cách để ngăn chặn cú pháp củai XML hoặc dò ra những trường hợp này trước khi phân tích cú pháp.

đầu Với SQL injection, mẹo tấn công ở đây là lợi dụng các kỹ thuật nhàm ghép người

sư dụng một cách trực tiếp với mã thực thi để nhằm chỉnh sửa mà nguồn ban đầu

Có thể giải thích nội dung của cách làm này bằng ví dụ sau:

Ng ười dùng nhập trực tiếp yêu cầu SQL:

SELECT city, zip, Street FROM customers WHERE ID=input

Nế u đầu vào dữ liệu của người dùng là 42, kết quả hiền thị của câu lệnh SQL sẽ là:

SELECT city, zip, Street FROM customers WHERE ID=42 Đây là một kết quả đúng trả lại mã thành phố, zip code, và tên phố của mọi mục trong

cơ sở dữ liệu có ID bằng 42

Tuy nhiên hãy xét ví dụ sau:

42 UNION SELECT login, password,Y FROM user Nếu thay đối câu lệnh thành:

SELECT city, zip, Street FROM customers WHERE ID=42 UNION

SELECT login, password,V FROM user Kết quả trả về khi đó sẽ là toàn bộ login và mật khẩu từ bảng có tên tương ứng với user trong câu lệnh Khi sử dụng XML, kỹ thuật tương tự hoàn toàn có thế sử dụng Với Xpath, người sử dụng có thế điều hướng trong tài liệu XML Nếu như dừ liệu đầu vào nhập trực tiếp ví dụ như đường dẫn, người dùng thậm chí có thể thao túng đường dần Điều này dẫn đến việc thay thế nội dung tài liệu XML, cho phép thao tác với dữ liệu khác

Xem xét ví dụ sau: một số mã nguồn sử dụng biểu thức Xpath sau:

string(//user[name/text() - user' and password/text() - pw']/accounƯtext())

to find account data in an XML database or file such as the following:

Do biểu thức thứ hai trong ba biếu thức kểt hợp với trường thông tin true, toàn bộ ràng buộc bên trong dấu [] trở thành vô giá trị Ket quả là, thông tin về tải khoán của người

sư dụng đầu tiên sẽ bị tiết lộ

SOAP attachments: Do SOAP cho phép đính kèm bất cứ loại tài liệu nào cùng với email, điều này có thể trở thành lồ hổng cho virus hay các loại sâu tấn công Do đó, người sử dụng phải cân nhắc sử dụng các chương trình chống virus tương thích với nền tảng SOA được sử dụng

1.9.6 Khi nào vẩn đề bảo mật cần được xem xét

Cuối cùng, phần này sẽ trình bày một số điều liên quan đến câu hỏi khi nào vấn dề bảo mật sẽ cần được xem xét SOA là một chiến lược rất phức tạp, chỉ bộc lộ ban chất nếu người sử dụng áp dụng dần dần từng bước một Lý do là vì không thê dự đoán trước được những yêu cầu và ảnh hưởng của việc triển khai công nghệ trước khi thực hiện Do đó, ta không thể giải quyết tất cả các khía cạnh bảo mật trước khi bát đầu triển khai SOA Điều này nghĩa ràng ta phải tìm hiểu, áp dụng và thay đổi một số nội dung liên quan đến bảo mật

Bào mật là một phần quan trọng của toàn bộ hệ thống, ảnh hưởng đến tất cá các dịch vụ Vì vậy, đế xây dựng một hệ thống SOA, ngay từ khi bắt đầu nhà phát triến cần có khả năng cải thiện tính bảo mật của các dịch vụ đang tồn tại

Nhà phát triển nên quan tâm đến vấn đề bảo mật ngay từ khi bắt đầu Không cần phái thử tất cả các kỳ thuật cho mọi tình huống có thể, nhưng họ cần phải cung cấp những điểm mở rộng cho việc triển khai những vấn đề an ninh sau này