After working on several web projects that have required plenty of integration involving many systems within the enterprise, I’ve come to some realisations about getting integration right:

Services must be exposed at the right level

It’s extremely tempting when performing integration to try and apply good application programming practices of keeping methods simple and stringing them together. This practice makes it easier to test methods in isolation, simplifies their contracts, and ultimately leads to more flexible and understandable code.

The frameworks available for performing integration (i.e. web services with Apache Axis) give you a healthy level of abstraction deliberately so that you can easily forget that you are performing integration at all.

But here in lies the problem. As soon as you forget that you are performing integration, you can start to perform good application practice which in turn can lead to disastrous integration practice. For instance, if the services exposed for integration are too fine grained, then the consumer may have to invoke many services to get a enough data to fulfill its objective. User experience and (distributed) server load are the first things that will suffer.

Services need to be exposed at the right level to ensure that a consumer can make as few a calls as possible (ideally one) to fulfill their objective.

No doubt getting this level of exposure correct is the tricky bit, but as soon as you find that you’re starting to become very chatty with services to get things done, this is the sign that its time to think about exposing a new service at a higher level of abstraction.

Ensure that services are fit for purpose

In a similar vein to the point above, it’s important to ensure that the service you’re invoking is truly designed to meet your purpose. There is a temptation to look at a service catalogue and pick out the services that will help you get what you’re after. However, if these services are not in line with your objectives, then there is a good chance that they’ll be doing more than they should be for your needs. This leads again to unnecessary server load and the likely-hood of an impaired user experience.

A good way to spot if a service is unfit for your purpose is to inspect its response payload. If it contains far more information than you need, then you’ve probably got to think about getting a better suited service exposed.

Thinking SOAP based web services as the protocol for integration, the above problem re-enforces for me why the document style web service is a far better approach than the RPC style web service. The later is tightly coupled and inflexible, just like a method call is. The former is the opposite allowing for a service to cover many situations and purposes. Some that may not have been originally conceived but are now required. Incorporating this support should not be costly and have limited if any impact on existing consumers.

So, if a service is using the document style approach and its not quite fit for purpose, you should be in luck! With a small enhancement, you will have the service that fits exactly to your needs.

Here’s an old article that sings the virtues of document style web services:

Reap the benefits of document style Web services