Joined: 16/02/2012 12:59:39
The web service main implementation and operations depends on the contract.Even though there is no official definition of the web-service contract, the contract is assumed to be the WSDL file. The WSDL describes all operations that the service provides, locations of the end-points (where the service can be invoked), and simple and complex elements that can be passed in requests and responses.
There are two approaches to web service development:
a) Contract First Approach:This approach is also known as the top down approach of web service development. In the contract-first web service, the "contract" (a WSDL definition of operations and endpoints and XML schema of the messages) is created first, without actually writing any service code.In the case of contract first, clients are decoupled from any logic on the server. The logic can be revised on the server without affecting the clients. Teams can work simultaneously on the server and the client implementations as long as they agree on the contract, which is the first thing that is created anyway. More granular control exists over what is in the request and response messages and WSDL structure.
b) Contract last Approach:This approach is also known as the bottom up approach of web service development. In this approach existing logic is "exposed" as a web service and the contract is created at the very end. In the case of contract-last, developers don't need to learn SOAP or any XML-related technologies, and services are created quickly by "exposing" internal APIs with automated tools, such as JBuilder or Apache Axis. The learning curve is smaller compared with the contract-first, and so could be the development time.
Here is a brief comparison of these two approaches I found on the web:
Research seems to show that, at the time of writing, contract-first is preferred over contract-last and various reasons are given:
-->Object to XML impedance mismatch, which generally means that with contract-last, some Java types don’t readily convert to XML and if they did then there could be a certain loss of information as defined by an XSD’s <restriction> element. I.e, Java isn’t really expressive enough to produce a rugged contract.
-->Contract-last could suffer from performance issues as you, the developer, have no control of what’s sent over the wire.
-->Using contract-first means that you have your XML types defined in a set of separate schema files, which could be re-used effectively.
--> Contract-first has looser coupling between definition and implementation making version management easier.
-->One of the positive things about web services is that they allow services written in different languages to work together. Contract-first reinforces this approach as the WDSL / XML Schema provides a programming language independent, centralised method of specifying a contract. Contract-last, on the other hand, means that your contract is defined in your implementation code, which may differ from your client’s implementation code and who’s to say which is the master copy of the code?
-->Which brings us on the next benefit of using contract-first: the management of change. There is usually a version 2 of an interface adding in something that was forgotten in version 1. Using a schema makes that change management easier.
-->Finally, a plus point for contract-last is that it should be easier, there’s no messing about with XSDs, meaning there are no extra skills for your team to learn.
Lets Leave the theory behind and work on with an example of contract first web service.
I am using eclipse as the development IDE and Apache axis as a generator tool.
Let us create a dynamic web project in eclipse called "ContractFirstWebService".
we will create the WSDL inside the WebContent/WEB-INF/wsdl in the project directory and name it as ExampleWSService.wsdl which will look as under:
This WSDL file imports an XSD file. Make sure this is placed in the same directory as the WSDL file, and name it ExampleWSService.xsd. Also update the location/URL in the WSDL file. This example assumes the application is called webservice and the service name is ExampleWSService.
Now from the eclipse use Apache axis to generate the necessary stubs and skeleton Java files. Remember These files generated do not have a implementation yet.
we just have three operations defined as :greet, multiply and sum without any implementation. Apache axis generates all the necessary stubs and skeleton files and we have to implement the logic on the skeleton files to get a valid response. we have to implement the interfaces defined for the operations in ExampleWSServiceSkeleton.java file.
Below is the modified version along with the implementation of ExampleWSServiceSkeleton.java
Now if we run the web service using tomcat and get the wsdl URI, for me it is http://localhost:8080/ContractFirstWebService/services/ExampleWSService?wsdl, then we can test the services request and response in SOAP UI.