[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: What does SOAP really add?
> 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|