I have worked on or seen a lot of projects using web services and there are many projects that even if use a single web service are touted as a SOA based project. Also, if you look at their approach of developing web service, you will find that they had never gone through a service identification phase and that they could have done without using any webservice. Most of the developers are nowadays handed over an intelligent IDE like jdeveloper or RAD and it becomes very easy for them to write some java code and just right click on the service interface class and choose the option of “generate web service”. And it’s all done. They become web service developers. Do you really think it’s that easy :). Forget about web services, I have come across developers who have worked on one of the many ESBs in the market without having any knowledge of web service or principles of SOA and they call themselves Integration architect or EAI specialist. This post is for those who have used bottom-up approach or code-first approach of developing web service and do not understand the limitation of using it. This post is to highlight the advantages of using contract or WSDL first or top-down approach of developing a web services.
1. Almost all projects are business driven and not IT driven. This means that your business should be aligned with IT and your architecture should be agile enough to adapt to the ever-changing business requirements. Top-Down approach helps you do that. How? Imagine a web service developed using bottom-up approach. The WSDL generated will contain embedded schema often referred to as business object. So each time your business object changes, you will regenerate your WSDL. This also means that you will need to republish your WSDL to service registry and inform all consumers about the change. On the other hand, in a top-down approach you can import/include your business object and if the object changes WSDL will not undergo any change. Also, the business object or XSD can be used by many services and in such case it can be reused.
2. You can develop a service using any programming language like java, .net etc. Each language has its own datatype and when you generate a WSDL you ask the SOAP engine (that contains a binding mechanism) to perform serialization of data types and convert those data types to equivalent data types defined by an XSD. The basic mapping between Java and XSD, for instance, is defined by JAX-RPC specification. So it becomes necessary for a java developer to go through the specification to understand what data type is he/she going to advertise to the client. Thers is another way that a developer can use if he/she insists to use a particluar java data type. In such cases, he/she needs to configure a bean and tell the binding mechanism (JAXB, xmlbeans etc.) which java class may to which XML schema type. Each SOAP engine (Axis, CXF etc) comes with a binding mechanism inside and it is not possible to access the binding mechanism directly while generating WSDL. Also, most clients add their flavor to the SOAP engine and do not allow the developer to customize the binding framework.
3. It is difficult to enforce restrictions in code and then generate WSDL. For instance, If the WSDL/XSD requires that an object can be nillable, then the developer may need to replace the primitive data types with their wrapper classes and regenerate the WSDL. Some developers use array in their code and when they generate WSDL it defines the datatype as arrayOfStrings. This is strictly discouraged by the WS-I basic profile as it causes interoperability issues. Remember, consumer of a web service can generate client in any language and he should have that freedom. You cannot use features that are not compliant with WS-I basic profile. There are various tools in market that allow you to check if your WSDL is WS-I BP conformant and it is very helpful for any developer who uses contract first approach. Obviously, you may not want to keep changing you code until it generates a WSDL that is WS-I BP conformant.
4. If your project is a typical SOA project then you must be using a service registry/repository to provide SOA governance. As everyone knows a registry stores metadata about the service and is a catalog of services, it should contain a lot of intricate details (version, milestones, creat date, expiration date etc) about any service. The service registry inherits a lot of information from your WSDL which means that the WSDL should be descriptive and should not require administrator to enter details manually in registry or should not require client to access registry for details that can be documented in a WSDL. The documentation element of a WSDL is an important place holder for such information but most of the tools do not generate documetation element inside WSDL.
5. There are lot of web services standards and incorporating these standards means the SOAP header will contain extra information. Hoever, a code first approach nowadays has support of annotations to specify header details in WSDL (when generated), it is always a better idea to use contract first approach to specify the header information. The web service client should know what it is going to receive in the SOAP header.