Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Stanisław Ambroszkiewicz the leader of enTish team IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie Project supported.

Similar presentations


Presentation on theme: "1 Stanisław Ambroszkiewicz the leader of enTish team IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie Project supported."— Presentation transcript:

1 1 Stanisław Ambroszkiewicz the leader of enTish team IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie Project supported by a KBN project and Agentcities.NET - a IST project Entish: e-Lingua for service description and composition xii.2002

2 2 Distributed systems middleware Service-Oriented Architecture (SOA) z provides a standard programming model that allows software components, residing on any network, to be published, discovered, and invoked by each other as services. There are essentially three components of SOA: Service Provider, Service Requester (or Client), and Service Registry. The provider hosts the service and controls access to it, and is responsible for publishing a description of its service to a service registry. The requester (client) is a software component in search of a component to invoke in order to realize a task. The service registry is a central repository that facilitates service discovery by the requesters. z Web services are supposed to realize the SOA in a global networked environment.

3 3 Service-Oriented Architecture middleware SOA clients services services Invocation, composition Serviceregistry discovery publication middleware Service requestor Service provider

4 4 Web services an idea to be realized  IBM’s def.: Web services  IBM’s def.: Web services are self-contained, self - describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions that can be anything from simple requests to complicated business processes... Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service (in an automatic way!).  From service providers’ point of view, if they can setup a web site they can join global community. From a client's point of view, if you can click, you can access services.

5 5 Web service integration the background zEthernet (CSMA/CD) -- >> simple and ubiquitous LAN zInternet (TCP/IP) -->> simple and ubiquitous global networking zWWW (URL / HTML /HTTP) -->> simple and ubiquitous access to data zWeb services (a magic protocol) -->> simple and ubiquitous access to applications GUI, API (applications) Web services (applications) for automatic service discovery, invocation, and composition a magic protocol

6 6 Industrial standards Web service integration - IBM, Microsoft, BEA zSOAP+WSDL+UDDI+BPEL are positioned as standards for web services applications Web services (applications) Invocation, composition??? BPEL4WS, WS-Coordination, WS-Transaction,... UDDIregistry discovery publication WSDL Web Service Description Language

7 7 Abstract architecture for implementation task, input resources and the final result You can define your own data type, functions, relations; i.e., you own ontology You can join applications via API

8 8 Abstract architecture for implementation task, input resources and the final result You can define your own data type, functions, relations; i.e., you own ontology You can join applications via API

9 9 Service architecture for implementation z communication layer, functionality layer, and executive (database management) layer. The functionality layer has exactly two interrelated components: raw application (Function), and so called filter associated with the raw application. Raw application implements a single operation, i.e., given input resources, it produces the output resource according to the operation specification. Given a specification of the desired output, the Filter replies with properties that must be satisfied by the input in order to produce the desired output by the raw application

10 10 Protocol stack for networked services: our proposal Communication Contents Language: Entish Service composition protocol: entish 1.0 Universal transport: e.g., SOAP+HTTP Internet (TCP/IP) Service architecture

11 11 What do we propose? Language and protocol – nothing but specifications To prove it does works, also the prototype implementation The current status of the enTish project: XML-spec. of language and composition protocol already completed (version 1.0) The prototype already implemented and ready for use and evaluation at http://www.ipipan.waw.pl/mas/ Near future: …

12 12 WSDL Web Services Activity of W3C zWSDL + SOAP may be considered as a universal RPC for application that process XML data. ySOAP is a transport protocol based on XML message format; yWSDL is a IDL for XML data types; wsdl description is generated from code

13 13 UDDI yellow pages - - success or failure? zUDDI provides a registry of businesses and web services. za UDDI service description consists of physical attributes such as name and address augmented by a collection of tModels, which describe additional features such as, for example, reference to WSDL document describing the service interface, and the classification of the service within some fixed taxonomies. z“more than 66.6% of UDDI entries are empty, not valid, etc.” quoted from http://www.webservicesarchitect.com/content/a rticles/modi01.asp http://www.webservicesarchitect.com/content/a rticles/modi01.asp

14 14 BPEL4WS, WS-Coordination, and WS-Transaction (August 2002) zComposed services are modeled as directed graphs where the nodes are services and the edges represent a dependency link from one service to another. zCanonical programmatic constructs like SWITCH, WHILE and PICK allow to direct an execution's path through the graph. zBPEL was released along with two others specs: WS-Coordination and WS-Transaction. yWS-Coordination describes how services can make use of pre-defined coordination contexts to subscribe to a particular role in a collaborative activity.

15 15 BPEL4WS, WS-Coordination, and WS-Transaction (cont.)

16 16 BPEL4WS, WS-Coordination, and WS-Transaction (cont.)

17 17 DAML-S an academic project supported by DARPA zDAML-S is a DAML+OIL ontology for describing Web Services. zIt aims to make Web services computer-interpretable -- described with sufficient information to enable *automated* Web service discovery, invocation, composition and execution monitoring. zThe DAML-S Ontology comprises: yServiceProfile - This is like the yellow page entry for a service. It relates and builds upon the type of content in UDDI, describing properties of a service necessary for automatic discovery, such as what the services offers, and its inputs, outputs, and its side-effects (preconditions and effects).. yServiceModel - Describes the service's process model (the control flow and data-flow involved in using the service). It is designed to enable automated composition and execution of services. yServiceGrounding - Connects the process model description to communication-level protocols and message descriptions in WSDL zThe main limitation of DAML+OIL is its lack of a definition of well formed formulae and an associated theorem prover. So that there is a problem with expressing (as formulas) preconditions, effects, and output – input constrains.

