Ways to access web service

Ways to access web service:

There are two ways to access web service.

• SOAP: - If Service provider knows client: If service provider knows its client then it will provide it’s wsdl to client and client will be able to access web service.

• REST: - Service provider register its WSDL to UDDI and client can access it from UDDI: Web services can register with a UDDI and make themselves available through it for discovery

1.Service provider registers with UDDI.

2.Client searches for service in UDDI.

3.UDDI returns all service providers offering that service.

4.Client chooses service provider

5.UDDI returns WSDL of chosen service provider.

6.Using WSDL of service provider, client accesses web service.

In the web services terms, Representational State Transfer (REST) is a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URIs.
It consists of two components REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.

In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol. REST isn't protocol specific, but when people talk about REST they usually mean REST over HTTP.

What is UDDI ? Why Soap ?

Web service is a way of communication that allows interoperability between different applications on different platforms, for example, a java based application on Windows can communicate with a .Net based one on Linux. The communication can be done through a set of XML messages over HTTP protocol.

Web services are browsers and OS independent service, which means it can run on any browser without the need of making any changes. Web Services take Web-applications to the Next Level.

Let’s say, you are a java developer and you can publish your functions on internet or LAN through java web service so any other developer (let’s say .Net developer) can access your function.

Universal Description, Discovery and Integration (UDDI):

Directory where any publisher can publish their web services and consumer can get access to all web services. Web services can register with a UDDI and make themselves available through it for discovery.

Simple Object Access Protocol (SOAP)

SOAP is a standard protocol specification for message exchange based on XML.
Communication between the web service and client happen using XML messages. SOAP is a XML format used to encode and decode different messages across network so that irrespective of technology it can understand each other.

Simple web service architecture has two components:

·Client

·Service provider

So in order to communicate client must know some information for e.g.

·Location of web services server

·Functions available, signature and return types of function.

·Communication protocol

·Input output formats

Service provider will create a standard XML file which will have all above information. So if this file is given to client then client will be able to access web service. This XML file is called WSDL.

What are the pros and cons of each approach, and which approach would you prefer?

Contract-first Web service/top-down approach
PROS:

·  Clients are decoupled from the server; hence the implementation logic can be revised on the server without affecting the clients.

·   Developers can work simultaneously on client and server side based on the contract both agreed on.You have full control over how the request and response messages are constructed -- for example, should "status" go as an element or as an attribute? The contract clearly defines it. You can change OXM (i.e. Object to XML Mapping) libraries without having to worry if the "status" would be generated as "attribute" instead of an element. Potentially, even Web service frameworks and tool kits can be changed as well from say Apache Axis to Apache CXF, etc 

CONS:More upfront work is involved in setting up the XSDs and WSDLs. There are tools like XML Spy, Oxygen XML, etc. to make things easier. The object models need to be written as well. Developers need to learn XSDs and WSDLs in addition to just knowing Java.

Contract-last Web service/bottom-up approach

PROS: Developers don't have to learn anything related to XSDs, WSDLs, and SOAP. The services are created quickly by exposing the existing service logic with frameworks/tool sets. For example, via IDE based wizards, etc. 

·  The learning curve and development time can be smaller compared to the Contract-first Web service.

CONS:

·         The development time can be shorter to initially develop it, but what about the ongoing maintenance and extension time if the contract changes or new elements need to be added? In this approach, since the clients and servers are more tightly coupled, the future changes may break the client contract and affect all clients or require the services to be properly versioned and managed.

·         In this approach, The XML payloads cannot be controlled. This means changing your OXM libraries could cause something that used to be an element to become an attribute with the change of the OXM.