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/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 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

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: Messagethe basic unit of data sent from one Web services agent to another in the context of Web services M. Transportmechanism that may be used by agents to deliver messages. Delivery Policyconstrains the methods by which messages are delivered M. Correlationallows 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

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: Serviceabstract resource that represents a capability of performing tasks that represents a coherent functionality of a provider. Is implemented by concrete agent. Service Taskan 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 Statestate of some service or resource that is desireable from some person or organization's point of view Service Roleintermediate abstraction between a Service and a Task. … => 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. Interfaceabstract 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. Choreographydefines 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

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. Permissionkind of policy that prescribes the allowed actions and states of an agent and/or resource, i.e. what it is expected to do Perm. Guarda mechanism deployed on behalf of an owner to enforce permission policies Obligationkind 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)

15. 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.P2P Interaction 8.Web Service Reliability 9.Web Service Management Here: mentioning of aspects, but no solutions / recommendations

16. 3. Related Aspects 3.1 Service Orientated Architecture -Distributed Systems odiscrete agents in different processing environments that work together oHave 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: oLatency & Reliability oPartial failure oUpdatability

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

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

20. 3. Related Aspects 3.5 Web Service Semantics -Basic Requirements for Interaction: ophysical connection oagreement 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: oIdentification of real-world entities by messages (Ontologies) oIdentification of the effects, i.e. changes of state of the world, when applying a Web Services (central aspect of WSMO) oServices 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 : oauthentication orole-based access control odistributed security policy enforcement omessage 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: oP2P Message Exchange Patterns oWS must have persistent identity oP2P Discovery, i.e. suitable expressiveness of WS Descriptions -MEP: oDefines a general communication pattern for P2P Interaction oPartners can “subscribe” to it - An Agent (i.e. Service or its concrete implementation) has to have: ounique & persistent identifier oclarify role (Requester or Provider) oa Description (here: Grounding) that allows autonomous acting oSemantics (definition of meanings) for supporting P2P Discovery

23. 3. Related Aspects 3.8 Web Service Reliability Errors, unpredictability is inescapable => techniques for “establishing” Reliability: Message Reliability: oAspects: 1.Same Message received as sent? – i.e. data correctness 2.Conform to message format required? 3.Conform to business process? – i.e. choreography-check osimilar techniques as Network Transport, e.g. TCP-Acknowledgements Service Reliability: omeans: is service available / a reliable provider? obasic technology: Transactional Context Management -Conversation Management, incl. failure handling & compensation -Not further elaborated oalso: monitoring of service choreographies (here: sequence and conditions under which multiple cooperating independent agents exchange messages) ocould 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 : oAvailability, Performance, Accessibility oService 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 today’s standards -Might be good to look at expectations on WS of EDI users When something goes wrong: oEDI does not tell what went wrong => should be there oE.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 owell, not new – but more complex in real-world scenarios oRequirements -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 oThereby: URI-concept of the Web as potential

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