1 Web Service Architecture Working Draft 學生 : 鄭偉豪 指導老師 : 葉慶隆 教授 報告日期 :2003/03/20 Editors: Michael Champion, Software AG Chris Ferris, IBM Eric Newcomer, Iona David Orchard, BEA Systems

2 Introduction Web services provide a standard means of communication among different software applications,running on a variety of platforms and/or frameworks The Web services reference architecture 1. identifies the functional components, 2. defines the relationships among those components, 3. and establishes a set of constraints upon each to effect the desired properties of the overall architecture.

3 The Need for an Architecture The generalized term "Web services" does not currently describe a coherent or necessarily consistent set of technologies, architectures, or even visions. What we think of as "Web services", including: 1. "Distributed Objects" or "Application Integration" 2. EDI / B2B 3. The World Wide Web itself The Web has proven enormously popular, scalable, and interoperable, but it too presents many challenges -- reliability, security, database-level transactions

4 2 What is a Web service? Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols

5 3 Architecture Overview 3.1 Basic Architecture 3.2 Extended Web Services Architecture

6 3.1 Basic Architecture(Cont) The basic architecture includes Web services technologies capable of: 1. Exchanging messages 2. Describing Web services 3. Publishing and discovering Web service descriptions The basic Web service architecture models the interactions between agents performing any of three roles

7 3.1 Basic Architecture(Cont) Requesters and providers interact using one or more message exchange patterns (MEPs) that define the sequence of one or more messages exchanged between them.(data type,structure information,identifies the MEP)

8 3.1 Basic Architecture(Cont) Software agents in the basic architecture can take on one or all of the following roles: 1. Service requester 2. Service provider 3. Discovery agency

9 3.1 Basic Architecture(Cont) Service Oriented Architecture The figure above illustrates the basic Web services architecture

Basic Architecture(Cont) A message is defined as a construct that can include zero or more headers, an envelope, data within the envelope and data external to the envelope. The header part of a message can include information pertinent to extended Web services functionality,such as security, transaction context, orchestration information, or message routing information. The data part of a message contains the message content or data.

Basic Architecture Service Oriented Architecture The figure above illustrates the relationships between requesters, providers, services, descriptions, and discovery services in the case where agents take on both requester and provider roles

Components The Service: A web service is a software module deployed on network accessible platform provided by service provider The Service Description: The service description contains the details of the interface and implementation of the service. This includes its data types, operations, binding information, and network location

Roles Service Provider: From a business perspective, this is the owner of the service. Service Requestor: From a business perspective, this is the business that requires certain function to be satisfied Discovery Agency: This is a searchable set of service descriptions. 1. A discovery agency can support both the pattern where it has descriptions sent to it and where the agency actively inspects public providers for descriptions

Operations In order for an application to take advantage of Web services, three behaviors must take place 1. Publish 2. Find 3. Interact

Extended Web Services Architecture The extended Web services architecture incorporates additional features and functionality by extending the technologies and components defined within the basic Web services architecture.

Features Features are..... A Feature is specified in the abstract, and is realized through one or more bindings, Message Exchange Patterns, or Modules.. Here is a partial list of Features 1. Message exchange pattern(MEP) 2. Caching 3. Message integrity 4. Message routing 5. Asynchronous messaging

Packaging For some applications, a purely XML-based representation of the payload is awkward or inefficient The most common packaging tactic in such cases is to introduce a multipart representation which carries the SOAP envelope and its related data

Transactions The fundamental characteristic of a transaction is the ability to join multiple actions into the same unit of work The transactional unit of work is responsible for ensuring that any state changes performed by participating Web services are either made permanent or undone. Two major cases of context management need to be addressed: 1. Where communication sessions (or conversations) are available to maintain shared state 2. Where communication sessions (or conversations) are not available to maintain shared state

Publish/Subscribe There are a number of mechanisms that can be used to support the distribution of messages 1. a publisher may only support one subscriber, in which case simple one-way or sync request/response may be used 2. When multiple publishers and subscribers are allowed, message distribution may occur at the protocol level 3. though an intermediary distribution service (e.g. a web service) that takes on the responsibility of distributing the messages to interested parties

Choreography(Cont) Choreographies define how multiple web services are used together, specifying the linkages and usage patterns involved. A choreography definition describes the sequence and conditions which control how the interactions occur.

