Web services communication flow Diagram:
- To understand how web services work, lets take an example.
- Scenario – A Citibank customer wants to pay his Vodafone phone bill through the bank’s website.
- 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
- 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
- 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.
- 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.
- The Vodafone Bill Payment service acknowledges success or failure of the transaction
- The above example brings out the interplay of:
- Messaging protocols – SOAP
- Programming standards – Interface based on WSDL standard
- Network registration – Information stored as per UDDI standard
Note: 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
Subscribe to our youtube channel to get new updates..!
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