W3C Web Service Architecture

1
W3C Web Service Architecture - Critical Summary
-

• From W3C Web Service Architecture Work Group
• Version Working group Note 11 Feb 2004
• Web http//www.w3c.org/TR/ws-arch/
• current is 4th work draft
• W3C WSA Work Group was working from early 2002
  until Jan 2004
• a lot of working members quitted the group during
  this time

Michael Stollberg 04-Mar-2004
2
Contents

• Introduction
• What is a Web Service?
• Basic Notion of WSA
• The Architecture
• Overall Architecture
• Message Orientated Model
• Service Orientated Model
• Resource Orientated Model
• Policy Orientated Model
• Related Aspects (called Stakeholder
  Perspectives)
• Discussion Points

3
1. Introduction Web Service related aspects

• - Web Service Definition
• A Web service is a software system designed to
  support interoperable machine-to-machine
  interaction over a network. It has an interface
  described in a machine-processable format
  (specifically WSDL). Other systems interact with
  the Web service in a manner prescribed by its
  description using SOAP messages, typically
  conveyed using HTTP with an XML serialization in
  conjunction with other Web-related standards
• Agent, Requester Provider
• Agent concrete implementation of a Web Service
  
• Requester a person or organization that wishes
  to make use of a WS
• Provider a person or organization that
  provides an appropriate agent to implement
  a particular service
• Service Description
• a Web Service is described in WSDL
• later, a Functional Description is added
  because needed for Discovery
• Semantics
• shared expectation about the behavior of the
  service
• "contract" between requester entity and provider
  entity regarding the purpose and consequences of
  interaction

4
1. Introduction General Process of WS Usage
5
1. Introduction uhh correlation to WSMO
Agent (human or machine)
WS Interface
WS Grounding
Web Service
6
2. Web Service Architecture Meta Model of
Architecture
Architecture? More a collection of WS related
aspects..
7
2. Web Service Architecture the Models Message
Orientated Model (MOM)
8
2. Web Service Architecture the Models Message
Orientated Model (MOM)

• A Conceptual Model for aspects related to
  messages
• Some important notions
• Message the basic unit of data sent from one Web
  services agent to another in the context of Web
  services
• M. Transport mechanism that may be used by agents
  to deliver messages.
• Delivery Policy constrains the methods by which
  messages are delivered
• M. Correlation allows a message to be associated
  with a particular purpose or context
• MEP A template, devoid of application
  semantics, that describes a generic pattern for
  the exchange of messages between agents
• gt Nothing really new

9
2. Web Service Architecture the Models Service
Orientated Model (SOM)
10
2. Web Service Architecture the Models Service
Orientated Model (SOM)

• A Conceptual Model for aspects related to
  Services
• Some important notions
• Service abstract resource that represents a
  capability of performing tasks that represents a
  coherent functionality of a provider. Is
  implemented by concrete agent.
• Service Task an action or combination of actions
  that is associated with a desired goal state.
  Performing the task involves executing the
  actions, and is intended to achieve a particular
  goal state
• Action any action that may be performed by an
  agent
• Goal State state of some service or resource that
  is desireable from some
• person or organization's point of view
• Service Role intermediate abstraction between a
  Service and a Task.
• gt only definitions, not a functional model

11
2. Web Service Architecture the Models Service
Orientated Model (SOM)

• Some important notions (cont.)
• Serv. Descript. machine-processable description
  of a Service. May be realized as a set of XML
  description documents.
• Semantics is the behavior expected when
  interacting with the service, expressing a
  contract between requester and provider.
  Describes the intended real-world effect of
  invoking the service.
• Serv. Interface abstract boundary that a service
  exposes, defines the types of messages and the
  message exchange patterns that are involved in
  interacting with the service.
• Capability named piece of functionality (or
  feature) that is declared as supported or
  requested by an agent.
• Choreography defines the sequence and conditions
  under which multiple cooperating independent
  agents exchange messages in order to perform a
  task to achieve a goal state.
