Cart
[Home] [By Thread] [By Date] [Recent Entries]
Joshua Allen wrote: > >... > > 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. Is this true? Can I take a WSDL for an asynchronous application, pump it through Visual Studio.NET and ask for an asynchronous binding (whether JMS or SMTP or response-less HTTP) and then expect it to work out of the box with BEA or Apache's toolkit? And if so, based upon what draft or completed standards? > .... 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. As clients move to *XML Schema* mappings, the SOAP mappings will become less and less interesting. Already, Microsoft's GET and POST bindings demonstrate that you can get *exactly the same* XML type mappings without using SOAP. And if you aren't interested in pre-declared types, XML-RPC is more reliably interoperable in my experience than SOAP. Paul Prescod
|
