W 3 C Web Service Architecture Critical Summary

W 3 C Web Service Architecture - Critical Summary From: W 3 C Web Service Architecture Work Group Version: Working group Note 11 Feb 2004 Web: http: //www. w 3 c. org/TR/ws-arch/ • current is 4 th work draft • W 3 C 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? More a collection of WS related aspects. .

2. Web Service Architecture – the Models Message Orientated Model (MOM)

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

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

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.

2. Web Service Architecture – the Models Service Orientated Model (SOM) - Some important notions (cont. ): •

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 machineprocessable 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.

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

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 Permission a constraint on the behavior of agents or people or organizations. kind of policy that prescribes the allowed actions and states of an agent and/or resource, i. e. what it is expected to do

3. Related Aspects “Discussion” of the following aspects: 1. Service Orientated Architecture 2. Web Service Technologies 3. Using Web Services 4. Web Service Discovery 5. Web Service Semantics 6. Web Service Security 7. P 2 P 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 together o 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: o Latency & Reliability o Partial failure o Updatability

3. Related Aspects 3. 2. Web Service Technologies XML, SOAP, WSL

3. Related Aspects 3. 3 Using Web Services 4 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 1. WSA does not use ontologies; for WSMO: ontologies have to be interoperable 2. Different scenarios how to communicate the used Semantics: one partner provides it, a 3 rd party (i. e. standard), or direct communication 3) The agent (i. e. concrete implementation) is “aligned” to the input of the Service Description 1. Means that WS Description and Implementation must fit 2. 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: machinereadable 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) < P 2 P … 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 connection o 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 o - 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 End 2 End Integrity and Confidentiality Audit Trails (trace user access / behavior) Distributed Security Policy Enforcement

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

3. Related Aspects 3. 8 Web Service Reliability Errors, unpredictability is inescapable => techniques for “establishing” Reliability: • Message Reliability: o Aspects: 1. 2. 3. • Same Message received as sent? – i. e. data correctness Conform to message format required? 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 o Availability, Performance, Accessibility Service Usage Measurement: frequency, duration, scope, functional extent Proposal: Definition of WS Management Policies IN WSMO: WS-non-functional Properties (D 2 v 02. 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 (E 1 should be able to query externally visible messaging with E 2), 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