UNG DUNG KIEN TRUC HUONG DICH VU VA CONG NGHE DICH VU MANG TRONG
XAY DUNG PHAN MEM Danh mục từ viết tắt
STT Từ viết tắt Giải nghĩa
Thát triển hướng thành phan
1 CBD
Component-Based Development
Kiến trúc môi giới yêu cầu đôi tượng chung
2 CORBA
Common Object Request Broker Architecture Mô hình đôi tượng thành phần phân tán
3 DCOM
Distributed Component Object Model Ngôn ngữ đặc tả giao diện
4 IDL
Interface Description Language Lạ tầng mạng thông minh cho Java
5 JINI
Java Intelligent Network Infrastructure Dich vu théng diép Java
6 JMS
Java Message Service Giao thức tru yên siêu văn bản
7 HTTP
HyperText Transfer Protocol
Ngôn ngữ đặc tà địch vụ có khả nãng truy cập qua mang
8 NASSI
Network Accessible Service Specification Language
Triệu gọi phương thức từ xa
9 RMI
Remote Method Invocation Ngôn ngữ đặc tả dịch vụ 19 SDL
Service Description Language Kiện utc huéng dich vu 11 SOA
Service-Oriented Architecture
Trang 2
STT | Tir viet tắt Giai nghia Giao thức truy cập đôi tượng đơn giản
12 SOAP
Simple Object Access Protocol
Trang 3Danh muc hinh vé Hình 1.1: Sự phát triển của các công íy Hình 1.2: Sự phát triển của kiến trúc Hình 1.3: Phát triển phần mềm theo mô ẨMH
Hinh 1.4: Phái triển phần mêm hướng đối tượng
Hình 1.5: Phái triển phần mềm hướng thành phần Hinh 1.6: Phát triển phần môm hướng dịch vụ
Hình 1.7: Kiên trúc phần mêm theo định nghĩa cổ điển Hinh 1.8: M6 hinh kiến trúc hướng địch vụ Hình 1.9: Ủy nhiệm dịch vụ 20 Hinh 1.10: Thanh phan Hình LI1: Hình 1.12: Mắt quan hệ giữa thành phân và dịch vụ Hình 1.13: Mã hình thành phần đơn đặt mua hàng Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng, thành phan, dịch vụ Hình 1.15: Các tầng của SOA
Hình I.16: Các nức độ thực hiện kiên trúc hướng dịch vụ
Hình 1.17: Vòng đời phái triển Aịch VỤ 22 ke
TRình 1.18: Mô hình kiến trúc Jimi
Hình I 10: Mô hình khung của Openwings
Tình 1.20: Mô hình ESB
Tình 2.1: M46 hình dịch vụ mạng
Hình 2.2: Cấu trúc thông điệp SOAP
Trang 4Hinh 2.7: M6t vi dig dich VỊ HIẠHG, Q2 nh ren 67 F;ƒ/.08.08,Á4Y12)10 0 0) 7 005886 x 70
Tình 3.1: Mô hình kiến trúc hướng dịch Vụ Ở HỨC CQÔ à à.àà ào ci.à.eisi.eeeeexrrrrxev 72 Hình 3.2: Biêu đỗ tưởng hợp sử dụng của bài KOÁH _ cLckvr.ecrrev 74 Hình 3.3: Cài đặt dỊCH VỊ HIỚN Là nh HH na Hà go né, 75 Hinh 3.4: Trang kiểm thử dịch vụ L8 79
Trang 5Muc luc
anh: trục tit viel litessossssssssisssesnnnsesssasnvnciesssannnissssesnnmessnied Datthe myc Witth Ve ececcceeserasecsoessessesscansssssssesvenenssasessecaesonsousecarsceseonves 3
,//00.7 20.5 saceeeenenseauanesseeaees 5
CHUONG I, LY THUYET KIEN 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 tìn.9
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 ly thuyết phát triển phần mềm
2.2 Kiên trúc hướng dich vi 2.3 Dịch vụ và thành phần ứng, dịch vụ kế hướng dịch vụ é và kiến trúc trong kiên trúc hướng dịch vụ 3 Các mức độ chấp nhận kiến trúc hướng dịch vụ
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 địch vụ 4 Các công nghệ hướng dịch vụ 4.1 Sun JINI 4.2 Openwing: 4.3 Dich vu mang 4.4, Enterprise Service Bus (ESB) 1 Kiến trúc dịch vụ mạng -ccczx+ccerszttrrrxrztrrrrrrrtrrrrsrrrer 2, Các chuẩn cho dịch vụ mạng 2.1 Ngôn ngữ mô tá địch vụ mạng WSDL 2.2 Giao thức truy cập đối tượng đơn giản SOAP 2.3, Dac tả mô tả và tích hợp tìm kiếm UDDI 3 Các kiểu liên kết trong dịch vụ mạng 3.1 Liên kết tĩnh
3.2 Liên kết động trong thời gian xây dựng, 3,3, Liên kết động trong thời gian chạy
a
X4y dung dịch vụ mạng
5.1 Vong doi cha dich vu mang 5.2, Bao mat trong dich vu mang
Trang 7Kiến trúc phần mềm của một hệ thông mô tả các thành phan 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 phan đượ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 lạp của phan mém ngay cảng tăng thì các kiến trúc phan mềm truyền thống đường như đang tiến tới giới hạn khả năng giải quyết vấn đề của chúng; trong khi đó, các tổ chức công nghệ thông tỉn 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 thụ hút và tích hợp với các đối tác mới v.v , và đặc biệ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ều phươ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ới mụ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 (fivrction), lớp (class), toi thanh phan
(component); cdc cau tric nay durge xem nhu nhiing 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à đữ liệu của mình thông qua một giao diện tường minh Ở mức độ đóng gói thấp, chúng ta sử dụng đối tượng để che giấu dữ liệu, ở mức độ đóng gói cao hơn, chúng ta sử dụng các thành phần dé thực hiện việc này Việc sử dụng đối lượng để che giản thông tin hoạt động tốt với các hệ thống nhỏ, nó cho phép tạo ra các cầu trúc phần mem phan anh được các đối tượng trong thế giới thực Van dé nay 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 đủ 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ượng
vẫn làm cho sự phụ thuộc giữa chúng trở nên khó kiêm sốt trong một hệ thơng tươ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ớn tốt hơn: một thành phần được định nghĩa là một nhóm các đối trợ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ệ nhu EJB (Enterprise Java Bean), NET, CORBA (Common Object Request Broker Architecture) té ra rat 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 tap hon, 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 đựng cá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ảng khác nhau (các thành phần không đồng nhat) cho một hệ thống thì cần có kha nang tí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ệ EIB đòi hỏi việc triệu goi phuong thic 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 đùng công nghé CORBA thi lai ding IIOP (niernet Inter-ORB Protocol), hon nita, 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ởi
tường lửa Ngay cả khi khô p phải những vẫn đê trên thì để sử dụng được thành
phần, chúng ta vẫn cần phải biết vị trí chính xác và giao điện của thành phần để nếu
Trang 8Kién tric hướng dịch vụ (Service-oriented architecture, viét tat la SOA) đang được phát triên và được xem như một bước đột phá tiếp theo trong kiến trúc
phầ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é dich vu mang (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ắng theo kiến trúc hướng dịch vụ một cách tự nhiên và dễ dàng hơn Wcb scrvicc và kiến trúc hướng dịch vu dang 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ông nộ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ủ (ciient/server) trong những năm 90 đã sử dụng “đị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) va 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ó: 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 ich sau:
© Mo réng cac lya chon về mặt công nghệ
e Các hệ thống được xây dựng linh hoạt và nhạy bén hơn ¢ Giam thời gian phát triển,
e Giam 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ông nghệ 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ất cho việc cài đặt ứng đụng theo kiến trúc hướng dịch vụ cũng như lợi ích của những
Trang 9CHUONG I LY THUYET KIEN TRUC HUO'NG
DICH VU
Kiến trúc hướng địch vụ là một làn sóng mới trong phát (rién (mg dung NO 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ề : v_ Sự tiễn hóa của các kỹ thuật phát triển phần mềm
vˆ_ Kiến trúc hướng địch vụ và phát triển phần mềm theo kiến trủc hướng dich vu *⁄_ 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ệc
giả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ố gang dé phục vụ khách hàng được tốt hơn, trở nên cạnh tranh hơn và phản ứng nhanh 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ủa các hệ thống và sự thay dai nhanh về mặt công nghệ Phan lớn các doanh nghiệp ngà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 gian tồ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 tín vì các bộ ứng dụng và kiến trúc hỗ trợ rất không mềm dẻo
Ss thay đổi công nghệ là yếu tố thứ hai mà các nhà quản lý công nghệ thông tin phải đôi mặt Sự tồn câu hố và kinh doanh điện tử đang làm tăng tộc sự thay đơi Sự tồ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ản xuấ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ải tiế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ủa khách hàng Doanh nghiệp phải nhanh chóng thích nghỉ dễ tồn tại, chưa kê dén việc phải thành công trong môi trường cạnh tranh động ngày nay, va ha ting công nghệ thông tin phải đem lại khả năng thích nghi cho các doanh nghiệp
Trang 10
ngay nay cần phải được thành phan hoá và phân tán Cần chú trọng vào dây chuyền cung 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ụ kinh doanh Phân chia theo chiều dọc Phân chia theo chiều ngang 'Những năm 1980 Những năm 1980-1990 Hệ sinh thất Oo oO DOO ul L PP LLLL'
Hình 1.1: Sự phát triển của các công ty
Lam thé nào đề môi trường công nghệ thông tin trở nên linh hoạt và nhạy bén hơn đối với sự thay đổi của các yêu cầu kinh doanh? Làm thế nao dé 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? Lam 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 dé 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ác chuyê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ụ (S4) Các đơn vị riêng lẻ Đổi tượng phân tán
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ệc xâ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 (Profocol 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ì hạ tầng cơ sở, hay là tuyến địch vụ (service bus), sẽ tạo ra một lựa chọn thích hợp cho người dùng Các đặc tả kỹ thuật cụ thể từ các công nghệ cài đặt khác nhau như J2EE hay NET không làm ảnh hưởng tới người dùng SOA Người dùng cũng có
Trang 11khả 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ững, khá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át triể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 lố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ày càng phức tạp hơn Họ cần một cách tốt hơn dé sir dung lại những đoạn mã đã - Khi những nhà nghiên cứu quan tâm tới van dé 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ác
hà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ột thời gian, từ 1960 đến 1980 Ứng Dụng Mô đun Hàm Hàm Dữ Liệu Mô đun Hàm Hàm
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 thay rằng họ đang thực hiện việc cắt đá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 dé nay Phuong phap phat 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
Trang 12Ung Dung Đối tượng
Hình 1.4: Phát triển phần mềm hướng đối trợ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 thay 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 sofware - CBD) Ứng Dụng Thành phần, 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 cach dé dang
Trang 13
Ứng Dụng Dich vu = Dich vu == er | oe | = L—Ị S| Dich vu Ec Fans pa Tan nhân P| [Ee iy 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át
triể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ản
nhấ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ại như 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ện
như thế nào thì viết lệnh như thế đó Don vị có thể tái sử dụng của phần mềm là rất
nhỏ - 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ến
thê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ần mề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 bao gồm cả những ứng dụng thương mại Kỹ thuật phát triển phần mềm hướng đối
tượ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ài
thập kỷ gần đây, việc đưa ra các khái niệm lớp, hàm và biến thành phan, 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úc chươ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ác thự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 đối tượ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ày cà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 cao
hơ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ành
Trang 14
phan 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ành phầ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ách ghé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ữa chú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ất cao, 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ày cà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êu cầu về khả năng tái sử dụng mã và kha nang dễ bảo trì đối với phần mềm đã khiến cho 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ần mề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 | Hướng đối |Hướng thành| Hướng dịch trúc tượng phần vụ Mức độ đóng gói Rất thấp Thấp Trung bình Cao ns 8 x 5 ae
ats Xác định /Công khai Công khai Xuât bản Kha ning tail „ —- “ane Thap Thap ‘ Trung binh 5 Cao
Độ gắn kết Chặt Chặt Long léo | Rat long lẻo
\Cée rang puod Po gian biên|Thời gian biên|Thời gian biên| Thời gian dịch dịch dịch chạy
“Phạmvi | Nộibộứng | Nộibộứng | Nộibộứng | Giữa các
truyền thông dụng dụng dụng công ty
2.2 Kiến trúc hướng dịch vụ
Kiến trúc phần mềm của một chương trình hoặc một hệ thống tính đoán là
cấu trúc hoặc các cấu trúc của hệ thống, bao gồm các thành phần phần mềm, các thuộc tính có thể nhìn thấy từ bên ngoài của các thành phần đó và các mối quan hệ giữa chúng[ 1] Thành phần Kết nỗi Thành phần
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
đặc tính riêng biệt
Trang 15
Tìm kiếm Xuất bản/Đăng ký “Tương tác (liên kết & thực thị)
[ saoao
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 vu (Service-oriented architecture - SOA) la 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 la m6t framework cho phép tinh nang tng dung đượ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à SÓA, nó là một trong các chuẩn cho phép xây dung SOA SOA tritu tượng hoá tính phức tạp và chỉ 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 tồn, tích hợp đáp ứng được các yêu cau nghiệp vụ Các giải pháp phải cài đặt, tối tru và chỉ dẫn sự thực thì quy trình nghiệp vụ bằng cách kết hợp tính năng củ iéng lẻ, đóng kín và có khả năng
tai 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 giita cdc thanh phan dich vụ với sự quản l tập trung va cai dat phan tan”.Dave Morris, I.T Security Lead TransAlta Corp
“SOA mé hinh hod nghiép vu nhw la m6t tập các dich vụ te chita dung (self- 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
“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 mm 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 lâ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 (W/SDL) cho tính năng và các lời gọi các phương thức của nó ” Rajesh Dawar
Trang 16
“Cac dich vu cung cp m6t 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é nao dé tao ra được chức năng ấy SOA là một cách tiếp cận để xây dung các ứng dụng phan mém như là các tập hợp địch vụ tự trị, tương tác không cân quan tâm tới nên tang, 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, Sofware
A@
“SOA là một kiểu thiết kế cỗ gắng cho phép sự tích hợp dễ dàng và các ứng dung linh hoạt Trong SOA, chức năng ứng dụng được thiết kế như là các dịch vụ có khả năng tái sứ dụng và chia sẻ Một dịch vụ là một phân của chức năng ứng dụng thể hiện chức năng của nó qua một giao diện trừu tượng, che giấu các phan việc bên trong của sự cài đặt dịch vụ "Anne Thomas Manes, analyst, Burton Group
“SOA la mét kién trie cho quy mô doanh nghiệp (thường trải rộng nh ou ung đụng rong 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 là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 lập, chứ không phải dưới dạng một mô hình lập trình cụ thé SOA dién hình bao gom cde đị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 đặit, 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ể "" Siefan 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 dich vụ này có thể được kết hợp theo một cách thúc lỏng lẻo đề tao thành các quy tì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 Sohmelzer, analyst, ZapThink LLC
*SOA là một cách tiếp cận dé 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 lăng cường tính tai sw dung va lién thong ” Ankur Gupta, marketing manager, Fiorano Software inc
“SOA la mét dạng của kiến trúc công nghệ gắn liền với các guy tắc của hướng dịch vụ Khi được cài đặt thông qua nên tang 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 nghiệp vụ và các miễn tự động hoá của một doanh nghiệp ” Thomas Erl, chief architect,
XMLTC Consuiting inc
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 lán cung cấp chức năng ứng dụng dưới dạng các dịch vụ tới các ứng dụng người dùng cuôi hoặc các dịch vụ khác:
Trang 17¢ SOA la mét kiến trúc dùng các chuẩn mở đề biểu điễn các thành phần phân mềm như là các dịch vụ
«Cung cấp một cách thức chuẩn hóa cho việc biểu điển và tương tác
với các thành phân phân mêm,
* Cac thành phần phần mềm riêng lẻ trở thành các khôi cơ bản có thé sử đụ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 16 chức
Dịch vụ là yếu 6 then chốt trong SOA Cé thé hiéu dich vụ như là hàm chức năng (mo dun pl in mém) thực hiện quy trình nghiệp vụ nào đó địch vụ trong SOA có các đặc điểm sau:
« Các dịch vụ là có thể tìm kiểm được e© Các dịch vụ có tính liên thơng
« Cac dịch vụ không được gan két chặt chẽ với nhan
e_ 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
e Cac địch vụ trong suốt về vi tri
¢ Cae 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 đẻo” với nhau (nghĩa là một ứng đụng có khả năng giao tiếp với một ứng dụng khác mà không biết các chỉ tiết kỹ thuật bên trong), có giao diện được định nghĩa rõ ràng và độc lập với nên tảng hệ thống và có thê tái sử dụng SOA là cấp độ cao hơn của phát triền ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao diện chuẩn để chc giấu sự phức tạp kỹ thuật bên đưới
Thiét ké SOA tach riêng phần thực hiện dịch vụ (phần mềm) với giao diện gọi dịch vụ Điều này fạo nên một giao diện nhất quán chơ ứ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 địch vụ Thay vì xây dựng các ứng dung don lẻ va dé s6, nhà phát triển sẽ xây dựng các dịch vụ tỉnh gọn hơn có thé trién khai và t dụng trong toàn bộ quy trình nghiệp vụ Điều nà cho phép tải sử dụng phần mềm tốt hơn, cũng như tăng sự mềm đéo vì nhà phát triển có thê cải tiến địch vụ mà không làm ảnh hướng đến ứng dụng sử dụng dich vu
Triết lý SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc
tươ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í đụ 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ề chỉ tiết tập hàm API, một thay đổi mã lệnh trong thành phan COM sé yêu cau những thay đổi trong tng déi với mã lệnh truy cập thành phần COM này
ƯUu điểm lớn nhất của SÓA là khả năng kết nối mềm đẻo và tái sứ dụng Các dịch vụ có thẻ được sử dụng trên nên tang bat ky và đước viết với ngôn ngữ bãi 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)
Trang 18SOA dựa trên hai nguyên tắc thiết kế quan trọng: Mô đun: tách vấn đề lớn thành nhiều vấn để nhỏ
Đóng gói: che giấu dữ liệu và logic trong từng mô đun đối với truy cập từ bền ngoài
Một thiết kế kiến trúc phù hợp với khái niệm của SOA cần tuân theo những
tinh chat sau:
Một đị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 (cod:se-grainedl)
Một dịch vụ có thể dùng lại được, cho phép có thể xây dựng được một dịch vụ mới từ các dịch vụ hiện có Do đó, việc quan sát các hảm ý có thê có của các thuộc tính phi chức năng như tính giao dịch là rat quan
trọng
Một giao diện dịch vụ là một điểm cuéi mang (network endpoint) dam bảo tính độc lập và trong suôt về vi tri
Một dịch vụ cần có khả năng được phát hiện ra một cách công khai bang cach sử dụng một nơi đăng ký dịch vụ nhắm cho phép các liên kết động tới dịch vụ
Một dịch vụ cần đảm bảo tính liên thông bằng cách hỗ trợ các giao thức truyền thông được chuân hóa và các định dạng dữ liệu rõ ràng Cac dac điểm trên đảm bảo cho một kiến trúc hướng dịch vụ khả năng gắn kết lỏng léo của các dịch vụ phân tán và có tính mô đun băng cách sử dụng các giao ước dịch vụ đê mô tả các định dạng thông điệp cân thiết
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: Dich vu (service)
Thành phan st dung dich vu (service consumer/ client/ requester) Thành phần cung cấp dịch vu (service provider)
Thanh phan dang ký dịch wu (service registry) Giao ude dich vy (contract)
Uy nhiém dich vu
Rảng buộc sir dung dich vu (service lease) Dich va:
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ê
Trang 19truy 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ính
chất sau:
¢ Dich vu cé tinh chất rõ ràng, là một dơ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ông chung
“ Có tính liên thông và vị trí trong suốt
e Dịch vụ được định nghĩa bằng các giao điệ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ụng dị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 độ đóng gó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 sử dụng dịch vụ:
Thanh phan sử dụng dịch vụ là một ứng dụng, một dịch vụ, hoặc một loại mô đun phần mềm khác có yêu cầu sử dụng dịch vụ Đây là thực thể khởi tạo việc định vị địch vụ tại một kho đăng ký dịch vụ, liên kết tới dịch vụ qua một kênh truyền thông và thực thi chức năng của dịch vụ Thành phần này thực thi nhiệm vụ băng cách gửi tới địch vụ một yêu cầu được định đạng theo đúng giao ước
Thanh phan cùng cấp dich va:
Thanh phan cung cấp dịch vụ là một thực thé có khả năng được địa chỉ hóa
qua 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ụng dịch vu Thanh phan cung cấp dich vụ có ‘thé là một hệ thống máy tính lớn, một thành phần, hoặc một loại hệ thống phần mềm khác có thê thực thí 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ân cung cập địch vụ và cung cấp các giao ước đó cho những thành phân sử dụng dịch vụ
Giao tóc dich vu:
Một giao ước là một bản đặc tả cách thức dễ thành phan str dung dich 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ệp yê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ập cá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ân thiết của dịch vụ đề thực thi một chức năng cu thé Ban giao ước cũng có thé bao
Trang 20gồ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ăng củ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 đị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ột hà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 tham chiếu tới thành phần cung cập dịch vụ trong nơi đăng ký Sau đó, nó định dạng thô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 cho thà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ết phầ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ôi trường khác nhau, mỗi ủy nhiệm dịch vụ được việt bằng ngôn ngữ của thành phan
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 ủy
nhiệ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 sử dụng dịch vụ Kho đăng ký Thành phần sử dụng địch vụ na Liên kết và thực thi Mã cài đặt Ủy nhiệm dich vụ Thành phần cung cấp dịch vụ Hình 1.9: Ủy nhiệm dịch vụ Ràng buộc sử dụng dịch vụ:
Ràng buộc sử dụng dịch vụ mà thành phần đăng ký dịch vụ gán cho thành
phầ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ên kế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 chặt chẽ giữa các thành phần này bằng cách giới hạn khoảng thời gian mà chú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ụ
Trang 21Tìm kiếm địch nự: 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 thí dịch vụ: Sau khi nhận được mô tâ dịch vụ, người dùng sẽ gọi địch vụ theo các thông tin mô tá
4.2.3 Lợi ích của kiến trúc hướng dịch vụ
Như đã trình bay trong phần mở đầu, các doanh nghiệp đang phải đối mặt
với hai vẫn dé cơ bản: khả năng thay đối một cách nhanh chóng, và yêu cầu giảm giá thành sản phẩm Với kiến trúc hướng địch vụ, chúng ta có thể nhận thấy nhiều lợi ích giúp các tô chức thành công trang 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ành nhữ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 được lợ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 địch vụ là đặ dịch vụ, không phả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 hố ả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 đựng trên các hệ thống riêng biệt, tích hợp trở nên dễ quân ly hơn vì độ phức tạp được cô lập Việc này thậ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 đây chuyền
Nhay bén hơn và thời gian tung ra thị trường nhanh hơn
Kha nang tao thành các dịch vụ mới từ những tài nguyên hiện có đem lại một lợ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 phan và dịch vụ hiện có làm giảm thời gian can 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ử V iệc này dẫn tới sự phát triển nhanh của các đị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ời gian 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 để đảng hơn và có thể được kết hợp đự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ềm nă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ình nghiệ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à quan lý một cách để dàng hơn để phù hợp với yêu cầu về thời gian SOA đem lại tí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
Trang 22Chuyé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ành
hướ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ợp
của chức năng nghiệp vụ khi doanh nghiệp phát sinh nhu câu hoặc đoán trước được cá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 so vớ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ật
lậ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ợp
cho 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 đổi
tượng, hướng thủ tục, và các hệ thong khac
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é dang tich 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ững dị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ột
cá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 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ào ngữ cảnh hoặc trạng thái của các dịch vụ khác.”
Trang 23OH OA Hinh 1.11: Dich vu Mối quan hệ giữa dịch vụ và thành phần: of} Or AZ ra đồ, = A
Hình 1.12: Mỗi quan hệ giữa thành phân và dich vụ
l Dịch vụ là một đơn vị xử lý có mức độ đóng gói cao, nó dùng và sinh Ta các tập đôi tượng được truyền theo kiêu tham trị Dịch vụ không giông như đôi tượng trong 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 đề cung cấ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 độ đóng gó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ăng nghiệ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í đụ, 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:
Trang 24CustomerReferenceType PurchOrdtype |+ epavaaw() + geiOrderNum() 1 |+ setValue ( ) + selOrderNum ( ) + gelCustomerFtef (_) tem + setCustomerRef ( ) + getitems ( ) MemList * getlD ( ) + setltems ( ) 1 + setlD ( ) * getTotal ( ) + getitem ( ) + | + getaty () + setTotal ( ) + selVaiue ( ) 213 +9 + selPrice ( )
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) va đó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ề danh sách các sản phẩm được đặt và tông số lượng của đơn đặt hàng; thành phan Item cung 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ột ngườ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ác
thự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ên
mộ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ầu nà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ụ để cung cấ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
6 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ủa phát triển hướng thành phần (CBD - Component-based Development) Nó cũng biểu diễn một bước phat trién trong việc đem các nghiệp vụ và công nghệ thông tin
xích lại gần nhau hơn Trong khi các dịch vy SOA là hữu hình đối với người dùng
đị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ấp
dịch vu, 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ác
quyế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ịch
vụ
Trang 25lập trình hướng đối tượn ig va dug phat triển thành mô hình, sau đó, nó được thêm và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úc tham chiếu xuất hiện sau đó
Phát triển hướng thành phần dã tạo ra một hướng tiếp cận mới trong việc thiế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ết trê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ên cá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ướng thà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 trong
phá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ại
khả năng tái sử đụ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 phan, con tao 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 dé đạt được kinh tế trong công nghệ phần mềm,
Các khái niệm và quy tắc của phát triển hướng đỗi trợng và hướng thành phan duge 4p dung dé dem lại các framework thích hợp cho việc chỉ dạ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ụ Trong các thành phan, chúng ta có thể tìm thấy các quy tắc thiế của hướng đối tượng xác định các câu trúc trong của thành phần Do vậy, mô hình hóa địch vụ là nhằm xá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 địch vụ này hoặc là được cấp phát một cách trực tiếp cho các thành
phầ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 đặt
bằ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ành phan str dung dich vụ không cần phải quan tâm về việc cài đặt hay hiện thực hóa
củ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
dich vụ Đây được gọi là khung nhìn của thành phần sử dung (Consumer View) BEn 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ú ing ta không cò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 trong của các ranh giới thành phần có mức độ đóng gói cao hơn, thông qua hướng đối tượng có mức độ đóng gói thấp hơn
Trang 26vụ như thé nao Khung nhìn bên trong là khung nhìn của người sử dụng hoặc thành
phầ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ần
cung 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ột tậ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 tham gia vào các cộng tác cần thiết để đáp ứng các dịch vụ Do vậ trong các thành phần cung 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ông
qua 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ập trình hướng đối tượng thích hợp đẻ cài đặt các thành phân Trong khi các thành
phần lại là cách thích hợp nhất dé cai đặt các dịch vụ, mặc dù cần hiệu rằng một ứng
dụ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ích hợ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ác tang 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 cho thay 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 dịch vụ Thiết kế hướng thành phần Thiết kế hướng đối tượng
Hình 1.14: Các tầng cài đặt trong thiết kế: đối trợ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ải
tuâ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 gian nam sau giao diện của dịch vụ Vượt qua các giao diện của dịch vụ có thê tốn nhiều công sức và chỉ 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ụ
Trang 27Nguyê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 địch vụ chia sẻ giao điệ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ử đụng dịch vụ Giao ước của dịch vụ mô tả cấu trúc của thông điệp và các ràng buộc giữa các thông điệp, điều nảy cho phép chúng ta bảo toản được tính toản vẹn của dịch vụ Các giao ước và giao điện phải được duy trì tính ến định với thời gian Vì vậy việc xây dựng chúng một cách mềm đẻo lả rất quan trọng
Nguyên tắc 4 : Tính tương thích của dịch vụ dựa trên chính sách Cả người cung cấp và người dùng dịch vụ sẽ phải có các chính sách để tương tác qua các giao
diện của dịch vụ Một ví dụ đơn giản về chính sách phía người cung cấp là mệt dịch
có thể đói hỏi người gọi phải có một tài khoản hợp lệ với người cung cấp dịch vụ Về phía người dùng địch vụ, một tổ chức có thể đòi hỏi các lời ọ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 dịnh thiết kế và kiến trúc là nền tang cho SOA dé dat đượ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úc thườ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 ứng chất lượng cho các thuộc tính đị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ử dung 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à [5]:
«Xác định dịch vụ: các quyết định thiết kế quyết định thành công của mội kiên trúc hướng địch vụ
và cải đặt thành p chứa: các quyết định thiết kế và kiến trúc rất quan trọng để một dịch vụ cung cấp các chức năng cho việc mở rộng vào bảo trì
e Mức độ đóng gói: các lựa chọn thiết kế về dịch vụ phải phù hợp với mức độ tái sử dụng và mềm dẻo được yêu câu trong ngữ cảnh cụ thê Các dich vụ có mức độ đóng gói cao hơn có thê trợ giúp việc đóng gói các thay đổi trong các dịch vụ kỹ thuật có mức độ đóng gói thấp hơn (các dịch vụ này thường có xu hướng thay đối thường xuyên hơn so với các nghiệp vụ ở mức cao hơn) Các nhân tố của tính mềm dẻo sẽ 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
e Tính gắn kết không chặt chẽ và câu hình lại động là một quyết định thiết kế yêu câu việc tách các giao diện khỏi cài đặt và cài đặt giao thứ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ĩa lấcc thành phần sử dụng dich vụ và các thành phan 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 để
Trang 28
đạt được các giải pháp nghiệp vu trong các môi trường kỳ thuật khác nhau và với các ràng buộc thao tác khác nhau của các đôi tác kinh
doanh mới
e 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ồm mộ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ụ
© Cade 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ành phâ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ế va kiến trúc được tiên hành Hình 1.15: Các tầng của SO4A
Tang 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ệ thống hoặc ứng dụng hiện có, bao gồm các ứng dụng được đóng gói, các ứng dụng đ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 ứng dụ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ợp
hướng dịch vụ
Tầng 2: tầng thành phan, 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
Trang 29Tang 3: cung cap ca 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ác thà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ủa chúng Trong tang nay, các giao diện được thê hiện ra ngồ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ố địch
vụ
Tang 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 ứng dụ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 nghỉ cụ thể Ở đây, các công cụ tổng hợp luồng trực quan có thể được sử đụng đề thiết kế luỗng ứng dung 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 địch vụ
Tầng 6: cho phép sự tích hợp của các đị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)
Tang 7: dam bao chat 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 số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 dich vu mang dé tạo ra một dich vụ nhận hóa đơn Các hóa đơn này sẽ được lưu trữ bởi địch vụ cho đến khi hệ thống kế toán trên máy PC của người dùng kết nối đến nó để nhận hóa đơn về bằng cách sử dụng đị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ướng dịch vụ, tuỳ thuộc vào mục tiêu và các ràng buộc công nghệ thông tin
Trang 30Các điểm đầu vào
“Chuyển đổi rộng khắp các mô hình nghiệp vụ ến đổi
hiện có hoặc triển khai các mô hình nghiệp vụ i nghiệp vụ theo Chuyển đổi (>——— yêu cầu
Một cài đặt được kiến ho phép tích
hợp nhiều chức năng nghiệp vụ tong tồn [TSAO đấi cơng nghệ Tích hợp các dich vow g nhiều ứng dung bên trong và bên ngoài tổ chức để thực hiện một mục đích nghiệp vụ Tạo các dịch vụ từ các nhiệm vụ trong các ứng dụng mới hoặc cũ Hình 1.16: Các mức độ thực hiện kiến trúc hướng dịch vụ Mức độ 1: Cài đặt các dịch vụ riêng lẻ
Mức độ này tạo ra các dịch vụ từ các nhiệm vụ có trong các ứng dụng mới hoặc các ứng dụng hiện có Kiến trúc hướng dịch vụ đem lại khả năng thiết kế các ứng dụng và hệ thống cung cấp các dịch vụ cho các ứng dụng khác thông qua các giao diện được xuất bản Cách tạo ra các ứng dụng này có thê đưa đến một mô hình lập trình mạnh hơn, linh hoạt hơn, giảm chỉ phí cả trong phát triển và bảo trì
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ợp
cá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ích hợ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 dụng hiện có Tích hợp thông tin: gồm cà đữ liệu doanh nghiệp và dữ liệu liên phòng ban Tích hợp quy trình: gồm tích hợp qua sự tập hợp, sắp xếp các ứng dụng và dịch vụ với nhiêu giao diện Tích hợp hệ thống: gồm sự kết nói các hệ thống không đồng nhất, các hệ thông hiện có và tích hợp ứng dụ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 dat SOA rong hon nay là một cài đặt được kiến trúc hoá cho phép tí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ình nghiệp vụ hiện có hoặc sự triển khai của các mô hình nghiệp vụ mới
Trang 313.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ến trúc hướng dịch vụ, tuy nhiên, dựa trên thực tế, 12 bước sau đã được đưa ra nhằm
tham khảo khi quyết định chuyển sang định hướng dịch vụ [3]
12 bước trong quy trình phat trién phan 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 dé
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 dị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 (các dịch vụ và thông tín)
8 Dinh 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 vụ đó
9, Định nghĩa các quy trình mới, cũng như các dịch vụ và ràng buộc thông tin cho các quy trình này
10 Lựa chọn tập công nghệ 11 Triển khai công nghệ SOA
12 Kiêm thử và đánh giá
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ài liệ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ực hiện bước nảy thì tập giải pháp thích hợp mới được đưa Ta
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 bat kỳ loại công nghẹ nảo Lợi ích hữu hình bao gôm việc tiêt kiệm chỉ 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ăng doanh 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ép các nhân công trao đôi thông tín tôt hơn
Bước 2: Xác định miền vấn đề
Trang 32lậ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ụng mộ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 van dé ma ban 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ệu
ngữ 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 đó ứng dụ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ệu khách hàng nhưng trong một ứng dụng này có thể có một giá trị và ý nghĩa hoan toà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áo
rằ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 ứng
dụ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 đanh 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 đồ đữ liệu vật lý và logic cũng sẽ có ích trong việc xác định đữ liệu trong các miền vấn đẻ Tuy nhiên, trong khi lược đồ và mô hình đữ liệu có thể cho phép nhìn vào cấu trúc cha co sé dit liu thi chung lại không thể xác định những thông tin đó được sử dụng như thế nào trong ngữ cảnh của đị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ằng việ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:
« - Vị trí của dịch vụ e Mục đích của dịch vụ
®_ Thơng tin ràng buộc của dịch vụ
«e Các phụ thuộc (nếu đó là một dịch vụ phức hợp) © Cac van dé bao mật
Vị trí tốt nhất để bắt đầu tìm hiễu là thư mục dich vụ Giống như các thư mục khác, đây là một kho chứa các thông tin được thu thập về các địch vụ hiện có, cùng với các tài liệu về mỗi dịch vụ, bao gồm mục đích của địch vụ, các thông tin vào/ - Thư mục này được sử dụng cùng với những hiểu biết về ngữ nghĩa của ứng đụng để xác định các điểm tích hợp trong tất cả các hệ thống của miễn van dé
Bước 5: Hiểu tat ca cdc 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 điệ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)
Trang 33Chúng ta cần phải hiểu rõ các khía cạnh sau: e Vị trí của chúng
=_ Cấu trúc của luồng thông tin vảo/ ra e Cac rang bude tích hợp
© Các phụ thuộc (các nguồn va đích khác, cũng có thể là các dịch vụ)
© Cac van 48 bao mat
Bước 6: Hiểu tất cả các quy trình
Chúng ta cần xác định va kê tất cả các quy trình nghiệp vụ tồn tài trong miễ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 quan trọ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 Irong nhiều trường hợp, những quy trình này vẫn chưa được tự động hóa hoặc chỉ có một p được tự động hóa Ví đu, nêu một kiến trúc sự tích hợp img dụng cần hiểu tat cả các quy trình hiện có trong một ứng đụ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ính xác là gì, và cong nghệ để thực hiện nó (Java hoặc C+~ ) Những quy trình nảy sau đó đượ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 chỉa sẻ với các thực thể bên ng:
một số trường hợp, chúng thậm chí còn không chỉa sẻ với các phần khác của tố chức) Các quy trình chía sẻ và quy trình riêng có thể tồn tại trong cùng một không gian 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ười dung
Một thông tin có thể được bảo trì trong phân loại, đó là thông tin bao gồm các biến được sử dụng trong các quy trình, các lược dé déi tượng, các yêu cầu bảo mậ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ộc tí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 trong miễn van dé 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 điệ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ên ngoài cho các tác, cũng như khả năng nhận biết và thúc day 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 nhan để hỗ trợ các quy trinh chia sé chung
Bước §: 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 địch vụ đó
Trang 34Chúng ta cần phải xác định tất cá các dịch vụ tạo thanh 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 rang 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ự động hóa các quy trình mà trước chưa được tự động hóa
Bước 10: Iựa chọn tập công nghệ
Có rất nhiều các công nghệ dé lựa chợn, gồm các máy chủ ứng dụng, các đối tượng phân tán, vả các máy chủ tích hợp Sự lựa chọn công nghệ sẽ 6
su tong hợp các sản phẩm và nhả cung cung cấp để đáp ứng được yêu
Rất hiểm có trường hợp một nhà cùng 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à san 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é dang Dé 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 rang nó sẽ hoạt động Thời gian can thiết để lựa chọn các công nghệ phủ hợp có thể đà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ợp dẫ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 địch vụ và quy trình mới, đã chọn lựa được lậ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ây dự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ào hoặ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 địch vụ được đưa ra nhằm loại bỏ sự trùng lặp và dư thừa qua việc tái sử dụng và tích hợp Cách đơn giản nhất để bắt đầu với SOA là thử với i rằng có nhiều cài đặt trong các ứng dụng khác nhau, sau đó bắt đầu xây dựng kết hoạch và chiến lược để loại bỏ các địch vụ dư thừa Kế hoạch này được gia tang dan để loại bỏ các bản sao đư 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ức của mình
Trang 35
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ừu tượng cao được xây đựng và triển khai là mỗi quan tâm chỉnh trong việc xây dựng các địch vụ trong kiến trúc hướng dịch vụ Chỉ với việc tập trung chú ý vào quy trình xác định dịch vụ mới đảm bảo việc cài dặt SÓA 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ến hành thực hiện việc xem xét lại và các đi kiểm tra từ sớm trong quy trình định nghĩ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 chỉ phí khắc phục lỗi tăng vọt khi dịch vụ được tiến hành phát triển và triển khai Thu nhận 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ĩa như 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ệp vụ
Thụ nhậm: Độ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ậm: Độ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 tinh chất lượng của dịch vụ
Trang 36Xuấ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
Cong 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ập trì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 hay phầ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ành phần cung cap dich vu Client chi can biét rang họ đang làm việc với một cài đặt của mộ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ác giao 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ành
phầ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ấu
hình tĩnh đề giao tiếp với một thành phần nhất định nào đó
Công nghệ lini đượ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 (RM/) 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ượng qua mạng Dịch vụ tra cứu Dich vụ tìm kiếm và đăng ký với dịch vụ tra cứu Tìm kiếm dịch vụ Thành phần sử dụng tài về đối tượng ủy nhiệm cho dịch vụ Thành phần sử Dịch vụ dụng dịch vụ Truyền thông với dịch vụ thông qua ủy nhiệm
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 thông với dịch vụ, bản thân nó cũng là một dịch vụ Jini
Dich vu 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ọi
thông qua giao diện công khai của mình (giao diện này được định nghĩa qua một
giao diện lava từ xa) Hệ thông nên tảng truyền thông của lini là RMI
Thành phần sử dụng dịch vụ Jini (Jini client)
Trang 37Thành phần sử dụng dịch vụ Jini là một phần mềm yêu cầu đối tượng ủy nhiệm từ dịch vụ tra cứu đề gọi dich vu Jini
Jini cé mét sé cac dịch vụ được xây đựng sẵn, bao gồm: Dich vu tim kiếm tra cứu (Lookup Discovery Service):
Dịch vụ tim kiểm tra cứu thông báo cho các thành phan str dung 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
Dich vy tai tao rang budc (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, trong trườ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
Dich vu giao dich (Transaction Service):
Dich vụ giao dịch cho phép sử dụng các giao dich trong một hệ thông phân tá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 giao dịch Dịch vụ giao dịch của Jini đưa tính năng giao dịch của cơ sở đữ liệu lên mạng Các dịch vụ có thể tham gia vào các giao dịch để dam bảo các thuộc tinh ACID (Atomicity Consistency Isolation Durability) gắn liền với giao dịch
Địch vụ hộp thư sự kiện (Event Mailbox Service):
Các thay dỗi trong mạng địch vụ Jini dược truyền di trong hệ thống bằng cá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ông báo các sự kiện cho các dịch vụ ngay cả khi dịch vụ không được kích hoại tại thời điêm hiện tại
4.2 Openwings
Opcnwings là một khung kiến trúc hướng dịch vụ cho việc xây dựng các hệ thống hoặc các siêu hệ thông (hệ thông của hệ thống) Mặc dù không bị rằng buộc cụ thể với Jini, nó xây dựng dựa trên các khái niệm của Java va Jini dé cung cấp
một giải pháp hoàn thiện hon
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ệ thong dam bao cho qua trinh tim kiếm
phát hiện (điscover}, thông qua sử dụng component service, việc tạo và đựa ra công
bó một đị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ử đụng các dich vụ nói chung trong hệ thống mà không phụ thuộc vào bất cứ một kỹ thuật định vị
Aim kiém (location/lookup) nao Vi du cdc k¥ dinh vi/lim kiém nhu
Trang 38Jin, UDDI với mô hình Web-services , giao thức phát hiện (discovery) Bluetooth
* Qué trinh giao tiép gitta cdc thanh phần hay dịch vụ được định nghĩa
với các API chuân cho các dịch vụ thông qua việc kê thừa từ những giao 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 bộ của các dịch vụ
s« Cung cấp khả năng điều khiển các dịch vụ thành phần ngay trong thời
điêm dịch vụ đó đang được gọi thực thi
« Hỗ trợ việc đưa ra các báo cáo về trạng thái của các thành phần tham
gia vào hệ thơng
¢ Cho phép thiết lập môi trường thực thi động dựa theo yêu cầu tại thời
điêm sử dụ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
Trang 39Anstall services (Cac dich vụ cai dat): \a thanh phan dịch vụ của famewok 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 phan 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 đa các tương tác băng tay cho người sử dụng Dâm báo không gây ra ánh hưở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ác thành phần được lưu trữ trong các thiết bị lưu trữ lưu động
e Có cơ chế thắm định quyền và độ ưu tiên cho việc cài đặt và gọi thực
hiện
e_ Có cơ chế hủy cài đặt an toàn cho hệ thống khi cần thiết
Context serives (cdc dich vu ngữ cảnh): la thanh phan 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ớn hơ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ạng
WAN
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 phan va dich vy 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 dich vụ bảo mậ£): cùng 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ện tấn công và đáp trả các tấn công vào hệ thống
Connector services (cdc dich 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ức
giao tiếp từ một giao diện dịch vụ được định trước theo các ky thuật chuyển tiếp
trung 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êu câu sử dụng Với đầy đủ các hồ trợ cho việc giao tiếp theo phiên hay theo dạng giao tiếp không duy trì kết nói Hỗ trợ day đủ các hàm cơ bản cho phép làm việc với RMI, CORBA, JMS, SOAP
Container services (các dịch vụ chứa đựng): cùng cấp môi trường tương ứng cho việc thực hiện các địch vụ trong mô hình openwings Đây là một thành phan quan trọng tạo nên khả năng vận hành động không phụ thuộc vào nền tang hay môi trường vận hành phân tán của hệ thắng
s« 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ột nền hệ thống từ xa
« Hỗ trợ việc quản lý vòng đời của các tiến trình die vy, các phương thức cho phép tự động khởi động lại, tạm đừng hay hủy dịch vụ
Trang 40« Cung cấp khả năng gán hay thiết lập cho một số tiễn trình xây dựng
bă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 phan khác
« Hỗ trợ việc gọi khởi động các dịch vụ không được xây đựng trên nền Java
© Cung cap các phương thức cho phép theo dõi tài nguyên hệ thống như theo đõi các thông tin về dung lượng bộ nhớ tron, khả năng hoạt động của bộ vi xử lý hay khả năng đáp ứng lưu lượng của đường truyề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 địch vụ mạng xuất hiện nhưng Web service vẫn đóng một vai trò quan trọng trong một kiến trúc hướng địch vụ Đó là bởi vì dịch vụ mạng được xây dựng trên một tập các giao thức được biệt tới nhiêu và dộc lập về nên tảng, Các giao thức nay bao g6m HTTP, XML, UDDI, WSDL va SOAP Chinh su két hop cilia cac giao thứ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 dịch vụ: SOA yêu cầu dịch vụ phải được phát hiện và triệu gọi động, yêu câu này
được thỏa mãn bằng UDDI, WSDL va SOAP, SOA yéu cầu địch vụ có một giao
ước giao điện độc lập nên tảng, yêu cầu này được thỏa mãn bởi XML; SOA nhấn mạnh tới tính liên thông, yêu câu này được thoả mãn bởi HTTP Đây là lý do tại sao các dịch vụ mạng lại có vai trò trung tâm trong kiến trúc hướng dịch vụ Chỉ tiết hơn về dịch vụ mạng sẽ được để cập tới tronp chương, sau
4.4 Enterprise Service Bus (ESB)