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

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ• • • TRẦN ĐÌNH CHÍ K IÉ N T R Ú C H Ư ỞN G D ỊC H • vụ VÀ ỨNG • DỤNG P H Á T T R IỂ N PHẦN • M È M C H Ứ N G KHOÁN Ngành: CÔNG NGHỆ THÔNG TIN Chuyên ngành: CÔNG NGHỆ PHÀN MÈM Mã số: 60 48 10 LUẬN VĂN THẠC sĩ NGƯỜI HƯỚNG DẲN KHOA HỌC: TS. TRÀN THỊ MINH CHÂU Hà N ộ i-2011 4 MỤC LỤC CHƯƠNG 1 - TÓNG QUAN VỀ SOA........................................................................... 1-. 1 Một số mô hình kiến trúc phân tán hiện tại và sự ra đời của SOA.......................... 1.1.1 D CO M .......................................................... ......................................................... 1.1.2 .NET Remoting...................................................................................................... 1.1.3 RMI....... ....... ....................................... ........................... ...................................... 1 . 1 . 4 . C O R B A . . . . ................................................................................. 12 12 12 13 14 .................................................................................. 15 11.2 Kiến trúc hướng dịch v ụ ................................................................................................ 16 1.2.1 Kiến trúc hướng dịch vụ là g ì?............................................................................. 16 1.2.2 Mô hình cơ bản của SO A ...................................................................................... 16 1.2.3 Kiến trúc phân tầng chi tiết của SOA.................................................................. 16 1.3 Các nguyên tắc thiết kế hệ thống SOA........................................................................ 18 1.3.1 Khớp nối lỏng lẻo dịch vụ (Service Loose Coupling)........................................ 18 1.3.2 Sự trừu tượng hóa dịch vụ (Service Abstraction).............................................. 19 1.3.3 Tái sử dụng dịch vụ (Service Reusability).......................................................... 19 1.3.4 Khả năng tự phục hồi (Self-healing).................................................................... ] 9 1.3.5 Sự tự trị cùa dịch vụ (Service Autonomy)........................................................... 20 1.3.6 Giảm thiếu tiêu thụ tài nguyên dịch vụ (Service Statelessness).........................20 1.3.7 Khả năng dò tìm dịch vụ (Service Discoverability)............................................ 20 1.3.8 Khả năng tổng hợp (Composite)............................................................................20 1.4 Các đặc điểm cúa SO A ....................................................................................................21 1.4.1 Hướng nghiệp vụ (Business-Driven)......................................................................21 1.4.2 Trung lập nhà cung cấp (Vendor-Neutral)............................................................ 21 1.4.3 Trung tâm doanh nghiệp (Enterprise-Centric)......................................................21 1.4.4 Trung tâm tổng hợp (Composition-Centric)......................................................... 21 1.5 Quy trình xây dựng một hệ thống SOA......................................................................... 21 1.6 Các chiến lược thiết kế hệ thống S O A ..........................................................................23 1.6.1 Chiến lược thiết kế top-down................................................................................. 23 1.6.2 Chiến lược thiết kế bottom-up................................................................................24 1.7 SOA và vấn đề tích hợp.................................................................................................. 26 1.7.1 Nhu cầu giải quyết bài toán tích họp..................................................................... 26 1.7.2 Chuyển đổi sang ứng dụng dịch v ụ ....................................................................... 27 1.8 SOA và hiệu năng............................................................................................................ 27 1.8.1 Phân tích vấn đề hiệu năng trong hệ thống S O A .................................................27 1.8.2 Các ràng buộc lời g ọ i..............................................................................................29 1.9 SOA và bảo mật............................................................................................................... 29 1.9.1 Các yêu cầu bảo mật................................................................................................ 29 1.9.2 Sự thỏa thuận với các yêu cầu bảo m ật.................................................................30 1.9.3 Bảo mật, hiệu năng và trạng thái............................................................................34 1.9.4 Bảo mật trong thực t ế ..............................................................................................35 1.9.5 Bảo mật với XML và Web Service....................................................................... 36 1.9.6 Khi nào vấn đề bảo mật cần được xem x é t.......................................................... 40 5 CHƯƠNG 2 - VAI TRÒ CỦA ENTERPRISE SERVICE BUS TRONG SOA........ 41 2.1 Khái niệm Enterprise Service Bus................................................................................. 41 2.2 Vai trò cùa ESB trong SOA............................................................................................ 41 2.3 Các mẫu Enterprise Service B u s ...................................................................................42 2.3.1 Kết nối điểm tới điểm..............................................................................................42 2.3.2 Kiểu lá chắn (Interceptors).....................................................................................44 CHƯƠNG 3 - ỨNG DỤNG WCF VÀO SOA...................................................................47 3.1 Giới thiệu về WCF...........................................................................................................47 3.2 Kiến trúc WCF................................................................................................................. 48 3.2.1. Hợp đồng (Contracts)......................................................................................... 48 3.3.2. Dịch vụ Runtime (Service Runtime)................................................................ 49 3.2.3. Thông điệp (Message)....................................................................................... 49 3.2.4. Kích hoạt và Chứa (Activation and Hosting )............................................... 49 CHƯƠNG 4 - NGHIỆP v ụ PHÀN M ÈM ...................................................................... 51 4.1 Quy trình nhập lệnh môi giới....................................................................................... 5 1 4.1.1 Mô tả khái quát.......................................................................................................5 1 4.1.2 Sơ đồ nghiệp vụ..................................................................................................... 51 4.1.3 Các bước thực hiện................................................................................................ 52 4. 2 Quy trình hủy lệnh........................................................................................................54 4.2.1 Mô tả khái quát......................................................................................................54 4.2.2 Sơ đồ nghiệp vụ......................................................................................................54 4.2.3 Mô tả chi tiết các bước..........................................................................................54 4.3 Quy trình sửa lện h .........................................................................................................55 4.3.1 Mô tả khái quát.......................................................................................................55 4.3.2 Sơ đồ nghiệp vụ......................................................................................................56 4.3.3 Các bước thực hiện................................................................................................ 56 CHƯƠNG 5 - THIẾT KẾ VÀ CÀI ĐẶT HỆ T H Ố N G ..................................................58 5.1 Lý do lựa chọn SOA cho việc phát triển phần mềm chứng khoán..........................58 5.2 Thực trạng của hệ thống phần mềm công ty chứng khoán StockMart Việt N am .. 58 5.3 Thiết kế hệ thống phần mềm mới theo kiến trúc SO A ............................................. 61 5.3.1 Phân tích dịch v ụ ................................................................................................... 61 5.3.2 Thiết kế các thành phần dịch vụ ...........................................................................63 5.3.3 Phát triển các dịch v ụ ............................................................................................68 5.4 Một sổ bảng chính trong cơ sở dữ liệu....................................................................... 68 5.5 Giới thiệu một số màn hình giao diện chính...............................................................73 KẺT L U Ậ N .......................................................................................................................... 77 TÀI LIỆU THAM K HẢ O .................................................................................................. 78 6 DANH M Ụ C HÌNH VẼ Hình 1.1: DCOM mở rộng COM bằng cách cho phép các thành phần COM giao tiếp thông qua các đường biên vật lý.......................................................................................... 12 Hình 1.2: Kiến trúc phân tầng của .NET Remoting......................................................... 13 Hình 1.3: Mô hình cơ bản của S O A ................................................................................... 16 Hình 1.4: Mô hình logic các thành phần của hệ thống SO A ........................................ 17 Hình 1.5: Các bước xây dựng một hệ thống SOA........................................................ 2 1 Hình 1.6: Các bước xây dựng hệ thống theo chiến lược top-down........................23 Hình 1.7: Các bước xây dựng hệ thống theo chiến lược bottom-up....................... 25 Hình 1.8: Biểu đồ tuần tự của một cuộc gọi dịch v ụ ........................................................27 Hình 1.9: Nhiều bước nhảy ngắn giữa người dùng cuối và các hệ thống backend..... 32 Hình 1.10: Các tầng bảo mật cho XML và các web service........................................... 36 Hình 2.1: Một Enterprise Service Bus................................................................................. 42 Hình Hình Hình Hình Hình Hình 2.2: 2.3: 2.4: 2.5: 3.1: 3.2: Một ESB cung cấp các kết nối điểm tới điểm ..................................................43 Một kết nối hòa giải của ESB [SOA in Practice]..............................................43 Một ESB với một bộ cân bằng tải cho các dịch vụ được cung cấp................ 45 Một ESB sử dụng các bộ chắn............................................................................. 46 Mô hình chương trình thống nhất đã được thiết lập bởi W CF........................ 47 Kiến trúc của W CF............................................................................................... 48 Hình Hình Hình Hình Hình Hình 4.1: 4.2: 4.3: 5.1: 5.2: 5.3: Sơ đồ quy trình nhập lệnh môi giới.....................................................................52 Sơ đồ quy trình hủy lệnh môi giới.......................................................................54 Sơ đồ nghiệp vụ quy trình sửa lệnh môi g iớ i.................................................... 56 Mô hình các thành phần của hệ thống phần mềm hiện tạ i...............................59 Các thành phần phần mềm được thiết kế theo kiến trúc S O A ........................ 62 ESB được triển khai để hỗ trợ cơ chế cân bằng tải và khắcphục lỗi...............67 Hình Hình Hình Hình 5.4: 5.5: 5.6: 5.7: Màn hình Màn hình Giao diện Giao diện giao diện đặt lệnh cho khách hàng.....................................................74 giao diện vấn tin lệnh đặt của khách hàng........................................74 vấn tin tổng hợp tài khoản khách hàng............................................. 75 mở tài khoản khách hàng....................................................................75 Hình 5.8: Giao diện quản lý nhóm người dùng và phân quyền.........................................76 Hình 5.9: Giao diện quản lý người dùng............................................................................. 76 7 DANH M Ụ C BẢNG BIÉƯ Bang 4.1: Mô tả chi tiết các bước của quy trình nhập lệnh............................................... 54 Bang 4.2: Mô tả chi tiết các bước của quy trình hủy lệnh................................................. 55 Báng 4.3: Mô tả chi tiết các bước của quy trình sửa lệnh................................................. 57 Bang 5.1: Danh sách các hàm chức năng cho dịch vụ TradingService........................... 64 Báng 5.2: Danh sách các hàm chức năng cho dịch vụ CoreService................................. 66 Bàng Bảng Bảng Bảng 5.3: 5.4: 5.5: 5.6: Mô Mô Mô Mô tả tả tả tả thông thông thông thông tin tin tin tin cho bảng Customers................................................................. 69 bảng GlStockCode.....................................................................69 bảng StockPrice......................................................................... 70 bảng StockOrder........................................................................70 Bảng 5.7: Mô tả thông tin bảng TradingOrder.................................................................... 71 Bảng 5.8: Mô tả thông tin bảng TradingResult...................................................................72 Bảng 5.9: Mô tả thông tin bảng Balance..............................................................................73 Bảng 5.10: Mô tả thông tin bảng Securities......................................................................73 8 BẢNG CÁC KÝ HIỆU V IẾT TẮT X t7 • Diên giai r \ • Ký hiệu viết tắt CK Chứng khoán CORBA Common Object Request Broker Architecture DCOM Distributed Component Object Model DMZ Demilitarized Zone Dos Denial-of-Service - Tấn công từ chối dịch vụ EAI Enterprise Application Integration - Tích hợp ứng dụng doanh nghiệp ESB Enterprise Service Bus HNX Sở giao dịch chứng khoán Hà Nội HSX Sở giao dịch chứng khoán thành phố Hồ Chí Minh IIS Internet Information Services KH Khách hàng RMI Remote Method Invocation SMS Short Message Services - Dịch vụ tin nhắn ngắn SOA Service Oriented Architecture - Kiến trúc hướng dịch vụ SOAP Simple Object Access Protocol SSL Secure Sockets Layer TK Tài khoản TTGD Trung tâm giao dịch WAS Windows Activation Service W CF Windows Communication Foundation ws Web Service WSDL Web Service Definition Language XML Extensible Markup Language 9 TÙ ĐIÉN THUẬT NGŨ s ử DỤNG TRO N G LUẬN VĂN • • • Coarse­ grained Mô tả mức độ gom nhóm xử lý của một thành phân xử lý thông tin. Các thành phần có tính coarse-grained thường truyền nhận và xử lý theo tùng khối dữ liệu có thông tin ngừ cảnh lớn và số lần trao đổi thông tin trong một giao tác là ít. Enterprise application Một sản phâm phân mêm được thiêt kê đê tích hợp các phân mêm con bên trong doanh nghiệp lại với nhau. Mục tiêu là để tích hợp các xử lý nghiệp vụ chính. Fine-grained Các thành phân có tính fine-grained truyên nhận và xử lý theo từng đon vị nhỏ và có ngữ cảnh ngầm định, cần nhiều lần trao đổi thông tin trong một giao tác dẫn đến tăng băng thông sử dụng và kéo dài thời gian hồi đáp. Granularity Khái niệm mô tả độ phức tạp của tiên trình hoặc dịch vụ. Granularity được chia làm hai loại là “fine-grained” và “coarse-grained” . Khái niệm granularity được hiểu một cách trừu tượng không phân biệt hai loại trên và tùy ngữ cảnh mà có cách hiếu khác nhau. Legacy system Hệ thông ứng dụng được cài đặt từ trước nhưng vân còn được sử dụng. Thông thường dây là những hệ thống sử dụng công nghệ đã lỗi thời nhưng vẫn quan trọng và còn hoạt động tốt. Đây là thành phần nền tảng cung câp xử lý cho các dịch vụ hoạt động ở câp cao hơn. Loose coupling Một sản phâm phân mêm được thiêt kê đê tích hợp các phân mêm con bên trong doanh nghiệp lại với nhau. Mục tiêu là đế tích hợp các xử lý Middleware nghiệp vụ chính. Là thành phân trung tâm liên kêt các phân mêm khác lại. Orchestration Sự sắp xếp tự động, điều phối và quản lý hệ thống máy tính phức tạp, lớp giữa và các dịch vụ. Service Consumer Người sử dụng dịch vụ ở đây có thê là một ứng dụng, một dịch vụ hoặc là các module phần mềm khác yêu cầu sử dụng dịch vụ. Service contract Một hợp đông (contract) là một đặc tả vê cách thức bên sử dụng dịch vụ trao đổi liên lạc với bên cung cấp dịch vụ. Nó chỉ rõ ra định dạng yêu cầu và đáp trả của dịch vụ. Service provider Nhà cung câp dịch vụ là một dịch vụ châp nhận và xử lý những yêu cầu từ người sử dụng dịch vụ. Tight coupling Ngược lại vói Loose coupling. 10 LÒÌ M Ở ĐẦU Trong thập kỷ qua, kiến trúc hướng dịch vụ đã chuyển từ sơ khai đến phổ biến trong thế giới phần mềm và bằng nhiều cách nó cho phép các mô hình thông tin tiếp theo cua công nghệ điện toán đám mây. Mô hình “Phần mềm + Dịch vụ” đã trở thành chuẩn mực, các doanh nghiệp định hướng theo kiến trúc SOA sẽ có một cách dễ dàng đê chuyến đối sang điện toán đám mây, SOA cho phép mở rộng quy mô tốt hơn và tiết kiệm chi phí do các tính chất của nó đem lại. Kiến trúc hướng dịch vụ là sự kỳ diệu đàng sau rất nhiều ứng dụng dựa trên Internet và các dịch vụ tích họp thông tin và dừ liệu từ nhiều nguồn thành một nguồn duy nhất. Việc thiết kế một cách lỏng léo của SOA cho phép các nhà phát triển tái sử dụng các dịch vụ hiện có để xây dựng các ứng dụng của họ, tự động thích ứng với thay đối trong những dịch vụ, và cung cấp các dịch vụ riêng của họ đế phát triển ứng dụng khác. Triết lý của SOA là “Đừng tốn công chế tạo lại bánh xe, hãy kết hợp những linh kiện (dịch vụ) có sẵn và bổ sung nhũng gì cần thiết để lắp ráp nhanh chóng chiếc xe đưa bạn đến đích”. SOA phép các nhà phát triên để làm điều đó bởi sự tập trung vào xây dựng các bộ phận duy nhất của các ứng dụng cua họ bằng cách cho phép họ sử dụng lại các dịch vụ hiện có của những người khác đã viết để giải quyết các vấn đề chung. Để phát triển, định hướng dịch vụ cung cấp một mô hình công nghệ có tiềm năng cho việc tạo ra và duy trì có hiệu quả sự tiến hóa của các ứng dụng, các ứng dụng có thề được thay đổi tốt hơn và được mở rộng hơn với các nghiệp vụ. Nhờ ứng dụng SOA, ta có thể định hướng dịch vụ để cung cấp các chiến lược và các công cụ đế phát triển các ứng dụng công nghệ thông tin hiện có và trong khi đồng thời đẩy mạnh phát triển các chức năng mới. Chiến thuật “Trích xuất và thay thế” của quá khứ để đối phó với việc thay đổi các công nghệ và nhu cầu nghiệp vụ đã không còn thích ứng với sự phát triển mạnh mẽ về hạ tầng công nghệ thông tin cũng như các yêu cầu của khách hàng. Như vậy SOA là một kiến trúc khá phổ biến hiện tại, vậy thật sự SOA là gì? Một hệ thống SOA có các tính chất gì?, Kiến trúc của nó ra sao và các mẫu thiết kế nó như thế nào,...? Đó chính là các câu hỏi mà đề tài nghiên cứu và trả lời. 11 Kết cấu của Luận văn, ngoài phần mở đầu và kết luận bao gồm 5 chương: Chuoìig 1 - Tổng quan về SOA Nội dung: Chương này trình bày khái niệm về SOA, mô hình kiến trúc SOA, các nguyên tắc thiết kế hệ thống SOA, quy trình xây dựng hệ thống SOA, đồng thời tìm hiểu một số vấn đề về hiệu năng và bảo mật của hệ thống SOA. C huong 2 - Vai trò của Enterprise service bus (ESB) trong SOA Nội dung: Chương này tìm hiểu khái niệm về ESB, vai trò của ESB trong SOA và một số mẫu thiết kế ESB phổ biến. Chưoìig 3 - ủ n g dụng Windows Communication Foundation (WCF) vào SOA Nội dung: Chương này giới thiệu về công nghệ WCF trong .NET Framework, như khái niệm WCF, mô hình kiến trúc WCF C huong 4 - Nghiệp vụ phần mềm Nội dung: Chương này trình bày một số quy trình nghiệp vụ trong giao dịch chứng khoán như quy trình đặt lệnh, sửa lệnh, hủy lệnh. Chương 5 - Thiết kế và cài đặt hệ thống Nội dung: Chương này trình bày việc phân tích hệ thống phần mềm cũ và xây dụng lại phần mềm theo kiến trúc hướng dịch vụ. 12 C H Ư Ơ N G 1 - TÓNG QUAN VỀ SOA ỈSI Nội dung của chương I trình bày về lý do lựa chọn kiến trúc hướng dịch vụ, từ đỏ đi vào tìm hiểu các nội dung chi tiết về kiến trúc hướng dịch vụ như: Mỏ hình kiên trúc hướng dịch vụ, quy trình thiết kế của kiến trúc hướng dịch vụ, vấn đề tích hợp, vấn đe về hiệu năng và bào mật trong hệ thong hướng dịch vụ. 1.1 Một số mô hình kiến trúc phân tán hiện tại và sự ra đòi của SOA 1.1.1 DCOM COM (Component Object Model) hỗ trợ việc đóng gói các hệ thống hướng đối tượng thành các thành phần nhị phân, nó hồ trợ đóng gói bằng cách ngăn chặn việc lộ ra các chi tiết thực hiện, và đóng gói logic trong các thành phần COM để nó chỉ có thê truy cập được nếu nó đã được lộ ra thông qua một interface chung. DCOM mơ rộng COM để cho phép giao tiếp giữa các máy tính khác nhau. DCOM đã thiết lập một giao thức bảo mật từ xa qua đó thúc đẩy framework báo mật đã được cung cấp bởi hệ điều hành của Windows. Ví dụ, nó được sử dụng danh sách điều khiển truy cập để các thành phần bảo mật mà sau đó có thể được cấu hình bằng cách sử dụng các công cụ DCOMCNFG. c o r/ ỉLrtirre p ro to col s ta c k c o r / r u r t ir r e c o r/ t corrporert p ro to c o l s ta c k ♦ DCOM r e t w o rk p ro to c o l 'Hình 1.1: DCOM mở rộng COM bằng cách cho phép các thành phần COM giao tiếp thông qua các đường biên vật lý Ưu điểm của DCOM: - Dcom là một mô hình phân tán dễ triển khai, chi phí thấp. - Quản lý kết nối hiệu quả và dễ dàng mở rộng. Nhu’O’c điểm của DCOM: [SO A With .NET and w indow s Azure] 13 - Phụ thuộc vào nền tảng Window do đó chỉ sử dụng được với các máy tính cùng sử dụng hệ điều hành Window. - DCOM có một sổ nhược điểm, bao gồm cả việc sử dụng cách ping “keep-alive” (còn được gọi là bộ thu gom rác phân tán), nó yêu cầu client định kỳ ping đối tượng phân tán. Nếu đối tượng phân tán không nhận được một thông điệp trong một khoảng thời gian xác định, nó bị ngừng hoạt động và cuối cùng bị phá hủy. Bộ thu gom rác phân tán là dễ bị lỗi, tăng lưu lượng mạng, và quy mô không vượt ra ngoài mạng nội bộ. DCOM do đó không thích hợp cho mạng WAN. - DCOM thông qua trực tiếp kết nổi TCP trên cổng cụ thể, làm cho nó phức tạp đế cấu hình trên nhiều máy tính và tường lửa, và thậm chí kém thích hợp cho truyền thông qua Internet. -.NET Enterprise Services có một vài giới hạn khi thiết kế dịch vụ với DCOM. Ví dụ, giao tiếp là phụ thuộc vào DCOM và proxy của client bị gắn chặt với server. Điều này gây khó khăn để thiết kế theo nguyên tắc chuẩn hóa các hợp đồng dịch vụ và tính loose coupling của dịch vụ. ỉ . 1.2 .N E T Remoting Tương tự như các công nghệ phân tán khác, .NET Remoting sử dụng một đối tượng proxy cho giao tiếp. Lớp proxy đóng vai đối tượng từ xa tại nội bộ và trừu tượng hóa ra bên ngoài cho quá trình giao tiếp, về bản chất, các lớp proxy chặn cuộc gọi và giao tiếp với đối tượng từ xa trên đại diện cho client. 2Hình 1.2: Kiến trúc phản tầng của .NET Remoting 2 [SOA With .NET and w indow s Azure] 14 Gói đối tượng giao tiếp với bộ định dạng đế các gói mà client yêu cầu và server đáp ứng được định dạng phù hợp. Bộ định dạng chuyển các thông điệp tới SOAP hoặc định dạng nhị phân. Bộ định dạng sau đó giao tiếp với các kênh truyền vận nhàm sử dụng thích hợp giao thức truyền vận để truyền tải dữ liệu. Kiến trúc phân tầng của •NET Remoting này được mở rộng và cho phép các định dạng mới và các kênh được giới thiệu. Kênh này và bộ định dạng cho một ứng dụng .NET hiện tại có thể được thay đối tập tin cấu hình ứng dụng mà không cần biên dịch lại mã. Khả năng cấu hình một ứng dụng phân tán bằng cách sử dụng một file cấu hình rất hiệu quả. Điều này đã được áp dụng sau đó với ASP.NET web service và sau đó là WCF. Ưu điểm của .NET Remoting: - .NET Remoting đã được giới thiệu chủ yếu để giải quyết những hạn chế trong COM và DCOM. Như với DCOM, nó cung cấp một cơ chế phân tán giữa các máy tính cho phép các client nhanh chóng cấu hình trên máy tính từ xa. Tuy nhiên, nó cho phép các thành phần client và server được cấu hình bằng cách sử dụng một file cấu hình XML, về cơ bản cho phép. NET Remoting đề thực hiện giao tiếp từ xa bằng cách gưi thông điệp nhị phân và thông điệp XML dựa trên SOAP. Nhược điểm của .NET Remoting: - .NET Remoting là công nghệ độc quyền của .NET, nó chỉ được sử dụng trong các hệ thống .NET và do đó không được thiết kế để hỗ trợ khả năng tương tác giữa các dịch vụ. Đối tượng .NET Remoting chỉ có thể được sử dụng với các client .NET khác và chủ yếu được sử dụng như là một phần của giải pháp phân tán đóng rằng không cần phải công bổ các hợp đồng hoặc các API. Nó chủ yếu được thiết kế để phù hợp giao tiếp trong các hệ thống . NET với nhau. - .NET Remoting thiếu khả năng chia sẻ hợp đồng vì nó không viện dẫn một cơ chế cho sự khám phá interface. - Nó không tương thích với Web Service và WCF ngay cả khi cấu hình để sử dụng định dạng SOAP và HTTP như một giao thức truyền vận. Điều này là bới vì .NET Remoting dựa vào RPC/Encoded SOAP, trong khi WCF và Web Service sử dụng các thông tin cơ bản trên Web Service. - Nó hạn chế việc áp dụng nguyên tắc tự trị dịch vụ. Với .NET remoting, người tiêu dùng kết hợp chặt chẽ với dịch vụ và tham chiếu với giao diện hoàn thành đã được chuyển đến người tiêu dùng dịch vụ để nó có thể được sử dụng. Việc gắn kết chặt này dẫn đến một sự mất mát đáng kể của tiềm năng tự trị dịch vụ. - Nó có một số giới hạn về hosting và không đưa ra một mô hình bảo mật. 1.1.3 RMI RMI là một phương pháp tiếp cận nơi mà một phương thức trên một máy từ xa viện dẫn một phương thức khác trên một máy tính khác để thực hiện một vài tính toán và trả về kết quả tới lời gọi phương thức, RMI được sử dụng để tương tác với các phương thức của những đối tượng trong những máy từ xa khác sử dụng JVM. 15 ư u điểm RMI: - Dễ dàng cài đặt dẫn tới các ứng dụng mạnh mẽ, dễ báo trì và mềm déo hơn. Nhược điểm RMI: - Kém hiệu quả hơn các đối tượng socket. - Không thể sử dụng mã ra khỏi phạm vi của Java. - Các vấn đề về an ninh cần được theo dõi một cách chặt chẽ hơn. - Không hồ trợ cho việc tái sử dụng các hệ thống cũ. 1.1.4. CORBA CORBA là một chuẩn được định nghĩa bởi Object Management Group (OMG) I1Ó cho phép các thành phần phần mềm được viết với nhiều ngôn ngừ và chạy trên nhiều máy tính đe làm việc cùng nhau, CORBA hồ trợ nhiều nền tảng. CORBA nằm ớ tầng giữa cho các đối tượng phân tán Ưu điểm: - Hướng đối tượng. - Định vị/truy cập trong suốt. - Độc lập ngôn ngữ. - Độc lập phần cứng. - Độc lập hệ điều hành. - Chuẩn mở, kiến trúc độc lập với nhà cung cấp. - Đa dạng trong việc thiết lập các dịch vụ. - HỖ trợ nhiều ngôn ngữ lập trình, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thoả các tính chất của CORBA. - Có thể tích hợp với các hệ thống cũ viết bằng các ngôn ngữ khác nhau nhưng cùng tuân theo kiến trúc của CORBA. Nhưọc điểm: - CORBA là ngôn ngừ lập trình cấp thấp, rất phức tạp, khó học và cần có một đội ngũ phát triển có kinh nghiệm. - Các đối tượng CORBA khó có thể tái sử dụng. Nhận xét chung: Các kiến trúc phân tán như RMI, DCOM,.Net Remoting, CORBA đa phần là các chuẩn đóng, chúng hầu như không thể kết họp với các chuẩn khác dẫn tới việc khó có thế tích hợp và tái sử dụng lại các hệ thống khác chuẩn với nhau. Ví dụ như bắt đối tượng Java trao đổi dừ liệu trực tiếp với một đối tượng DCOM là không thể. Như vậy bài toán đặt ra đối với các nhà phát triển phần mềm là phải tạo ra được một kiến trúc mới nhằm có thể tận dụng được các ưu điểm của các kiến trúc phân tán trôn đồng thời còn có khả năng dễ dàng tích họp với các hệ thống khác, dễ dàng m ở rộng, nâng cấp,...và các nhà phát triển phần mềm đã tạo ra một kiến trúc mới thỏa mãn các tính chất trên đó là kiến trúc hướng dịch vụ (SOA). 16 1.2 Kiến trúc hướng dịch vụ 1.2.1 Kiến trúc hướng dịch vụ là gì? Kiến trúc hướng dịch vụ (SOA) là một phương pháp luận được sứ dụng trong phát triển phần mềm để xây dựng các hệ thống phân tán. Phân phát các chức năng dưới dạng các dịch vụ và các dịch vụ được người dùng cuối sử dụng vào ứng dụng cùa mình hoặc được sử dụng để xây dựng một dịch vụ khác. Giống như khái niệm đổi tượng là trung tâm của kiến trúc hướng đối tượng thì khái niệm dịch vụ là trung tàm của SOA. Dịch vụ (Service) là các hàm chức năng, mô đun phần mềm thực hiện một qui trình nghiệp vụ nào đó. 1.2.2 Mô hình cơ bản của SOA Service p ro v id e r service request service response Hình 1.3: Mô hình cơ bản của SOA Trong đó: Service provider Một service provider cung cấp các dịch vụ phục vụ cho một nhu cầu nào đó. Người dùng (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động, họ chỉ cần quan tâm dịch vụ đó là gì. Service consumer Người dùng sử dụng dịch vụ được cung cấp bởi Service Provider 1.2.3 Kiến trúc phân tầng chỉ tiết của SOA Hiện tại không có một mô hình thống nhất cho các thành phần của hệ thống SOA, mồi công ty khác nhau khi phát triển một hệ thống SOA có thể đưa ra mô hình các thành phần của SOA khác nhau, đây là mô hình các thành phần của hệ thống SOA theo quan điểm của công ty IBM và đây cũng là một mô hình khá phổ biến cho kiến trúc cùa hệ thống SOA. 1 [B u ild in g S O A -b a se d S o lu tio n s for IB M S y ste m i P latform ] 4 [h ttp ://w w w .ser v ice -a rc h ite c tu r e .c o m ] 17 H u sin ess services h x p lo il the S O A fo u n d a tio n ta d e live r a c o m p o rte n i b u s in e s s m o d e l Bus n e s s inn ovation & o p tim iza tio n s e rvices Provifle for better decision-m aking with real-tim e business Interaction services Vi X UfQb'e COỈÍQÙoîûtfon t'.eî'A'fî f?/i peopfe a; Ẹ *-> ựi Ui ■n Œ c ai ị re u — ttî E n terprise s ervice bus Enable inter-conneclivỉty betw een services ° a r r e r s e 'V ices CỉMnect with tỉrìrtm <7 partners B u sin ess application s e rvices Biiiỉơ Of? (i robu st A c c e s s s e 'Vi ces lí> u l 0 Ư) T' c Tỉ ) . Cl aj Facibt&iv mtuructiofis v*ầttt: existing information -3/10 upphcutiotf assets scafabie. and secure set Vices títỉv/ĩotỉ(ĨW Ỉ \ĩ infrastru ctu re s e rvices O ptim ize throughput, availability and utilization r y r Hình 1.4: Mô hình logic các thành phân của hệ thông SOA Trong đó: Enterprise Service Bus (ESB): Là thành phần cơ bản của SOA cung cấp khà năng kết nối cần thiết cho những dịch vụ trong toàn bộ hệ thống, bao gồm cả dịch vụ liên quan tới thực hiện giao vận (transport), quản lý tình huống (event) và điều phối (mediation). ESB cho phép nhà phát triển tận dụng giá trị của phương thức giao tiếp qua gửi nhận thcng điệp mà không phải thực hiện viết những đoạn mã chuyên biệt. Dịch vụ tương tác (interaction services) có trách nhiệm trình bày các mô hình nghiệp vụ Nói cách khác, đây là những thành phần giúp các ứng dụng và người dùng cuối giao tiếp với nhau, ở đây người dùng cuối (enduser) không chỉ là con người, mà cũng có thể là cảm biến, robot,... Dịch vụ quy trình (Process services) chịu trách nhiệm cho logic thành phần. Thành phin là tập hợp các dịch vụ mà được tạo một luồng tiến trình nghiệp vụ. Và các dịch vụ quy trình tạo ra các cơ chế thành phần. Dịch vụ thông tin (Information services) chịu trách nhiệm về tính logic của dừ liệu, dịch vụ này cung cấp các chức năng tập hợp, thay thế và chuyển đổi nhiều nguồn dừ liệi khác nhau được thực hiện bởi nhiều cách thức khác nhau. Những dịch vụ này có mệt ở hai cấp độ: cấp độ bên ngoài đảm bảo việc cung cấp truy cập vào các dừ liệu cùa doinh nghiệp và cấp độ bên trong đảm bảo luồng dữ liệu trong tổ chức. ĐAI HỌC QUỐC GIA HẢ NỘI ■TRUNG TẤM THÔNG ỈIN THƯ VIẺ N I o o o ap o o o w - 18 Dịch vụ đôi tác (Partner services) có trách nhiệm thu thập thông tin về đối tác (ví dụ như các chính sách và hạn chế) và cung cấp tài liệu, giao thức, các chức năng quản lý đối tác cho những quy trình nghiệp vụ có yêu cầu tương tác với đối tác bên ngoài và nhà cung cấp. Dịch vụ ứng dụng nghiệp vụ (Business application services) chịu trách nhiệm về logic nghiệp vụ cốt lõi. Đây là những dịch vụ được tạo ra đặc biệt để thực hiện các mô hình nghiệp vụ. Chúng đại diện cho các khối xây dựng cơ bản cho việc thiết kế quy trình nghiệp vụ . Những dịch vụ này không thể bị phân hủy, thay vì kết nối với các dịch vụ khác để tạo thành một quy trình nghiệp vụ. Dịch vụ truy cập (Access services) có trách nhiệm để kết nối các ứng dụng và chức năng vào kiến trúc hướng dịch vụ. Cung cấp các chức năng bắc cầu cho những ứng dụng cũ (legacy applications), kho dừ liệu chính, và ESB nhằm kết họp dịch vụ có trong những ứng dụng hiện tại vào hệ thống SOA. Dịch vụ đoi mới và tối ưu hóa nghiệp vụ (Business innovation and optimization services) có trách nhiệm cung cấp các công cụ và các cấu trúc siêu dữ liệu đê đại diện cho thiết kế nghiệp vụ, bao gồm cả chính sách và mục tiêu nghiệp vụ. Dịch vụ phát triển (Development services) cung cấp môi trường tích hợp cho thiết kế và tạo ra giải pháp. Dịch vụ cơ sở hạ tầng (Infrastructure services) Những dịch vụ này có trách nhiệm để lưu trữ các ứng dụng SOA và giúp cung cấp sử dụng hiệu quả các nguồn tài nguyên đế tối ưu băng thông, sẵn sàng và hiệu năng. Đây chỉ là một tổng quan về các thành phần chính của mô hình SOA. Như đã đề cập, các công ty khác nhau cung cấp cách nhìn khác nhau trên cùng một vấn đề. Tuy nhiên, các nguyên tắc chính vẫn như cũ. SOA là một kiến trúc đó là dựa trên dịch vụ, đóng gói, tái sử dụng và khớp nối lỏng lẻo. Đây là dịch vụ tạo ra giá trị kinh doanh, hỗ trợ tin học và thế giới nghiệp vụ để giao tiếp một cách thích hợp. Dịch vụ có thế được truy cập và sử dụng từ bên trong tổ chức với sự giúp đỡ của dịch vụ ESB. 61.3 Các nguyên tắc thiết kế hệ thống SOA 1.3.1 Khớp nối lỏng lẻo dịch vụ (Service Loose Coupling) Coupling đề cập đển một kết nối hay mối quan hệ giữa hai thành phần. Một biện pháp của các khớp nối có thể so sánh được với một mức độ phụ thuộc. Nguyên tắc này ủng hộ việc tạo ra một loại hình cụ thể của mối quan hệ bên trong và bên ngoài địa giới dịch vụ, với sự nhấn mạnh liên tục giảm sự phụ thuộc giữa các hợp đồng dịch vụ, sự thi hành, và người tiêu dùng dịch vụ của nó. Nguyên tắc của dịch vụ “Loose coupling” thúc đẩy thiết kế và đánh giá độc lập logic của một dịch vụ và thực hiện trong khi vẫn đảm bảo khả năng tương tác với người tiêu dùng. Có rất nhiều loại cua các khớp nối có liên quan đến trong thiết kế của một dịch vụ, mỗi trong số đó có thể ảnh hưởng đến nội dung và chi tiết các hợp đồng của nó. Để đạt được mức độ thích 6 [SOA Principles o f Service D esign] 19 hợp của các khớp nối yêu cầu xem xét thực tế được cân đối với các ưu đãi dịch vụ thiết kế khác nhau. 1.3.2 Sự trừu tượng hóa dịch vụ (Service Abstraction) Các hợp đồng dịch vụ chỉ chứa đựng thông tin cần thiết và các thông tin về dịch vụ được giới hạn bởi những gì đã được công bố trong các hợp đồng dịch vụ. Mối quan hệ trừu tượng vào nhiều khía cạnh của định hướng dịch vụ. Ở mức độ cơ bản, nguyên tắc này nhấn mạnh sự cần thiết phải ẩn càng nhiều các chi tiết cơ bản của một dịch vụ càng tốt. Làm như vậy trực tiếp cho phép và duy trì mối quan hệ “loose coupling” như phần mô tá trước. Sự trừu tượng hóa dịch vụ cũng đóng một vai trò quan trọng trong việc định vị và thiết kế các thành phần dịch vụ, các hình thức khác nhau của siêu dừ liệu vào hình ảnh khi đánh giá mức độ trừu tượng thích hợp. Mức độ trừu tưọng áp dụng có thể ảnh hưởng đến tính granularity của hợp đồng dịch vụ và tiếp tục có thê ảnh hưởng đến chi phí và nỗ lực cuối cùng của quản lý dịch vụ. 1.3.3 Tái sử dụng dịch vụ (Service Reusability) Tái sử dụng dịch vụ là nhấn mạnh trong định hướng dịch vụ, vì thế nó sẽ trở thành một phần cốt lõi của phân tích dịch vụ, các quá trình thiết kể, và cũng tạo cơ sở CỈ10 các mô hình dịch vụ quan trọng. Sự tiến triển của công nghệ dịch vụ đã cung cấp co hội đế tối đa hóa tiềm năng tái sử dụng dịch vụ đa mục đích trên một mức độ chưa từng có. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lặp và tăng tốc độ vững chắc trong cài đặt, nó còn giúp đơn giản hóa việc quản trị. 1.3.4 Khả năng tự phục hồi (Self-healing) Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ thống tự hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con người. Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nào trong tình trạng hỗn loạn. Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tồng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi. Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên để xây dựng ứng dụng. Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên. Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu sự tách biệt giữa giao diện (interface) và cài đặt nèn có thể có nhiều cài đặt khác nhau cho cùng một giao diện. Nếu một thể hiện dịch vụ nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì. Khả năng này chỉ có được khi khách hàng chí tương tác với giao diện (interface) của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ. Đây là một trong những tính chất cơ bản của các hệ thống hướng dịch vụ. 20 1.3.5 S ự tự trị của dịch vụ (Service Autonomy) Đối với dịch vụ để thực hiện khả năng của mình một cách nhất quán và đáng tin cậy, giải pháp logic cơ bản để có một mức độ đáng kê của việc kiểm soát môi trường và tài nguyên của nó. Nguyên tắc tự trị dịch vụ hồ trợ khi mà các nguyên tắc thiết kế khác có hiệu quả thực hiện trong môi trường sản xuất thực, bằng cách bố sung các đặc điểm thiết kế làm tăng độ tin cậy của dịch vụ và khả năng dự đoán hành vi. Nguyên tấc nàv đặt ra các vấn đề khác nhau mà liên quan đến các thiết kế logic dịch vụ cùng như môi trường thực hiện thực tế của dịch vụ. Mức cô lập và xem xét bình thường hóa dịch vụ được đưa vào để đạt được một biện pháp phù hợp với quyền tự trị, đặc biệt cho các dịch vụ tái sử dụng thường xuyên chia sẻ. 1.3.6 Giảm thiểu tiêu thụ tài nguyên dịch vụ (Service Statelessness) Dịch vụ giảm thiểu tiêu thụ tài nguyên bằng cách trì hoãn việc quản lý thông tin trạng thái khi cần thiết. Việc quản lý thông tin trạng thái quá mức có thể làm suy yếu khả năng mở rộng của nó. Dịch vụ lý tưởng thiết kế để duy trì trạng thái khi có yêu cầu. 1.3.7 Khả năng dò tìm dịch vụ (Service Discoverability) Khi một client cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chí. Client chỉ cần hỏi một đăng ký (registry) về một dịch vụ nào thởa yêu càu tìm kiếm rồi trả về cho client một dịch vụ thích hợp. 1.3.8 Khả năng tổng hợp (Composite) Chức năng phần mềm có thể được đóng gói như là các dịch vụ có mức độ trừu tượng khác nhau trong một nghiệp vụ. Các dịch vụ có thể được tống hợp đê cài đặt các dịch vụ có mức độ trừu tượng cao hơn. Ví dụ, việc tổng hợp một quy trình nghiệp vụ từ các dịch vụ, sau đó quy trình được kết xuất như là một dịch vụ. Khả năng tổng hợp của dịch vụ liên quan tới cấu trúc đặc tả của dịch vụ. c ấ u trúc đặc tả cho phép các dịch vụ có khả năng tổng họp, lắp ráp vào các ứng dụng mà lập trình viên tích hợp không quan tâm đến dịch vụ đó được thiết kế như thế nào. Bằng việc sử dụng các dịch vụ đã được kiểm thử và xây dựng hoàn chỉnh làm gia tăng chất lượng của hệ thống phần mềm. Xây dựng các hệ thống theo kiến trúc hướng dịch vụ là đầu tư cho hiện tại và cả tương lai. Vì các dịch vụ dễ dàng dùng lại, dễ dàng tổng họp vào các ứng dụng khác. Với khả năng tổng hợp của dịch vụ làm cho hệ thống phần mềm có thế thích ứng nhanh chóng với các thay đổi, dễ dàng cải tiến, tái cấu trúc hệ thống phần mềm và thêm mới các chức năng cho nó một cách nhanh nhất có thể có. Một dịch vụ có thê được tổng hợp theo 3 cách: ứng dụng tổng hợp, các dịch vụ liên quan, dịch vụ tống hợp. Một ứng dụng thường là sự lắp ráp, tổng hợp từ các dịch vụ, các thành phần với nhau cho một mục đích xác định. Dịch vụ liên quan là tập các dịch vụ được quan lý trong một dịch vụ lớn hơn. Ví dụ, dịch vụ kiểm tra tài khoản, dịch vụ đăng kí tài khoản, dịch vụ quản lý thông tin khách hàng. Có thể được tổng hợp vào dịch vụ lớn là dịch vụ khách hàng. Dịch vụ tổng họp là dịch vụ thực thi một nghiệp vụ, tương tác với 21 nhiều dịch vụ hệ thống để tạo ra bản thân nó, thường được gọi là quy trình nghiệp vụ. Quy trình nghiệp vụ gồm một hay nhiều bước thực hiện, mỗi bước thực hiện là một tác vụ nghiệp vụ, mỗi tác vụ nghiệp vụ thực hiện gọi dịch vụ đế hoàn thành tác vụ. 71.4 Các đặc điểm của SOA 1.4.1 Hướng nghiệp vụ (Business-Driven) Kiến trúc công nghệ phù hợp với kiến trúc nghiệp vụ hiện tại. Bối cảnh này sau đó được duy trì liên tục để các kiến trúc công nghệ phát triển song song với nghiệp vụ theo thời gian. 1.4.2 Trung lập nhà cung cấp (Vendor-Neutral) Mô hình kiến trúc không chỉ dựa vào một nền tảng nhất định, cho phép các công nghệ của các nhà cung cấp khác nhau được kết họp hoặc thay thế theo thời gian đê tối đa hóa các yêu cầu nghiệp vụ. 1.4.3 Trung tâm doanh nghiệp (Enterprise-Centric) Phạm vi của kiến trúc đại diện cho một phân đoạn có ý nghĩa của doanh nghiệp, cho phép tái sử dụng và tống hợp các dịch vụ, đồng thời cho phép các giải pháp hướng dịch vụ để mở rộng ứng dụng truyền thống. 1.4.4 Trung tâm tổng hợp (Composition-Centric) Kiến trúc vốn đã hỗ trợ khả năng của việc lặp lại sự tổng hợp dịch vụ, cho phép nó đế thích ứng với thay đổi liên tục thông qua khả năng nhanh chóng lắp ráp các thành phần dịch vụ. 1.5 Quy trình xây dựng một hệ thống SOA Xây dựng một hệ thống SOA trải qua các bước như hình sau: i 1f Service-or »entod analysis Service development Service deployment 1r 1f 1Ỉ Service oriented design Service testing Service administration i 1 8Hình 1.5: Các bước xảy dựng một hệ thống SOA Bưóc 1: Service-oriented analysis (Phân tích hướng dịch vụ) 7 [S O A D esig n Patterns] 8 [S ervice-O rien ted A rchitecture: C o n cep ts, T e c h n o lo g y , and D esig n ] 22 Đây là pha đầu tiên trong tiến trình xây dựng hệ thống SOA. Pha này có nhiệm vụ xác định rõ các yêu cầu nghiệp vụ của một hệ thống SOA đồng thời nó quyết định phạm vi của hệ thống SOA. Các mục tiêu tổng thể thực hiện một phân tích hướng dịch vụ như sau: - Xác định một tập hợp sơ bộ của các dịch vụ trong hệ thống. - Xác định miền dịch vụ: + Làm sao gom nhóm các dịch vụ thành các miền luận lý (logic domain). + Việc phân loại gom nhóm các dịch vụ thành các miền luận lý sẽ đơn giản hóa kiến trúc bơi sẽ giảm được sổ lượng các thành phần cần xây dựng.Việc định nghĩa các miền như thế cũng ảnh hưởng đến nhiều khía cạnh khác của kiến trúc hệ thống như cân bằng tải, điều khiến truy cập, sự phân chia theo chiều sâu hay chiều rộng cua xử lý nuhiệp vụ. - Xác định ranh giới dịch vụ sơ bộ để chúng không trùng với bất kỳ dịch vụ hiện cỏ hoặc dự kiến. - Xác định logic đóng gói với tiềm năng tái sử dụng. - Đảm bảo rằng bối cảnh của logic đóng gói phù họp cho mục đích sử dụng của nó. - Xác định bất kỳ mô hình thành phần ban đầu được biết đến. Bưó'c 2: Service-oriented design (Thiết kế hướng dịch vụ) Thiết kế theo định hướng dịch vụ là một quá trình cụ thể thiết kế dịch vụ vật lý được dẫn xuất từ các ứng viên dịch vụ hợp lý và sau đó lắp ráp thành các thành phần trừu tượng mà thực hiện một quy trình nghiệp vụ. Các cáu hỏi chính đã được trả lời trong pha này là: - Làm thế nào đế xác định giao diện dịch vụ vật lý có thể được bắt nguồn từ các ứng viên dịch vụ theo mô hình trong giai đoạn phân tích hướng dịch vụ? - Những đặc điểm gì của SOA mà ta muốn nhận ra và hỗ trợ? - Chuẩn công nghiệp gì và phần mở rộng sẽ được yêu cầu bởi SOA để thực hiện thiết kế các dịch vụ và các đặc tính của SOA? Các mục tiêu trong giai đoạn này là: - Xác định các thiết lập cốt lõi của phần kiến trúc mở rộng. - Thiết lập ranh giới của kiến trúc. - Xác định các chuẩn thiết kế yêu cầu. - Xác định giao diện dịch vụ trừu tượng. - Xác định các thành phần dịch vụ tiềm năng. - Đánh giá hồ trợ cho các nguyên tắc hướng dịch vụ. - Khám phá hỗ trợ cho các đặc điểm của SOA hiện tại. Bưóc 3: Service development (Phát triển dịch vụ) Giai đoạn này bao gồm việc lựa chọn ngôn ngừ lập trình và môi trường phát triên các thành phần dịch vụ trong hệ thống SOA, đây là bước xây dựng thực tế hệ thống SOA dựa trên việc phân tích và thiết kế yêu cầu như ở trên.