[
Lists Home |
Date Index |
Thread Index
]
> The basic answer is that it allows out-of-box interop (well, usually) so
> things like VS.NET can work with BEA, and BEA can work with Apache, and
> so on. This doesn't negate the value of loose-coupling -- it is still
> beneficial to do loose-coupled async architectures even if the
> message/document format is not SOAP. But the fact that 90% of clients
> and servers support automatic SOAP mappings mean that SOAP is a safe bet
> for an XML novice trying to whip up a loosely coupled architecture in a
> hurry.
So these automatic SOAP mappings for my proprietary object model will
magically create a loosely coupled XML messaging format that doesn't
expose details of my model to my trading partner, and also works similar
magic at their end?
My limited experience with only simple SOAP interfaces has shown that getting
the messaging format right, i.e. the hard bit the modelling, was the necessary bit
and that the benefits of automatic mappings were pretty thin, if they exist at all.
If you existing object model doesn't map nicely into the desire messaging
format -- which needs specifying independently for truely loose coupling, IMO --
then you end up writing conversion code anyway. Just here you're converting from
your existing model, into that auto-generated by the mapping layer rather
than directly into the XML. Seems to be shifting the work around.
I've only seen this magic working when both ends use the exact same
object model and SOAP toolkits. But maybe I'm not looking in the right
places, or waving the right wand.
Cheers,
L.
|
