OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] What does SOAP really add?

[ 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.




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS