Stanislaw Ambroszkiewicz the leader of enTish team

1
Entish e-Lingua for service description and
composition

• Stanislaw 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

xii.2002
2
Distributed systems middleware

• Service-Oriented Architecture (SOA)
• 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.
• Web services are supposed to realize the SOA in a
  global networked environment.

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

• SOA

4
Web services an idea to be
realized

• IBMs 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
Web service integration the background

• Ethernet (CSMA/CD)
• -- gtgt simple and ubiquitous LAN
• Internet (TCP/IP) --gtgt simple and ubiquitous
  global networking
• WWW (URL / HTML /HTTP) --gtgt simple and
  ubiquitous access to data
• Web services (a magic protocol) --gtgt simple and
  ubiquitous access to applications

6
Industrial standards Web service integration -
IBM, Microsoft, BEA
UDDI registry
discovery
publication
WSDL Web Service Description Language
applications
Web services (applications)
Invocation, composition??? BPEL4WS,
WS-Coordination, WS-Transaction, ...

• SOAPWSDLUDDIBPEL are positioned as standards
  for web services

7
Abstract architecture for
implementation
8
Abstract architecture for
implementation
9
Service architecture for
implementation

• 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
Protocol stack for networked servicesour
proposal
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
WSDL Web Services Activity of W3C

• WSDL SOAP may be considered as a universal RPC
  for application that process XML data.
• SOAP is a transport protocol based on XML message
  format
• WSDL is a IDL for XML data types wsdl
  description is generated from code

13
UDDI yellow pages - - success
or failure?

• UDDI provides a registry of businesses and web
  services.
• a 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.
• more than 66.6 of UDDI entries are empty, not
  valid, etc. quoted from http//www.webservicesarc
  hitect.com/content/articles/modi01.asp

14
BPEL4WS, WS-Coordination, and WS-Transaction
(August 2002)

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

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

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

17
DAML-San academic project supported by DARPA

• DAML-S is a DAMLOIL ontology for describing Web
  Services.
• It aims to make Web services computer-interpretabl
  e -- described with sufficient information to
  enable automated Web service discovery,
  invocation, composition and execution monitoring.
  
• The DAML-S Ontology comprises
• ServiceProfile - 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 servicenecessary for automatic
  discovery, such as what the services offers, and
  its inputs,outputs, and its side-effects
  (preconditions and effects)..
• ServiceModel - 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.
• ServiceGrounding - Connects the process model
  description to communication-level protocols and
  message descriptions in WSDL
• The main limitation of DAMLOIL 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
Requirements for networked services

• The term web services is reserved for WSDL
  and DAML-S.
• Lets use the term networked services
• What are networked services?
• Applications that are describable, locatable,
  invocable, can negotiate coordination,
  composable, can implement transactions, etc.
• Service description
• Only IDL interface, i.e., spec. of the input
  output types ?
• Also what the service does (i.e., the abstract
  function it implements), constrains on input
  output resources, etc.

19
Requirements for networked services (cont.)

• RPC-style versus messaging
• Only raw applications, i.e. only objects
  methods available by universal RPC ?
• Applications can also speak a common language to
  arrange coordination and transactions
• Agents versus services
• agents are clients
• services supply applications
• What is the client? how to do versus what
  to do
• a programmer writing code in BPEL or DAML-S ?
• a user creates task in a declarative language and
  delegates the task to an agent to realize.

20
Language and protocol Don't ask what
it means, but rather how it is used.


- L. Wittgenstein

• Language Entish
• XML 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
• Ability to express agent / service mental
  attributes intentions, goals, commitments as
  atomic formulas.
• Protocol entish 1.0
• Specifies message exchange order
• Message format is defined in XML
• Realizes service invocation and composition
  supporting 2PC transactions

21
Language syntax

• XML-syntax
• formula.xsd
• definition.xsd
• properEntish.xml --gt an instance of
  definitions.xsd
• info.xsd --gt evaluated Entish formula

22
Language What do we want to describe?

• resources - data (e-documents) collected in
  types, e.g., Typ1, Typ2, ...
• services - applications where the resources are
  stored and processed
• type of operation performed by the service
• precondition formInOperationType
• postcondition formOutOperationType
• functions implemented by operations, e.g., f
  parameter a is of type Typ1, the term f( a ) is
  of type Typ2

23
Language What do we want to describe?

• tasks specify what is to be processed, how and
  when, and where the result is to be stored
• when - timeout timeout( date ), i.e., the
  current GMT time is before the date
• where - relation isIn( res, service ) , i.e, a
  resource res is in service service

24
Language What do we want to describe?

• task example
• resource res1 is processed by function f and
  the result is stored in service ser1 by the time
  date1
• formally
• isIn( f( res1 ), ser1 ) and timeout( date1 )

25
Language What do we want to describe?

• Service attributes
• The type of operation the service performs is
  represented as a pair of atomic formulas
• formInOperationType( service )
• formOutOperationType( service )

26
Language What do we want to describe?

• Agent is a process dedicated to a single task
  realization
• Agent attribute(s)
• intentions( agent ) is an atomic formula

27
Language Term and formula construction

• Terms are constructed in the standard way
• Composite formulas are constructed using only
  conjunction, disjunction and implication
  no quantifiers and no negation!

28
Composition protocol
version 1.0

• message.xsd --gt
• message types (orders)
• state.xsd --gt schema for agents state and
  services state
• entish1.specs
• composition

29
Our idea of service integration
Service description

• Service description
• unique name and communication address - URI,
  e.g., service name soap//ipipan.waw.pl8080/my_
  service
• operation type the pair of formulas
• formInOperationType( name )
• formOutOperationType( name )
• the service is invoked if formIn is satisfied
• formOut describes the result of operation
  performed by the service

30
Our idea of service integration
Service invocation protocol

• Six steps of service invocation
• agent sends to the service my intention is
  f
• f --gt intentions( agent )
• service responds I commit to realize f if ? is
  satisfied
• ? --gt formInCommitments( service )
• and
• formOutCommitments( service ) --gt f
• ? is satisfied
• operation is performed by the service
• f is satisfied
• service sends confirmation to the agent

31
Idea of service integration
Service composition
protocol

• Composition of two services (service0 and
  service1) is arranged by the agent in the
  following way.
• The agent arranges the realization of its first
  intention f0, with the service0 .
• Service agrees to realize this intention
  conditionally, i.e., if the formula f1 is
  satisfied.
• Then, the agent puts the formula f1 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 f1 .
  
• Continued on the next slide

32
Our idea of service integration
Service composition
protocol

• The agent starts conversation with the service1
  by sending the message "my intention is f1 " .
• Once 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.
• Recall that the agent task and its first
  intention is of the form
• f0 isIn( g(f( res0 )), GUI ) and timeout(
  date0 )
• f is implemented by service0 , g is implemented
  by service1
• the service composition corresponds to the
  abstract function composition

33
enTish enTish enTish enTish enTish