Re: Transactional Integrity of Services (LONG)
"Anthony B. Coates" wrote: > I guess I'm somewhat familiar with this argument of yours now, but a > couple of things escape me. One is why this is an *XML* problem. I don't > see that the arguments apply differently to XML than to binary formats or > other textual > formats. Hi Tony. It is an XML problem to the extent that XML is increasingly perceived as, somehow, the basis of 'interoperability'. The nature of any interoperability achieved depends, however, on how the processes which are supposed to interoperate are implemented. If the XML which is used for interprocess communication is understood as documents--and processes are implemented on the necessary implications of that premise--then there is a basis for transactional interoperability of those processes, though it is through a novel mechanism which doesn't look much like two-phase commit. On the other hand, most (by far, sadly) of the designs we see for processes interoperating through producing and consuming XML make either (or occasionally both) the unfortunate assumptions that: 1) XML is the serialization of some object or some data structure, though an XML instance is in fact a document and the relationship of document (even adhering to a strict content model or schematic) to instantiated data structure adhering to the same content model or schematic is inherently many-to-many. At the point at which that relationship is constrained to be one-to-one, we have no longer a document but the fully-instantiated data structure itself--i.e., no perceptible 'serialization'. The corollary of this unsuitable assumption is that the generic processing of an XML instance--i.e., before process control might be handed off to some specialized application but after basic parsing assures conformance of the instance's syntax and perhaps its validity wrt some content model or schematic--should instantiate for the recipient's processing the 'same' data structure, or the data structure which the document creator 'intended'. 2) An XML instance can be so decorated with type and schematic annotation that it becomes itself effectively the instantiated data structure upon which an application process might operate directly. This would be true of binary formats and, given particular processes, for certain text formats, but it is never true of an XML document. > The other thing that escapes me is how the world is supposed to function > under your approach that you cannot predict how another system will react > to a document/message/bit-sequence that you send to it. That's just the point: these are autonomous services. They perform their own expert processing, part of the expertise of which is knowing what data to select, where to find it, and how to instantiate it for their own particular purposes. They are not intended to do another system's bidding, and most especially not to execute remote procedure calls from another system nor to react in some expected way when a particular data structure is presented to them. Such autonomy assures that these services are not enlisted to produce fraudulent outcomes merely because a public interface is invoked in correct form. By design, it is not the interfaces, or more broadly the input requirements of these services which are public, but their output which is published and may be used by other process whose purpose the creator of that data knows nothing of. > I'm guessing that it involves a lot of "out of band" negotiation by > humans. Not at all. No. Absolutely not. > If that is the case, my reply would be that this is what always happens. Yes, it does, both when designing and when executing processes in precisely the manner that I am trying to avoid. The point of such negotiation is to align the output of one process with the input expectations of another, accomplished by tweaking the form of interprocess communication between them. By contrast, I am describing a design where the form of one process' output is specific to the expertise which that process is intended to express, may well be immutable, and in any case is not decided with reference to the requirements or expectations of any downstream process, the purpose or even existence of which the original process might well know nothing of. > Schemas/templates/formats get abused, and some human interaction is needed > to resolve the problem by getting both sides to agree on what is what. > However, that doesn't make XML/Schemas/etc. bad things. They reduce the > *amount* of that "out of band" negotiation enormously, and that is not a > bad result as I see things. I can't help but feel that you are looking entirely at the input side of a process, where you regard schemas as a public interface, a sort of contract of what a process will accept and agree to do something with. Outside of the enterprise firewall, such 'contracts' which oblige processes to execute in a certain way when given particular input are simply invitations to fraud. I am instead looking for the output of a process to be published, in the sense of being made available at a URI, subject to usual http security, where a process with an interest in that data might find it. A schema associated with that document might help a consumer of that data to understand what that document is on its own term. Such a schema cannot, however, indicate how a consumer is to instantiate some or al of the content of that document: any such instantiation is specific to the use which the consumer makes of the document and to the process by which that use is effected. Respectfully, Walter Perry
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