Cart
[Home] [By Thread] [By Date] [Recent Entries]
> We are watching a transition from "close-coupled" comms to > "loosely-coupled" comms. I'm using "coupling" here to refer to how much > the send and receive code has to know about the fine structure of the > data being sent, from an RPC-style list of individually-typed parameters > at one extreme to a single XML document at the other. This is > crystalised in the web-services technology stack, and not always in the > ways you might expect. > > SOAP, the exciting XML contender, has a spec which is focussed on > close-coupled calls. The SOAP EncodingStyle allows you to serialise an > RPC-style parameter set. There's nothing to stop you sending single > literal XML documents, there is just no explanation of how literal XML > content should be signalled, just a statement that the "section 5" SOAP > EncodingStyle is the only one defined in the spec, and "There is no > default encoding defined for a SOAP message." > (http://www.w3.org/TR/SOAP/#_Toc478383495) Wow. In the above 2 paras, you essentially read my mind and spilled the contents forth to the list. In my latest Thinking XML column installment I tossed the cryptic barb that ebXML's adoption of SOAP could actually prove a defeat for its principles of loose-coupling. The tyranny of the SOAP serialization is one of the factors behind this observation. While I left this unsaid in my column, I have vented about it at length in discussions about Python/Web services efforts. I had an argument with Rich Salz because I chose not to use the SOAP serialization when implementing the "native" SOAP API for 4Suite Server. I chose not to do so because section 5 is such a horrid mess and besides, my intentions were not to create yet another RPC mechanism for 4SS but rather to provide a message-oriented request system. Someone with a stronger stomach than I do might still implement section 5 for 4SS so that the RPC folks can do their thing, but this wasn't the point of the argument with Rich. He as much as said that any SOAP implementation that didn't use section 5 was wilfully flouting interoperability goals. I pointed out that if Web services were to offer anything more than CORBA or DCOM they would have to provide true loose coupling in the face of the normally opaque boundaries between information systems. Registries and the technology to mine them for the requisite data models are the key to Web services success, not forcing conformity of core message payload format. Egads, this is XML, isn't it? Remember the "X"? I'm not saying that registries are a magic bullet for successful interoperability in the face of loose coupling. There is still a lot of work to be done, and some of it may require fundamental comp sci developments, but if Web services are really a valulable new development, and not just a slower, less secure, fatter network form of RPC, we'll have to find a way to make it as flexible as the pundits claim it can be. > WSDL makes explicit provision for both RPC-style and document-style > messages - in fact for the SOAP binding, the default values for the > soap:operation/@use and soap:body/@style attributes appear to make > unadorned literal XML content the default. I'd like to think this isn't a sop to folks who argue as I do, but every example and piece of advocacy I've seen invariably involves SOAP serialization in the "message/parts" and XML schemas in the "types" descriptors. > The UDDI Programmer's API 1.0, I notice, specifies that "In version 1 of > the UDDI specification, the SOAP encoding feature (section 5) is not > supported. Operator Sites will reject any request that arrives with a > SOAP encoding attribute." Whoa! I missed this, and I'm quite surprised, I must say. Maybe there is hope... Gotta go research. > We already use XML Schema structured messages to interface between major > components, internal and external, of our retail finance systems. My > view is that [a] single document style is far more productive than RPC > style, [b] that XML Schema means that the message can use declarative > validation in the comms layer rather than procedural validation in the > application (and no, DTDs don't cut it for us) and [c] that XML Schemas > will be the units of selection by which industry standard common message > structures will evolve. I can buy most of this, but parts of it requires my sprinkling on a lot of hot Nigerian pepper to mask the bad taste. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
