The document discusses key technologies in basic web services: XML, SOAP, WSDL, and UDDI. SOAP defines standard message formats and protocols for invoking web services. WSDL specifies web service interfaces and operations. UDDI provides a registry for publishing and discovering web services. The document provides an overview of how these standards work together to enable web services functionality.

1. Basic Web Services Technology Sanjoy Sanyal (Tech for NonGeek)

3. SOAP Sanjoy Sanyal (Tech for NonGeek) Application Object (client) SOAP-based middleware Service requestor Application Object (service provider) SOAP-based middleware Service provider SOAP messages exchanged on top of HTTP, SMTP or other transport protocol Converts procedure calls to/from XML messages sent through HTTP or other protocols Clients can invoke Web Services by exchanging SOAP messages Services can exchange messages by means of standardized conventions to turn a service invocation into an XML message, to exchange the message and to turn the XML message back into an actual service invocation

4. WSDL Sanjoy Sanyal (Tech for NonGeek) Application Object (client) SOAP-based middleware Service requestor WSDL of service provider WSDL compiler (client side) WSDL compiler (server side) Application Object (service provider) SOAP-based middleware Service provider stub skeleton The programming interface of a Web service can be specified using WSDL. The interface is specified in terms of methods supported by the Web service, and the corresponding input and output messages WSDL specifications can be compiled into stubs and skeletons, analogous to IDL in conventional middleware. Dashed lines denote steps performed at development time, solid line to those performed at run-time SOAP messages

5. UDDI Sanjoy Sanyal (Tech for NonGeek) Application Object (client) SOAP-based middleware Service requestor Application Object (service provider) SOAP-based middleware stub skeleton SOAP messages (to look for services) Service provider SOAP-based middleware Service descriptions SOAP messages SOAP messages (to publish service descriptions) UDDI standardizes the Web services registry Providers advertise their services in a UDDI registry. Clients (at development or run-time) look for services in the registry, thereby statically or dynamically binding to a service. Then clients can invoke the service

6. SOAP Sanjoy Sanyal (Tech for NonGeek)

8. SOAP message Sanjoy Sanyal (Tech for NonGeek) SOAP envelope SOAP header header block SOAP body body block Applications enclose information in a SOAP envelope Each envelope has a header and a body . Both can have multiple sub-parts in the form of blocks . The header is not mandatory The core of the information that is to be transmitted to the receiver is in the body Any additional information for intermediate processing or value added services (transactional interaction, security) goes into the header

9. SOAP messages: interaction styles Sanjoy Sanyal (Tech for NonGeek) SOAP body PurchaseOrderDocument -product item-quantity SOAP envelope SOAP body Acknowldge document -orderid SOAP envelope Document style interaction The two interacting applications agree upon the structure of the documents to be exchanged SOAP body Methodname OrderGoods SOAP envelope Input parameter 1 Product item Input parameter 1 Quantity SOAP body Method return SOAP envelope Return value Order id RPC style interaction The two interacting applications agree upon the RPC method signature The body of the requesting message includes the name of the procedure being invoked and the input parameters. The body of the response message contains the output parameters

13. Simple SOAP implementation Sanjoy Sanyal (Tech for NonGeek) Client implementation SOAP engine Service requestor Client stub HTTP Engine Invokes the service as a local call Invokes SOAP engine to prepare SOAP message Packages SOAP into HTTP and passes it to an HTTP client that sends it to provider Service implementation SOAP router Service requestor server stub HTTP server Invokes the local procedure of the service implementation Router parses the message, identifies the appropriate stub and delivers the parsed message Passes the content of the HTTP message to the router SOAP supports asynchronous interaction of loosely coupled interactions Any further complications such as two-way synchronous messaging or transactions requires SOAP to be associated with an underlying protocol or middleware that has additional properties

17. Defining a WSDL Interface: Steps Sanjoy Sanyal (Tech for NonGeek) Step 1: Identify and Define all the data structures that will be exchanged as parts of messages between applications Step 2: Define messages that build on data structures. In WSDL each message is divided into parts Step 3: Define operations (also called transmission primitives or interactions). Four basic operations: one-way, request-response, solicit-response, notification One-way and notification operations require a single message . Asynchronous interactions are defined using one-way and notification operations Request-Response and Solicit-Response requires two messages. The former is initiated outside the service and the latter by the service. Synchronous interactions are defined using these operations. Step 4: Group operations into port types Step 5: Define a concrete service by specifying concrete binding, encoding, locations ….

19. Using WSDL Sanjoy Sanyal (Tech for NonGeek) Application Object (client) SOAP-based middleware Service requestor WSDL of service provider WSDL compiler (client side) WSDL compiler (server side) Application Object (service provider) SOAP-based middleware Service provider stub skeleton WSDL documents can be automatically generated thru APIs Dashed lines indicate compile-time activities First, WSDL is generated. Next, stubs and skeletons are generated. SOAP messages WSDL generator 1 2

