ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ CÔNG NGHỆ DỊCH VỤ MẠNG TRONG XÂY DỰNG PHẦN MỀM

Kiến trúc phần mềm của một hệ thống mô tả các thành phần của hệ thống và cách thức các thành phần này tương tác với nhau; tương tác giữa các thành phần được gọi là “liên kết” (connector) [1].

2 CORBA Kiến trúc môi giới yêu cầu đối tượng chung

Common Object Request Broker Architecture

Distributed Component Object Model

Interface Description Language

Java Intelligent Network Infrastructure

Java Message Service

HyperText Transfer Protocol

8 NASSL Ngôn ngữ đặc tả dịch vụ có khả năng truy cập qua mạng

Network Accessible Service Specification Language

Remote Method Invocation

Service Description Language

STT Từ viết tắt Giải nghĩa

Service-Oriented Architecture

12 SOAP Giao thức truy cập đối tượng đơn giản

Simple Object Access Protocol

13 UDDI Mô tả, tích hợp và tìm kiếm toàn cầu.

Universal Description Discovery and Integration

Danh mục hình vẽ

Hình 1.1: Sự phát triển của các công ty 10

Hình 1.2: Sự phát triển của kiến trúc 10

Hình 1.3: Phát triển phần mềm theo mô đun 11

Hình 1.4: Phát triển phần mềm hướng đối tượng 12

Hình 1.5: Phát triển phần mềm hướng thành phần 12

Hình 1.6: Phát triển phần mềm hướng dịch vụ 13

Hình 1.7: Kiến trúc phần mềm theo định nghĩa cổ điển 14

Hình 1.8: Mô hình kiến trúc hướng dịch vụ 15

Hình 1.9: Ủy nhiệm dịch vụ 20

Hình 1.10: Thành phần 22

Hình 1.11: Dịch vụ 23

Hình 1.12: Mối quan hệ giữa thành phần và dịch vụ 23

Hình 1.13: Mô hình thành phần đơn đặt mua hàng 24

Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng, thành phần, dịch vụ 26

Hình 1.15: Các tầng của SOA 28

Hình 1.16: Các mức độ thực hiện kiến trúc hướng dịch vụ 30

Hình 1.17: Vòng đời phát triển dịch vụ 35

Hình 1.18: Mô hình kiến trúc Jini 36

Hình 1.19: Mô hình khung của Openwings 38

Hình 1.20: Mô hình ESB 41

Hình 2.1: Mô hình dịch vụ mạng 45

Hình 2.2: Cấu trúc thông điệp SOAP 51

Hình 2.3: Các kiểu dữ liệu chính trong UDDI 56

Hình 2.4: Liên kết tĩnh 60

Hình 2.5: Liên kết động thời gian xây dựng 61

Hình 2.6: Liên kết động thời gian chạy 63

Hình 2.7: Một ví dụ dịch vụ mạng 67

Hình 2.8: WSDL và việc sinh mã 70

Hình 3.1: Mô hình kiến trúc hướng dịch vụ ở mức cao 72

Hình 3.2: Biểu đồ trường hợp sử dụng của bài toán 74

Hình 3.3: Cài đặt dịch vụ mạng 75

Hình 3.4: Trang kiểm thử dịch vụ mạng 79

Hình 3.5: Đăng ký dịch vụ với UDDI 79

Hình 3.6: Mô hình liên kết dịch vụ mạng động 80

Hình 3.7: Tìm kiếm trong UDDI 81

Hình 3.8: Sử dụng công cụ wsdl.exe 81

Hình 3.9: Giao diện dịch vụ UDDI 82

Hình 3.10: Giao diện của chương trình 83

Hình 3.11: Thông tin chi tiết về dịch vụ 83

Hình 3.12: Dịch vụ thay đổi 84

Hình 3.13: Truy vấn thay đổi dịch vụ thành công 84

Hình 3.14: Thông tin về dịch vụ thay đổi 85

Mục lục

Danh mục từ viết tắt 1

Danh mục hình vẽ 3

Mục lục 5

MỞ ĐẦU 7

CHƯƠNG I LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ 9

1 Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin 9 2 Kiến trúc hướng dịch vụ - một giải pháp 11

2.1 Sự tiến hóa của lý thuyết phát triển phần mềm 11

2.2 Kiến trúc hướng dịch vụ 14

2.3 Dịch vụ và thành phần 22

3 Thiết kế theo kiến trúc hướng dịch vụ 26

3.1 Các nguyên tắc trong thiết kế hướng dịch vụ 26

3.2 Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ 27

3.3 Các mức độ chấp nhận kiến trúc hướng dịch vụ 29

3.4 Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ 31

3.5 Vòng đời phát triển của dịch vụ 35

4 Các công nghệ hướng dịch vụ 36

4.1 Sun JINI 36

4.2 Openwings 37

4.3 Dịch vụ mạng 40

4.4 Enterprise Service Bus (ESB) 40

5 Kết luận chương 42

CHƯƠNG II CÔNG NGHỆ DỊCH VỤ MẠNG 44

1 Kiến trúc dịch vụ mạng 45

2 Các chuẩn cho dịch vụ mạng 46

2.1 Ngôn ngữ mô tả dịch vụ mạng WSDL 46

2.2 Giao thức truy cập đối tượng đơn giản SOAP 50

2.3 Đặc tả mô tả và tích hợp tìm kiếm UDDI 55

3 Các kiểu liên kết trong dịch vụ mạng 60

3.1 Liên kết tĩnh 60

3.2 Liên kết động trong thời gian xây dựng 61

3.3 Liên kết động trong thời gian chạy 62

5 Xây dựng dịch vụ mạng 64

5.1 Vòng đời của dịch vụ mạng 64

5.2 Bảo mật trong dịch vụ mạng 64

5.3 Tính liên thông giữa các dịch vụ mạng 70

6 Kết luận chương 70

Chương III: CÀI ĐẶT ỨNG DỤNG 72

1 Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ 72

2 Mô tả bài toán 73

3 Cài đặt bài toán 75

3.1 Thành phần cung cấp dịch vụ 75

3.2 Thành phần sử dụng dịch vụ 80

3.3 Thành phần đăng ký dịch vụ 81

4 Các kết quả đạt được 82

5 Đánh giá về ứng dụng 85

5.1 Ưu điểm 85

5.2 Các điểm hạn chế 86

KẾT LUẬN 87

Danh mục tài liệu tham khảo 89

MỞ ĐẦU

Kiến trúc phần mềm của một hệ thống mô tả các thành phần của hệ thống vàcách thức các thành phần này tương tác với nhau; tương tác giữa các thành phầnđược gọi là “liên kết” (connector) [1] Trong một hệ thống phần mềm có quy môlớn và phức tạp thì kiến trúc của hệ thống giữ một vị trí quan trọng trong việc hiểu

hệ thống, việc tổ chức phát triển và tăng cường tái sử dụng

Ngày nay, khi mà độ phức tạp của phần mềm ngày càng tăng thì các kiếntrúc phần mềm truyền thống dường như đang tiến tới giới hạn khả năng giải quyếtvấn đề của chúng; trong khi đó, các tổ chức công nghệ thông tin vẫn phải đáp ứngđược những yêu cầu đặt ra như: yêu cầu được đáp ứng nhanh, yêu cầu giảm giáthành, yêu cầu về khả năng thu hút và tích hợp với các đối tác mới v.v…, và đặcbiệt là sự thay đổi nhanh chóng của các công nghệ

Trong suốt bốn thập kỷ qua, thực tế phát triển phần mềm đã trải qua nhiềuphương pháp phát triển khác nhau Mỗi phương pháp mới xuất hiện đều hướng tớimục tiêu quản lý độ phức tạp ngày càng tăng của phần mềm bằng cách đưa ra các

cấu trúc có mức độ đóng gói tăng dần: từ hàm (function), lớp (class), tới thành phần (component); các cấu trúc này được xem như những phần mềm “hộp đen”, chúng

che giấu cài đặt nhờ việc kiểm soát việc truy cập tới hành vi và dữ liệu của mìnhthông qua một giao diện tường minh Ở mức độ đóng gói thấp, chúng ta sử dụng đốitượng để che giấu dữ liệu, ở mức độ đóng gói cao hơn, chúng ta sử dụng các thànhphần để thực hiện việc này Việc sử dụng đối tượng để che giấu thông tin hoạt độngtốt với các hệ thống nhỏ, nó cho phép tạo ra các cấu trúc phần mềm phản ánh đượccác đối tượng trong thế giới thực Vấn đề nảy sinh khi chúng ta cố gắng nhóm một

số lượng lớn các đối tượng cùng với nhau Mặc dù truy cập tới các đối tượng đượcđiều khiển thông qua giao diện của chúng, mức độ đóng gói thấp của các đối tượngvẫn làm cho sự phụ thuộc giữa chúng trở nên khó kiểm soát trong một hệ thốngtương đối lớn Khái niệm thành phần được phát triển giúp quản lý các hệ thống lớntốt hơn: một thành phần được định nghĩa là một nhóm các đối tượng hoạt động cùng

nhau để thực hiện một chức năng của hệ thống Các công nghệ như EJB (Enterprise Java Bean), NET, CORBA (Common Object Request Broker Architecture) tỏ ra rất

hiệu quả trong việc cài đặt các thành phần Phương pháp phát triển phần mềm dựa

thành phần (Component-based Development - CBD) cho phép những nhà phát triển

tạo ra các hệ thống phức tạp hơn, có chất lượng cao hơn và nhanh hơn bất kỳphương pháp phát triển phần mềm nào khác trước đó Nhưng khi chúng ta xây dựngcác thành phần trên các ngôn ngữ khác nhau, hay thậm chí là trên những nền tảngkhác nhau (các thành phần không đồng nhất) cho một hệ thống thì cần có khả năngtích hợp chúng lại với nhau, nhưng một vấn đề nảy sinh: các thành phần dùng công

nghệ EJB đòi hỏi việc triệu gọi phương thức thông qua RMI (Remote Method Invocation – Triệu gọi phương thức từ xa), trong khi đó, các thành phần dùng công nghệ CORBA thì lại dùng IIOP (Internet Inter-ORB Protocol), hơn nữa, khi các

thành phần được định vị qua Internet, các thông điệp giữa chúng có thể bị chặn bởitường lửa Ngay cả khi không gặp phải những vấn đề trên thì để sử dụng được thànhphần, chúng ta vẫn cần phải biết vị trí chính xác và giao diện của thành phần để nếugiao diện thay đổi, chúng ta cũng phải thay đổi cách gọi đến chúng Vì số lượng

người dùng thành phần có thể rất lớn nên việc này sẽ tạo ra các phụ thuộc có quy

mô lớn, rất khó kiểm soát Vậy làm thế nào chúng ta có thế giải quyết vấn đề này?

Kiến trúc hướng dịch vụ (Service-oriented architecture, viết tắt là SOA)

đang được phát triển và được xem như một bước đột phá tiếp theo trong kiến trúcphần mềm giúp giải quyết vấn đề “khủng hoảng” phần mềm Sự xuất hiện của công

nghệ dịch vụ mạng (Web services) trong vài năm trở lại đây đã tạo ra sự quan tâm

mạnh mẽ tới kiến trúc này bởi Web service hiện thực hóa việc phát triển hệ thốngtheo kiến trúc hướng dịch vụ một cách tự nhiên và dễ dàng hơn Web service vàkiến trúc hướng dịch vụ đang thay đổi một cách căn bản cách thức xây dựng các hệthống nội bộ (các hệ thống thông tin hỗ trợ trong các tổ chức) và cách các hệ thốngnội bộ tương tác với các hệ thống bên ngoài mà chưa một kiến trúc nào trước đó cóthể thực hiện được Thuật ngữ “dịch vụ” trong kiến trúc hướng dịch vụ cũng không

