Web Services Presented By : Noam Ben Haim

Agenda Introduction What is a web service Basic Architecture Extended Architecture WS Stacks

Introduction The Need: The expanding WWW is not able to communicate correctly. Distributed Systems – Maturity in the enterprise, only born in WWW. Failure of COM and CORBA to interoperate, lots of security issues over the web.

Introduction The opportunity: evolve of several Web Technologies such as SOAP, XML and WSDL.

What is a Web Service Software system Identified by URI Defined and described using XML Can be discovered XML based messages over internet protocols

Web Services are an Architectural Evolution. Main Frame

Technology Evolution XML Programmability Connectivity HTML Presentation TCP/IP Technology Innovation FTP, , Gopher Web Pages Browse the Web Program the Web Web Services

Some Terminology SOAP: Simple Object Access Protocol (remote invocation) WSDL: Web Service Definition Language (service characteristics) UDDI: Universal Description, Discovery, and Integration (directory) XKMS: XML Key Management Specification (under development) XML:Extensible Markup Language XLANG:Transactional support (under development) ebXML: (e-business XML)

Basic Architecture Various components that comprise a WS “Stack”  Exchanging messages  Describing Web services  Publishing and Discovering WS description The Basic architecture defines an interactions between SW agents

Basic Architecture (cont.) Models interactions between three roles:  Service provider  Service discovery agency  Service requestor Models three operations:  Publish  Find  Bind

Basic Architecture (cont.) Service Requesto r Service Provider Discovery Agency Client Service Service Description find Interact Publish

Basic Architecture (Cont.) Typical scenario:  Service provider hosts a network accessible software module (an implementation of WS)  The service provider defines a service description and publishes it.  The service requestor uses a find operation to retrieve the description from the Disco Agency  The Service requestor uses the description to bind with the service provider.

Basic Architecture (Cont.) Requestors and Providers interact using Message Exchange Patterns (MEP’s) The description includes data types, MEP info and address of the service provider.

Basic Architecture (cont.) The Components:  The Service: the implementation of the WS whose description is the interface. A software module deployed on the network. It exists to be invoked or to interact with service requestor It may also act a a requestor using other WS in its implementation

Basic Architecture (Cont.) The Components:  The Service Description: Contains the details of the interface and implementation Data types, Operations, Binding info, network locations. Metadata : Categorization, etc. Published to a requestor directly or to a Disco Agency

Basic Architecture (Cont.) The Roles:  Service Provider: The platform that hosts access to the service. Acts as a server for the requestor in the MEP  Service Requestor: The application that interacts with the service. Can be played by a browser operated by human or by a program with no UI. Acts as a client.

Basic Architecture (Cont.) The Roles:  The Discovery Agency: A searchable set of service descriptions. Centralized or Distributed. Can be push or pull. Support static and dynamic binding for apps.

Basic Architecture (Cont.) The Operations:  Publish: The service publishes its description such that the requestor can find it.  Find: The service requestor retrieves a service description directly or queries the registry. Can be involved in the design time or run time.

Basic Architecture (Cont.) The Operations:  Interact: The service requestor invokes or initiates an interactions with the service. Single Message One Way, Broadcast, Multi Message conversation, etc. Synchronous or Async.

Extended Architecture Extends the basic architecture with additional features and functionality, extending the technologies and Components.

Extended Architecture (Cont.) List of Features (Partial):  A sync. Messaging  Attachments – packaging of multiple docs together, binary data, etc. (SOAP with Attachments and DIME)  Caching  Long running transactions  Message Authentication – HTTP auth, x.509

Extended Architecture (Cont.) List of Features (Partial):  Message Confidentiality – SSL/TLS, SOAP encryption  Message Integrity – digital signature with SOAP  Management messages  Session

Web Services Stacks The “stack” of technologies create the protocol.

WS Stacks – Wire Stack Wire Stack  Encapsulates the concepts and technologies needed for the actual, physical exchange of information between the roles mentioned before. Network transport Message packaging Message extensions

WS Stacks – Wire Stack

Transport:  HTTP is the de facto standard network protocol for internet available web services.  Intranet domains may use MQSeries, CORBA, etc.  The choice of network technology can be made transparent to the developer and consumer of the service

WS Stacks – Wire Stack Packaging:  SOAP is the de facto standard for XML messaging. Relatively simple, thin layer on top of existing network technologies (HTTP). Extensible, allows solutions to be incrementally applied as needed. Based on XML, enjoys a broad support from the community More on SOAP later.

WS Stacks – Wire stack Extensions:  Provides a framework that allows additional information to be attached to WS messages.  SOAP defines a mechanism to incorporate orthogonal extensions (features).  A broad collection of features are already standard, and more to come…

WS Stacks – Wire stack

WS Stacks – Description Stack

A stack of description documents defined using XML Schema. Through the service description a service provider communicates all the specifications for invoking the web service. Uses WSDL for base level service desc.

WS Stacks – Description Stack Interface and implementation:  The messages the service expects and returns, and how to encode the messages and where to send them to.  Minimum service description.

WS Stacks – Description Stack Policy:  defines business context, QoS, security req, etc. Presentation:  how to render the input/output messages on screen for different devices/

WS Stacks – Description Stack The upper levels of this stack are somewhat left for the user to guess…

WS Stacks – Discovery stack

The discovery stack can be implemented with a range of solutions. Service discovery depends on service publication. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery

WS Stacks – Discovery stack Publication:  Several tools exist that help the developer to produce the service description.  Direct publish : send description directl to the user ( , ftp, etc)  UDDI Registry: business context and toxonomies.

WS Stacks – Discovery stack Discovery and publication:  Service requestors can retrieve a service description at design time or run time, from a web page (URL), repository or UDDI registry.  The service requestor uses the description to create SOAP requests to send to the service.

WS Stacks – Discovery stack Inspection:  Inspection technologies such as WSIL provide a de- centralized service discovery method  Local service discovery for ‘local’ web service applications (micro SOAs that don’t leave the box… all else is the same except it limits where it looks for services).  Application integration.  Discovery agents populated by crawlers looking for WSIL documents.  Management topologies of available services (but its not a discovery source).

WS Stacks - Summary

Questions

Bibliography W3C Web services architecture: W3C Web Services Glossary: Web Services Architecture Usage Scenarios :