Dịch vụ web và kiến trúc hướng dịch vụ

1 CHƢƠNG 1: TỔNG QUAN  Tóm tắt:  Nội dung phần Tổng Quan trình bày về dịch vụ web và kiến trúc hướng dịch vụ, nhu cầu tìm kiếm dịch vụ web và tìm kiếm dịch vụ web dựa trên ngữ nghĩa, tiếp theo đó là lý do thực hiện và mục tiêu của luận văn. Nội dung tóm tắt của từng chương trong luận văn được trình bày ở cuối phần này. 1.1 Dịch vụ web và kiến trúc hƣớng dịch vụ Dịch vụ web (Web Servive) là các ứng dụng có khả năng giao tiếp với các ứng dụng khác thông qua môi trƣờng mạng dựa trên việc sử dụng tập các giao thức chuẩn hóa. Dịch vụ web đƣợc sử dụng có ƣu điểm là bản thân nó cung cấp các chức năng cho ngƣời ta dùng thông qua việc khai báo giao diện một cách rõ ràng và che giấu nội dung cài đặt bên dƣới, ngƣời sử dụng chỉ quan tâm đến giao diện và cách thức tƣơng tác với dịch vụ, không cần quan tâm đến nội dung cài đặt bên dƣới bằng ngôn ngữ, công nghệ hay đƣợc triển khai trên môi trƣờng nào. Các dịch vụ web có thể đƣợc sử dụng từ các dịch vụ web khác hoặc từ các ứng dụng khách. Dịch vụ web cung cấp một chuẩn tƣơng hợp cho phép các ứng dụng phần mềm khác nhau có khả năng tƣơng tác với nhau khi chạy trên cùng hoặc các nền tảng khác nhau [25]. Dịch vụ web ngày càng phổ biến, đa dạng, đƣợc sử dụng rộng rãi và số lƣợng dịch vụ không ngừng tăng theo thời gian. Theo thống kê của Seekda [1] cho đến tháng 03 năm 2010 có đến 28.529 dịch vụ web thực đƣợc triển khai từ 7689 nhà cung cấp dịch vụ trên nhiều quốc gia trên thế giới đƣợc minh họa trong Hình 1.1. Các dịch vụ web Seekda tìm thấy là các dịch vụ web thực thi đƣợc, chƣa tính đến các dịch vụ web đƣợc triển khai nội bộ trong các doanh nghiệp hoặc các dịch vụ web khác không công bố. Dịch vụ web giúp cho việc tƣơng tác và tích hợp giữa các 2 hệ thống, ứng dụng khác nhau trở nên dễ dàng hơn thông qua việc sử dụng các chuẩn mở nhƣ WSDL [28], UDDI [3], SOAP [26][27]. Hình 1.1 Số lƣợng dịch vụ web và các nhà cung cấp dịch vụ web [1] Các dịch vụ web không chỉ sử dụng đơn lẻ mà còn đƣợc sử dụng trong các hệ thống theo kiến trúc hƣớng dịch vụ (SOA – Service Oriented Architecture). Kiến trúc hƣớng dịch vụ là một hƣớng tiếp cận cho việc xây dựng các hệ thống phân tán và hoàn thành sự tích hợp hệ thống bằng việc phân phối chức năng ứng dụng nhƣ là các dịch vụ đến các ứng dụng ngƣời dùng cuối và đƣợc sử dụng cho việc xây dựng các dịch vụ khác. Kiến trúc hƣớng dịch vụ đƣa ra một kiến trúc dựa trên các chuẩn mở để phân phối các tài nguyên phần mềm nhƣ là các dịch vụ, cung cấp một phƣơng pháp chuẩn cho việc phân phối và tƣơng tác với các tài nguyên phần mềm. Các tài nguyên trên một mạng trong môi trƣờng kiến trúc hƣớng dịch vụ có giá trị nhƣ là các dịch vụ độc lập có thể đƣợc truy xuất không cần biết cài đặt chi tiết bên dƣới. Kiến trúc hƣớng dịch vụ cho phép các tài nguyên phần mềm độc lập trở thành các khối xây dựng sẵn để có thể đƣợc tái sử dụng trong việc phát triển các ứng dụng khác. Với kiến trúc hƣớng dịch giúp tập trung vào việc tổng hợp ứng dụng hơn là việc cài đặt chi tiết. Kiến trúc hƣớng dịch vụ đƣợc sử dụng để tạo ra các ứng dụng mới từ các thành phần sẳn có bên trong hệ thống mặt khác nó còn có thể đƣợc sử dụng để tích hợp với các ứng dụng bên ngoài hệ thống, một hƣớng tiếp cận nhằm xây dựng các ứng dụng phân tán thông qua việc tổng hợp các dịch vụ. Kiến trúc hƣớng dịch vụ ra đời với mục tiêu chính là tổng hợp ứng dụng hơn là xây dựng ứng dụng chi tiết, trong đó các 3 dịch vụ mới đƣợc tạo ra bằng cách tổng hợp từ các dịch vụ có sẵn theo một quy trình nghiệp vụ. Dịch vụ mới đƣợc tạo ra trong kiến trúc hƣớng dịch vụ giúp dễ dàng tái cấu trúc lại quy trình nghiệp vụ, cũng nhƣ thay thế các dịch vụ đang đƣợc sử dụng trong quy trình . Hình 1.2 Kiến trúc hƣớng dịch vụ trên nền IBM Kiến trúc hƣớng dịch vụ ngày càng đƣợc sử dụng phổ biến và ngày càng phát triển; nhiều công cụ hỗ trợ phát triển ứng dụng theo kiến trúc hƣớng dịch vụ đƣợc giới công nghiệp hỗ trợ, ví dụ nhƣ IBM với các công cụ hỗ trợ từng giai đoạn từ việc mô hình hóa, tổng hợp, triển khai cho đến cả các công cụ quản lý nhƣ trong pha mô hình hóa (Model) ở bƣớc 1các yêu cầu đƣợc thu thập và lƣu trữ bằng công cụ IBM Rational RequisitePro, kế đến các quy trình nghiệp vụ đƣợc mô hình hóa bằng công cụ IBM Websphere Business Modeler, sau đó đặc tả và thiết kế dịch vụ bằng công cụ IBM Rational Software Architect và kết quả từ việc mô hình ở pha mô hình hóa cũng là đầu vào cho công cụ Websphere Business Monitor để xác định và theo dõi, đo lƣờng tính hiệu quả của các nghiệp vụ. 4 Hình 1.3 Kiến trúc hƣớng dịch vụ trên nền Microsoft Trong pha tổng hợp (Assemble), sau khi các dịch vụ đã đƣợc thiết kế bằng IBM Rational Software Architect đƣợc thực hiện, sau đó sẽ lập trình bằng công cụ IBM Rational Application Developer, kết quả từ việc mô hình ở pha mô hình hóa sẽ là các quy trình BPEL [30] làm đầu vào cho IBM Websphere Integration Developer, Các dịch vụ đƣợc triển khai sẽ đƣợc sử dụng trong lúc cài đặt các quy trình nghiệp vụ trong IBM Websphere Integration Developer. Trong pha triển khai (Deploy) Các dịch vụ và các thành phần J2EE đã thực thi sẽ đƣợc triển khai vào Websphere Application Server còn các quy trình nghiệp vụ đƣợc pha trộn, tích hợp trong Websphere Integration Developer sẽ đƣợc triển khai vào Websphere Process Server. Process Server sử dụng Websphere ESB để sắp xếp và định vị các dịch vụ. Trong pha quản lý (Manage) các quy trình nghiệp vụ đƣợc quản lí và kiểm soát bằng công cụ Websphere Business Monitor, sau đó các dịch vụ đƣợc kiểm soát và quản lí bằng công cụ ITCAM For SOA , còn độ an tòan bảo mật của các dịch vụ đƣợc quản lí bằng công cụ Tivoli Federated Identity Manager, sau đó các giao tác với nhau thông qua IT Stack sử dụng ITCAM For Response Time Tracking, Sau đó dữ liệu thật từ IBM WebSphere Business Monitor lại dùng để mô phỏng và tối ƣu hóa các quy trình trong IBM WebSphere Business Modeler, bắt đầu một pha mô hình hóa 5 mới trong chu kỳ sống. Kiến trúc hƣớng dịch vụ trên nền IBM đƣợc minh họa cụ thể trong Hình 1.2. Microsoft cũng hỗ trợ công cụ nhƣ Visual Studio, Biztalk Server, … để xây dựng phần mềm theo kiến trúc hƣớng dịch vụ, đáng lƣu ý ở đây là Microsoft hỗ trợ xây dựng dịch vụ tổng hợp là WF và server để thực thi là Biztalk Server. Kiến trúc hƣớng dịch vụ trên nền Microsoft đƣợc minh họa cụ thể trong Hình 1.3. Hình 1.4 Sự phối hợp hoạt động khi sử dụng dịch vụ web 1.2 Tìm kiếm dịch vụ web Sự phối hợp hoạt động khi sử dụng dịch vụ web là mô hình tìm kiếm, nối kết và gọi thực hiện dịch vụ đƣợc minh họa trong Hình 1.4. Ngƣời dùng dịch vụ (Service Requestor) định vị trí dịch vụ động bằng cách truy vấn đến nơi đăng ký dịch vụ tìm kiếm một dịch vụ khớp với yêu cầu của nó. Nếu dịch vụ tồn tại, nơi đăng 6 ký dịch vụ sẽ cung cấp cho ngƣời dùng dịch vụ hợp đồng dịch vụ và địa chỉ điểm cuối của dịch vụ cung cấp. Trong đó Công bố(Publish): Nhà cung cấp dịch vụ (Service Provider) công bố bản đặc tả dịch vụ WSDL của mình lên nơi đăng ký dịch vụ, khi đó ngƣời dùng dịch vụ có thể tìm kiếm và gọi thực hiện dịch vụ thông qua bản đặc tả này. Tìm kiếm (Inquiry): Ngƣời dùng dịch vụ định vị trí một dịch vụ bằng cách truy vấn đến nơi đăng ký dịch vụ (Service Registry) yêu cầu cung cấp một dịch vụ theo tiêu chuẩn của nó. Nối kết và gọi thực hiện: Sau khi có đƣợc bản đặc tả dịch vụ, ngƣời dùng dịch vụ tiến hành gọi thực hiện dịch vụ theo thông tin trong bản đặc tả dịch vụ. UDDI (Universal Description, Discovery and Integration) [3] là một trong những công nghệ cốt lõi của dịch vụ web, UDDI là nơi đăng ký dịch vụ web, cho phép nhà cung cấp dịch vụ đăng ký (publish) các dịch vụ của mình và hỗ trợ ngƣời dùng dịch vụ tìm kiếm dịch vụ (Inquiry) đang có trên hệ thống. UDDI hiện tại đƣợc nhiều công ty phần mềm cài đặt và triển khai nhƣ: IBM WebSphere UDDI Registry, Oracle Service Registry, SAP Enterprise Services Registry, Microsoft Windows Server 2003 Enterprise UDDI Services, ... UDDI hỗ trợ tìm kiếm dịch vụ dựa trên các input, output của dịch vụ; hoặc tìm kiếm dựa trên các thông tin nhƣ danh mục dịch vụ (service category), chất lƣợng dịch vụ (QoS); hoặc tìm kiếm dịch vụ dựa trên tên dịch vụ(service name), mô tả dịch vụ (text description), danh thông tin về nhà cung cấp dịch vụ,… theo các từ khóa (keyword) tìm thấy. UDDI chỉ hỗ trợ so khớp từ khóa, UDDI không có khả suy diễn, hiểu các từ đồng nghĩa, … Do vậy kết quả tìm kiếm đƣợc này phải nhờ vào quyết định của con ngƣời khi chọn dịch vụ web cần sử dụng. Máy có thể xử lý đƣợc nhƣng máy vẫn chƣa có khả năng hiểu và xử lý dịch vụ trả về có thật sự đúng với yêu cầu của ngƣời dùng dịch vụ. Vấn đề ở đây là các đặc tả dịch vụ WSDL giúp máy có khả năng xử lý đƣợc, nhƣng vẫn thiếu ngữ nghĩa cho máy có khả năng hiểu đƣợc với khả năng suy diễn và 7 xử lý tự động. Do đó các UDDI không thể có khả năng hỗ trợ tìm kiếm dịch vụ một cách tự động cũng nhƣ máy tính không có khả năng tìm kiếm, tổng hợp và gọi dịch vụ một cách tự động. 1.3 Tìm kiếm dịch vụ web dựa trên ngữ nghĩa Năm 2001, Tim Berners-Lee cùng với nhóm tác giả công bố công trình về web ngữ nghĩa [20]. Nhóm tác giả mở rộng khả năng con ngƣời có thể đọc và hiểu các thông tin web sang máy có khả năng hiểu và vận dụng nó một cách có ý nghĩa. Nhóm tác giả đã đƣa ra vài ứng dụng minh họa cho việc sử dụng công nghệ này. Một ứng dụng cơ bản đó là ứng dụng trong lĩnh vực tìm kiếm thông tin, giúp máy có khả năng phân biệt các ngữ nghĩa. Các ứng dụng nâng cao khác bao gồm các software agent có khả năng thực hiện các công việc cho sẵn phụ thuộc vào lúc thực thi, khi đó các agent tự động tìm ra các dịch vụ đáp ứng đƣợc công việc này một cách tự động, agent biết bằng cách nào để phát hiện, chọn đúng và thực thi dịch vụ và trả kết quả theo đúng yêu cầu của ngƣời dùng. Cũng dựa trên công trình này, Các nghiên cứu dịch vụ web ngữ nghĩa (Semantic Web Service) đã giải quyết đƣợc vấn đề này bằng cách thêm ngữ nghĩa vào bên trong thành phần của dịch vụ vì vậy không chỉ UDDI có khả năng hỗ trợ ngƣời dùng dịch vụ tìm kiếm dịch vụ tự động mà còn giúp cho việc sử dụng dịch vụ một cách tự động trong giai đoạn thiết kế cũng nhƣ giai đoạn thực thi của một quy trình nghiệp vụ bên trong kiến trúc hƣớng dịch vụ [4]. Dịch vụ web ngữ nghĩa = web ngữ nghĩa + Dịch vụ web. Nhƣ vậy, dịch vụ web ngữ nghĩa là phƣơng pháp ứng dụng web ngữ nghĩa vào trong dịch vụ web, nói cách khác dịch vụ web ngữ nghĩa là phƣơng pháp mở rộng dịch vụ web với cách biểu diễn ngữ nghĩa cho nó. Dịch vụ web ngữ nghĩa mở ra khả năng cho phép tìm kiếm, tổng hợp và gọi thực hiện dịch vụ web động trong lúc thực thi. 8 Ngôn ngữ biểu diễn ngữ nghĩa cho dịch vụ web đƣợc tổ chức W3C đệ trình đầu tiên vào tháng 11 năm 2004 là OWL-S [31]. Ngoài ra còn các ngôn ngữ biểu diễn ngữ nghĩa cho dịch vụ web ra đời sau cũng đƣợc tổ chức w3c đệ trình nhƣ là: WSMO [32], SAWSDL [33]. Trong đó WSMO đƣợc đệ trình vào 6/2006 và SAWSDL đƣợc đệ trình sau cùng vào 08/2007. Hình 1.5 Tập dữ liệu từ thế giới thực [19], [42] Trong các ngôn ngữ biểu diễn ngữ nghĩa cho dịch vụ web, OWL-S là ngôn ngữ ra đời đầu tiên và cũng là ngôn ngữ có nhiều dịch vụ đƣợc ứng dụng rộng rãi , theo số liệu [18], [42] (đƣợc minh họa Hình 1.5) có khoảng 1% dịch vụ web đƣơc chú giải ngữ nghĩa, trong đó OWL-S chiếm 65%, do đó trong đề tại này chúng tôi sẽ tập trung vào việc phân tích, đánh giá trên ngôn ngữ OWL-S . Quá trình tìm kiếm dịch vụ web dựa trên các ngữ nghĩa về các thành phần chức năng và phi chức năng của dịch vụ. Nhiều công trình đƣợc đề xuất nhằm đáp ứng nhu cầu tìm kiếm dịch vụ động. Nhiều công trình tìm kiếm dịch vụ có hỗ trợ ngữ nghĩa bao gồm dựa trên input (I) và output(O) nhƣ OWLS-UDDI [9], OWLSM [10], OWLS-MX[11] trong hệ thống CASCOM, SAWSDL-MX [12], tìm kiếm dựa trên Precondition (P) và 9 Effect (E): PCEM [8] trong hệ thống CASCOM, tìm kiếm dựa trên IOPE nhƣ GLUE [13], RFSD [14]. Công trình tìm kiếm dịch vụ dựa trên vai trò (Role) ROWLS [15] trong hệ thống CASCOM. Tìm kiếm dựa vào toàn bộ thông tin mô tả của dịch vụ (profile) nhƣ FC-MATCH [16]. 1.4 Lý do thực hiện đề tài Việc nghiên cứu web ngữ nghĩa nói chung và dịch vụ web ngữ nghĩa nói riêng đã thu hút sự quan tâm của rất nhiều nhà khoa học trên thế giới. Điều đó đƣợc minh chứng thông qua việc những hội nghị quốc tế có uy tín liên tục đƣợc tổ chức với quy mô toàn thế giới cũng nhƣ ở khu vực ví dụ nhƣ hội nghị quốc tế ISWC (International Semantic Web Conference) đƣợc tổ chức từ năm 2002 đến 2010. Tiếp theo là hội nghị ở châu Âu ESWC (European Semantic Web Conference) đƣợc tổ chức từ năm 2004 đến năm 2010 và hội nghị ở châu Á là ASWC (Asian Semantic Web Conference) đƣợc tổ chức từ năm 2006 đến 2010. Một dịch vụ OWL-S bao gồm 3 phần: Thứ nhất là ServiceProfile phục vụ cho việc quảng cáo và phát hiện dịch vụ; Thứ hai là ServiceModel chịu trách nhiệm mô tả hoạt động của dịch vụ và thứ ba là ServiceGrounding chịu trách nhiệm cung cấp cách tƣơng tác với dịch vụ. Service Profile đƣợc thiết kế để mô tả dịch vụ làm gì thông qua các Input, Output, Precondition và Postcondition. Michael C. Jaeger nhận định rằng các Precondition và Postcondition vẫn chƣa đủ chuẩn hóa để phục vụ cho thuật toán so khớp dịch vụ [10]. Chúng tôi khảo sát cho đến thời điểm hiện tại là tập dữ liệu dịch vụ OWL-S đƣợc công bố vào 06/04/2005 và liên tục đƣợc phát triển đến 11/11/2009 bởi nhóm nghiên cứu Matthias Klusch [18] và đƣợc phát triển tiếp bởi cộng đồng S3Contest [21], chúng tôi thấy rằng Precondion và Postcondition vẫn chƣa đƣợc thêm vào. Do đó khi nhiều Service Profile cùng các Input và các ouput có thể có những công dụng khác nhau. 10 David Martin nhận định rằng việc chú giải ngữ nghĩa cho phƣơng thức bằng một cách nào đó sẽ hữu dụng trong một số tình huống đặc biệt là trong quá trình tìm kiếm [17]. Thông qua các Input, Output, Preconditon và Postcondition của Service Profile cung cấp một cách để xác định ngữ nghĩa của phƣơng thức. Chúng tôi thấy rằng việc chú giải ngữ nghĩa cho phƣơng thức thông qua các công dụng dịch vụ cung cấp có thể đƣợc sử dụng cho việc phát hiện các dịch vụ đáp ứng đƣợc nhu cầu của ngƣời dùng tƣơng ứng với chức năng họ cần thật sự, nhƣ vậy các chú giải công dụng của dịch vụ có thể đƣợc phục vụ cho việc quyết định lựa chọn các dịch vụ có công dụng tƣơng ứng trong quá trình tổng hợp dịch vụ động. Thêm vào đó việc tìm kiếm dịch vụ dựa vào các công dụng có thể đƣợc sử dụng nhƣ một bƣớc tiền xử lý cho các thuật toán tìm kiếm dịch vụ dựa trên các Input, Output cũng nhƣ các thành phần còn lại của dịch vụ, điều đó sẽ giảm bớt đáng kể số lƣợng dịch vụ có các Input và Output và các thành phần còn lại phải so khớp. 1.5 Mục tiêu đề tài - Khảo sát, phân tích, đánh giá các hƣớng tiếp cận biểu diễn ngữ nghĩa cho dịch vụ web, từ đó đề xuất bổ sung các công dụng cho OWLS Profile. - Khảo sát, phân tích, đánh giá một số hƣớng tiếp cận liên quan đến tìm kiếm dịch vụ web, từ đó đề xuất phƣơng pháp tìm kiếm dịch vụ web dựa trên công dụng kết hợp với phƣơng pháp tìm kiếm dựa trên Input và Output đã có. - Xây dựng thử nghiệm hệ thống cho phép chú giải, đăng ký và tìm kiếm dịch vụ OWL-S dựa trên các công dụng kết hợp với các Input và Output 11 1.6 Nội dung đề tài Chƣơng 1 trình bày về dịch vụ web và kiến trúc hƣớng dịch vụ, nhu cầu tìm kiếm dịch vụ web và tìm kiếm dịch vụ web dựa trên ngữ nghĩa, tiếp theo lý do thực hiện và mục tiêu của luận văn. Chƣơng 2 trình bày sơ lƣợc về định nghĩa, cấu trúc, sự phối hợp hoạt động khi sử dụng dịch vụ web, các công nghệ cốt lõi của dịch vụ web. Các hạn chế khi sử dụng dịch vụ web đƣợc trình bày cuối chƣơng này. Chƣơng 3 trình bày sơ lƣợc về web nghĩa, các phƣơng pháp biểu diễn ngữ nghĩa của dịch vụ web. Tiếp theo là trình bày về một số hƣớng nghiên cứu chính trong lĩnh vực dịch vụ web ngữ nghĩa . Phƣơng pháp tìm kiếm dịch vụ web dựa trên công dụng sẽ đƣợc trình bày vào cuối chƣơng này. Chƣơng 4 trình bày phƣơng pháp do chúng tôi đề xuất nhằm mở rộng OWL-S Profile dựa trên các công dụng, sự lựa chọn Ontology để chú giải công dụng của OWL-S Profile, ánh xạ OWL-S Profile dựa trên công dụng vào UDDI. So sánh phƣơng pháp chú giải công dụng cho OWL-s Profile với một số phƣơng pháp chú giải ngữ nghĩa cho phƣơng thức web sẽ đƣợc trình bày trong cuối chƣơng này. Chƣơng 5 trình bày về phƣơng pháp xác định mức độ phù hợp ngữ nghĩa giữa hai khái niệm trong Ontology và đề xuất các thuật toán xác định mức độ phù hợp dựa trên công dụng. Đề xuất hệ thống tìm kiếm dịch vụ web kết hợp công dụng và Input, Output sẽ đƣợc trình bày trong phần cuối chƣơng này. Chƣơng 6 trình bày về các hệ thống xây dựng thử nghiệm phục vụ sự phối hợp hoạt động của dịch vụ web. Nội dung đánh giá sẽ đƣợc trình bày trong phần cuối chƣơng này. Chƣơng 7 trình bày các kết quả đạt đƣợc và hƣớng phát triển.