What Are Code First and Contract First?
In the case of the contract-first approach, you start with a Web services contact called WSDL (Web Service Description Language) and then write server-side and client-side code based on the contact. To start with, the contact-first approach having an understanding about WSDL is very useful; however, even though you do not have enough knowledge on WSDL, there are many tools available for you to create a skeleton on the server side and a proxy of client-side code. If you take Axis2 as an example, you have a number of ways in which you can create a service or a client for a given WSDL document, command-line tools, and IDE Plugins can be considered as some examples of them.
It is true that not everyone will from WSDL to write services and clients; most of the time, developers like to convert a bit of code they have as a Web service. That is called the code-first approach, where you start with code rather than a contract. This approach is the most commonly used approach in the industry. With the code-first approach, you can write a Web service without knowing anything about WSDL, SOAP, and other related terminologies. And, most importantly, if you have a very old system and if you want to expose that as a Web service, the code-first approach will be a good candidate as well. In the meantime, the code-first approach can be used in a situation where a prototype is being developed. Although you start with code, you can get the WSDL document for your service because most Web service frameworks do support WSDL auto generation.
What Is the Better Approach?
It is very hard to determine which one is better because each has its own advantages and disadvantages. So, the best thing is to choose the one that matches your requirement. It is not mandatory to start with code first or contract first just because someone else is using that.
However, the article will discuss how to write a POJO application and the problems, limitations, and so forth.
Creating a Web Service from a Java Class
POJO stand for Plain Old Java Objects, so when it come to Web services world, what you do is we write a Java class and expose that as a Web service. And, of course, in writing such an application there are some limitation in Axis2. These will be fixed in an upcoming release, and I'll discuss that later in the article.
Once you have written the application, there are a number of ways that you can expose it as a Web service:
- POJO deployment (drop the .class file or .jar file into the pojo directory in the repository)
- As a service archive, where you bundle compiled class(es) along with the configuration file
- Using a programmetric way of deploying services.
Note: All the above methods support JSR 181 annotations, so you can write your application using annotations and expect Axis2 to do the right thing.
The Axis2 POJO has the following features. These features will be discussed in detail:
- Support for primitive types (int, boolean, long, String, and so on)
- Support for method excludes
- Support for any kind of "Java Beans"
- Support for Object Arrays
- Binary support using byte[] and DataHandlers
- Support of Axiom
- Serialization support for List
- Namespaces handling
- Inheritances support
- Support for Bean property excludes
- Method overloading support using annotations
What Are the Java Types Axis2 Support?
You can write a simple applications or a complex application using primitive types. However, when writing a complex application, it is much cleaner to use Java beans, but that is not compulsory. So, a very simple POJO with primitive types is shown below.
package sample;
public class SampleService {
public String echo(String value) {
return value;
}
public int add(int a, int b) {
return a + b;
}
public void update(int c) {
}
}
You easily can make this into a Web service by using one of the methods that I discussed earlier. Once you do so, all the public methods will be exposed as Web operations. And, once we use a POJO service, it is recommended that you use RPCMessageReceiver; one reason for that is that it has been tested enough to handle any kind of complex scenario.
If you are using archived-based deployment, the corresponding services.xml would be look like this:
<service name="SampleService">
<description>This is my Sample Service</description>
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.rpc.receivers.
RPCInOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.
RPCMessageReceiver"/>
</messageReceivers>
<parameter name="ServiceClass">sample.SampleService</parameter>
</service>
As you can see, you have not listed any of the operations that you need to expose; it happens automatically and publishes all the public operations. To understand what's happening, create a service archive file and deploy and see. Once you click on ?wsdl for that service, you can can see the auto-generated file with three methods. Once you deploy the service, you can invoke the service as you want: You either can generate a client or you can invoke the service in REST manner.
For the purposes of easy deployment, you can use the one-line deployment mechanisms and see how it looks.
public static void main(String[] args) throws Exception{
new AxisServer().deployService(SampleService.class.getName());
}
Now, go to http://localhost:6060/.
Then, once you click the SampleService link, you can clearly see three methods.
Generate Revenue Through IT Using Business Service Management
Managing the Modern Network
Storage Networking 2, Configuration and Planning
Is Your Disaster Recovery Plan Good Enough? Get Disaster Recovery Right 
IE 7
Firefox 2.0
