Why people are interested in CODE-FIRST approach? Answer is simple. No need to go through the complexities of XML, XSD, WSDL structure. Just code in any of your favorite programming language and create the WSDL file using any of your tools/frameworks. I had taken some interviews these days for a Webservice-SOA project. Honestly it was too difficult to find out the right candidates with good knowledge in Webservices. Most of them are just consumed webservices. And if we find somebody who developed webservices then they would be just familiar with the Code first approach and have no idea about WSDL files. Becuase just seeing WSDL in that endpoint URL finishes their works.
Here in this series of Posts I would like to put a small webservice example which is doing in “CONTRACT FIRST” approach.
If you want to go through a Code-First Approach using CXF then please check my previous posts. For your convenience I am pasting it below.
Why we require CONTRACT FIRST approach?
This article from SOA world will help you to understand. A contract-first approach results in better long-term development, interoperability, and maintenance. For larger applications, long-lasting Web services, and service-oriented architecture (SOA), contract-first thinking has advantages that usually outweigh the ease of method-first thinking. I know first exposure to Web services, WSDL and Schema are very tough to grasp but when you are coming into a BIG SOA application development people will choose contract-first. At least me!
Some of the Points for this selection are:
- Its better to define data types and all first than converting from a programming language.
- It makes you be very clear with both the producer and consumer of the service exactly what is needed and what is expected
- Contract-first is the generally accepted ‘best practice”.
Creating a small webservice application using CXF
Lets start our example. Want we are trying to achieve is, we want to deploy a service called “getProduct”. If we are giving a “Composite ID” as an input to our web service then it should return a Product Details to us.
First we will start with our XSD structure. Even though this is a small service and we can define it inside the WSDL itself, we will create a separate XSD for our better understanding. We can import this XSD in the types tag of WSDL.
Creating our XSD
Here I had created one ProductDetails and one ProductId types.
Product Details contains all the product related information like productname, category, price and details. ProductId type is a composite primary key with sequence number and deptcode. I am also created a request and response types here.
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsd:schema targetNamespace="http://com/your/company/service/Product/"
4: elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
5: <xsd:complexType name="productID">
7: <xsd:element minOccurs="0" name="sequenceNumber" type="xsd:int" />
8: <xsd:element minOccurs="0" name="deptNumber" type="xsd:string" />
11: <xsd:complexType name="productDetails">
13: <xsd:element name="id" nillable="false" type="prd:productID" />
14: <xsd:element name="productName" nillable="false" type="xsd:string" />
15: <xsd:element name="category" nillable="true" type="xsd:string" />
16: <xsd:element name="price" nillable="false" type="xsd:long" />
17: <xsd:element name="details" nillable="true" type="xsd:string" />
20: <xsd:complexType name="ProductRequest">
22: <xsd:element name="productID" type="prd:productID" />
25: <xsd:complexType name="ProductResponse">
27: <xsd:element name="product" type="prd:productDetails" />