20. UDDI: Universal Description Discovery Integration Sanjoy Sanyal (Tech for NonGeek)

23. UDDI Data Sanjoy Sanyal (Tech for NonGeek) Type of Data Description businessEntity Describes an organization that provides Web services businessService Describes a group of related Web services offered by a businessEntity,. businessService may correspond to one type of service but provided at multiple addresses, versions, technologies (protocols, bindings) bindingTemplate Describes the technical information necessary to use a particular Web service tModel Stands for “technical model”-generic container for any kind of specification. (for e.g.: WSDL service interface, interaction model…)

24. UDDI Data Sanjoy Sanyal (Tech for NonGeek) businessEntity name contacts description identifiers categories businessService service key name description categories bindingTemplate binding key description address detailed info references to tModels tModel key name description overviewDoc identifiers categories tModel key name description overviewDoc identifiers categories Specs stored at the provider’s site One businessEntity can include One businessService can include Multiple businessServices Multiple bindingTemplates

26. UDDI Registry API Sanjoy Sanyal (Tech for NonGeek) UDDI registries have three main types of users: service providers, service requestors, other registries that need to exchange information UDDI API Description UDDI Inquiry API To find registry entries ( find_business,find_binding,find_tModel) To get details about a specific entity ( get_businessDetail,get_serviceDetail, get_bindingDetail,get_tModelDetail ) UDDI Publishers API Add, Modify, delete entries in the registry ( save_business,save_ service,save_binding,save_tModel,delete_business,delete_service ….) UDDI Security API Get and discard authentication tokens ( get_authToken, discard_authToken ) UDDI Subscription API Monitors changes in a registry by subscribing to track new, modified and deleted entries ( delete_subscription,get_subscriptionResults,get_subscriptions, save_subscriptions ) UDDI Replication API Supports replication of information between registries, so that different registries can be kept synchronized.

27. UDDI Access Points & APIs Sanjoy Sanyal (Tech for NonGeek) Service Requestor Service Provider Web service interface Service descriptions Web service interface Service descriptions Subscription, Replication and Custody transfer APIs SOAP/HTTP SOAP/HTTPS Inquiry API Publishers API UDDI registers maintain different access points (URIs) for requestors, publishers and other registries to separate inquiries that do not require authentication from those they do. Registries interact to transfer the custody of an entity and replicate information. Each entity is owned by a single registry

29. Public and Private Registries Sanjoy Sanyal (Tech for NonGeek) Registry Description Public Provides Open and public access to registry data Private Internal registry isolated behind a firewall Used by organizations to support integration of internal applications Shared/Semi-private Deployed within a controlled environment and shared with trusted partners

30. Web Services at Work Sanjoy Sanyal (Tech for NonGeek) Service implementation SOAP router Service provider server stub HTTP Engine WSDL generator WSDL service descriptions WSDL compiler UDDI publisher 1 2 3 businessEntity businessService bindingTemplate tModel UDDI publisher Inquiry API Publishers API Exposing an internal service as a Web Service Step 1: Generation of WSDL Step 2: Generation of servlet and registration with SOAP router Step 3: Registration in UDDI registry

31. Web Services @ work - Steps Sanjoy Sanyal (Tech for NonGeek) Exposing an internal service as a Web Service Step 1: The interface of the procedure is translated into a description of the Web service by mapping the information into the corresponding WSDL structure Step 2: The generated WSDL is stored at the providers site. A WSDL compiler can then create a server stub (in the form of a servlet in the Java world) and register the servlet with the SOAP router so that the router knows it has to invoke the servlet whenever a certain URI is invoked. Step 3: A tModel is published that refers to the generated WSDL in a UDDI registry accessible to clients. Next, new businessService and a bindingTemplate entities are published providing the address at which the service is available and referencing the tModel. Scenario: WSDL specification has been provided and the service provider wants to offer a service compliant with the standardised interface Step 1: WSDL is retrieved from the UDDI registry, following the pointer in the tModel Step 2: The WSDL compiler generates the code required on the server side. The servlet (in the Java world) is registered with the SOAP router Step 3: Publication of the UDDI registry as above. This time there is no need to register the tModel sine it has already been regsitered.

32. Related Standards Sanjoy Sanyal (Tech for NonGeek) Standard Description WS – Addressing Proposes a protocol-neutral mechanism for specifying endpoint references of services within SOAP messages I mplementation Example : Creating one stateful persistent object for each new client, which manages all the interactions with the client. WS – Routing Allows a way of specifying which intermediaries should be visited by a SOAP message WS - Security Extension to SOAP that defines a SOAP header block (called Security) which is where security information can be included WS - Policy Framework thru which clients and services can express their policies (requirements, capabilities, preferences) WSIF Web Services Invocation Framework – a pluggable framework that allows providers to be added to an existing Web Services infrastructure. This allows a service to be invoked thru a WSDL binding