d58f1e4f9b42f4cff1e3b323dce7575c.ppt
- Количество слайдов: 121
Semantic Web, XML Web Services, and Grid Computing Microsoft MVP 2 nd Devpia XML Sysop Samsung Software Membership 11 th Hanyang University HPC&OT Lab M. S. 3 rd
Seed Paper Turning Software into a Service Mark Turner et al. , published by IEEE Computer Society , Oct, 2003
Motivation Providing S/W Object Component Based S/W Service Delivery - Service based S/W Services UI Business Logic
Motivation (Cont’d)
Motivation (Cont’d) Semantic Web Services Semantic Grid Semantic Web Grid Computing Semantic for Grid Services
Agenda XML Web Services Semantic Web Services Grid Computing Turn into a Service
Part 1 XML Web Services
XML Web Services 1. Distributed Object History 2. Roles of XML-WS 3. XML Web Services History 4. XML-WS Architecture
1. 1 Distributed Object History DCE CORBA Sun-RPC COM+ XML Web Services
1. 2 Web Service란 무엇인가? . NET의 정의 (MSCEO 스티브 발머) 인터넷이 하나의 플랫폼으로 쓰이는 차세대를 지원하는 하나의 그룹이자 하나의 환경이고 하나의 프로그래밍 하부구조를 보여주는 것입니다.
웹 서비스의 첫번째 역할 Messaging의 통합 EAI Enterprise Application Integration XML Web Service는 종전의 이질적인 메세지 환경 (CORBA, COM+ , RMI 등)을 통합하는, 즉 Messaging들을 통합하는 역할을 한다.
웹서비스의 두번째 역할 인터넷을 가상의 OS로 만드는 역할. Microsoft Terra-Service Amazon Web Service
웹서비스의 세번째 역할 Ubiquitous Computing의 핵심 프로토콜
1. 3 XML Web Services 의 과거, 현재, 미래 1. XML Web Services History 2. 2. XML Web Services B 2 C Strategy 3. XML Web Services B 2 B Strategy 6. The Future of Web Service
XML Web Services History MS. NET – XML Web Services Concentrate Service Hail. Storm (MS, IBM, BEA) Passport SDK Sun. One – eb. XML P 2 P Service JXTA (Liberty Alliance) Sign. One MS Etc XML Web Services IBM Sybase Oracle SOAP Repository Biz. Talk, Web. Method
IPV 6 210. xxx. xxx. xxx 210. xxx
XInternet and IPV 6
B 2 C XML Web Services Devices Apps Services SOAP
B 2 B XML Web Service 다양한 생산자 Remote Object 신뢰할 수 있는 운송수단 SOAP 운송포장의 표준화 Using HTTP XML
B 2 B XML Web Services Strategy 다양한 생산자 IBM Remote Object MS 신뢰할 수 있는 운송수단 SOAP Repository Etc 운송포장의 표준화 Using HTTP XML Oracle SOAP Sybase Repository Biz. Talk, Web Method
The Future of XML Web Services The Base Step of Ubiquitous Computing Smart Client SOA (Service – Oriented Architecture) The Core Foe of Grid Computing Semantic Web Services (OWL-S) MS (XML Web Services) Etc XML Web Services IBM Sybase Oracle SOAP Repository Biz. Talk, Web. Method
XML-WS Architecture CORBA Architecture Web Services Architecture
CORBA Architecture
Web Service Architecture SOA (Service Oriented Architecture) SOAP (Simple Object Access Protocol) WSDL (Web Service Description Language) UDDI (Universal Description, Discovery, and Integration)
Service Oriented Architecture Web Service Broker Publish Find Internet Web Service Provider Web Service Consumer Bind
Simple Object Access Protocol SOAP Overview SOAP 메시지 구조. NET Framework에서 SOAP의 동작원리
SOAP Overview Simple Object Access Protocol 1. New Service Tier in Network Model – 모든 Application Protocol을 사용가능 - 새로운 Service Layer의 탄생 2. Beyond on Security - SOAP은 80번 포트를 사용하므로 방화벽에 제한을 받지 않는다.
Overview of SOAP 3. Base Request (Loosely Coupled) - Request / Response Model - 기본적으로 HTTP 프로토콜 위에서 작동 4. XML로 데이터를 주고 받는다 - 모든 플랫폼에서 호출 가능 - 분산 객체의 표준 - Any. Where, Any. Device, Any. Time
Structure of SOAP Envelope En ( Make , Do) + Velop e (Wrap) De (Down , Away) + Velop e (Wrap) SOAP XML 메시지를 에워싸고 있는 최상위 엘리먼트 SOAP Header는 데이터를 효율적으로 교환하기 위해 유연한 구조를 가짐 1. 인증, 트랙잭션, 비용 등 다양한 요소를 추가가능 2. SOAP Body 엘리먼트의 필요한 정보를 간추려 제공한다.
Structure of SOAP Body Web Service에서 실제적으로 주고 받는 데이터를 기술한다. - Web Service Method의 이름과 매개변수 - Web Service Method를 호출할 때 반환되는 리턴 값 - 기본 자료형이 아니면 literal 형태로 전송 SOAP Fault SOAP의 에러 메시지는 전송중 발생하는 에러나, 전송받는 데이터의 에러 가 다를 경우 에러가 발생한다. Soap Fault Element defines the following four child element. faultcode Web Service Error 코드 faultstring 사람이 쉽게 읽을 수 있는 에러 설명 faultactor 어디에서 에러가 발생했는지 설명 detail 자세한 에러 설명 (message , errorcode)
Example of SOAP Structure SOAP 구조의 예 – 데이터 전송시 <? xml version="1. 0" encoding="utf-8"? > <soap: Envelope xmlns: xsi=http: //www. w 3. org/2001/XMLSchema-instance xmlns: xsd="http: //www. w 3. org/2001/XMLSchema" xmlns: soap="http: //schemas. xmlsoap. org/soap/envelope/"> <soap: Body> <Get. Books xmlns="http: //127. 0. 0. 1/Pubs. WS/"> <isdn> 123230 -123213123</isdn> <name>Hello </name> </Get. Books> </soap: Body> </soap: Envelope>
Example of SOAP Error SOAP 구조의 예 – 에러 발생시 <? xml version="1. 0" encoding="utf-8"? > <soap: Envelope xmlns: soap="http: //schemas. xmlsoap. org/soap/envelope/"> <soap: Body> <soap: Fault> <faultcode>123 XYZ<faultcode> <faultstring>Server Error<faultstring> <detail> <bank: faultdetail xmlns: bank=“urn: bank”> <message>Your account is overdrawn</message> <errorcode>1234</errorcode> </bank> </detail> </soap: Fault> </soap: Body> </soap: Envelope>
What is WSDL ? Web Service Description Language WSDL은 COM+의 IDL과 유사한 역할을 하는 것으로 Service Consumer에게 XML 문법으로 Web Service 메시지를 사용할 수 있게 인터페이스를 제공하는 역할을 한다. WSDL Document를 사용함으로써, Web Service의 연산 안에 사용되는 타입(Simple Data Type)과, 각각의 연산에서 교환 받는 Document의 Type(Schema)을 정의함. Define Message Format Network Protocol (String…. ) (HTTP, SOAP…)
WSDL Document Structure Type – 웹 서비스에 사용되는 자료형 정의 Binding – 메시지 포멧 (자료형, 프로토콜) 정의 Port – 프로토콜 별로 지원되는 서비스의 정의 Message – 교환되는 메시지를 정의 Service – 웹 서비스 주소를 정의
Web Service 전체 구성도 Type, Message Proxy Binding Web Service Consumer Web Service Provider
WSDL Document Structure Type Element는 메시지를 주고 받기 위해 사용되는 다양한 데이터 타입을 정의한다 <types> <s: complex. Type> <s: sequence> <s: element min. Occurs="0" max. Occurs="1" name=“TA"> <s: complex. Type> <s: sequence> <s: studentname type="s: string /> <s: studentnumber type="s: string /> </s: sequence> </s: complex. Type> </s: element> </s: sequence> </s: complex. Type> </types>
WSDL Document Structure Message Element는 교환되는 메시지를 설명한다. public Data. Set Get. Authors(){} <message name="Get. Authors. Http. Get. In" /> <message name="Get. Authors. Http. Get. Out"> <part name="Body" element="s 0: Data. Set" /> </message> public Data. Set Get. Author(string s. SSN){} <message name="Get. Author. Http. Get. In"> <part name="s. SSN" type="s: string" /> </message> <message name="Get. Author. Http. Get. Out"> <part name="Body" element="s 0: Data. Set" /> </message>
WSDL Document Structure port. Type Element 는 Web Service 메소드의 집합으로서, 다양한 프로토콜에 독립적인 양식을 가지도록 만드는 Element <port. Type name="Pubs. WSSoap"> <operation name="Get. Authors"> <operation name="Get. Books"> <port. Type name="Pubs. WSHttp. Get"> ……………… <port. Type> <port. Type name="Pubs. WSHttp. Post"> ……………. . <port. Type>
WSDL Document Structure Binding Element는 각각의 특별한 Port Type을 위한 메시지 포멧과 프로토콜을 정의한다. SOAP과 같이 웹서비스가 어떤 프로토콜을 해석하고 통신하는지 정의한다. <binding name="Pubs. WSSoap" type="s 0: Pubs. WSSoap"> <soap: binding transport="http: //schemas. xmlsoap. org/soap/http" style="document" /> <operation name="Get. Authors"> <soap: operation soap. Action="http: //127. 0. 0. 1/Pubs. WS/Get. Authors" style="document" /> <input> <soap: body use="literal" /> <!-- 문자열 형태로데이터 전송--> </input> <output> <soap: body use="literal" /> </output> </operation> </binding>
WSDL Document Structure Service Element는 웹 서비스의 물리적인 주소를 정의하며, 특정 주소를 언급하는 포트의 이름을 가지고 있다. <service name="Pubs. WS"> <port name="Pubs. WSSoap" binding="s 0: Pubs. WSSoap"> <soap: address location="http: //127. 0. 0. 1/Pubs. WS. asmx"/> </port> <port name="Pubs. WSHttp. Get" binding="s 0: Pubs. WSHttp. Get"> <http: address location="http: //127. 0. 0. 1/Pubs. WS. asmx"/> </port> <port name="Pubs. WSHttp. Post" binding="s 0: Pubs. WSHttp. Post"> <http: address location="http: //127. 0. 0. 1/Pubs. WS. asmx"/> </port> </service>
2. 4 Overview of UDDI What is UDDI? UDDI Data Structure UDDI Programmer’s APIs
What is UDDI? A Collection of Specifications Universal Description, Discovery, and Integration (UDDI) is a Collection of Specification for distributed Web-Based information registries of Web Services - UDDI Programmer’s API Specification - UDDI Data Structure Specification The UDDI Programmer’s API Specification - A Publisher API that allows you to publish data in a registry - An Inquiry API that allows you to read information from a registry The UDDI Data Structure Specification outlines the details of each of the XML Structures associated with the messages defined in the Programmer’s API Specification
UDDI Data Structure Overview <business. Entity> name, contacts, description, indentifiers, categories <business. Service> (1. . n) name, description, categories <binding. Template > (1. . n) technical information <t. Model> name description URL pointers to specificaitons
UDDI Data Structure Overview t. Model business. Entity Contains Define Relationship Between two business element publisher. Assertion Has reference to business. Service Contains binding. Template
The business. Entity Element or entity The business. Entity Element describes a business that has registered a Web Service within UDDI <business. Entity business. Key = “ 43444 F 4 -6 E 17 -1342 -EA 4136 E 642531 DAO” operation = “”> <name>Contoso Micropayments</name> <description xml: lang=“en”>The Contoso Micropayments</description> <contacts> <contact> <description xml: lang=“en”> Web sidte Administrator </description> <person. Name>Son Young Su</person. Name> <phone>800 -234 -1234</phone> <email>ysson@cse. hanyang. ac. kr</email> <address><address. Line>Hanyang Univ</address. Line></address> <contact> </contacts>
The business. Service Element The business. Service element describes a Web Service that is exposed by a business entity <business. Services> <business. Service business. Key = “ 43444 F 4 -6 E 17 -1342 -EA 4136 E 642531 DAO” service. Key = “AE 4 C 8990 -2358 -1253 -EADE-AFE 9329 QDDQ 8”> <name>Business Service Example</name> <description xml: lang=“en”>description goes here</description> <binding. Template> <!-- zero or more binding templates --> </binding. Template> <binding. Template> elements go here </binding. Templates> </business. Services>
The binding. Template Element The binding. Template element has information on how to access a Web service The binding information is described as either an access point or A hosting redirector <binding. Template binding. Key=“FE 542889 -EE 4 B-2353 -2534 -AEFC 3901223 A” service. Key=“AEAC 8990 -2891 -3894 -DEC 1 -AEF 89234 EE 18”> <description xml: lang=“en”> Micropayments binding template <description> <access. Point URLType=“http”> http: //www. bluette. com/blue. asmx </access. Point> <t. Model. Instance. Details> < ! --. . Zero or more -- > <t. Model. Instance. Info> element Goes Here <t. Model. Instance. Info> </t. Model. Instance. Details> </binding. Template>
The t. Model Element The t. Model element is point to the specification or interface definitions(WSDL) for a service <t. Modelkey=“uuid: 455655 B 7 -4 C 43 -4 F 3 E-BB 0 B-695 FE 2120 C 5 C”> <name>Micropayment t. Model</name> <description xml: lang=“en”> WSDL Description for a micropayment web service </description> <overview. Doc> <description xml: lang=“en”> The Micropayment web service t. Model </descritpion> <overview. URL>http: //localhost/Contoso/overview. htm</overview. URL> </overview. Doc> <category. Bag> <keyed. Refernece t. Modelkey=“uuid: C 1 ACF 26 D-9672 -404 -9 D 70 -234234 e 62342 key. Name = “uuid-org: types” keyvalue=“wsdlspec”> </category. Bag> </t. Model>
The publisher. Assertion Element Businesses can model relations between themselves using publisher assertions Many Large organizations may not be effectively represented by a single business. Entity. As a result, such organizations publish several business Entity structure. However, these business entities are still related and at least some of their relationships should be visible in their UDDI <publisher. Assertion> <fromkey>1234 -……</fromkey> Business. Entity Key <tokey>4567 -……. </tokey> <keyed. Reference t. Modelkey=“uuid: 1357…” key. Name = “Holding Company” key. Value=“parent-child”/> </publsher. Assertion>
Part 2 Semantic Web
What is the Semantic Web? n n T. Berners-Lee, J. Hendler, O. Lassila • The Semantic Web is not a separate Web, but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. W 3 C (World Wide Web Consortium) • The Semantic Web is the abstract representation of data on the World Wide Web, based on the RDF standards and other standards to be defined.
Goals of Semantic Web n To develop enabling standards and technologies designed to help machines understand more information on the Web so that they can support richer discovery, data integration, navigation, and automation of tasks. • receive more exact result when searching for information • know when to integrate information from different sources and what information to compare • associate semantically rich, descriptive information with any resource • add specific information to the Web to aid in the automation of services
Semantic Web Layers
Metadata n Metadata: “structured data about data” • Descriptive information about an object or resource Data Metadata Joe Smith Name 222 Happy Lane Address Sierra Vista City AZ State • Labeling, cataloging, descriptive information n Ex) Library card catalogs • Markup
Smart Data Continuum n n Semantic Web Technologies • Are the foundations of a systematic approach to creating “smart data”. Smart Data Continuum • Text documents and database records • XML documents usingle vocabularies • XML taxonomies and docs with mixed vocabularies • XML ontology and automated reasoning
How XML fit into Semantic Web? n Characteristics of XML • XML creates application-independent documents and data • XML has a standard syntax for metadata • XML has a standard structure for both documents and data XML is the syntactical foundation layer of Semantic Web
XML is not enough n Limitations of XML • Many ways to say the same thing n Multiple valid structures for the same data • Not impose a common interpretation of a data n heading vs. title n price vs. cost
RDF n Resource Description Framework • RDF is an infrastructure that enables the encoding, exchange and reuse of structured metadata. • RDF is a foundation for processing metadata n It provides interoperability between applications that exchange machine-understandable information on the Web. • RDF is an application of XML that imposes needed structural constraints to provide unambiguous methods of expressing semantics.
RDF Model n n n Resources • All things being described by RDF expressions • A resource may be an entire Web page; may be a part of a Web page; may be a whole collection of pages; Properties • A specific aspect, characteristic, attribute, or relation used to describe a resource • Each property has a specific meaning n defines its permitted values, the types of resources it can describe, and its relationship with other properties. Statements • A specific resource together with a named property plus the value of that property for that resource is an RDF statement.
RDF Graph Model Property (Predicate) Statement URI URI Resource (subject) (object)
RDF Example Graph Diagram s: Publisher s: Title http: //www. w 3. org/ WWW Consortium W 3 C Home Page s: Date 1998 -10 -03 T 02: 27 XML Serialization
XML vs. RDF n n XML was designed for documents, not data. • Many features (like attributes and entities) are document-oriented, not for expressing data • There are many ways to say the same thing in XML • Hybrid tree structure: confusing and nonstandard • Makes basic operations more complex (e. g. merging) RDF was designed for statements, or data • The number of changes you can make to a triple are fairly small • Simple structure: triples • Merging two documents are simply combining two into one
Ontology n An ontology is a formal, explicit specification of a shared conceptualization. (by Gruber) • Conceptualization: an abstract model of how people think about things in the world, usually restricted to a particular subject area • Explicit specification: the type of concepts used and the constraints on their use are explicitly defined • Formal: the ontology should be machine understandable n different degrees of formality are possible • Shared: an ontology captures consensual knowledge; it is not restricted to some individual but is accepted by a group
Ontology for Semantic Web n Web Ontology • A program that wants to compare or combine information across the two databases has to know that two terms are being used to mean the same thing. • Ontologies can play a crucial role in enabling Web-based knowledge processing, sharing, and reuse between applications. • The most typical kind of ontology for the Web has a taxonomy and a set of inference rules.
Taxonomy and Inference Rules n n Taxonomy • Defines classes of objects and relations among them n ex) address may be defined as a type of location n ex) city codes may be defined to apply only to locations • Classes, subclasses and relations among entities are a very powerful tool for Web use Inference rules • A program can deduce new instances • The computer doesn’t truly understand any of this information, but it can now manipulate the terms much more effectively in ways that are useful and meaningful to the human user
Ontology Languages n “Ontology Languages for the Semantic Web” paper • IEEE Intelligent Systems, Jan/Feb 2002, pp 54 -60 • analyze the most representative ontology languages created for the Web, and compare them using a common framework ¨ ¨ ¨ ¨ XOL (XML-based Ontology Exchange Language) SHOE (Simple HTML Ontology Extension) OML (Ontology Markup Language) RDF(S) (Resource Description Framework (Schema)) OIL (Ontology Interchange Language) DAML+OIL (DARPA Agent Markup Language + OIL) OWL (Ontology Web Language)
DAML+OIL n DARPA Agent Markup Language + OIL (www. w 3. org/TR/daml+oil-reference) • A semantic markup language for Web resources • Builds on earlier W 3 C standards such as RDF and RDF Schema, and extends these languages with richer modeling primitives • Provides modeling primitives commonly found in frame-based languages • A DAML+OIL ontology consists of headers, class elements, property elements, and instances
DAML+OIL Ontology : Classes
DAML+OIL Ontology : Properties
Logic, Proof, Trust n n Parts of the Semantic Web that haven’t been developed much yet Logic • State any logical principle and permit the computer to reason (by inference) using these principles Proof • Once we begin to build systems that follow logic, it makes sense to use them to prove things Trust • Issue of whether we can trust RDF statements
W 3 C Semantic Web Activity n n n RDF Interest Group • A forum for W 3 C Members and non-Members to discuss innovative applications of RDF Core Working Group • Chartered to consider update to the RDF Model and Syntax Recommendation, and to a few revisions to the RDF Schema specification Web Ontology Working Group • Chartered to build upon the RDF Core work a language for defining structured web based ontologies which will provide richer integration and interoperability of data among descriptive communities
Part 3 Semantic Web Services
Semantic Web Service n n n Motivation of Semantic Web Services DAML-S Architecture Service Grounding Service Profile Service Process
Motivation of Semantic WSs Web service discovery Find me a shipping service that transports goods to Dubai Web service invocation Buy me 500 lbs. powdered milk from www. acmemoo. com Web service selection & composition Arrange food for 500 people for 2 weeks in Dubai Web service execution monitoring Has the powdered milk been ordered and paid for yet?
DAML-S
Service. Grounding n General WSDL Format Type – 웹 서비스에 사용되는 자료형 정의 Binding – 메시지 포멧 (자료형, 프로토콜) 정의 Port – 프로토콜 별로 지원되는 서비스의 정의 Message – 실제 서비스의 input/output 파라메터 Service – 웹 서비스 주소를 정의
Service. Grounding (cont’d) n DAML-S WSDL Format Type Ontology Binding – 메시지 포멧 (자료형, 프로토콜) 정의 Port – 프로토콜 별로 지원되는 서비스의 정의 Message – 실제 서비스의 input/output 파라메터 Service – 웹 서비스 주소를 정의 WSDL
Service. Grounding (cont’d) Import Type Ontology
Service. Profile Import Ontology Type Functional Description Input, Output Parameter…. Functional Attribute Range, Constraint. . Actor The Profile of Service Provider
Service. Model
DAML-S Architecture
Part 4 Grid Computing
What is the Grid? n n The Grid is “flexible, secure, coordinated resource sharing among dynamic collections of individuals, institutions, and resources—what we refer to as virtual organizations. ” - Ian Foster 지리적으로 분산된 고성능 컴퓨터 등의 정보통신 자원을 고속 네트워크로 연결해 상호 공유, 이용할 수 있도록 하 는 컴퓨팅 플랫폼. Electricity power grid에서 유래. Implement by Grid middleware • Globus Toolkit 3. 0, Unicore
What is the Grid? (Cont’d) n 그리드 활용 분야 NT ET 대형연구 장비 BT 연구망 (Gbps) Supercomputer 첨단대형 연구장비 원격제어 및 감시 가상실험 시스템 Grid 선박 IT 첨단연구장비 학제간공동 연구 기계 고성능 클러스터 대규모 데이터 (BT, NT, etc. ) 반도체 자동차 기상
Grids n Data Grid • responds to requests for computers and data stores n Information Grid • responds to requests for computational processes • that may require several data sources and processing stages to deliver a desired result n Knowledge Grid • responds to high-level questions • finds the appropriate processes to deliver answers in the required form.
Grid Services n Open Grid Services Architecture (OGSA) n Grid requirements and technique + Web Service n • Resource sharing + Application sharing • Service-oriented approach Grid Services (Four tiers) Fabric Base Security, data transport, certification, remote access … resource scheduling, data access, event notification … High Level workflow, database management, personalization … Application a gene sequence alignment, a gene finding algorithm …
Grid Services (cont. ) n n Each tier relies on metadata. To achieve the flexible assembly of Grid services requires information. • Functionality, availability and interfaces of the various services. n Service discovery, brokering and composition uses metadata descriptions.
Grid+SW The Semantic Grid is metadata based middleware n To support the full richness of the grid computing vision, we need Semantic Web technologies to Grid middleware and applications; i. e. the Semantic Grid n Semantic Web base services -> Grid Base Services n Semantic Web metadata and ontologies -> Grid metadata n
Semantic Web for Grid Infrastructure n Semantic Grid Service • Depends on service metadata. • For automated discovery, search, selections, matching, composition, and interoperation. • Classification of services based on the functionality. E. g. UDDI
IBM : Globus Tookit
MS : Direct System Initiative + SFU (Service for Unix)
Sun Open Grid Environment
Part 5 For Real SOA
Considerations for Real SOA Service Description Service Discovery Service Delivery Service Composition
Service Models of WSs supply - led demand - led This model supports application that can provide only a predetermined range of services from remote server This model can be constructed from smaller component services and bound dynamically as needed.
Service Integration Layer Service Description provides the means of mapping between the provider’s description of its offerings and the client’s description of its needs Functionality, Interfaces, Nonfunctional characteristics and constraints such as quality of service and cost
Service Integration Layer Service Discovery Client identifies those potential service providers whose offerings meet its functional needs and who are prepared to negotiate within some acceptable bounds
Service Integration Layer Service Negotiation Service negotiation involves the interaction between a client and one or more of the service providers identified through the discovery process or already known to the client.
Service Integration Layer Service Delivery Discovery Step The client requests the provider to supply the specified service according to the agreed terms and conditions. Validation Step The service provider must supply the agreed-upon service within the period agreed to in the supply contract. Invocation Step Invocate Service Suspension Step The suspension step establishes the point at which the client to longer needs the provider to supply the service.
Service Integration Layer Service Composition The service provider can compose the real service from low-level services. Creating the means of automatically providing entirely new services will clearly only be practical once the other elements of the service integration layer
Proposed WS Framework
Realizing The Service Integration Layer Service Description Service Discovery Service Negotiation Service Delivery Service Composition
Service Description The Limitation of WSDL Don’t support semantic of services Lacks descriptions of service delivery negotiable aspects WSDL just describes acceptable data types, methods, message format, transport protocol, and end-point uniform resource identifier (URI).
Service Description (eb. XML) eb. XML The Collaboration Protocol Profile specification deals with service description it includes more details about the service provider and error handling scenarios than WSDL
Service Description (WSEL) WSEL (Web Service Endpoint Language) This Language is the only protocol explicitly designed to describe the nonfunctional, negotiable elements of Web Services <activity name="process. PO"> <wsel: duration limit="30" metric="minutes"/> <wsel: retry max. Number="10"/> <wsel: escalate> <wsel: staff who="select PID from Person where skill >15“ Invoke="c: programsorg_query. exe "/> </wsel: escalate> <wsel: observed> <wsel: staff who="select PID from Flows where Flow. Name= "Total. Supply. Flow" " Invoke="c: programsorg_query. exe "/> </wsel: observed> ………………… </activity>
Service Description (DAML-S) DAML-S is the only available description method designed specifically for describing the functional and nonfunctional aspects of service.
Service Description (DAML-S) The Drawbacks of OWL-S DAML-S has not yet reached a final release. The exact details of what the service profile will include have yet to be finalized DAML-S also currently lacks an extensive selection of usable, standardized ontologies.
Service Discovery The limitation of UDDI This limits searching to keywords, Such as the name of the service provider or the service itself, the service’s location, or the business classification eb. XML registry specifications offers richer searching capabilities in the form of SQL and XML filter queries, It doesn’t allow semantic searching.
Service Discovery DAML-S The ontology language based, its inferential capabilities should allow matching requests to service descriptions. Solution – Importing the Semantic Web in UDDI. References: M. Paolucci et al. “Importing the Semantic Web in UDDI” DAML-S Profile UDDI
Service Negotiation The client and provider must negotiate the service’s delivery terms and conditions automatically. eb. XML’s CPP, DAML-S, and WSEL don’t allow for fully automated negotiation. Only eb. XML includes such contracts using CPA. But, The Collaboration Protocol Agreement primarily defines the common protocols and capabilities of only two parties.
Service Negotiation
Service Delivery Current technologies cover a Web service’s basic invocation and provision. eb. XML = CPP and CPA Web Service Based = WSCI and WSEL Current technologies don’t monitor any legal or nonfunctional parameters such as cost or QOS.
Service Composition The automatic composition of Web services requires suitable protocols at the conversations, choreography, workflows, and transactions layers. WSDL-Based Framework IBM, MS = BPEL 4 WS eb. XML + Sun = BPML + WSCI Semantic-Based Framework DAML-S Service. Model (don’t support Transaction)
Service Composition Orchestration always represent control from one party’s perspective. Choreography tracks the message sequences among multiple parties and sources.
Service Composition WSCI BPML WSCI BPEL
BPEL Implementation using Biz. Talk
Process Monitoring Tool of Biz. Talk
Conclusion Service Web ontology Broker Grid Computing DAML-S UDDI ontology Services Business Process Work. Flow System
Conclusion (Cont’d) Semantic Web Services Semantic Grid Semantic Web Grid Computing Semantic for Grid Services
References n Service Oriented Computing Communication of the ACM, Oct 2003, Vol. 46 n Web Services IEEE Computer Society, Oct 2003 n Service Oriented Architecture Randaill Perrey etc al, Brunel Univ n BPEL 4 WS Spec Ver 1. 1 n Biz. Talk Server 2004 http: //msdn. microsoft. com/ n Web Service Interoperability Organization http: //www. ws-i. org
References - Chris Peltz. , “Web Services Orchestration and Choreography”, published by IEEE Computer Society , Oct, 2003 - Massimo Paolucci et al. , “Importing the Semantic Web in UDDI”, CAi. SE 2002, Sprint-Verlag, 2002, pp. 225 -236 - D. Cotroneo, C. Di Flora, S. Russo et al. , “Improving Dependability of Service Oriented Architectures for Pervasive Computing”, Proceedings of The Eighth IEEE International Workshop on Object. Oriented Real-Time - OWL-S (http: //www. daml-s. org) - BPEL Spec 1. 1 (http: //msdn. microsoft. com/)
d58f1e4f9b42f4cff1e3b323dce7575c.ppt