• gt (Nearly) equivalent to WSMO WS Interface in
  v0,2
• gt only definitions, but no functional
  specification

12
2. Web Service Architecture the Models
Resource Orientated Model (ROM)

• Some important notions
• Resource anything that can have an identifier
  (unambiguous name).
• Resource Description machine readable data that
  may permit resources to be discovered
• Discovery locating a machine-processable
  description of a Web service-related resource
  that may have been previously unknown and that
  meets certain functional criteria. It involves
  matching a set of functional and other criteria
  with a set of resource descriptions.

13
2. Web Service Architecture the Models Policy
Model (PM)
14
2. Web Service Architecture the Models Policy
Model (PM)

• A Conceptual Model for aspects related to
  Policies, i.e. Security and Quality of Services
• Some important notions
• Policy a constraint on the behavior of agents or
  people or organizations.
• Permission kind of policy that prescribes the
  allowed actions and states of an agent and/or
  resource, i.e. what it is expected to do
• Perm. Guard a mechanism deployed on behalf of an
  owner to enforce permission policies
• Obligation kind of policy that prescribes actions
  and/or states of an agent and/or resource, i.e.
  what it is required to do
• Oblig. Guard a mechanism deployed on behalf of
  an owner to enforce permission policies
• gt Only Notions, No Solutions (goes for all
  Models)

15
3. Related Aspects Discussion of the following
aspects

• Service Orientated Architecture
• Web Service Technologies
• Using Web Services
• Web Service Discovery
• Web Service Semantics
• Web Service Security
• P2P Interaction
• Web Service Reliability
• Web Service Management
• Here mentioning of aspects, but no solutions /
  recommendations

16
3. Related Aspects 3.1 Service Orientated
Architecture

• Distributed Systems
• discrete agents in different processing
  environments that work together
• Have to communicate
• therefore
• Service Orientated Architecture
• Logical view abstract, functional view of actual
  implementation
• Message Orientation service interaction formally
  defined by messages they interchange
• Description Orientation services are described
  by machine-processable meta-data (only externally
  visible behavior).
• Network Orientation services interact via
  network
• Platform Neutral messages are platform neutral
  XML as format
• Arising Problems
• Latency Reliability
• Partial failure
• Updatability

17
3. Related Aspects 3.2. Web Service Technologies
XML, SOAP, WSL
18
3. Related Aspects 3.3 Using Web Services

• 4 stages, see beginning
• Partners get to know each other
• Requester is initiator gt WS Discovery
• Provider is initiator, i.e. push-scenario
• Partners agree on Service Description Semantics
  
• WSA does not use ontologies for WSMO ontologies
  have to be interoperable
• Different scenarios how to communicate the used
  Semantics one partner provides it, a 3rd party
  (i.e. standard), or direct communication
• The agent (i.e. concrete implementation) is
  aligned to the input of the Service Description
  
• Means that WS Description and Implementation must
  fit
• In WSMO 1 WS Description for 1 Service,
  correctness left to developer
• Req. lt-gt Provider agents exchange SOAP messages

19
3. Related Aspects 3.4 Web Services Discovery
"the act of locating a machine-processable
description of a Web service that may has been
previously unknown and that meets certain
functional criteria. "

• Functional Description machine-readable
  description, by words lt Meta Data lt OWL-S lt
  WSMO, should be
• web friendly
• unambiguous
• capable, i.e. expressive enough
• Discovery Service logical rule that matches
  Capability with Goals

• Types of Discovery Services
• Manual vs. automatic
• Centralized vs. decentralized Registry (UDDI) lt
  Index (Google) lt P2P always trade-offs !!
• Federated Discovery Service like a Meta Search
  Engine

20
3. Related Aspects 3.5 Web Service Semantics

• Basic Requirements for Interaction
• physical connection
• agreement on from of data, semantics of data,
  MEPs
• Further aspects
• Visibility of Message Flows, i.e. private
  reliable interaction required
