Web Services Concepts


Objectives

nAfter completing this lesson, you should be able to do the following:
qUnderstand power of web services
qUnderstand WSDL
qUnderstand SOAP

Introducing Web Services


nWeb services are:
qSelf-describing business functions
qAccessible from any Web-connected device using:
nMessaging Protocols – The messaging protocols are standards-based and are platform independent.  These enable one service to call another one  - SOAP over HTTP, JMS
nProgramming standards – The underlying programming standards help create services that conform to a predefined structure.  This means it is possible to figure out what the service does in a platform and language independent way. - WSDL
nNetwork registration – The services can be searched in a common way - UDDI

Web Services Communication Flow

Web Services Communication Flow Example

nTo understand how web services work, lets take an example.
n
nScenario – A Citibank customer wants to pay his Vodafone phone bill through the bank’s website. 
n
nSolution
1.First, the Vodafone IT team would create a service that allows one to pay their bills through a web service.  This service may be implemented in any way they please, using ADF, POJO, PL/SQL etc.  However, the service needs to expose its interface according to WSDL specification
2.In order to facilitate clients to be able to find this service, the Vodafone team publishes this WSDL to a web services directory.  The directory is capable of storing different kind of information like the request and response messages, version, publisher details, type of service etc.  All this information is structured in a standard way so that interested parties can search or discover them.  This common format is the UDDI
3.Citibank IT team, which is developing their website, and want to provide this service to their customer, finds the service developed by Vodafone team.  This completes the setup.
4.When a customer chooses to pay his bill, the required information is sent to the Vodafone Bill Payment web service.  This communication is done using a SOAP message.  As SOAP can work over HTTP, which is the most used protocol on the Internet, this invocation can utilize the power of Internet
5.The Vodafone Bill Payment service acknowledges success or failure of the transaction
●
nThe above example brings out the interplay of:
nMessaging protocols - SOAP
nProgramming standards – Interface based on WSDL standard
nNetwork registration – Information stored as per UDDI standard
n
nNote: A Public Registry, while a really cool concept, didn’t really take off as expected.  However, the concept itself found takers at organization level and typically an organization that takes its SOA seriously will have a registry setup.

 
Describing a web service

Lets understand what it takes to describe a web service.  If we can appreciate these, then understanding why WSDL looks like it does would be that much simpler.
•Requirement 1: We need to tell what is the location of this web service
•Requirement 2: We need to tell what is the language  the web service speaks
•Requirement 3: We need to tell what functions or operations this web service is providing
•Requirement 4: We need to tell what input and output parameters the service takes
•Requirement 5: We need to tell the datatype of these parameters

WSDL Enters….

nA WSDL document is just a simple XML document.
nIt contains set of definitions to describe a web service.
nWSDL document fulfills all the above requirements
qRequirement 1 – Where is the service hosted
n<service>
qRequirement 2 – What protocol to use to talk to the service
n<binding>
qRequirement 3 – What are the operations
n<portType>
qRequirement 4 – What are the parameters
n<message>
qRequirement 5 – What is the datatype of the messages
n<type>

Introducing WSDL

nWSDL stands for Web Services Description Language
nWSDL is written in XML
nWSDL is used to describe Web services
nWSDL is also used to locate Web services
WSDL is a W3C recommendation

WSDL Document Structure


WSDL Ports

nThe <portType> element is the most important WSDL element.
nIt describes a web service, the operations that can be performed, and the messages that are involved.
nThe <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language


Operation Types


One-way operation type


The operation can receive a message but will not return a response


Request-response operation type

The operation can receive a request and will return a response


nNow, a web service operation can take only one parameter.  But I want to pass multiple parameters……what do I need to do 

WSDL Messages

nThe <message> element defines the data elements of an operation.
nEach message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language. 

nI want to pass a complex object to my web service……what do I need to do 

WSDL Types

nThe <types> element defines the data type that are used by the web service.
nFor maximum platform neutrality, WSDL uses XML Schema syntax to define data types.


nI want my web service to be accessible to a HTTP client, as well as to a RMI client and a SOAP client……what do I need to do 

WSDL Bindings

nThe <binding> element defines the message format and protocol details for each port.



nbinding
qname – can be anything
qType – points to port
nsoap:binding
qStyle – rpc or document
qTransport – soap protocol to use
noperation
qDefines each operation the the service exposes

WSDL Bindings

nThe <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.
nThe bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP.
nThe bindings provide concrete information on what protocol is being used to transfer portType operations.
nFor SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.
qWSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify SOAPspecific details, including SOAP headers, SOAP encoding styles, and the SOAPAction HTTP header. The SOAP extension elements include:
nsoap:binding
nsoap:operation
nsoap:body
nYou can specify multiple bindings for a single portType.

WSDL Services

nThe <services> element connects the binding to an actual URL where the service is available.


A service element describes a Web service as a collection of port elements. A port element defines a specific network address for a binding. The sample below shows the basic outline of a service that supplies an address for a SOAP binding:
<service name="ServiceName">
   <port name="PortName" binding="BindingRef">
      <soap:address location="URL"/>
   </port>
</service>
The ServiceName sets the name of the service. The PortName sets the name of the specific address. The BindingRef refers to the name of a binding element. The BindingRef must be namespace qualified if the targetNamespace for the WSDL definitions element is not the same as the default namespace.

Complete WSDL Example


SOAP

nSOAP stands for Simple Object Access Protocol
nSOAP is a communication protocol
nSOAP is for communication between applications
nSOAP is a format for sending messages
nSOAP communicates via Internet
nSOAP is platform independent
nSOAP is language independent
nSOAP is based on XML
nRelies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission.
nSOAP is a W3C recommendation

SOAP Message Structure


SOAP Request 


SOAP Response


UDDI

nUDDI stands for Universal Description, Discovery and Integration.
nThe UDDI specification enables businesses to quickly, easily, and dynamically find and transact with one another.
nUDDI enables a business to
1.Describe its business and its services,
2.Discover other businesses that offer desired services
3.Integrate with these other businesses. 

UDDI Data Model

The information that makes up a UDDI registry consists of instances of four core data structure types, the businessEntity, the businessService, the bindingTemplate and the tModel, together with instances of additional data structure types defined in the UDDI API Schema.
Each of the core data structure types is used to express specific types of data, arranged in the relationship shown 


Why do we need a registry

nThe ability to register, discover, and govern Web services is an essential requirement for any Service Oriented Architecture (SOA) implementation.
nA highly available environment contains multiple application server nodes, multiple instances, and multiple processes. Regardless of where the services will be deployed they have to be flexible enough to run anywhere without requiring changes to the actual process implementation.
nThis need may not be fully appreciated in the early stages of an SOA roll-out when dealing with a small number of services.
nHowever, large organizations will typically need to support a large number of Web services, and as the number of services deployed grows to dozens or hundreds, centralized facilities for access and control of service metadata and artifacts becomes critical.
A service registry provides these capabilities and is a key infrastructural component and cornerstone for SOA deployments

Registry and UDDI

UDDI defines a framework to enable the establishment of service registries to provide distributed directory service to the producers and consumers of Web services. It includes a common set of SOAP-based APIs to support registration and advertisement of Web services by service producers, and to facilitate the searching and lookup of Web services by service consumers.

Resources





Leave a Reply

Subscribe to Posts | Subscribe to Comments

About This Site

Howdy! My name is Suersh Rohan and I am the developer and maintainer of this blog. It mainly consists of my thoughts and opinions on the technologies I learn,use and develop with.
Powered by Blogger.

- Copyright © My Code Snapshots -Metrominimalist- Powered by Blogger - Designed by Suresh Rohan -