When people (make that “developers”) start talking about WebServices I immediatelly get cautious. Once they use phrases like “other clients”, “probably different plattform”, and “serialization” in the same sentence I get that weary feeling, like I just eat something bad. Ironically if I ask what they actually mean when they talk about “WebService” I am the one being looked at as if I have been out of business for the past 5 years.
Well, I cannot blame them. Actually I blame Microsoft. And IBM. Bea. They made it far to easy to create something they called WebService directly from code (i.e. SOAP wrappers on objects). Then they invented SOA and talked about something entirely different which they also named WebService. It is not as if they don’t try, actually they try very hard to tell people the difference. In fact there are bright people within those companies who do nothing else. Yet this sometimes strucks me as damage control; damage caused by carelessly giving two very different things the same name – or rather by sticking with the name when WebServices evolved into something completely different.
Just as a side note: Did you notice I didn’t mention SUN? They are not to blame. They jumped on the train when it was already on its way and even then they did it reluctantly.
Here are the differences I am refering to:
There is a technology stack (namely HTTP, SOAP, and WSDL, possibly augmented with WS-* standards) commonly named “Web Service” on one hand. And on the other hand we have the architectural concept of services – nowadays allways in the context of a SOA -, which is usually also named “WebService” because WebServices are the predominant/canonical implementation technology for this concept. And because WebServices are the predominant implementation technology people often confuse the concept and the technology. Thus, when they use the technology they asume that the bennefits of the service come for free. (That is “service” in the SOA sense – unfortunately “service” is also a term that has very diverse meanings).
In order to clearly distinguish both kinds I usually use the terms “internal/private WebService” (the technology focused ones) and “external/public WebService” (following the service concept). The (somewhat idealized) definition of these two kinds of WebService goes like this:
Internal/private WebServices are used within a logical application as a means for distribution.
Both sides (client and server) are under control of the development team, both are deployed in unison, both have the same notion about the data model. Actually the fact that a WebService (or rather HTTP/SOAP) is used is just an implementation detail. One could also think of any other kind of remote method call technology (Remoting, DCOM, RMI, FTP, …) without affecting the application architecture.
These WebServices are meant to be never called from outside the application.
External/public WebService are published by an application to be used by other independend consumers – consumers you may not even know. These WebServices constitute another UI layer (rather than the interface of a layer). They require contracting, security, versioning, logging, fault tolerance, etc.. In particular this includes developing a separate data model for the interface. This model has to be versionable, stable, aligned with the service calls, and devoid of any implementation details. What you should not do is simply publish the internal data model. Apart from inflicting implementation details on the consumer, the least thing that will happen is that you can’t change anything afterwards without breaking your consumers. In other words: If you did that, you would have built the handcuffs, tied them to your own hands, threw away the key, and jumped in the water. Even good swimmers will drown in this situation. Publishing your internal data structures will get you into trouble. Trust me on this, I can show the scars.
Needless to say that internal WebServices are far easier to implement than external ones. The pitfall created by the similar term is that in my experience most WebServices are implemented as internal WebServices, yet sooner or later someone will use them externaly, expecting the quality and the features of an external WebService. Also quite often certain people (deliberately?) ignore the difference – even if you tell them. Internal WebServices are so much cheaper and a WebService is a WebService, no matter what this bitcounting bonehead (me!) says.
The way I try to avoid this situation consists of one single rule: I observe this clear distinction during design, development, and especially when talking about these things. I use the term WebService for the external kind and put emphasis on the service characteristics. Also I mark them accordingly with price tags – and sorry, nothing on sale today. For internal WebServices I try to avoid that term altogether, rather I use something like “SOAP interface”.
Of course there’s a gray area and sometimes 3 is an even number, yet following this rule will avoid a lot of problems afterwards.
That’s all for now folks,
AJ.NET
AJ's blog 
Leave a Reply