SOA / Web Services / Java

A Technology Blog

Archive for December, 2009

Developing web service – Top-Down vs Bottom-Up approach

Posted by Vivek on December 25, 2009

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.

Posted in Web Services | Tagged: , , | 37 Comments »

Why not Message or EAI Broker?

Posted by Vivek on December 25, 2009

There has been lot of discussion whether to use message brokers (hub and spoke integration broker or EAI hubs) or ESB to integrate applications and build SOA. While most of the people think that they can still extract most out of an EAI broker, here are some pain points that I want to highlight:

1. Message broker allows centralized routing between applications which means that it doesnt allow regional control over local integration domains.
2. BPM tools cant build choreography or business processes that can span departments or business units. So a message broker is a hindrance to implementing SOA.
3. A message broker is limited by the underlying MOM in its ability to cross physical network LAN segment boundaries and firewalls.
4. Proprietary nature of brokers combined with the high cost of consulting usually results-in vendor lock-in or an expensive restart for each subsequent project.
5. Implementation time is high.
6. Integration softwares are expensive

Posted in integration | Tagged: , , | Leave a Comment »

Pub-Sub model using WS-Addresing and WS-Base Notification

Posted by Vivek on December 25, 2009

Application developed in the real world can be either a producer or a consumer. Senders (producers) produce messages and receivers (consumers) consume messages. An application may be both a producer and a consumer at the same time. In a SOA world, producers and consumers are loosely coupled with each other through virtual channels  called publish and subscribe channels or point to point channels. These two distinct channel types are also called topics and queues.

The producer does not need to know which applications are receiving a message and the consumer does not need to know which applications are sending the data. The challenge is to design the model in such a way that it adhers to industry standards and complies with the rules of SOA. One such mechanism that is described in this post recommends use of ESB as a transport and routing channel and WS standards (WS-Addressing and WS-Base Notification) as carriers of the message information. Since, a pub-sub model is intended for a 1 to many broadcast of information, the emphasis should be to have a logic that can handle multiple subscribers and a provision that can allow any system to subscribe or unsubscribe in future without affecting any other systems. In pub-sub model, multiple consumers may register an interest with, or subscribe to, a topic. A producer sends a message on that topic and each subscriber receives a copy of that message. A message is typically composed of three basic parts: the headers, the properties and the message payload or body. The headers are used by both the messaging system and the application developer to provide information about things such as destination, fault-to destination, message type, expiration date etc. The properties and message payload may vary depending upon the format of the message and its content.

In every pub-sub model, there is an entity that generates the message. That entity is generally referred to as Notification Producer and the message that it generates is a notify message that is used to notify the subscribers of any changes. Since, the notification producer can generate any user-defined message, the message needs to be transported using an industry standard so that different subscribers can implement logic at their end to extract the information thay wish to use by understanding the format of the message. WS-Base Notification ( is a standard that could be used to represent the information that needs to be sent to a subscriber. As it defines a standard format, it is easier for any subscriber to access the details.

It is not possible for a notification producer to carry the responsibility of managing the subscribers and topics. A subscriber may be interested in receiving only a subset of data while other subscribers may require entire data contained in a message. Also some information may be confidential and should be shared only with trusted subscribers. Masking that information before giving to a non-trusted subscriber requires additional logic. It is difficult for a notification producer to maintain a list of subscribers since at a given point of time new subscribers may join or existing subscribers may opt to leave. Also, broadcasting a message is not something a notification producer intends to perform especially, when some subscribers cannot receive message in a format generated by producer. For such subscribers there has to an intermediary who can transform message for them. The well known web services standards (WS-Addressing and WS-Base Notification) can help the intermediary to process the message and access the details it requires for transformation and routing. Any ESB with basic features can be used as an intermediary in such cases.

Posted in SOA, Web Services | Tagged: , , , | 1 Comment »