Working with a framework vs. code generation...
It sounds like I will be crabby on my posts this week. Although I am not seeing axis or IBM Web Services for the first time, I cannot stop myself from being horribly surprised by the programming model. I will not compain about all the times the environment (Web Sphere Studio 5.1 or test integration server crashes for unknown reasons). I simply cannot understand how they expect a developper to be working with tons of generated code, which has even a few bugs... like this line :
mc.setProperty(com.ibm.ws.webservices.engine.MessageContext.PARAM_MAXOCCURS_NOT1, _set2)
It gets generated in the SOAPBindingStub when working with unbounded arrays as return type, but it seems that MessageContext has no such field...
Not too long ago, I was looking at some interop problems one of my customers had, and we found ourselves forced to deal with a huge amount of generated client side generated source code to be able to pass a username and password for authentication (the version of the tools we were using simply dropped authentication by username and password when they added support for oasis...)
My main problem is not why there are a few bugs (even if they are at a very basic level and should definitely not be there if anyone is going to be using the tools in the real world), but that the bugs are in generated code, which will be regenerated when one makes changes to the source of the bean the service is built from. This means that the bug will have to be fixed manually zillions of times during the development process !!! and I have not even started to talk about maintaining the service after it is deployed... and it is not something that happens on 1 generated file, but a big number (serialization/deserialization classes, binding stub, proxy, service interface, helper classes, meta data, and other bizarre things)
XML Web Services are built on protocols and interoperability specifications, and the mapping between an object model and a service model should be built as a framework that encapsulates the generic way of mapping the two worlds, or on a new programming model totally built for services (message contract, service contract, channels, ports...etc.).
That is the way Microsoft is dealing with the problem, and I think they are right in doing so. the asmx model offers an extensible easy way to map the object world to the message world, and takes care of mapping the whole thing into xsd and wsdl. This model is still OO, but it works for the OO developer. with Visual Studio 2005, and later with Indigo, the service programming model gets its implementation as a framework.
Between the two programming models, my choice is definitely made. .Net | main | Views
9/7/2004 1:16:55 AM UTC
|