Software Reality Community After you've read the article, check out the accompanying message forum...

SOAP-based Web Services are being heralded as the next big thing, promising a utopia of disparate yet cleanly interoperable systems. Here's a timely look at the current reality of developing a "real-life" Web Service:

The State of Web Services

By Dino Fancellu
January 27, 2002 (Updated February 3)

The potential of Web Services is well documented. A huge amount has been written, both by enthusiastic IT journalists and by the server vendors' enthusiastic spinmeister marketeers, about the benefits that this new services-oriented bandwagon will bring us.

Amongst all this frothy spin, a little bit has also been written about what Web Services actually are, and what they should represent from a programmer's point of view.

The promise of Web Services is that different implementations on different platforms will be able to communicate quite easily with each other, as if they are written in the same language, running on the same platform and the same machine. It's a promise that was made by CORBA, and by RPC before it. Web Services brings us a step closer, but there are still glitches, wrinkles that need to be ironed out.

To begin, here is a word about Web Services under WebLogic: Argh.

For some reason, WebLogic forces the programmer to implement some horrible EJBs just in order to publish a simple web service. The programmer must jump through tonnes of pointless hoops.

Mercy.

As far as implementations go, GLUE is definitely the best so far, even if .Net does barf on it sometimes. GLUE makes the publishing process as simple as it could possibly be. There's none of that messing around with modifications, stub generators, or other old-fashioned approaches - simply start up the GLUE server and tell it which object(s) to publish, and then you can access the object's interface remotely as if it was a local object.

When it comes to real-world applications, even GLUE has some wrinkles to be ironed out though. Nothing insurmountable - just things that you need to be aware of, in case you thought that getting your Java proggy to communicate with .Net would be a breeze.

For example, see the discussion thread here (you will need to register first but it's free):

http://groups.yahoo.com/group/MindElectricTechnology/message/3472

The above thread highlights a problem with mapping data types between different platforms, e.g. the Integer, Double mappings are not handled by C# which only has an int, which can be null (however C# has an Int32 object that is very much like Integer).

This is just a detail. Not important. What is important is that cross-platform compatibility is never perfect, never 100%. GLUE simply emits wsdl (Web Services Description Language). It knows nothing of the client platform, which is as it should be. It would just be nice if it had been tested with .Net a bit more (no doubt this will come with time though - these are early days yet).

.Net is a very important platform, as it allows many VB type programmers to start knocking up Web Service clients and servers with relative ease.

It's still not quite straightforward to get a Java client talking to a .Net service (and vice versa). This is because Web Services under Java is quite immature. Unfortunately, the promise of 100% interoperability between all the different implementations is a bit far off.

The different implementations all have bugs, hence things that work on one system won't work on another, e.g.:

http://www.apache.org/~rubys/ApacheClientInterop.html

So, if I use toolkit X, even though it may say it is SOAP 1.x compliant, there is no guarantee it will work with some system I find on the net and decide to poke. Wrinkles always come up that mess things up.

Something May be Lost in the Translation

For example, I have a service that returns a dependant object, with fields and accessors. However in wsdl only the fields get exposed, not the accessors. This is reasonable but annoying. Data is pretty platform neutral, code
isn't.

If I have an accessor, getName(), that returns name, how does wsdl know that? It can't.

And if it did, how would this translate to some other client platform? It couldn't.

So, while service methods get published when you publish a service, they don't for dependant objects. That is because the service is on the server, access by reference, but the dependant object goes back and forth by value.

Beware. Your system will not code just as it is when you move to SOAP.

Simply publishing your current API's en masse to SOAP will probably not work very well. Best have some specific business methods in mind and code especially to expose those.

Conclusion

The reality is that if I decide to base my business on talking to some other server I will have to talk to a human being to guarantee the server stays up, doesn't change services offered, behaviour etc.

And hence if some data doesn't come through, some service doesn't quite mesh with mine, I'll just have a chat with a human and we'll work things out.

SOAP doesn't solve all system to system problems. It just helps.

So, when we publish our example Northwind services, as we do here (http://www.javelinsoft.com:8081), there is no guarantee that every person will be happy with our wsdl, or that every client will be able to cleanly access our services without some extra help.

That's life. As SOAP becomes more in use, as it matures, this will become less of an issue, but it will always be there.

At the moment, I can't even guarantee that my "pure" JSP will work from one container to another!

These are, of course, just examples. No doubt with a patch, or some more code on my side I might be able to make .Net happy, for example. But that's really the point - it normally takes more effort than is advertised. The fact that Visual Net simply sucks in wsdl and doesn't complain even when it doesn't like it is bad too.

A system that simply doesn't understand nullable objects, perhaps only having primitives, would equally have problems. Platforms are different. Getting them to gel takes work, hacks, 'facades' if you want to put a nicer ring to it.

It's important to understand that for all the hype surrounding Web Services, it doesn't mean plug/play, and yay the lion will sleep with the lamb etc. It's just a useful tool.

About the author:
Dino Fancellu is the Lead Technologist at Javelin Software Ltd., a UK-based Java consultancy firm. He has worked with Java since it was in Beta, and has been a commercial programmer since 1986, specialising in complex enterprise/financial systems. More recently at Javelin, his work has taken him to dot-coms such as LastMinute.com, Sapient/AssertaHome and PensionsBusiness.com.

Talkback - Have Your Say:

Post a new message

As an addendum...
Dino 

Post a new message

Back to Programming