18 18 Requirements for networked services zThe term “web services” is reserved for WSDL+… and DAML-S. zLet’s use the term “networked services” zWhat are networked services? yApplications that are describable, locatable, invocable, can negotiate coordination, composable, can implement transactions, etc. … zService description yOnly IDL interface, i.e., spec. of the input – output types ? yAlso what the service does (i.e., the abstract function it implements), constrains on input – output resources, etc. …

19 19 Requirements for networked services (cont.) zRPC-style versus messaging yOnly raw applications, i.e. only objects + methods available by universal RPC ? yApplications can also speak a common language to arrange coordination and transactions zAgents versus services yagents are clients yservices supply applications zWhat is the client? “how to do” versus “what to do” ya programmer writing code in BPEL or DAML-S ? ya user creates task in a declarative language and delegates the task to an agent to realize.

20 20 Language and protocol Don't ask what it means, but rather how it is used. - L. Wittgenstein zLanguage Entish – yXML syntax, 0.5 order logic language; no quantifiers, describes only static relations between agents, services, functions the services implement, and resources; no actions, fully declarative language yAbility to express agent / service mental attributes: intentions, goals, commitments as atomic formulas. zProtocol entish 1.0 ySpecifies message exchange order yMessage format is defined in XML yRealizes service invocation and composition supporting 2PC transactions

21 21 Language syntax z XML-syntax: yformula.xsd ydefinition.xsd yproperEntish.xml --> an instance of definitions.xsd yinfo.xsd --> evaluated Entish formula

22 22 zresources - data (e-documents) collected in types, e.g., Typ1, Typ2,... zservices - applications where the resources are stored and processed: ytype of operation performed by the service: xprecondition formInOperationType xpostcondition formOutOperationType zfunctions implemented by operations, e.g., f; parameter a is of type Typ1, the term f( a ) is of type Typ2 Language: What do we want to describe?

23 23 ztasks specify what is to be processed, how and when, and where the result is to be stored: ywhen - timeout: timeout( date ), i.e., the current GMT time is before the date ywhere - relation: isIn( res, service ), i.e, a resource res is in service service Language: What do we want to describe?

24 24 ztask example: y“resource res1 is processed by function f and the result is stored in service ser1 by the time date1” zformally: isIn( f( res1 ), ser1 ) and timeout( date1 ) Language: What do we want to describe?

25 25 zService attributes: yThe type of operation the service performs is represented as a pair of atomic formulas: formInOperationType( service ) formOutOperationType( service ) x Language: What do we want to describe?

26 26 zAgent is a process dedicated to a single task realization zAgent attribute(s): yintentions( agent ) is an atomic formula Language: What do we want to describe?

27 27 zTerms are constructed in the standard way zComposite formulas are constructed using only conjunction, disjunction and implication; no quantifiers and no negation! Language: Term and formula construction

28 28 Composition protocol version 1.0 zmessage.xsd --> ymessage types (orders) zstate.xsd --> schema for agent’s state and service’s state y … zentish1.specs ycomposition …

29 29 Service description: yunique name and communication address - URI, e.g., service name = soap://ipipan.waw.pl:8080/my_service yoperation type: the pair of formulas xformInOperationType( name ) xformOutOperationType( name ) ythe service is invoked if formIn is satisfied yformOut describes the result of operation performed by the service Our idea of service integration: Service description

30 30 Six steps of service invocation: 1.agent sends to the service: “my intention is φ” φ --> intentions( agent ) 2.service responds: ”I commit to realize φ if ψ is satisfied” ψ --> formInCommitments( service ) and formOutCommitments( service ) --> φ 3.ψ is satisfied 4.operation is performed by the service 5.φ is satisfied 6.service sends confirmation to the agent Our idea of service integration: Service invocation protocol

31 31 zComposition of two services (service0 and service1) is arranged by the agent in the following way.  The agent arranges the realization of its first intention φ0, with the service0.  Service agrees to realize this intention conditionally, i.e., if the formula φ1 is satisfied.  Then, the agent puts the formula φ1 as its current intention, and looks for another service that could realize this intention.  Suppose that the agent got to know that the service1 could realize its current intention φ1. zContinued on the next slide Idea of service integration: Service composition protocol

32 32  The agent starts conversation with the service1 by sending the message: "my intention is φ1 ". zOnce the service1 agrees to realize this intention, the operations of the service0 and the service1 are composed, and form a part of a workflow the agent must construct in order to realize its task. zRecall that the agent task and its first intention is of the form: φ0= isIn( g(f( res0 )), GUI ) and timeout( date0 )  f is implemented by service0, g is implemented by service1 ythe service composition corresponds to the abstract function composition Our idea of service integration: Service composition protocol

33 33 enTish


Download ppt "1 Stanisław Ambroszkiewicz the leader of enTish team IPI PAN, Polish Academy of Sciences and Institute of Informatics, University of Podlasie Project supported."

Similar presentations


Ads by Google