phải là khái niệm mới: các ứng dụng khách/chủ (client/server) trong những năm 90

đã sử dụng “dịch vụ” để chỉ khả năng thực hiện lời gọi phương thức từ xa Kiến trúc

hướng dịch vụ đặc biệt đề cao tính liên thông (interoperability) và sự trong suốt về

vị trí của các dịch vụ, nói tới dịch vụ và kiến trúc hướng dịch vụ là nói về việc thiết

kế và xây dựng các hệ thống sử dụng các thành phần phần mềm không đồng nhất

Sử dụng công nghệ dịch vụ mạng và kiến trúc hướng dịch vụ đem lại các lợiích sau:

 Mở rộng các lựa chọn về mặt công nghệ

 Các hệ thống được xây dựng linh hoạt và nhạy bén hơn

 Giảm thời gian phát triển

 Giảm chi phí bảo trì

Trong đồ án tốt nghiệp này, người viết đồ án (NVĐA) sẽ trình bày về lýthuyết của kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, tại sao những côngnghệ này có thể xóa bỏ những rào cản công nghệ để tạo ra các hệ thống phần mềm

có tính tích hợp cao, và tại sao lựa chọn công nghệ dịch vụ mạng là thích hợp nhấtcho việc cài đặt ứng dụng theo kiến trúc hướng dịch vụ cũng như lợi ích của nhữngứng dụng này khi xây dựng theo kiến trúc hướng dịch vụ

CHƯƠNG I LÝ THUYẾT KIẾN TRÚC HƯỚNG

DỊCH VỤ

Kiến trúc hướng dịch vụ là một làn sóng mới trong phát triển ứng dụng Nó

có thể được xem như là một tập hợp của các khái niệm kiến trúc hoặc một môhình lập trình

Chương này sẽ trình bày các khái niệm cơ bản về :

 Sự tiến hóa của các kỹ thuật phát triển phần mềm

 Kiến trúc hướng dịch vụ và phát triển phần mềm theo kiến trúc hướng dịch vụ

 Các công nghệ giúp hiện thực hóa triết lý của kiến trúc hướng dịch vụ

1 Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ

thông tin

Trong khi các nhà quản lý công nghệ thông tin đang phải đối đầu với việcgiảm giá thành và tối đa lợi ích của các công nghệ hiện có, họ vẫn phải liên tục cốgắng để phục vụ khách hàng được tốt hơn, trở nên cạnh tranh hơn và phản ứngnhanh hơn với chiến lược của doanh nghiệp

Có hai yếu tố chính ẩn sau những áp lực này, đó là tính không đồng nhất củacác hệ thống và sự thay đổi nhanh về mặt công nghệ Phần lớn các doanh nghiệpngày nay đều gồm nhiều hệ thống, ứng dụng và kiến trúc khác nhau với thời giantồn tại và công nghệ khác nhau Việc tích hợp các sản phẩm từ nhiều nhà cung cấp

và nhiều nền tảng thực sự là điều khó khăn Nhưng chúng ta cũng không thể cốgắng tiếp cận theo kiểu một nhà cung cấp đối với công nghệ thông tin vì các bộ ứngdụng và kiến trúc hỗ trợ rất không mềm dẻo

Sự thay đổi công nghệ là yếu tố thứ hai mà các nhà quản lý công nghệ thôngtin phải đối mặt Sự toàn cầu hoá và kinh doanh điện tử đang làm tăng tốc sự thayđổi Sự toàn cầu hoá dẫn tới sự cạnh tranh gay gắt trong việc rút ngắn chu kỳ sảnxuất để có thể chiếm ưu thế đối với đối thủ cạnh tranh Các thay đổi về yêu cầu vànhu cầu của khách hàng nhanh chóng hơn do tác động của phân phối cạnh tranh và

sự phong phú về thông tin sản phẩm trên Internet Do đó lại càng thúc đẩy việc cảitiến trong sản phẩm và dịch vụ diễn ra nhanh hơn

Các cải tiến trong công nghệ tiếp tục tăng, làm tăng sự thay đổi yêu cầu củakhách hàng Doanh nghiệp phải nhanh chóng thích nghi để tồn tại, chưa kể đến việcphải thành công trong môi trường cạnh tranh động ngày nay, và hạ tầng công nghệthông tin phải đem lại khả năng thích nghi cho các doanh nghiệp

Vì vậy, các tổ chức kinh doanh đang phát triển từ sự phân chia doanh nghiệptheo chiều dọc, cô lập của những năm 1980 về trước thành các cấu trúc chú trọngquy trình kinh doanh theo chiều ngang của những năm 1980, 1990, tới mô hình kinh

doanh mới trong đó các doanh nghiệp có tác động lẫn nhau Các dịch vụ kinh doanhngày nay cần phải được thành phần hoá và phân tán Cần chú trọng vào dây chuyềncung cấp mở rộng, cho phép khách hàng và đối tác truy cập tới các dịch vụ kinhdoanh.

Phân chia theo chiều dọc

Những năm 1980

Phân chia theo chiều ngang

Hình 1.1: Sự phát triển của các công ty

Làm thế nào để môi trường công nghệ thông tin trở nên linh hoạt và nhạybén hơn đối với sự thay đổi của các yêu cầu kinh doanh? Làm thế nào để các hệthống và ứng dụng không đồng nhất trao đổi với nhau một cách liền mạch? Làm thếnào để đạt được các mục tiêu kinh doanh mà không làm phá sản các doanh nghiệp?

Đã có nhiều giải pháp được đề ra song song với sự phát triển của các vấn đềkinh doanh, như được chỉ ra trong hình 1.2 Hiện nay, nhiều nhà quản lý và cácchuyên gia công nghệ thông tin tin rằng chúng ta đang tiến ngày một gần hơn tới

câu trả lời với kiến trúc hướng dịch vụ (SOA).

Hình 1.2: Sự phát triển của kiến trúc

Để đáp ứng được nhu cầu về sự không đồng nhất, tính liên thông và sự thayđổi yêu cầu không ngừng, một kiến trúc như vậy phải đem lại một nền tảng cho việcxây dựng các dịch vụ ứng dụng với các đặc tính sau:

 Liên kết lỏng lẻo (Loosely coupled)

 Vị trí trong suốt (Location transparent)

 Độc lập về giao thức (Protocol independent)

Dựa trên một kiến trúc hướng dịch vụ như vậy, người dùng dịch vụ thậm chí không cần phải quan tâm tới một dịch vụ cụ thể mà mình đang trao đổi thông tin vì

J2EE hay NET không làm ảnh hưởng tới người dùng SOA Người dùng cũng có khả năng cân nhắc và thay thế một cài đặt dịch vụ tốt hơn nếu tồn tại một dịch vụ khác có chất lượng tốt hơn.

2 Kiến trúc hướng dịch vụ - một giải pháp

2.1 Sự tiến hóa của lý thuyết phát triển phần mềm.

Trước khi giải thích về kiến trúc hướng dịch vụ cũng như bản chất nhữngkhái niệm tạo nên kiến trúc hướng dịch vụ, chúng ta cần phải hiểu về lịch sử pháttriển của kiến trúc hướng dịch vụ bằng cách nhìn lại những khó khăn mà những nhàphát triển phần mềm đã phải đối mặt trong vài thập kỷ qua và xem xét các giải phápđược đưa ra để giải quyết các khó khăn đó

Những người lập trình đã sớm nhận ra rằng việc viết phần mềm đã đang ngàycàng phức tạp hơn Họ cần một cách tốt hơn để sử dụng lại những đoạn mã đã viết.Khi những nhà nghiên cứu quan tâm tới vấn đề này, họ đã đưa ra khái niệm thiết kế

mô đun Với các quy tắc của thiết kế mô đun, các lập trình viên có khả năng viết cáchàm và chương trình con và sử dụng lại mã đã viết Đó quả là một bước đột phá vàmột điều tuyệt vời cho việc xây dựng phần mềm Cách này có hiệu quả tốt trong mộtthời gian, từ 1960 đến 1980

Hàm Hàm

Mô đun

Hàm Hàm

Ứng Dụng

Hình 1.3: Phát triển phần mềm theo mô đun

Nhưng sau đó, các lập trình viên lại nhận thấy rằng họ đang thực hiện việc cắt dán các mô đun vào các ứng dụng khác, điều này bắt đầu tạo ra một cơn ác mộng về bảo trì: khi một lỗi được phát hiện trong một hàm nào đó, họ phải kiểm tra tất cả các ứng dụng có sử dụng hàm này và thay đổi mã để sửa chữa Những nhà phát triển không muốn điều này, họ cần một mức trừu tượng cao hơn Các nhà nghiên cứu đã đưa ra khái niệm các lớp và phần mềm hướng đối để giải quyết vấn

đề này Phương pháp phát triển phần mềm hướng đối tượng đã có hiệu quả trong một thời gian, từ 1980 đến 1990

Đối tượng

Đối tượng

Đối tượng Ứng Dụng

Hình 1.4: Phát triển phần mềm hướng đối tượng

Lại một lần nữa, khi độ phức tạp của phần mềm tăng lên, các nhà phát triển bắt đầu nhận thấy việc xây dựng và bảo trì phần mềm là rất phức tạp, họ muốn một cách nào đó để sử dụng lại và bảo trì các chức năng chứ không chỉ đơn thuần là mã nguồn Các nhà nghiên cứu lại đưa ra một lớp trừu tượng khác để kiểm soát độ phức

tạp này, đó là phần mềm dựa thành phần (Component-based software - CBD).

Đối tượng

Đối tượng Đối

tượng Thành phần

Đối tượng

Đối tượng Đối

tượng

Thành phần Đối

tượng

Đối tượng Đối

tượng Thành phần

Ứng Dụng

Hình 1.5: Phát triển phần mềm hướng thành phần

CBD là một giải pháp tốt cho việc sử dụng lại và bảo trì, nhưng nó không kiểm soát được tất cả các độ phức tạp mà các nhà phát triển hiện nay đang phải đối mặt như: phần mềm phân tán, các ứng dụng tích hợp, các nền tảng, thiết bị khác nhau v.v… Phần mềm ngày nay phải được xây dựng sao cho có thể đáp ứng được tất cả các yêu cầu trên Và kiến trúc hướng dịch vụ cùng với công nghệ dịch vụ mạng xuất hiện đã đem lại một giải pháp cho tất cả các yêu cầu Bằng cách thực hiện SOA, các nhà phát triển có thể loại bỏ được những sự không tương thích về giao thức, nền tảng và các ứng dụng được tích hợp một cách dễ dàng

Đối tượng

Đối tượng Đối

tượng

Thành phần

Đối tượng

Đối tượng Đối

tượng

Thành phần

Dịch vụ

Đối tượng

Đối tượng Đối

tượng

Thành phần

Đối tượng

Đối tượng Đối

tượng

Thành phần

Đối tượng

Đối tượng Đối

tượng

Thành phần

Dịch vụ

Đối tượng

Đối tượng Đối

tượng

Thành phần

Đối tượng

Đối tượng Đối

tượng

Thành phần

Đối tượng

Đối tượng Đối

tượng

Thành phần

Dịch vụ Ứng Dụng

Hình 1.6: Phát triển phần mềm hướng dịch vụ

Như vậy, theo thời gian, chúng ta nhận thấy rằng những phương pháp pháttriển phần mềm đã liên tục tiến hóa, từ phương pháp xây dựng phần mềm đơn giảnnhất cho đến những phương pháp xây dựng phần mềm đồ sộ như ngày nay

