« Clemens Vasters on my "Wrong" post ;-) | Main | Tim Ewald on (Indigo) contracts »
18.02.05
About Indigo, typed and untyped messages, and right or wrong
Clemens Vasters and I have a discussion about Indigo and web service implementations. At first I am happy to be discussing this topic with him, and my “Wrong^4” post was both a way to express my concern and a way of gaining attention. At least the latter was successful ;-).
To get things straight. I think that Indigo is or will be one of the most sophisticated communication stacks around. It provides all the flexibility a developer or architect could want. Maybe I’m exaggerating a little bit, but only a little. Indigo provides support for contract and implementation first development which is a good thing. Please don’t get me wrong, CLR typed messages and types are one possible way of implementing web services, WSDL based development is another. The same applies for typed messages, i.e. serialized XML, and untyped messages. Both have their place in a SOA.
I got the impression that Clemens Vaster was pushing the CLR typed messages and the implementation first approach too much. There are reasons for untyped messages.
In a perfect world I would like to define messages and typed in a contract. Typed would have mandatory and optional attributes, simple or complex. The message would contain the required data (at least the mandatory attributes) and the requested service (operation). The defined endpoint would then choose the appropriate implementation. That’s message-based communication to me. Non-braking changes could easily be implemented in the service without the need to change the consumers. This is loose coupling at its best. Hm, exaggerating again. I understood that Indigo provides the means for implementing such services.
Again: I want both or better all the ways of developing message-based systems provided by Indigo. I don’t want to loose possibilities by sticking to the simple solution which hides the (sometimes) important details. As I already pointed out before, I’m not sure that making everything as simple as possible is the right way. Maybe complex programming models will be difficult to grasp for the every day developer. But making things too simple might lead to a naive and error-prone , hard to maintain implementation. I’ve seen so many system which contained tons of diverse simple approaches which ended up in a highly entangled chaos. Maybe that’s something completely different but making things sooooo simple often sounds toooooo good ;-).
Posted by Hartmut Wilms at 18.02.05 21:13
Trackback Pings
TrackBack URL for this entry:
http://www.innoq.com/movabletype/mt-tb.cgi/1169