• The Semantics of the Architecture Models must be
  clear, i.e. partners must know what they are
  talking about (see meta-ontology in WSMO)
• Meta-Data are the essential thing in SOA and thus
  for WS, but they are not mature yet for
  industrial strength gt Requirements
• Identification of real-world entities by messages
  (Ontologies)
• Identification of the effects, i.e. changes of
  state of the world, when applying a Web Services
  (central aspect of WSMO)
• Services need to understand the data the are
  dealing with (Ontologies). This is needed for
  every data element used in a WS.

21
3. Related Aspects 3.6 Web Service Security

• Security is a Balance of Assessed Risk and Cost
  of Countermeasures
• Important Aspects
• authentication
• role-based access control
• distributed security policy enforcement
• message layer security (needed as a message might
  pass several entities)
• No broadly adopted tools existent (proposal
  XML-based security mechanisms)

• Aspects of WS Security
• Authentication Mechanism
• Authorization (resource access management)
• Data Integrity Confidentiality
• Integrity of Transactions Communications
• Message End2End Integrity and Confidentiality
• Audit Trails (trace user access / behavior)
• Distributed Security Policy Enforcement

22
3. Related Aspects 3.7 P2P Interaction

• Basic Requirements for P2P Interaction
• P2P Message Exchange Patterns
• WS must have persistent identity
• P2P Discovery, i.e. suitable expressiveness of WS
  Descriptions
• MEP
• Defines a general communication pattern for P2P
  Interaction
• Partners can subscribe to it
• An Agent (i.e. Service or its concrete
  implementation) has to have
• unique persistent identifier
• clarify role (Requester or Provider)
• a Description (here Grounding) that allows
  autonomous acting
• Semantics (definition of meanings) for supporting
  P2P Discovery

23
3. Related Aspects 3.8 Web Service Reliability

• Errors, unpredictability is inescapable gt
  techniques for establishing Reliability
• Message Reliability
• Aspects
• Same Message received as sent? i.e. data
  correctness
• Conform to message format required?
• Conform to business process? i.e.
  choreography-check
• similar techniques as Network Transport, e.g.
  TCP-Acknowledgements
• Service Reliability
• means is service available / a reliable
  provider?
• basic technology Transactional Context
  Management
• Conversation Management, incl. failure handling
  compensation
• Not further elaborated
• also monitoring of service choreographies (here
  sequence and conditions under which multiple
  cooperating independent agents exchange messages)
  
• could be controlled by intermediaries

24
3. Related Aspects 3.9 Web Service Management

• About monitoring, controlling, and reporting of
  service qualities and usage.
• Important Aspects
• Availability, Performance, Accessibility
• Service Usage Measurement frequency, duration,
  scope, functional extent

Proposal Definition of WS Management Policies
IN WSMO WS-non-functional Properties
(D2v02.6.1)
25
3. Related Aspects 3.10 Web Service and EDI
Transaction Tracking

• EAI as main application areas of Web Services
• EDI one of todays standards
• Might be good to look at expectations on WS of
  EDI users
• When something goes wrong
• EDI does not tell what went wrong gt should be
  there
• E.g. support for queries like When was that
  message sent and was it received? should recall
  the answer The message was delivered to company
  B's mailbox on Dec 24 but they have not as yet
  downloaded the message".
• gt Solution Tracking
• well, not new but more complex in real-world
  scenarios
• Requirements
• uniform tracking queries interface (E1 should be
  able to query externally visible messaging with
  E2), i.e. policies needed
• standard IDs for transactions individual
  messages
• techniques to establish trust relationships
  between partners in policies
• Thereby URI-concept of the Web as potential

26
4. Points for Discussion

• Understanding of Web Services related notions
• gt a terminology glossary is needed for WSMO
• In what way do we / can we / must we adopt to the
  Doc?
• What to do with Related Aspects?
• gt WSMO needs
• Identify Questions / Problems arising within SWS
• State rationalize the approach for solution