w3c web service architecture - critical summary - from: w3c web service architecture work group...

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

Contents

1. Introduction: • What is a Web Service? • Basic Notion of WSA

2. The “Architecture” • Overall “Architecture”• Message Orientated Model • Service Orientated Model• Resource Orientated Model • Policy Orientated Model

3. “Related Aspects” (called: Stakeholder Perspectives) 4. Discussion Points

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

1. Introduction

General Process of WS Usage

1. Introduction

uhh … correlation to WSMO

Agent (human or machine)

WS Interface

WS Grounding

Web Service

2. Web Service Architecture

Meta Model of Architecture

Architecture? More a collection of WS related aspects..

2. Web Service Architecture – the Models

Message Orientated Model (MOM)


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

=> Nothing really new


Service Orientated Model (SOM)


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

someperson or organization's point of view

• Service Role intermediate abstraction between a Service and a Task.• …

=> only definitions, not a functional model


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.

=> (Nearly) equivalent to WSMO WS Interface in v0,2

=> only definitions, but no functional specification


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.


Policy Model (PM)


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

=> Only Notions, No Solutions (goes for all Models)

3. Related Aspects

“Discussion” of the following aspects:

1. Service Orientated Architecture2. Web Service Technologies 3. Using Web Services 4. Web Service Discovery 5. Web Service Semantics 6. Web Service Security 7. P2P Interaction 8. Web Service Reliability 9. Web Service Management

Here: mentioning of aspects, but no solutions / recommendations

3. Related Aspects

3.1 Service Orientated Architecture

- Distributed Systems o discrete agents in different processing environments that work togethero Have to communicatetherefore

- 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:o Latency & Reliabilityo Partial failureo Updatability

3. Related Aspects

3.2. Web Service Technologies

XML, SOAP, WSL

3. Related Aspects

3.3 Using Web Services4 stages, see beginning

1) Partners get to know each other a. Requester is initiator => WS Discovery b. Provider is initiator, i.e. push-scenario

2) 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

3) 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

4) Req. <-> Provider agents exchange SOAP messages

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 < Meta Data < OWL-S < 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) < Index (Google) < P2P … always trade-offs !!

• Federated Discovery Service: like a Meta Search Engine

3. Related Aspects

3.5 Web Service Semantics - Basic Requirements for Interaction:

o physical connectiono 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 => Requirements: o Identification of real-world entities by messages (Ontologies) o Identification of the effects, i.e. changes of state of the world, when

applying a Web Services (central aspect of WSMO) o Services need to “understand” the data the are dealing with

(Ontologies). This is needed for every data element used in a WS.

3. Related Aspects

3.6 Web Service Security - “Security is a Balance of Assessed Risk and Cost of Countermeasures” - Important Aspects :

o authentication o role-based access controlo distributed security policy enforcement o 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

3. Related Aspects

3.7 P2P Interaction - Basic Requirements for P2P Interaction:

o P2P Message Exchange Patterns o WS must have persistent identityo P2P Discovery, i.e. suitable expressiveness of WS Descriptions

- MEP:o Defines a general communication pattern for P2P Interaction o Partners can “subscribe” to it

- An Agent (i.e. Service or its concrete implementation) has to have: o unique & persistent identifiero clarify role (Requester or Provider)o a Description (here: Grounding) that allows autonomous acting o Semantics (definition of meanings) for supporting P2P Discovery

3. Related Aspects

3.8 Web Service Reliability

Errors, unpredictability is inescapable => techniques for “establishing” Reliability: • Message Reliability:

o Aspects: 1. Same Message received as sent? – i.e. data correctness2. Conform to message format required? 3. Conform to business process? – i.e. choreography-check

o similar techniques as Network Transport, e.g. TCP-Acknowledgements • Service Reliability:

o means: is service available / a reliable provider? o basic technology: Transactional Context Management

- Conversation Management, incl. failure handling & compensation - Not further elaborated

o also: monitoring of service choreographies (here: sequence and conditions under which multiple cooperating independent agents exchange messages)

o could be „controlled“ by intermediaries

3. Related Aspects

3.9 Web Service Management- About: monitoring, controlling, and reporting of service qualities and usage. - Important Aspects :

o Availability, Performance, Accessibility o Service Usage Measurement: frequency, duration, scope, functional extent

Proposal: Definition of WS Management Policies

IN WSMO: WS-non-functional Properties (D2v02.6.1)

3. Related Aspects

3.10 Web Service and EDI: Transaction Tracking

EAI as main application areas of Web Services - EDI: one of today’s standards- Might be good to look at expectations on WS of EDI users • When something goes wrong:

o EDI does not tell what went wrong => should be there o 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".

=> Solution: Tracking o well, not new – but more complex in real-world scenarios o 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

o Thereby: URI-concept of the Web as potential

4. Points for Discussion

- Understanding of Web Services & related notions => 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”? => WSMO needs • Identify Questions / Problems arising within SWS • State & rationalize the approach for solution

w3c web service architecture - critical summary - from: w3c web service architecture work group...

Documents