Web Services: Look Before You Leap

Web Services: Look Before You Leap

Desktops with gigabytes of RAM, Handheld devices that work like computers and an SOA compliant enterprise do not evoke a reaction these days; they have become more of a given thing. Today everybody wants to have an SOA compliant architecture without giving much thought about its applicability and ROI but Let us keep that discussion for another day. Let us assume that you have a good case for SOA and it actually makes sense for your enterprise to be service oriented. Now, the only question that needs to be answered is how to find out that if you are getting the right stuff.

Let’s take an example. Suppose I run an Insurance company and right now I sell policies only in my branch offices using a very sophisticated and expensive core system.  Now my business teams comes to me and says, “Abhishek, in order to grow our revenue, we need to have a website for selling policies directly to the end customer.”

So, I go to my core system vendor and ask them to expose a web service which can be integrated with the website. These people come back to me and say “Since you are one of our valued customers, we are going to expose ALL the functionality of the base system in a single web service so that the web site can have the full functionality of the base system.”  Is my vendor doing me a favour or setting me up for failure?

When you look for a technical solution, most of the times, the simplest solution is the best solution. You need to understand what your short term and mid-term goals and figure out how to address those goals.  There is point in creating a system that is going to last for 15 years but is going to be a pain in the neck to maintain. The other aspect that you need to look at is, are you going to use all the functionality of the base system? (Yes, there is a finite chance of a nuclear powered world war, but do I need to build a bunker instead of a house?). My product vendor is giving me this option because he wants to cut corners in development and pass his half baked, high maintenance ‘SOA Compliant’ web service as a state of the art system. Instead of taking a more granular and systematic approach to developing web services, the vendor is planning to expose his current, internal methods as web service which is going to save them development effort, but with quadruple the effort for integration and then later maintaining the services. 

From our experience in working with different customers on SOA enablement, we have come up with a quick dipstick to evaluate if you are getting a lemon instead of web services:

  1. Granularity of Calls – If the call is too fine grained and is expecting you to pass more than 10-15 parameters, it is not a neatly designed service but a legacy code in disguise.
  2. Content of the Web Service Message – A lot of legacy system which used messaging queues extend the same mechanism to web services – methods accepting XML strings instead of Objects. This has significant transformation overheads and also do not utilize the out of the box web services validations.
  3. Documentation – Most unplanned web service implementations come with zero documentation. If you get sample input/output instead of a document, think twice before starting implementation, you are in for a long haul.
  4. Error Communication – When you hit a error on the server side a well written web service will give you an exact error code and an explanation of what just happen, for instance – “ERPRM012: Unable to calculate premium as insured value is null”. A lemon, on the other hand will give you –“ Unable to calculate premium” or worse –“Error processing request”
  5. If it is too good to be true, it isn’t!

Though, these are simple and intuitive things to follow, yet you come across so many systems that do not pay any heed to any of these checks. Integration is one of the more complicated aspects of system development and an ill designed web services can significantly increase your Cost, effort and time spent during integration and during the maintenance period.

5 Comments

  1. Harish Kashyap says:

    Nice post Abhishek. Very well written. I have one point of view on the granularity you have mentioned. With everyone embracing REST and ROA replacing SOA, we will see more fine grained services accessible. So, in my view the granularity can be fine as long as the encapsulation is right. i.e. you can expose 100s of services, each with 10 to 15 params but the fact that i am exposing 100 should be ok.

    1. abhishek says:

      Thanks Harish, I completely agree with your point, I also wanted to emphasise the same thing in Point 1. The number of parameter may wary from situation to situation but your web service should be designed to a specific task efficiently, Instead of having a single webservice that does 10 different tasks and expect a large set of input parameters.

  2. Anoop says:

    Abhishek,

    Nice post. But I was wondering why your list of must haves in a webservice does not talk about web service security.. Isnt it a key aspect while designing oye using a web service..

    1. abhishek says:

      Thanks Anoop,
      Yes, Security is a key aspect in the design of a Webservice, and most of the blogs on Webservices talk about security.But, through this blog I wanted to cover those common points( which are generally not covered in most of the blogs) which can make sure that the Webservice integration happens as smoothly as possible and with minimum amount of time and effort. Probably I will talk about security and performance in my next blog.

Leave a Comment

Your email address will not be published. Required fields are marked *

*
= 4 + 0