Choreography Example uses of choreography definitions include: 1. Service Composition 2. Workflow 3. Linking businesses through Web Services A standard choreography definition language provides significant benefits 1. Complements WSDL 2. Standardized choreographies

Semantics Semantics in web services provide formal documentation of meaning. 1.Rights and obligations of parties 2.Who is doing what to whom 3.Effect of invoking services Preconditions,consequences, Expected effects of actions 4.Notable events 5.Definition of terms references to external ontologies local definitions specific to the agreement

Diagrammatic representation of features

Flows Service Oriented Architecture Derivate Patterns Peer to Peer

Flows Service Oriented Architecture Derivate Patterns Direct interaction

Flows Service Oriented Architecture Derivate Patterns intermediary

Flows NEW Service Oriented Architecture Derivate Patterns one way message

28 4 Web Services Stacks To ensure interoperability when performing the publish, find and bind operations expressed in the Service Oriented Architecture (SOA) diagram; conceptual and technical standards must be defined for each role and type of interaction This section will explore each of roles and interactions in order identify each relevant stack of technologies

Wire "Stack" The wire stack encapsulates the concepts and technologies dealing with the actual physical exchange of information between any of the roles in the SOA diagram. This includes the variety network transport, message packaging and message extensions that may be utilized to facilitate data exchange

30 Wire

Transport Web services that are publicly available on the Internet use commonly deployed network protocols. Because of its ubiquity, HTTP is the de facto standard network protocol for Internet-available web services. Other Internet protocols may be supported including SMTP and FTP.

Packaging Packaging, represents the technologies that may be used to package information being exchanged SOAP consists of four fundamental components 1. an envelop 2. a set of encoding rules 3. a convention for representing remote procedure calls (RPC) and responses 4. a set of rules for using SOAP with HTTP

Packaging SOAP is currently the de facto standard for XML messaging for a number of reasons. 1. SOAP is relatively simple, defining a thin layer that builds on top of existing network technologies such as HTTP 2. SOAP is flexible and extensible 3. SOAP is based on XML. 4. SOAP enjoys broad industry and developer community support

Extensions Extensions provides a framework that allows additional information to be attached to Web service messages representing a variety of additional concerns; such as context, routing, policy, etc.

XML Messaging with SOAP(cont)

XML Messaging with SOAP Application integration with SOAP can be achieved by using four basic steps 1. A service requestor’s application creates a SOAP message. 2. The SOAP runtime is responsible for converting the XML Message into programming language specific objects 3. The web service is responsible for processing the request message and formulating a response 4. The response message is received by the networking infrastructure on the service requestor’s node

Interactions 1. One way: Message sent from requestor to provider. Provider may or may not return a response 2. Conversational: Requester and Provider exchange multiple messages.Can be defined by choreography language 3. Many-to-Many: Requester sends message to many providers. Or, service provider responds to many requestors. Can be defined by choreography language

Description "Stack“

Descriptions Applying to a Particular Web Service

Interface A service interface definition is an abstract or reusable service definition that may be instantiated and referenced by multiple service implementation definitions. Service interfaces may be defined by industry standards organizations, such as RosettaNet or HL7 for the health industry. The service interface contains elements that comprise the reusable portion of the service description:binding, portType, message and type elements

Implementation The service implementation definition describes how a particular service interface is implemented by a given service provider. also describes its location so that a requester can interact with it.

Policy Policy for Web services consists of facts, or assertions, and rules that apply to a particular Web service. The policy description layer is where the additional description necessary to specify the business context, qualities of service, security requirements and offerings, and management requirements.

Presentation This description could be used to render the service on a variety of devices including phones, PDAs, and systems.

Discovery Agencies "Stack"

Discovery Agencies "Stack" A web service cannot be discovered if it has not been published, service discovery depends upon service publication.

Service Publication A service description can be published using a variety of mechanisms. These various mechanisms provide different capabilities depending on how dynamic the application using the service is intended to be.

Publishing Service Descriptions Internal Enterprise Application UDDI registry Portal UDDI registry Partner Catalog UDDI registry e-Marketplace UDDI Business Registry UDDI registry

Service Discovery -- Acquiring Service Descriptions Service requestors can retrieve a service description at design time or runtime from a Web page (URL), a service description repository, a simple service registry or a UDDI registry.

Overarching Concerns

Realization in Web Services Architecture

The Complete Web Services "Stack"