Topic6 Basic Web Services Technology

Basic Web Services Technology Sanjoy Sanyal (Tech for NonGeek)

Basic Technology Components XML SOAP WSDL UDDI Sanjoy Sanyal (Tech for NonGeek)

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

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

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

SOAP Sanjoy Sanyal (Tech for NonGeek)

SOAP specifications A message format for one-way communication, describing how information can be packaged into XML Conventions to implement RPC interaction pattern, defining how remote services can be invoked Set of rules that any entity that processes a SOAP message must follow Description of how a SOAP message should be transported on top of HTTP and SMTP Sanjoy Sanyal (Tech for NonGeek)

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

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

SOAP messages: encoding rules SOAP does not impose any specific form of encoding SOAP 1.2 does specify SOAP encoding which defines how data structures can be serialized into XML Applications are free to agree on other encoding (literal encoding) Sanjoy Sanyal (Tech for NonGeek)

SOAP message processing Every message has: A sender, An ultimate receiver and a number of intermediary nodes that process and route Nodes are typically the middleware architecture: They process the header of the SOAP message A Header block can be assigned to following roles: None: will not be processed by a node (can be read) UltimateReceiver: block is solely meant for the ultimate receiver Next: every node can process the message Header block can have a mustUnderstand flag: A node playing that role must process the block and if it cannot raise a fault Sanjoy Sanyal (Tech for NonGeek)

SOAP: Binding to a Transport protocol SOAP does not impose any transport protocol Typically associated with HTTP or SMTP The specification of which protocol to use is called a binding Functions of the binding: Defines how the message has to be treated using the primitives of the transport protocol (GET/POST etc. for HTTP) Addressing (since the identification of the ultimate receiver is not part of a SOAP message) Routing (since there is no mechanism to describe a SOAP path as a part of a SOAP message) Sanjoy Sanyal (Tech for NonGeek)

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

WSDL Web Services Description Language Sanjoy Sanyal (Tech for NonGeek)

WSDL Goals Specifications as XML documents that describe Web services and service interfaces Role and purpose similar to IDLs with differences: Also needs to define the protocols to access the services Also needs to define the locations at which the service is available Also needs to handle the cope with the complexity of several asynchronous messages used in Web Services Sanjoy Sanyal (Tech for NonGeek)

WSDL Interface Structure Sanjoy Sanyal (Tech for NonGeek) abstract part types WSDL specification messages operations port types concrete part bindings Services & ports Each port type is a logical collection of related operations Each operation defines an exchange of messages The type system allows the data that is being exchanged to be correctly interpreted. By default WSDL uses the same type system as XML Schemas, although a different type system can be specified in necessary InterfaceBindings specifies the message encoding and protocol bindings (for example: interaction style: (RPC style operation/document style) -transport bindings (SOAP/SOAP is typical but not mandatory, HTTP/SMTP given SOAP,) encoding rules) (SOAP encoding/literal encoding) Ports: also called EndPoints combine the InterfaceBinding information to a network address (specified by a URI) Services : logical grouping of Ports

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

WSDL Implications Solicit-response operation: A service can proactively initiate the interaction Separation of abstract and concrete: Different services could combine different interfaces using different bindings and make them available at different addresses Both SOAP with WSDL are generic standards SOAP is a generic envelope to wrap invocations that the applications may make using other tools WSDL is a generic service description for services built using other languages Sanjoy Sanyal (Tech for NonGeek)

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

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

UDDI Goals Specifies a framework for describing and discovering Web services Business registry : sophisticated naming and directory service Defines data structures and APIs for publishing service descriptions in the registry and for querying the registry Universal Business Registry: Worldwide directory for services was the original goal Sanjoy Sanyal (Tech for NonGeek)

Information in a UDDI registry White pages: Listing of organizations, their contact information and the services they provide To find Web services provided by a given business Yellow pages: Classification of both organizations and Web services To find Web services according to a category Green pages: Describes how a given Web service can be invoked Points to description documents stored outside the registry Sanjoy Sanyal (Tech for NonGeek)

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

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

tModel Structure The actual content (Service Description) Resides within an overviewDoc to which the tModel points but which is stored outside the registry overviewDoc can be in any structure and written in any language A tModel once published is assigned a unique key Sanjoy Sanyal (Tech for NonGeek)

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.

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

UDDI & WSDL WSDL interface definitions (specifically port types and protocol bindings) are registered as tModels: whose overviewDoc will point to the corresponding WSDL document Sanjoy Sanyal (Tech for NonGeek) businessEntity businessService bindingTemplate tModel WSDL Service descriptions Service provider

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

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

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.

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

Summary SOAP Interactions in Web Services happens thru SOAP Provides standardized way to encode interaction mechanisms into XML documents Defines transport bindings WSDL Defines interface to a Web Service The interface is specified in terms of methods supported by the Web service, and the corresponding input and output messages UDDI Defines data structures and APIs for publishing service descriptions in the registry and for querying the registry (the material in this topic is based on Web Services: Concepts, Architectures and Applications by Alonso, Casati, Kuno, Machiraju) Sanjoy Sanyal (Tech for NonGeek)

Topic6 Basic Web Services Technology

More Related Content

What's hot (19)

Viewers also liked (7)

Similar to Topic6 Basic Web Services Technology (20)

More from sanjoysanyal (20)

Recently uploaded (20)

Topic6 Basic Web Services Technology