Quá trình tiến hóa của phương pháp phát triển phần mềm có thể tóm lược lạinhư sau: ban đầu là phương pháp phát triển tự phát, tức là cần máy tính thực hiệnnhư thế nào thì viết lệnh như thế đó Đơn vị có thể tái sử dụng của phần mềm là rấtnhỏ - từng dòng lệnh Những phần mềm được viết ra thường nhỏ, và đơn giản, chủyếu là các phần mềm hỗ trợ tính toán Sau đó kỹ thuật phát triển phần mềm tiếnthêm một bước mới, đó là phát triển phần mềm theo mô đun Nhờ phương pháp này,những đơn vị chương trình có khả năng tái sử dụng đã tăng lên và quy mô của phầnmềm cũng đã lớn hơn, không chỉ dừng ở các phần mềm hỗ trợ tính toán, mà còn baogồm cả những ứng dụng thương mại Kỹ thuật phát triển phần mềm hướng đốitượng đã trở thành một làn sóng mới về kỹ thuật phát triển phần mềm trong một vàithập kỷ gần đây, việc đưa ra các khái niệm lớp, hàm và biến thành phần, kế thừa,kết tập đã khiến cho việc xây dựng phần mềm trở nên dễ dàng hơn, cấu trúcchương trình trở nên dễ hiểu hơn, với khái niệm đối tượng tương đối gần với cácthực thể trong đời sống tự nhiên và xã hội Kỹ thuật phát triển phần mềm hướng đốitượng đã làm tăng khả năng tái sử dụng mã, và nó cũng làm cho phần mềm có khảnăng khả chuyển hơn do đặc tính khép kín của các lớp Cùng với sự phát triển ngàycàng nhanh của các phần mềm cả về quy mô lẫn yêu cầu về thời gian phát triển,phương pháp phát triển phần mềm hướng thành phần là mức trừu tượng hóa caohơn của phương pháp phát triển hướng đối tượng Đặc điểm chính của các phần

mềm phát triển theo phương pháp này là chúng gồm nhiều thành phần, mỗi thànhphần có thể hoàn thành một hoặc một số công việc cụ thể, nhất định Mỗi thànhphần bao gồm một tập các lớp, các đối tượng Phần mềm được tạo ra bằng cáchghép các thành phần đó lại với nhau, thông qua việc sử dụng các giao diện giữachúng Phần mềm được tạo ra theo phương pháp này có khả năng tái sử dụng mã rấtcao, việc bảo trì và nâng cấp khá dễ dàng Tuy nhiên, quy mô của phần mềm ngàycàng nở rộng, thời gian đưa ra thị trường được đòi hỏi ngày càng phải sớm hơn, yêucầu về khả năng tái sử dụng mã và khả năng dễ bảo trì đối với phần mềm đã khiếncho phương pháp phát triển phần mềm hướng dịch vụ ra đời và đang được xem như

là một làn sóng mới trong phát triển phần mềm

Bảng so sánh dưới đây cho ta thấy rõ ưu thế của phương pháp phát triển phầnmềm hướng dịch vụ so với các phương pháp phát triển phần mềm trước đó

Hướng cấu trúc Hướng đối tượng Hướng thành phần Hướng dịch vụ Mức độ đóng

Hình 1.7: Kiến trúc phần mềm theo định nghĩa cổ điển

Kiến trúc hướng dịch vụ là một loại kiến trúc phần mềm đặc biệt có nhiều

Thành phần sử dụng

Thành phần đăng ký dịch vụ Giao kèo

Giao kèo Giao kèo

Truyền thông điệp

Dịch vụ

Mô tả dịch vụ

Mô tả dịch vụ

Tương tác (liên kết & thực thi)

Hình 1.8: Mô hình kiến trúc hướng dịch vụ

2.2.1 Các định nghĩa về kiến trúc hướng dịch vụ

Kiến trúc hướng dịch vụ (Service-oriented architecture - SOA) là một cụm từ thông dụng trong công nghệ thông tin ngày nay Mặc dù đã có nhiều cố gắng nhưng vẫn không có được sự thống nhất trong định nghĩa về kiến trúc này [4]

“SOA là một framework cho phép tính năng ứng dụng được cung cấp, tìm ra và tiêu thụ như là các tập dịch vụ mạng có khả năng tái sử dụng Trong khi dịch vụ mạng không phải là SOA, nó là một trong các chuẩn cho phép xây dựng SOA SOA trừu tượng hoá tính phức tạp và chi tiết cài đặt, khiến cho nó trở thành một kiến trúc hoàn thiện để xây dựng các hệ thống phần mềm.” Scott Rosenbloom is chief strategist with WRQ Inc

“Các giải pháp công nghệ thông tin an toàn, tích hợp đáp ứng được các yêu cầu nghiệp vụ Các giải pháp phải cài đặt, tối ưu và chỉ dẫn sự thực thi quy trình nghiệp vụ bằng cách kết hợp tính năng của các dịch vụ riêng lẻ, đóng kín và có khả năng tái sử dụng SOA không nặng nề về việc phát triển ứng dụng phức tạp mà tập trung vào việc chuẩn hoá giao diện giữa các thành phần dịch vụ với sự quản lý tập trung và cài đặt phân tán”.Dave Morris, I.T Security Lead TransAlta Corp

“SOA mô hình hoá nghiệp vụ như là một tập các dịch vụ tự chứa đựng contained) có hiệu lực giữa các tổ chức và có thể được gọi cả từ bên trong và bên ngoài thông qua các giao thức chuẩn.” Dave McComb, president, Semantic Arts

(self-“SOA không phải là cái gì khác ngoài kiến trúc hướng nghiệp vụ, cái mà cho phép tính mềm dẻo của các ứng dụng nghiệp vụ, để trở thành độc lập nhưng cộng tác, trong khi cung cấp các dịch vụ của chúng Các ứng dụng dưới kiến trúc này cùng một lúc có thể là trình khách và chủ với các dịch vụ tuỳ thích.” Satheesan Kunnel, USWWI

“SOA là một hướng tiếp cận để thiết kế và tích hợp phần mềm theo một phương pháp mô đun trong đó, mỗi mô đun là một “dịch vụ được kết nối lỏng lẻo”

có thể truy cập qua mạng và có khả năng tích hợp động với các dịch vụ khác trong thời gian chạy Một dịch vụ phải đưa ra một giao diện chuẩn (WSDL) cho tính năng

và các lời gọi các phương thức của nó.” Rajesh Dawar

“Các dịch vụ cung cấp một số chức năng cho những người biết cách yêu cầu

và tiêu thụ chúng mà không cần phải biết làm thế nào để tạo ra được chức năng ấy SOA là một cách tiếp cận để xây dựng các ứng dụng phần mềm như là các tập hợp dịch vụ tự trị, tương tác không cần quan tâm tới nền tảng, cấu trúc dữ liệu hay các thuật toán bên trong của các dịch vụ khác.” Michael Champion, R&D specialist, Software

“SOA là một kiến trúc cho quy mô doanh nghiệp (thường trải rộng nhiều ứng dụng trong một doanh nghiệp hoặc nhiều doanh nghiệp) trong đó thành phần cấu trúc chính là dịch vụ.

Một dịch vụ là một tập hợp các chức năng nghiệp vụ liên quan tới nhau tương tác nội bộ hoặc từ xa sử dụng kiểu truyền thông truyền thông điệp / hướng tài liệu Một dịch vụ bao gồm một giao diện dịch vụ và một cài đặt dịch vụ cài đặt một hoặc nhiều giao diện dịch vụ và gắn liền với một tập hợp tính năng nhất định Các dịch vụ cụ thể được xác định dưới dạng giao thức vận chuyển/ ứng dụng/ thông điệp, chứ không phải dưới dạng một mô hình lập trình cụ thể SOA điển hình bao gồm các dịch vụ kỹ thuật để quản lý siêu dữ liệu về các giao diện dịch vụ và các cài đặt, các nguồn cung cấp và nguồn tiêu thụ dịch vụ; và các dịch vụ cho việc quản lý

và bắt tuân theo các chính sách, điều khiển truy cập, các tính năng bảo mật, các giao dịch, mặc dù tất cả các dịch vụ này đều là tuỳ chọn trong một thể hiện SOA cụ thể.” Stefan Tilkov, CEO, innoQ

“SOA là một quy tắc kiến trúc tập trung vào quan điểm cho rằng các tài sản công nghệ thông tin được mô tả và thể hiện ra như là các dịch vụ Các dịch vụ này

có thể được kết hợp theo một cách thức lỏng lẻo để tạo thành các quy trình nghiệp

vụ ở mức cao hơn, đem lại cho nghiệp vụ tính nhanh nhẹn trong sự không đồng nhất về mặt công nghệ thông tin “ Ronald Schmelzer, analyst, ZapThink LLC

“ SOA là một cách tiếp cận để phát triển các ứng dụng phân tán liên kết không chặt chẽ, độc lập giao thức tạo thành từ các tài nguyên phần mềm có tính hoàn toàn xác định, tự chứa đựng có khả năng truy cập như là các dịch vụ giữa các doanh nghiệp được mở rộng theo một cách được chuẩn hoá nhằm tăng cường tính tái sử dụng và liên thông ” Ankur Gupta, marketing manager, Fiorano Software Inc

“SOA là một dạng của kiến trúc công nghệ gắn liền với các quy tắc của hướng dịch vụ Khi được cài đặt thông qua nền tảng công nghệ Web Service, SOA tạo ra tiềm năng để hỗ trợ và thúc đẩy các quy tắc này trong toàn bộ quy trình

Nói tóm lại, SOA có thể được hiểu là một hướng tiếp cận để xây dựng các hệthống phân tán cung cấp chức năng ứng dụng dưới dạng các dịch vụ tới các ứngdụng người dùng cuối hoặc các dịch vụ khác:

 SOA là một kiến trúc dùng các chuẩn mở để biểu diễn các thành phầnphần mềm như là các dịch vụ

 Cung cấp một cách thức chuẩn hóa cho việc biểu diễn và tương tácvới các thành phần phần mềm

 Các thành phần phần mềm riêng lẻ trở thành các khối cơ bản có thể sửdụng lại để xây dựng các ứng dụng khác

 Được sử dụng để tích hợp các ứng dụng bên trong và bên ngoài tổchức

Dịch vụ là yếu tố then chốt trong SOA Có thể hiểu dịch vụ như là hàm chứcnăng (mô đun phần mềm) thực hiện quy trình nghiệp vụ nào đó Các dịch vụ trongSOA có các đặc điểm sau:

 Các dịch vụ là có thể tìm kiếm được

 Các dịch vụ có tính liên thông

 Các dịch vụ không được gắn kết chặt chẽ với nhau

 Các dịch vụ là phức hợp, bao gồm nhiều thành phần, được đóng gói ởmức cao

 Các dịch vụ trong suốt về vị trí

 Các dịch vụ có khả năng tự hàn gắn

Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối “mềm dẻo” với nhau(nghĩa là một ứng dụng có khả năng giao tiếp với một ứng dụng khác mà không biếtcác chi tiết kỹ thuật bên trong), có giao diện được định nghĩa rõ ràng và độc lập vớinền tảng hệ thống, và có thể tái sử dụng SOA là cấp độ cao hơn của phát triển ứngdụng, chú trọng đến quy trình nghiệp vụ và dùng giao diện chuẩn để che giấu sựphức tạp kỹ thuật bên dưới

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao diệngọi dịch vụ Điều này tạo nên một giao diện nhất quán cho ứng dụng sử dụng dịch

vụ mà không cần quan tâm tới công nghệ thực hiện dịch vụ Thay vì xây dựng cácứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn hơn cóthể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ Điều này cho phéptái sử dụng phần mềm tốt hơn, cũng như tăng sự mềm dẻo vì nhà phát triển có thểcải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng sử dụng dịch vụ

Triết lý SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúctương tự Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt,

ví dụ như các ứng dụng phân tán muốn làm việc với nhau phải được thỏa thuận về

chi tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu nhữngthay đổi tương ứng đối với mã lệnh truy cập thành phần COM này.

Ưu điểm lớn nhất của SOA là khả năng kết nối mềm dẻo và tái sử dụng Cácdịch vụ có thể được sử dụng trên nền tảng bất kỳ và đước viết với ngôn ngữ bất kỳ(ví dụ, ứng dụng Java có thể liên kết với dịch vụ mạng NET và ngược lại)

SOA dựa trên hai nguyên tắc thiết kế quan trọng:

 Mô đun: tách vấn đề lớn thành nhiều vấn đề nhỏ

 Đóng gói: che giấu dữ liệu và logic trong từng mô đun đối với truycập từ bên ngoài

Một thiết kế kiến trúc phù hợp với khái niệm của SOA cần tuân theo nhữngtính chất sau:

 Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có

tính tự chứa đựng và mức độ đóng gói cao (coarse-grained).

 Một dịch vụ có thể dùng lại được, cho phép có thể xây dựng được mộtdịch vụ mới từ các dịch vụ hiện có Do đó, việc quan sát các hàm ý cóthể có của các thuộc tính phi chức năng như tính giao dịch là rất quantrọng

 Một giao diện dịch vụ là một điểm cuối mạng (network endpoint) đảm

bảo tính độc lập và trong suốt về vị trí

 Một dịch vụ cần có khả năng được phát hiện ra một cách công khaibằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liênkết động tới dịch vụ

 Một dịch vụ cần đảm bảo tính liên thông bằng cách hỗ trợ các giaothức truyền thông được chuẩn hóa và các định dạng dữ liệu rõ ràng.Các đặc điểm trên đảm bảo cho một kiến trúc hướng dịch vụ khả năng gắnkết lỏng lẻo của các dịch vụ phân tán và có tính mô đun bằng cách sử dụng các giaoước dịch vụ để mô tả các định dạng thông điệp cần thiết

2.2.2 Các thực thể trong kiến trúc hướng dịch vụ

Các thực thể trong kiến trúc hướng dịch vụ bao gồm:

 Dịch vụ (service).

 Thành phần sử dụng dịch vụ (service consumer/ client/ requester).

 Thành phần cung cấp dịch vụ (service provider).

 Thành phần đăng ký dịch vụ (service registry).

 Giao ước dịch vụ (contract).

 Ràng buộc sử dụng dịch vụ (service lease).

Dịch vụ:

Dịch vụ là một chức năng rõ ràng, tự chứa đựng và không phụ thuộc vào ngữcảnh hay trạng thái của các dịch vụ khác Các thành phần sử dụng dịch vụ có thểtruy cập tới dịch vụ thông qua giao diện dịch vụ được xuất bản Dịch vụ có các tínhchất sau:

 Dịch vụ có tính chất rõ ràng, là một đơn vị chức năng nghiệp vụ để cóthể được triệu gọi

 Có khả năng triệu gọi thông qua các giao thức truyền thôngchung

 Có tính liên thông và vị trí trong suốt

 Dịch vụ được định nghĩa bằng các giao diện tường minh

 Các giao diện độc lập với cài đặt

 Cung cấp giao ước giữa các thành phần cung cấp và sử dụngdịch vụ

Dịch vụ là các mô đun phức tạp, bao gồm nhiều thành phần Mức độ đónggói của dịch vụ càng cao thì dịch vụ càng có khả năng tái sử dụng và linh hoạt

Thành phần cung cấp dịch vụ:

Thành phần cung cấp dịch vụ là một thực thể có khả năng được địa chỉ hóaqua mạng, nó có thể chấp nhận và thực thi các yêu cầu từ những thành phần sử dụngdịch vụ Thành phần cung cấp dịch vụ có thể là một hệ thống máy tính lớn, mộtthành phần, hoặc một loại hệ thống phần mềm khác có thể thực thi các yêu cầu dịch

vụ Thực thể này xuất bản giao ước dịch vụ của nó trong một kho đăng ký dịch vụ

để các thành phần sử dụng dịch vụ có thể truy cập

Thành phần đăng ký dịch vụ:

Thành phần đăng ký dịch vụ là một thư mục trên mạng có chứa các dịch vụsẵn dùng Đây là một thực thể chấp nhận và lưu trữ các giao ước từ các thành phầncung cấp dịch vụ và cung cấp các giao ước đó cho những thành phần sử dụng dịchvụ

Giao ước dịch vụ:

Một giao ước là một bản đặc tả cách thức để thành phần sử dụng dịch vụ cóthể tương tác với thành phần cung cấp dịch vụ Nó chỉ ra khuôn dạng của thông điệpyêu cầu và thông điệp đáp ứng từ dịch vụ Giao ước dịch vụ có thể đòi hỏi một tậpcác điều kiện tiên quyết và điều kiện sau Các điều kiện này xác định trạng thái cầnthiết của dịch vụ để thực thi một chức năng cụ thể Bản giao ước cũng có thể baogồm các mức độ chất lượng của dịch vụ, các đặc tả cho các khía cạnh phi chức năngcủa dịch vụ.

Ủy nhiệm dịch vụ:

Thành phần cung cấp dịch vụ cung cấp một ủy nhiệm dịch vụ cho thành phần

sử dụng dịch vụ Thành phần sử dụng dịch vụ thực thi yêu cầu bằng cách gọi mộthàm API trên nó Ủy nhiệm dịch vụ (hình 1.9) sẽ tìm một giao ước và một thamchiếu tới thành phần cung cấp dịch vụ trong nơi đăng ký Sau đó, nó định dạngthông điệp yêu cầu và thực thi yêu cầu trên danh nghĩa của thành phần sử dụng dịch

vụ Ủy nhiệm dịch vụ là một thực thể không bắt buộc, nó chỉ đơn giản hóa chothành phần sử dụng dịch vụ và thành phần sử dụng dịch vụ hoàn toàn có thể viếtphần mềm để truy cập trực tiếp tới dịch vụ

Một thành phần cung cấp dịch vụ sẽ cung cấp nhiều ủy nhiệm cho các môitrường khác nhau, mỗi ủy nhiệm dịch vụ được viết bằng ngôn ngữ của thành phần

sử dụng dịch vụ Ví dụ, một thành phần cung cấp dịch vụ có thể cung cấp các ủynhiệm cho Java, Visual Basic, Delphi nếu đó là các nền tảng của thành phần sửdụng dịch vụ sử dụng dịch vụ Mặc dù ủy nhiệm dịch vụ là không bắt buộc nhưng

nó có thể cải thiện một cách đáng kể hiệu năng và tính tiện dụng cho các thành phần

Ràng buộc sử dụng dịch vụ mà thành phần đăng ký dịch vụ gán cho thànhphần sử dụng dịch vụ rất cần thiết để dịch vụ bảo trì được thông tin trạng thái liênkết giữa thành phần sử dụng và thành phần cung cấp Nó tạo ra sự gắn kết không

được liên kết với nhau Không có ràng buộc, một thành phần sử dụng dịch vụ có thểliên kết với một dịch vụ mãi mãi và không bao giờ liên kết lại với giao ước của nó.

Các thao tác trong kiến trúc hướng dịch vụ bao gồm:

Xuất bản dịch vụ: Để có thể truy cập được, một mô tả dịch vụ phải được

xuất bản để nó có thể được tìm thấy và triệu gọi bởi một người dùng dịch vụ

Tìm kiếm dịch vụ: Một người yêu cầu dịch vụ định vị một dịch vụ bằng cách

yêu cầu nơi đăng ký dịch vụ một dịch vụ phù hợp với các tiêu chí đặt ra

Liên kết và thực thi dịch vụ: Sau khi nhận được mô tả dịch vụ, người dùng

sẽ gọi dịch vụ theo các thông tin mô tả

2.2.3 Lợi ích của kiến trúc hướng dịch vụ

Như đã trình bày trong phần mở đầu, các doanh nghiệp đang phải đối mặtvới hai vấn đề cơ bản: khả năng thay đổi một cách nhanh chóng, và yêu cầu giảmgiá thành sản phẩm Với kiến trúc hướng dịch vụ, chúng ta có thể nhận thấy nhiềulợi ích giúp các tổ chức thành công trong môi trường kinh doanh hiện nay:

Thúc đẩy được các tài sản hiện có

SOA cung cấp một lớp trừu tượng cho phép một tổ chức tiếp tục thúc đẩyđầu tư vào công nghệ thông in bằng cách đóng gói những tài sản hiện có này thànhnhững dịch vụ cho các chức năng nghiệp vụ Các tổ chức có thể tiếp tục thu đượclợi nhuận từ các tài nguyên hiện có thay vì phải xây dựng lại chúng từ đầu

Tích hợp và quản lý độ phức tạp dễ dàng hơn

Điểm tích hợp trong một kiến trúc hướng dịch vụ là đặc tả dịch vụ, khôngphải là cài đặt dịch vụ Điều này làm cho cài đặt được trong suốt và tổi thiểu hoáảnh hưởng khi thay đổi hạ tầng và cài đặt xảy ra Bằng cách cung cấp một đặc tảdịch vụ trước các tài nguyên và tài sản hiện có được xây dựng trên các hệ thốngriêng biệt, tích hợp trở nên dễ quản lý hơn vì độ phức tạp được cô lập Việc nàythậm chí còn trở nên quan trọng hơn khi nhiều nghiệp vụ hơn hoạt động cùng nhau

để tạo nên một dây chuyền

Nhạy bén hơn và thời gian tung ra thị trường nhanh hơn.

Khả năng tạo thành các dịch vụ mới từ những tài nguyên hiện có đem lại mộtlợi ích khác biệt cho một tổ chức phải nhanh chóng đáp ứng được yêu cầu nghiệp vụthay đổi Thúc đẩy các thành phần và dịch vụ hiện có làm giảm thời gian cần thiết

để đi qua vòng đời phát triển phần mềm gồm: thu thập yêu cầu, thực hiện thiết kế,phát triển và kiểm thử Việc này dẫn tới sự phát triển nhanh của các dịch vụ nghiệp

vụ mới và cho phép tổ chức nhanh chóng đáp ứng được các thay đổi và giảm thờigian cần thiết để tung sản phẩm ra thị trường

Giảm giá thành và tăng cường tái sử dụng:

Với các dịch vụ nghiệp vụ cốt lõi được thể hiện theo cách liên kết lỏng lẻo,chúng có thể được sử dụng một cách dễ dàng hơn và có thể được kết hợp dựa trên

các yêu cầu nghiệp vụ; có nghĩa là giảm sự trùng lặp về tài nguyên, nâng cao tiềmnăng tái sử dụng và hạ giá thành sản phẩm.

SOA cho phép các doanh nghiệp sẵn sàng cho tương lai Các quy trìnhnghiệp vụ bao gồm hàng loạt các dịch vụ nghiệp vụ có thể được tạo ra, thay đổi vàquản lý một cách dễ dàng hơn để phù hợp với yêu cầu về thời gian SOA đem lạitính linh hoạt và nhạy bén cần thiết cho các tổ chức có thể tồn tại và phát triển

Chuyển sang kiến trúc hướng dịch vụ không phải là một nhiệm vụ đơn giản.Thay vì việc chuyển toàn bộ các chức năng nghiệp vụ của một doanh nghiệp thànhhướng dịch vụ, hướng tiếp cận được khuyến cáo là chỉ chuyển một tập con phù hợpcủa chức năng nghiệp vụ khi doanh nghiệp phát sinh nhu cầu hoặc đoán trước đượccác nhu cầu

Kiến trúc hướng dịch vụ tạo ra một viễn cảnh và một cách suy nghĩ khác sovới các kiến trúc trước đây, nhưng kiến trúc hướng dịch vụ không phải là một sựthay thế, mà chỉ là sự bổ sung cho các kiến trúc trước, cốt lõi của nó vẫn là kỹ thuậtlập trình hướng dịch vụ và hướng thành phần: kiến trúc hướng dịch vụ thích hợpcho tính liên thông giữa các môi trường thực thi khác nhau, bao gồm cả hướng đốitượng, hướng thủ tục, và các hệ thống khác

Khi sử dụng kiến trúc hướng dịch vụ, các hệ thống công nghệ thông tin hiệnđang tồn tại có thể được xem như là các dịch vụ cung cấp các chức năng nghiệp vụ.Các dịch vụ này có thể dễ dàng tích hợp với nhau vì chúng có các giao diện rõ ràng

và có thể truy cập nhờ việc sử dụng các chuẩn và các giao thức truyền thông phổbiến Chính điều này đã đặt nền tảng cho việc tích hợp các dịch vụ thành nhữngdịch vụ mới phản ánh các quy trình nghiệp vụ

2.3 Dịch vụ và thành phần

Thành phần là gì?

“Thành phần là một gói các tạo tác phần mềm có thể được phát triển mộtcách độc lập và có thể được phân phối như là một đơn vị, các đơn vị này sau đó cóthể kết hợp với nhau để tạo thành một thứ gì đó lớn hơn “

Giao diện

Sự kiện

Phương thức

Hình 1.10: Thành phần

Dịch vụ là gì?

“Dịch vụ là một chức năng rõ ràng, tự chứa đựng và không phụ thuộc vàongữ cảnh hoặc trạng thái của các dịch vụ khác.”

Hình 1.11: Dịch vụ

Mối quan hệ giữa dịch vụ và thành phần:

Hình 1.12: Mối quan hệ giữa thành phần và dịch vụ

Dịch vụ là một đơn vị xử lý có mức độ đóng gói cao, nó dùng và sinh ra cáctập đối tượng được truyền theo kiểu tham trị Dịch vụ không giống như đối tượngtrong ngôn ngữ lập trình, nó gần với khái niệm giao dịch kinh doanh hơn

Một dịch vụ gồm một tập hợp các thành phần hoạt động cùng nhau để cungcấp một chức năng nghiệp vụ Vì vậy, có thể nói rằng thành phần có mức độ đónggói thấp hơn hơn dịch vụ Ngoài ra, trong khi dịch vụ ánh xạ tới một chức năngnghiệp vụ thì thành phần ánh xạ tới các thực thể nghiệp vụ và quy tắc nghiệp vụthao tác trên các thực thể đó Ví dụ, xem xét mô hình thành phần Đơn đặt mua hàng(Purchase Order) cho ví dụ quản lý mạng lưới cung cấp trong hình sau:

Hình 1.13: Mô hình thành phần đơn đặt mua hàng

Trong thiết kế hướng thành phần, các thành phần được tạo ra gần tươngđương với các thực thể nghiệp vụ (như Customer, Purchase Order, Oder Item) vàđóng gói hành vi phù hợp với các hành vi mà thực thể cần

Ví dụ, thành phần Purchase Order cung cấp các hàm nhận thông tin về danhsách các sản phẩm được đặt và tổng số lượng của đơn đặt hàng; thành phần Itemcung cấp các hàm để nhận được thông tin về số lượng và giá thành của sản phẩmđược đặt Cài đặt của mỗi thành phần được đóng gói sau giao diện Vì vậy, mộtngười dùng thành phần Purchase Order không biết về lược đồ bảng Purchase Order

và thuật toán tính thuế, số tiền được giảm trên tổng số đơn đặt hàng

Trong thiết kế hướng dịch vụ, các dịch vụ được thiết kế không dựa trên cácthực thể nghiệp vụ, thay vào đó, mỗi dịch vụ là một khối quản lý các thao tác trênmột tập các thực thể nghiệp vụ Ví dụ, dịch vụ Customer sẽ trả lời bất kỳ yêu cầunào từ hệ thống hoặc dịch vụ khác cần truy cập tới thông tin khách hàng Dịch vụCustomer có thể xử lý một yêu cầu cập nhật thông tin khách hàng, thêm, cập nhật,xoá các danh mục đầu tư, và điều tra về lịch sử đặt hàng của Customer Dịch vụCustomer chứa tất cả các dữ liệu liên quan tới khách hàng mà nó đang quản lý và cókhả năng tạo ra các yêu cầu dịch vụ với danh nghĩa là người dùng dịch vụ để cungcấp một khung nhìn dịch vụ khách hàng thống nhất Điều này có nghĩa là một dịch

vụ là một đối tượng quản lý tạo ra và quản lý tập các thành phần của nó

Kiến trúc hướng dịch vụ và phát triển hướng thành phần

Ở rất nhiều khía cạnh, SOA là một sự phát triển các nguyên lý cơ bản củaphát triển hướng thành phần (CBD – Component-based Development) Nó cũngbiểu diễn một bước phát triển trong việc đem các nghiệp vụ và công nghệ thông tinxích lại gần nhau hơn Trong khi các dịch vụ SOA là hữu hình đối với người dùngdịch vụ, các thành phần nền tảng của chúng là trong suốt Đối với người cung cấpdịch vụ, thiết kế của các thành phần, sự thể hiện và quản lý dịch vụ phản ánh cácquyết định thiết kế và kiến trúc chính cho phép phát triển dịch vụ trong SOA Việc

ra những quyết định đó đòi hỏi một sự hiểu biết về các thành phần của SOA và môhình hóa SOA để nhận diện, phân loại, xác định và cấu trúc các thành phần của dịchvụ

Sự phát triển của SOA bắt nguồn từ phát triển hướng đối tượng và hướngthành phần Thế giới của các đối tượng bắt đầu với sự xuất hiện của các ngôn ngữlập trình hướng đối tượng và được phát triển thành mô hình, sau đó, nó được thêmvào các kỹ thuật thiết kế và các phương pháp phân tích thiết kế hướng đối tượng.Các dịch vụ hạ tầng, các công cụ, các nền tảng phát triển, các mẫu, và các kiến trúctham chiếu xuất hiện sau đó.

Phát triển hướng thành phần đã tạo ra một hướng tiếp cận mới trong việcthiết kế, xây dựng, cài đặt và phát triển của các ứng dụng phần mềm Các ứng dụngđược lắp ráp từ các thành phần từ nhiều nguồn khác nhau, các thành phần được viếttrên nhiều ngôn ngữ lập trình khác nhau, nhiều môi trường khác nhau, và chạy trêncác nền tảng khác nhau Nhưng chỉ với phát triển hướng đối tượng, các dịch vụ hạtầng, các công cụ, nền tảng phát triển và các mẫu mới làm cho phát triển hướngthành phần trở thành hiện thực

Cả hướng đối tượng và hướng thành phần đều yêu cầu tính tái sử dụng trongphát triển phần mềm Với phát triển hướng đối tượng thì đó một yếu tố tùy chọn,còn với phát triển hướng thành phần là bắt buộc Phát triển hướng dịch vụ đem lạikhả năng tái sử dụng lớn hơn so với phát triển hướng đối tượng SOA, với nền tảng

là cả phát triển hướng đối tượng và hướng thành phần, còn tạo ra khả năng tái sửdụng cao hơn nữa nó đã trở thành một nhân tố mới để đạt được kinh tế trong côngnghệ phần mềm

Các khái niệm và quy tắc của phát triển hướng đối tượng và hướng thànhphần được áp dụng để đem lại các framework thích hợp cho việc chỉ đạo thiết kế vàphát triển các dịch vụ SOA

Rất nhiều các nhà cung cấp dịch vụ thường cài đặt một mô tả dịch vụ Trongcác thành phần, chúng ta có thể tìm thấy các quy tắc thiết kế của hướng đối tượngxác định các cấu trúc trong của thành phần Do vậy, mô hình hóa dịch vụ là nhằmxác định đúng các dịch vụ, tổ chức chúng theo một cây phân cấp của các dịch vụphức hợp (các thành phần có mức độ đóng gói thấp hỗ trợ các thành phần có mức

độ đóng gói cao), sắp xếp chúng để hỗ trợ cho một quy trình nghiệp vụ Về phía nhàcung cấp, các dịch vụ này hoặc là được cấp phát một cách trực tiếp cho các thànhphần chứa hướng thành phần để cài đặt các chức năng của chúng, hoặc được cài đặtbằng cách thay đổi các chức năng sẵn có

Đây là bước tiến cơ bản trong công nghệ phần mềm hướng dịch vụ: thànhphần sử dụng dịch vụ không cần phải quan tâm về việc cài đặt hay hiện thực hóacủa dịch vụ, miễn là nó hỗ trợ các chức năng và chất lượng theo đúng yêu cầu của

dịch vụ Đây được gọi là khung nhìn của thành phần sử dụng (Consumer View) Bên

cạnh đó, khung nhìn của thành phần cung cấp đưa ra một triển vọng về cách thiết kếcài đặt của thành phần cung cấp dịch vụ; các quyết định và thiết kế kiến trúc của nó

Một sự khác biệt chính với hướng đối tượng truyền thống là chúng ta khôngcòn phải tạo ra các mô hình đối tượng lớn, mà chỉ cần tạo ra các thiết kế bên trongcủa các ranh giới thành phần có mức độ đóng gói cao hơn, thông qua hướng đốitượng có mức độ đóng gói thấp hơn

Các thành phần cung cấp dịch vụ không cần quan tâm tới các thành phần sửdụng dịch vụ, chỉ cần các giao ước sử dụng dịch vụ của chúng được thỏa mãn.Thành phần cung cấp dịch vụ cần thiết kế một cài đặt dịch vụ thỏa mãn các yêu cầu

đó thông qua các quyết định về việc chúng chứa đựng, quản lý và cài đặt đặc tả dịch

vụ như thế nào Khung nhìn bên trong là khung nhìn của người sử dụng hoặc thànhphần sử dụng – tức là những thành phần chỉ nhìn thấy dịch vụ thông qua thành phầncung cấp, và khung nhìn ngoài, ở đó thành phần cung cấp dịch vụ tạo ra các dịch vụthông qua các giao diện của chúng Để thực hiện được như vậy, chúng yêu cầu mộttập trong gồm các thành phần có mức độ đóng gói thấp hơn, hoặc ngang bằng thamgia vào các cộng tác cần thiết để đáp ứng các dịch vụ Do vậy, trong các thành phầncung cấp dịch vụ, chúng ta sẽ có các thành phần ở mức độ miền tương ứng với các

mô hình đối tượng miền trong hướng đối tượng truyền thống và được cài đặt thôngqua các cơ chế chứa đựng thành phần chuẩn hóa như các máy chủ ứng dụng(Application server)

3 Thiết kế theo kiến trúc hướng dịch vụ

Trong sự tiến hóa của các các kỹ thuật xây dựng phần mềm, kỹ thuật lậptrình hướng đối tượng thích hợp để cài đặt các thành phần Trong khi các thànhphần lại là cách thích hợp nhất để cài đặt các dịch vụ, mặc dù cần hiểu rằng một ứngdụng dựa thành phần tốt không cần thiết phải là một ứng dụng hướng dịch vụ tốt.Khi vai trò của dịch vụ trong kiến trúc ứng dụng được hiểu rõ, chúng ta có thể tíchhợp các thành phần mới và các thành phần hiện có Hình 1.14 minh hoạ cách cáctầng công nghệ có thể được áp dụng cho kiến trúc ứng dụng để đem lại các cài đặt ởmức độ đóng gói cao hơn khi tiến gần hơn tới người dùng ứng dụng, nó cũng chothấy dịch vụ là cách thích hợp để thể hiện khung nhìn ngoài của một hệ thống với sựtái sử dụng bên trong có sử dụng thiết kế thành phần truyền thống

Lớp đối tượng

Lớp thành phần Lớp dịch vụ

Thiết kế hướng đối tượng

Thiết kế hướng thành phần

Thiết kế hướng dịch vụ

Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng, thành phần, dịch vụ 3.1 Các nguyên tắc trong thiết kế hướng dịch vụ

Việc tiếp cận xây dựng các hệ thống dựa trên mô hình hướng dịch vụ phảituân theo bốn nguyên tắc sau [6]:

Nguyên tắc 1 : Giao diện của dịch vụ phải rõ ràng Các dịch vụ tương tác qua

việc truyền đi các thông điệp tường minh Chúng ta không cần biết về không giannằm sau giao diện của dịch vụ Vượt qua các giao diện của dịch vụ có thể tốn nhiềucông sức và chi phí Các giao diện rõ ràng cho phép cài đặt các tương tác độc lập –nghĩa là không cần biết về nền tảng hay các ngôn ngữ lập trình được lựa chọn để càiđặt các dịch vụ

Nguyên tắc 2: Dịch vụ là tự trị Các dịch vụ hoạt động như là các thực thể

độc lập Không có quyền làm chủ trong một môi trường hướng dịch vụ Các dịch vụđược triển khai, thay đổi, quản lý một cách độc lập

Nguyên tắc 3 : Các dịch vụ chia sẻ giao diện và giao ước không chia sẻ cài

đặt Các dịch vụ tương tác với nhau chỉ dựa vào giao diện và giao ước sử dụng dịch

vụ Giao ước của dịch vụ mô tả cấu trúc của thông điệp và các ràng buộc giữa cácthông điệp, điều này cho phép chúng ta bảo toàn được tính toàn vẹn của dịch vụ.Các giao ước và giao diện phải được duy trì tính ổn định với thời gian Vì vậy việcxây dựng chúng một cách mềm dẻo là rất quan trọng

Nguyên tắc 4 : Tính tương thích của dịch vụ dựa trên chính sách Cả người

cung cấp và người dùng dịch vụ sẽ phải có các chính sách để tương tác qua các giaodiện của dịch vụ Một ví dụ đơn giản về chính sách phía người cung cấp là một dịch

có thể đỏi hỏi người gọi phải có một tài khoản hợp lệ với người cung cấp dịch vụ

Về phía người dùng dịch vụ, một tổ chức có thể đòi hỏi các lời gọi qua Internet phảiđược mã hóa

3.2 Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ

Có rất nhiều quyết định thiết kế và kiến trúc là nền tảng cho SOA để đạtđược các mục tiêu và lợi ích mà kiến trúc này đã nêu ra Các quyết định kiến trúcthường liên quan tới việc chọn lựa các công nghệ và sản phẩm cần thiết để đáp ứngchất lượng cho các thuộc tính dịch vụ được yêu cầu bởi một quy trình nghiệp vụ.Các quyết định thiết kế tập trung vào các lựa chọn dịch vụ sử dụng kỹ thuật được

mô tả sau trong phân tích và thiết kế hướng đối tượng Một số các quyết định chính

là các tiêu chuẩn chính cho việc đóng gói hơn là việc chỉ đơn thuầnđóng gói chức năng

 Tính gắn kết không chặt chẽ và cấu hình lại động là một quyết địnhthiết kế yêu cầu việc tách các giao diện khỏi cài đặt và cài đặt giaothức thông qua các chuẩn mở Kết nối giữa các thành phần cung cấp

và sử dụng dịch vụ cần phải bền vững và được cấu trúc rõ ràng, cókhả năng cấu hình lại linh hoạt Có khả năng cấu hình lại có nghĩalấcc thành phần sử dụng dịch vụ và các thành phần cung cấp dịch vụhiện có có thể được lắp ghép lại với chức năng không bị thay đổi đểđạt được các giải pháp nghiệp vụ trong các môi trường kỹ thuật khácnhau và với các ràng buộc thao tác khác nhau của các đối tác kinhdoanh mới

 Các tầng SOA: Các thành phần của một kiến trúc hướng dịch vụ

Các thành phần chính của một kiến trúc hướng dịch vụ là:

 Danh mục dịch vụ: mô tả các dịch vụ nghiệp vụ trong SOA, bao gồmmột danh sách, phân loại và cấu trúc cây của các dịch vụ được xácđịnh thông qua kx thuật phân tích và thiết kế hướng dịch vụ

 Các thành phần: Cung cấp các cài đặt chức năng của dịch vụ

 Thành phần sử dụng dịch vụ, thành phần cung cấp dịch vụ và thànhphần môi giới dịch vụ (tùy chọn) với các kho đăng ký dịch vụ, ở đó,các định nghĩa và mô tả dịch vụ được xuất bản

 Các tầng SOA: vị trí của các thành phần và dịch vụ

Hình 1.15 mô tả các tầng SOA Với mỗi tầng, các quyết định thiết kế và kiếntrúc được tiến hành

Hình 1.15: Các tầng của SOA Tầng 1: tầng dưới cùng, mô tả các hệ thống vận hành Tầng này chứa các hệ

đang có, và các cài đặt hệ thống hướng đối tượng theo kiểu cũ cũng như các ứngdụng thu thập nghiệp vụ Kiến trúc theo tầng của một kiến trúc hướng đối tượng cóthể thúc đẩy các hệ thống hiện có, tích hợp chúng bằng cách sử dụng tích hợphướng dịch vụ.

Tầng 2: tầng thành phần, sử dụgn các kỹ thuật và thiết kế dựa đối tượng

chứa trong phát triển hướng thành phần truyền thống

Tầng 3: cung cấp cơ chế để lấy các thành phần ở quy mô doanh nghiệp, các

thành phần cho từng đơn vị nghiệp vụ cụ thể, và trong một số trường hợp là cácthành phần của từng dự án và cung cấp các dịch vụ thông qua các giao diện củachúng Trong tầng này, các giao diện được thể hiện ra ngoài thông qua các đặc tảdịch vụ, ở đó, các dịch vụ tồn tại một cách độc lập hoặc là tổng hợp của một số dịchvụ

Tầng 4: là một sự tiến hóa của việc tổng hợp dịch vụ thành các luồng hoặc

sắp đặt các nhiệm vụ được phân nhóm vào một luồng để hoạt động như một ứngdụng Các ứng dụng này hỗ trợ các trường hợp sử dụng và các quy trình nghiệp vụ

cụ thể Ở đây, các công cụ tổng hợp luồng trực quan có thể được sử dụng để thiết kếluồng ứng dụng

Tầng 5: Tầng trình diễn thường là nằm ngoài phạm vi của một kiến trúc

hướng dịch vụ

Tầng 6: cho phép sự tích hợp của các dịch vụ thông qua việc định tuyến tin

cậy và thông minh, giao thức trung gian, và một số cơ chế chuyển đổi khác, thườngđược mô tả như là một tuyến dịch vụ doanh nghiệp (ESB – Enterprise Service Bus)

Tầng 7: đảm bảo chất lượng dịch vụ thông qua các cơ chế cảm biến và đáp

ứng và các công cụ kiểm soát các ứng dụng SOA

3.3 Các mức độ chấp nhận kiến trúc hướng dịch vụ

Việc sử dụng kiến trúc hướng dịch vụ không bị giới hạn cho các tổ chức lớn.Trong thực tế, kiến trúc này tạo ra cơ hội cho các tổ chức vừa và nhỏ Một ví dụ vềviệc các doanh nghiệp nhỏ có thể sử dụng dịch vụ là việc nhận các hóa đơn: chúng

ta có thể dùng dịch vụ mạng để tạo ra một dịch vụ nhận hóa đơn Các hóa đơn này

sẽ được lưu trữ bởi dịch vụ cho đến khi hệ thống kế toán trên máy PC của ngườidùng kết nối đến nó để nhận hóa đơn về bằng cách sử dụng dịch vụ mạng Các hóađơn sau đó sẽ được cập nhận một cách tự động trên PC… Bằng cách này, bất kỳ tổchức nào, không phụ thuộc vào quy mô lớn hay nhỏ, đều có thể nhận được lợi ích từviệc sử dụng kiến trúc hướng dịch vụ

Một tổ chức có thể dùng nhiều cách khác nhau để nhận được kiến trúc hướngdịch vụ, tuỳ thuộc vào mục tiêu và các ràng buộc công nghệ thông tin

Cài đặt các dịch vụ Web đơn lẻ

Tích hợp các chức năng nghiệp

vụ theo định hướng dịch vụ

Chuyển đổi công nghệ thông tin rộng lớn trên toàn bộ tổ chức

Chuyển đổi nghiệp vụ theo yêu cầu

Tạo các dịch vụ từ các nhiệm vụ trong các ứng dụng mới hoặc cũ

Tích hợp các dịch vụ từ nhiều ứng dụng bên trong

và bên ngoài tổ chức để thực hiện một mục đích nghiệp vụ

Một cài đặt được kiến trúc cho phép tích hợp nhiều chức năng nghiệp vụ trong toàn

Mức độ 2: Tích hợp hướng dịch vụ các chức năng nghiệp vụ

Mức độ tiếp theo là tích hợp hướng dịch vụ Bước này bao gồm việc tích hợpcác dịch vụ từ nhiều ứng dụng khác nhau cả bên trong và bên ngoài doanh nghiệp

để phục vụ cho mục đích nghiệp vụ Mức độ này cũng phải hỗ trợ nhiều kiểu tíchhợp, bao gồm:

Tích hợp ứng dụng: gồm phát triển các giao diện mới để thể hiện các ứng

Mức độ 3: Chuyển đổi doanh nghiệp công nghệ thông tin có quy mô lớn.

Mức cài đặt SOA rộng hơn này là một cài đặt được kiến trúc hoá cho phéptích hợp nhiều chức năng nghiệp vụ trong toàn doanh nghiệp

Mức độ 4: Chuyển đổi nghiệp vụ theo yêu cầu.

Đây là mức độ cuối cùng trong phát triển kiến trúc hướng dịch vụ Mức độnày là sự định hướng chiến lược hướng tới sự chuyển đổi rộng của các mô hìnhnghiệp vụ hiện có hoặc sự triển khai của các mô hình nghiệp vụ mới.

3.4 Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ

Hiện nay, chưa có một quy trình cụ thể để phát triển các ứng dụng theo kiếntrúc hướng dịch vụ, tuy nhiên, dựa trên thực tế, 12 bước sau đã được đưa ra nhằmtham khảo khi quyết định chuyển sang định hướng dịch vụ [3]

12 bước trong quy trình phát triển phần mềm theo kiến trúc hướng dịch vụ:

1 Hiểu nghiệp vụ

2 Xác định phạm vi (miền) của vấn đề

3 Hiểu tất cả các ngữ nghĩa ứng dụng trong miền đó

4 Hiểu tất cả các dịch vụ hiện có trong miền

5 Hiểu tất cả các nguồn và đích của thông tin có trong miền

6 Hiểu tất cả các quy trình trong miền

7 Xác định và phân loại tất cả các giao diện bên ngoài miền cần thiếtcho việc xây dựng ứng dụng (các dịch vụ và thông tin)

8 Định nghĩa các dịch vụ mới và các ràng buộc thông tin của các dịch

Bước 1: Hiểu các mục đích nghiệp vụ, và xác định thành công.

Đây là nhiệm vụ thu thập yêu cầu cơ bản Nó đòi hỏi phải tiếp xúc với tàiliệu, nhân sự và hệ thống để xác định thông tin cho phép việc tích hợp ứng dụngđược xác định đúng để có thể phân tích, mô hình hóa và cải tiến Chỉ sau khi thựchiện bước này thì tập giải pháp thích hợp mới được đưa ra

Cần lưu ý rằng có cả lợi ích hữu hình và vô hình từ việc cài đặt bất kỳ loạicông nghẹ nào Lợi ích hữu hình bao gồm việc tiết kiệm chi phí tức thì, như việc tựđộng hóa một hệ thống bán theo đơn đặt hàng thay cho việc bán hàng thủ công Lợiích vô hình thì khó nhận biết hơn, như sự thỏa mãn của khách hàng dẫn tới việc tăngdoanh số bán hàng, hoặc cộng tác chặt chẽ hơn tăng cường chất lượng và cho phépcác nhân công trao đổi thông tin tốt hơn

Bước 2: Xác định miền vấn đề.

Phải xác định phạm vi của việc ứng dụng SOA trong một tổ chức Hãy chianhỏ tổ chức để áp dụng SOA thay vì áp dụng vào toàn bộ tổ chức Cùng với thờigian, những thành công nhỏ sẽ dẫn tới các chiến lược thành công lớn hơn, phải thiếtlập các đường ranh giới khi bắt đầu dự án để có thể tiến hành xây dựng ứng dụngmột cách trọng tâm hơn

Bước 3: Hiểu tất cả các ngữ nghĩa ứng dụng trong miền vấn đề.

Chúng ta không thể giải quyết các vấn để mà bản thân mình không hiểu rõ

Vì vậy, bước tiếp theo này là cực kỳ quan trọng để xác định tất cả các siêu dữ liệungữ nghĩa tồn tại trong miền ứng dụng nhằm giải quyết vấn đề một cách hoàn hảo

Sự hiểu biết về ngữ nghĩa ứng dụng thiết lập cách thức và khuôn dạng trong đó ứngdụng tham khảo các thuộc tính của quy trình nghiệp vụ Ví dụ, cùng một số hiệukhách hàng nhưng trong một ứng dụng này có thể có một giá trị và ý nghĩa hoàntoàn khác trong một ứng dụng khác Việc hiểu ngữ nghĩa của ứng dụng đảm bảorằng sẽ không có bất kỳ sự xung đột thông tin nào khi nó được tích hợp với các ứngdụng khác ở mức độ thông tin hoặc dịch vụ Xác định ngữ nghĩa của ứng dụng làmột công việc khó khăn vì có thể nhiều hệ thống mà chúng ta đang phân tích đã cũhoặc mang tính độc quyền Bước đầu tiên trong việc xác định và định vị ngữ nghĩa

là tạo ra một danh sách các hệ thống ứng viên Danh sách này sẽ cho phép chúng ta

có thể xác định những kho chứa dữ liệu nào tồn tại trong các hệ thống đó Bất kỳcông nghệ nào có thể xây dựng lại các lược đồ dữ liệu vật lý và logic cũng sẽ có íchtrong việc xác định dữ liệu trong các miền vấn đề Tuy nhiên, trong khi lược đồ và

mô hình dữ liệu có thể cho phép nhìn vào cấu trúc của cơ sở dữ liệu thì chúng lạikhông thể xác định những thông tin đó được sử dụng như thế nào trong ngữ cảnhcủa dịch vụ hoặc ứng dụng; đó là lý do chúng ta cần tới các bước tiếp theo Bằngviệc hiểu rõ các ngữ nghĩa của ứng dụng, chúng ta có thể hiểu trọn vẹn việc tích hợpứng dụng, và đảm bảo rằng tất cả các hệ thống nguồn và đích trong và giữa các tổchức được tích hợp một cách hoàn hảo

Bước 4: Hiểu tất cả các dịch vụ hiện có trong miền.

Tìm hiểu các thông tin về dịch vụ, bao gồm:

Bước 5: Hiểu tất cả các nguồn và đích thông tin hiện có trong miền vấn đề.

Bước này xác định các giao diện xử lý các thông tin đơn giản Chúng có thểthực hiện một trong 2 vai trò: sử dụng thông tin (đích) hoặc cung cấp thông tin(nguồn)

Chúng ta cần phải hiểu rõ các khía cạnh sau:

Bước 6: Hiểu tất cả các quy trình.

Chúng ta cần xác định và liệt kê tất cả các quy trình nghiệp vụ tồn tài trongmiền vấn đề, có thể là tự động hóa hoặc không phải tự động hóa Việc này rất quantrọng vì chúng ta đã biết dịch các dịch vụ và nguồn/ đích thông nào hiện có, chúng

ta cần phải xác định các cơ chế tương tác cao hơn, bao gồm tất cả các quy trình ởmức mức cao, mức trung bình và mức thấp Trong nhiều trường hợp, những quytrình này vẫn chưa được tự động hóa hoặc chỉ có một phần được tự động hóa Ví du,nếu một kiến trúc sư tích hợp ứng dụng cần hiểu tất cả các quy trình hiện có trongmột ứng dụng kiểm kê, anh ta sẽ hoặc là đọc tài liệu hoặc là đọc mã nguồn để xácđịnh quy trình nào đang được thực hiện Sau đó, anh ta sẽ đưa quy trình nghiệp vụvào phân loại và xác định mục đích của quy trình, ai là người sở hữu nó, nó chínhxác là gì, và công nghệ để thực hiện nó (Java hoặc C++ …) Những quy trình nàysau đó được gắn với các quy trình mới để đáp ứng được yêu cầu nghiệp vụ Chúng

ta cần phải xem xét khái niệm quy trình chia sẻ và quy trình riêng Một số quy trình

là quy trình riêng, và do đó, chúng không chia sẻ với các thực thể bên ngoài (trongmột số trường hợp, chúng thậm chí còn không chia sẻ với các phần khác của tổchức) Các quy trình chia sẻ và quy trình riêng có thể tồn tại trong cùng một khônggian quy trình với công nghệ tích hợp quy trình quản lý bảo mật giữa các ngườidùng

Một thông tin có thể được bảo trì trong phân loại, đó là thông tin bao gồmcác biến được sử dụng trong các quy trình, các lược đồ đối tượng, các yêu cầu bảomật, và/ hoặc các đặc điểm hiệu suất Mỗi phân loại quy trình phải duy trì tập thuộctính riêng của nó, được xây dựng tùy biến cho mỗi yêu cầu tích hợp ứng dụng cụthể

Bước 7: Xác định và phân loại tất cả các giao diện bên ngoài miền cần thiết

cho việc xây dựng ứng dụng

Chúng ta cần xác định tất cả các giaodiện bên ngoài mà các hệ thống trongmiền vấn đề của chúng ta có tương tác với, hoặc cần tương tác với để đem lại giá trịtối đa Điều quan trọng ở đây là phải chắc chắn rằng tất cả các giao diện cần thiết

đều được xác định, bao gồm khả năng thể hiện các dịch vụ của miền vấn đề ra bênngoài cho các đối tác, cũng như khả năng nhận biết và thúc đẩy dịch vụ của họ Các

hệ thống của đối tác và của chúng ta cần hoạt động cùng nhau để hỗ trợ các quytrình chia sẻ chung

Bước 8: Xác định các dịch vụ mới, các dịch vụ phức hợp và thông tin ràng

buộc đối với các dịch vụ đó

Chúng ta cần phải xác định tất cả các dịch vụ tạo thành SOA; những dịch vụnày được chia thành 3 loại

Bước 9: Xác định các quy trình mới, cũng như các dịch vụ và thông tin ràng

buộc đối với các quy trình đó

Đến bước này, chúng ta cần hiểu phần lớn những thành phần cần thiết để xácđịnh các quy trình mới, cũng như liên kết chúng với các quy trình hiện có, tự độnghóa các quy trình mà trước chưa được tự động hóa

Bước 10: Lựa chọn tập công nghệ.

Có rất nhiều các công nghệ để lựa chọn, gồm các máy chủ ứng dụng, các đốitượng phân tán, và các máy chủ tích hợp Sự lựa chọn công nghệ sẽ giống nhu một

sự tổng hợp các sản phẩm và nhà cung cung cấp để đáp ứng được yêu cầu cho SOA.Rất hiếm có trường hợp một nhà cung cấp duy nhất có khả năng giải quyết được tất

cả các vấn đề

Lựa chọn công nghệ là một công việc khó khăn yêu cầu một lượng thời gian

và công sức đáng kể Việc tạo ra tiêu chuẩn cho công nghệ và sản phẩm, việc hiểu

rõ các giải pháp được đưa ra, và sau đó nối các tiêu chuẩn với các sản phẩm đó làviệc không dễ dàng Để thành công, việc kết nối tiêu chuẩn với sản phẩm thườngđòi hỏi một dự án thử nghiệm để chứng minh rằng nó sẽ hoạt động Thời gian cầnthiết để lựa chọn các công nghệ phù hợp có thể dài bằng thời gian phát triển SOA,nhưng nếu nản chí, có thể sẽ dẫn tới việc lựa chọn các công nghệ không phù hợpdẫn đến phá hỏng hệ thống

Bước 11: Triển khai công nghệ SOA.

Đến bước này, chúng ta đã hiểu tất cả những gì cần phải hiểu, đã xác địnhđược các dịch vụ và quy trình mới, đã chọn lựa được tập công nghệ thích hợp, vàbây giờ sẽ là thời gian để xây dựng hệ thống

Bước 12: Kiểm thử và đánh giá

Để đảm bảo cho việc kiểm thử, cần phải xây dựng kế hoạch kiểm thử

Cần phải hiểu rằng 12 bước trên không phải là quy trình bắt buộc để xâydựng một dự án SOA thành công Trong một số trường hợp, chúng ta cần thêm vàohoặc xóa bỏ đi một số bước để phù hợp với từng yêu cầu cụ thể

Kiến trúc hướng dịch vụ được đưa ra nhằm loại bỏ sự trùng lặp và dư thừa

sau đó bắt đầu xây dựng kết hoạch và chiến lược để loại bỏ các dịch vụ dư thừa Kếhoạch này được gia tăng dần để loại bỏ các bản sao dư thừa Quy trình cài đặt này

sẽ giúp chúng ta đáp ứng được các yêu cầu cơ bản của tổ chức ẩn sau bước chuyểnđổi thành công sang SOA Khi chúng ta đã thực hiện được quy trình này, chúng ta

sẽ có tất cả các công cụ và hiểu biết để mở rộng quy mô áp dụng SOA trong tổ chứccủa mình

3.5 Vòng đời phát triển của dịch vụ

Việc đảm bảo rằng chỉ có các dịch vụ nghiệp vụ chuẩn hóa và có mức trừutượng cao được xây dựng và triển khai là mối quan tâm chính trong việc xây dựngcác dịch vụ trong kiến trúc hướng dịch vụ Chỉ với việc tập trung chú ý vào quytrình xác định dịch vụ mới đảm bảo việc cài đặt SOA trở nên hiệu quả như mongđợi

Dưới đây là một vòng đời phát triển và định nghĩa dịch vụ cho phép tiếnhành thực hiện việc xem xét lại và các điểm kiểm tra từ sớm trong quy trình địnhnghĩa dịch vụ [8] Điều này sẽ giúp loại bỏ lỗi trước khi chúng làm cho chi phí khắcphục lỗi tăng vọt khi dịch vụ được tiến hành phát triển và triển khai

Khởi tạo

Thu nhận

Chứng nhận Phân loại Cài đặt Kiểm thử Xuất bản Sử dụng dịch vụ

Hình 1.17: Vòng đời phát triển dịch vụ

Hình 1.17 mô tả vòng đời phát triển dịch vụ, mỗi trạng thái được định nghĩanhư sau:

Khởi tạo: một dịch vụ tiềm năng được xác định từ việc phân tích các yêu cầu

của doanh nghiệp từ trên xuống (top – down) và việc mô hình hóa quy trình nghiệpvụ

Thu nhận: Đội ngũ kiến trúc dịch vụ thông báo là đã nhận được yêu cầu

dịch vụ và bắt đầu đánh giá nó

Chứng nhận: Đội ngũ kiến trúc dịch vụ đã đánh giá dịch vụ và thống nhất

giao diện chức năng của nó

Phân loại: Dịch vụ được xác định và được chuyển giao cho đội phát triển Cài đặt: Đội ngũ phát triển dịch vụ cài đặt dịch vụ theo các quy tắc và hướng

dẫn phát triển được định nghĩa bởi framework

Kiểm thử: Đội ngũ kiểm thử dịch vụ kiểm chứng tính năng cũng như các đặc

tính chất lượng của dịch vụ

Xuất bản: Dịch vụ được xuất bản để có thể được sử dụng bởi các dịch vụ

khác hoặc các ứng dụng định hướng quy trình

4 Các công nghệ hướng dịch vụ

4.1 Sun JINI

Công nghệ Jini cho phép xây dựng một hệ thống là một mạng của các dịch

vụ Các dịch vụ có thể được thêm vào và xoá bỏ khỏi mạng, và người dùng mới cóthể tìm kiếm các dịch vụ hiện có Tất cả đều xảy ra động, không có sự quản lý

Dịch vụ được dựa trên các giao diện đã biết được viết trong ngôn ngữ lậptrình Java Nó không quan tâm tới việc dịch vụ được cài đặt bằng phần cứng hayphần mềm Đối tượng dịch vụ mà người dùng tải về được cung cấp bởi các thànhphần cung cấp dịch vụ Client chỉ cần biết rằng họ đang làm việc với một cài đặt củamột giao diện được viết bằng ngôn ngữ lập trình Java Việc thiết kế dựa trên cácgiao diện dịch vụ cho phép xây dựng các hệ thống với tính sẵn dùng cao Một thànhphần có thể sử dụng bất kỳ dịch vụ nào phù hợp với giao diện, thay vì được cấuhình tĩnh để giao tiếp với một thành phần nhất định nào đó

Công nghệ Jini được xây dựng phía trên công nghệ Java (xem hình dưới)

Phương thức triệu gọi từ xa của Java (RMI) cung cấp cơ chế thu rác từ xa của các

đối tượng từ xa và khả năng truyền trạng thái của đối tượng cũng như mã đối tượngqua mạng

Hình 1.18: Mô hình kiến trúc Jini

Kiến trúc Jini bao gồm:

Dịch vụ tra cứu (Lookup Service):

Dịch vụ tra cứu lưu giữ các dịch vụ Jini và cung cấp các ủy nhiệm để truyền

Dịch vụ Jini (Jini service)

Dịch vụ Jini được đăng ký với dịch vụ tra cứu và có khả năng được triệu gọithông qua giao diện công khai của mình (giao diện này được định nghĩa qua mộtgiao diện Java từ xa) Hệ thống nền tảng truyền thông của Jini là RMI

Thành phần sử dụng dịch vụ Jini (Jini client)

Thành phần sử dụng dịch vụ Jini là một phần mềm yêu cầu đối tượng ủynhiệm từ dịch vụ tra cứu để gọi dịch vụ Jini

Jini có một số các dịch vụ được xây dựng sẵn, bao gồm:

Dịch vụ tìm kiếm tra cứu (Lookup Discovery Service):

Dịch vụ tìm kiếm tra cứu thông báo cho các thành phần sử dụng dịch vụ vềcác thay đổi trong mạng Jini Các dịch vụ có thể kết hợp hoặc tách ra khỏi mạng bất

kỳ thời gian nào

Dịch vụ tái tạo ràng buộc (Lease Renewal Service):

Khái niệm tái tạo ràng buộc hỗ trợ mạng dịch vụ Jini tính năng tự hàn gắn vàkhắc phục lỗi Dịch vụ phải tái tạo ràng buộc của chúng với dịch vụ tra cứu, trongtrường hợp một ràng buộc không được tái tạo, dịch vụ sẽ là một ứng viên bị loại bỏkhỏi mạng lưới dịch vụ Trách nhiệm của những người quản trị trong lĩnh vực nàyđược giảm tới mức tối thiểu nhờ tính năng tự hàn gắn của hệ thống

Dịch vụ giao dịch (Transaction Service):

Dịch vụ giao dịch cho phép sử dụng các giao dịch trong một hệ thống phântán Thông thường, các tổ chức sử dụng cơ sở dữ liệu để tạo ra các hệ thống giaodịch Dịch vụ giao dịch của Jini đưa tính năng giao dịch của cơ sở dữ liệu lên mạng.Các dịch vụ có thể tham gia vào các giao dịch để đảm bảo các thuộc tính ACID

(Atomicity – Consistency – Isolation – Durability) gắn liền với giao dịch.

Dịch vụ hộp thư sự kiện (Event Mailbox Service):

Các thay đổi trong mạng dịch vụ Jini được truyền đi trong hệ thống bằngcách sử dụng các sự kiện phân tán Dịch vụ hộp thư sự kiện hỗ trợ tính năng thôngbáo các sự kiện cho các dịch vụ ngay cả khi dịch vụ không được kích hoạt tại thờiđiểm hiện tại

Openwing có hàng loạt các dịch vụ cốt lõi hỗ trợ tính toán hướng đối tượng

Component services (Các dịch vụ thành phần) : cung cấp các kỹ thuật cho

việc đưa ra công bố một dịch vụ trong hệ thống đảm bảo cho quá trình tìm kiếm

phát hiện (discover), thông qua sử dụng component service, việc tạo và đưa ra công

bố một dịch vụ sẽ đảm bảo được tính nhất quán theo một quy cách chung Cụ thể

hơn, component cung cấp các thư viện cho phép :

 Tạo ra khả năng cung cấp, định vị và sử dụng các dịch vụ nói chungtrong hệ thống mà không phụ thuộc vào bất cứ một kỹ thuật định vị/tìm kiếm (location/lookup) nào Ví dụ các kỹ định vị/tìm kiếm nhưJini, UDDI với mô hình Web-services , giao thức phát hiện(discovery) Bluetooth

 Quá trình giao tiếp giữa các thành phần hay dịch vụ được định nghĩavới các API chuẩn cho các dịch vụ thông qua việc kế thừa từ nhữnggiao diện chuẩn mà openwings đề xuất

 Cung cấp các component API cho giao thức tương tác giữa các dịch

vụ qua mạng mà không phụ thuộc vào tính đồng bộ hay không đồng

Qua hình vẽ minh họa sau, ta có thể thấy được vị trí trung tâm của các dịch

vụ thành phần trong mô hình khung mà openwings đề xuất :

Hình 1.19: Mô hình khung của Openwings

Install services (Các dịch vụ cài đặt): là thành phần dịch vụ của framewok

cho phép thực hiện cài đặt các thành phần mới vào hệ thống Để cài đặt được thìcác thành phần này cần phải qua các quy trình chuẩn mà openwings đề xuất

 Cung cấp khả năng cài đặt thêm những dịch vụ mới với hạn chế tối đacác tương tác bằng tay cho người sử dụng Đảm bảo không gây ra ảnhhưởng tới các file hay dịch vụ đã được cài đặt trước đó

 Cung cấp khả năng tự động dò tìm và cho phép gọi thực hiện với cácthành phần được lưu trữ trong các thiết bị lưu trữ lưu động

 Có cơ chế thẩm định quyền và độ ưu tiên cho việc cài đặt và gọi thựchiện

 Có cơ chế hủy cài đặt an toàn cho hệ thống khi cần thiết

Context serives (các dịch vụ ngữ cảnh): là thành phần cho hỗ trợ việc kết

hợp chức năng các dịch vụ trong môi trường hệ thống để có được một dịch vụ lớnhơn Đồng thời còn hỗ trợ việc kết hợp các dịch vụ được chia sẻ trong một mạngWAN

Menagement services (các dịch vụ quản lý): cung cấp các phương thức cơ

bản hỗ trợ việc quản lý các thành phần và dịch vụ trong hệ thống Với các hỗ trợ từ

dạng quản lý thông qua can thiệp bằng tay hay thông qua việc đặt các cơ chế quản

lý tự động Các hỗ trợ này được đóng gói trong Mbean

Security services (các dịch vụ bảo mật): cung cấp các phương thức cho việc

mã hóa, truyền tải dữ liệu trọng hệ thống, các hỗ trợ cơ bản cho việc cấp quyền,thẩm định quyền, đảm bảo an toàn khi truyền tin, tính toàn vẹn, khả năng phát hiệntấn công và đáp trả các tấn công vào hệ thống

Connector services (các dịch vụ kết nối): cung cấp các kỹ thuật cho việc

giao tiếp gữa các thành phần hay dịch vụ trong hệ thống Hỗ trợ trực tiếp cho các kỹthuật giao tiếp thông qua một đối tượng chuyển tiếp trung gian như CORBA, RMI,JMS … Một kết nối theo định hướng của Openwings sẽ cài đặt trực tiếp giao thứcgiao tiếp từ một giao diện dịch vụ được định trước theo các kỹ thuật chuyển tiếptrung gian chuẩn với cơ chế động ngay tại thời điểm diễn ra giao tiếp tùy theo yêucầu sử dụng Với đầy đủ các hỗ trợ cho việc giao tiếp theo phiên hay theo dạng giaotiếp không duy trì kết nối Hỗ trợ đầy đủ các hàm cơ bản cho phép làm việc vớiRMI, CORBA, JMS, SOAP …

Container services (các dịch vụ chứa đựng): cung cấp môi trường tương

ứng cho việc thực hiện các dịch vụ trong mô hình openwings Đây là một thànhphần quan trọng tạo nên khả năng vận hành động không phụ thuộc vào nền tảng haymôi trường vận hành phân tán của hệ thống

 Cung cấp khả năng gọi chạy các dịch vụ trên máy hiện tại qua mộtnền hệ thống từ xa

 Hỗ trợ việc quản lý vòng đời của các tiến trình dịc vụ, các phươngthức cho phép tự động khởi động lại, tạm dừng hay hủy dịch vụ

 Cung cấp khả năng gán hay thiết lập cho một số tiến trình xây dựngbằng Java có thể hoạt động độc lập trên các máy ảo Java mà khôngảnh hưởng tới các thành phần khác

 Hỗ trợ việc gọi khởi động các dịch vụ không được xây dựng trên nềnJava

 Cung cấp các phương thức cho phép theo dõi tài nguyên hệ thống nhưtheo dõi các thông tin về dung lượng bộ nhớ trong, khả năng hoạtđộng của bộ vi xử lý hay khả năng đáp ứng lưu lượng của đườngtruyền tải dữ liệu

4.3 Dịch vụ mạng

Mặc dù các khái niệm nền tảng cho kiến trúc hướng dịch vụ đã được thiết lập

từ trước khi dịch vụ mạng xuất hiện nhưng Web service vẫn đóng một vai trò quantrọng trong một kiến trúc hướng dịch vụ Đó là bởi vì dịch vụ mạng được xây dựngtrên một tập các giao thức được biết tới nhiều và độc lập về nền tảng Các giao thứcnày bao gồm HTTP, XML, UDDI, WSDL và SOAP Chính sự kết hợp của các giaothức này đã làm dịch vụ mạng đáp ứng được các yêu cầu chính của kiến trúc hướng