Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Categories of Web Service messages: data-oriented vs acti
 > From: Roger L. Costello [mailto:costello@m...] <snip/> > I feel like we are close to exhausting the issue of the best way to > design an XML message. Recall the 2 approaches we have discussed: > > - Approach 1: should I colocate an indication of the > desired action > with the part of the message that the action applies to, or > - Approach 2: should I separate the actions from the data? I think it depends upon what you can get away with. The comments made by others regarding the value of decoupling the action from the data were quite valid. However, I would draw an analogy with the Composite [1] and Chain of Responsibility [2] patterns from the OO world. A message may be a composite of smaller messages as a way of constructing rich messages. There also may be situation where it is convenient or useful to bundle a set of messages together into a batch. HTTP pipelining is a valid alternative to the latter in some instances, but there may be instances where collecting them into a batch is more useful. For instance, if employing a message broker or doing message queueing, it may be more convenient or more useful to queue or publish one large message rather than 1000 small ones. > I am hopeful that today we can come to an agreed-to best practice for > this issue. At the very least, I would like to ensure that both > approaches are completely understood, as well as the tradeoffs. I'm not sure it is realistic to have one agreed-to best practice. I think something more like the design pattern catalogs that arose in the OO world would be better -- a collection of patterns with the pros and cons of each approach noted. > Yesterday Mark Baker and Michael Brennen were tossing around > an example > of an XML message to purchase a CD. Michael asserted that such a > message would contain multiple actions: > > - a "buy this item" action, > - a "use this credit card" action, and > - a "ship to this address" action. Although the question of the intent (or action) of a message depends upon what layer in the architecture you are looking at, or what component in the processing chain you ask. Submitting an HTML form has a "POST" action associated with it as far as the HTTP server is concerned, but may have "but this item", "use this credit card" actions associated with it from the perspective of the application that processes the order (of which the HTTP server is blissfully ignorant). There is also no reason why, IMO, a SOAP message could not have one top-level "intent", than delegate portions of the message to various components for processing (the Chain of Responsibility pattern[2]), each of which may see an intent in their portion of the message, represented via an element or attribute within the message. I'm really arguing for flexibility, here, and the ability to pile on as many layers as needed; not just one way of doing things. > In previous discussions we have not looked at an example with multiple > actions. Hopefully, such an example will provide insight into which > approach is better. So, I would like to use this CD-purchase > example to > compare (once again) the 2 approaches. > > Here's the CD-purchase message where each action is colocated with the > XML subtree that it applies to. > > <message> > <body> > <PurchaseOrder action="purchase-CD"> > <CD> > <Title>Timeless Serenity</Title> > <Author>Dyveke Spino</Author> > <Date>1984</Date> > <RecordingCompany> > Dyveke Spino Productions > </RecordingCompany> > </CD> > <credit-card action="bill-credit-card"> > <type>Visa</type> > <name>John Doe</name> > <number>1234 5678 9012 3456</number> > <exp-date>11-03</exp-date> > </credit-card> > <billing-address> > <street>101 Smith Rd</street> > <city>Boston</city> > <state>MA</state> > <zip>03100</zip> > </billing-address> > <delivery-address action="mail-item"> > <street>101 Smith Rd</street> > <city>Boston</city> > <state>MA</state> > <zip>03100</zip> > </delivery-address> > </PurchaseOrder> > </body> > </message> > > Note the 3 actions that are specified: > - purchase-CD > - bill-credit-card > - mail-item > > The purchase-CD action is an attribute of the <PurchaseOrder> > element. > The bill-credit-card action is an attribute of the <credit-card> > element. The mail-item action is an attribute of the > <delivery-address> > element. Although you could still add a single top-level action (say "execute-transaction" or "submit-purchase-request", or whatever) that could facilitate dispatching by a top-level component. > > Questions: > > 1. I am having a really hard time understanding the later two > actions. > Of course I understand that a service would need to perform these two > actions, but I fail to understand why a "client" would have to > explicitly specify these actions in the XML message. Such > "sub-actions" > seem to be part of the semantics of the umbrella > "purchase-CD" action. > Can someone explain this to me? Or, is it just a poor example of a > multi-action message? If so, please give me a better example. I think this is a very simplistic example. This example could be easily served by a single top-level action. This is simplistic because each of the actions could probably be reliably inferred from a top-level action. But you might want a server-side configuration that associates actions with particular sub-elements so that you can employ lightweight, modular components for processing. For instance, a component that processes the order but does not know how to authorize a credit-card purchase, a separate component that authorizes the credit-card purchase but does not process the order, a component that notifies the shipping department of an order and provides the shipping address, etc. Where actions become relevant is when there is more than one way to interpret a subelement and you want to have a consistent, modular way to represent the data independently of the action that will be applied. Here's an example modelled after the sorts of things that we are actually doing (though the specific syntax is just off the top of my head and does not necessarily match any of our existing integrations). <UpdatePerson> <MatchCode>someID</MatchCode> <!-- unique identifier assigned by remote system for synchronization --> <FirstName>Roger</FirstName> <LastName>Costello</LastName> <Addresses> <RemoveAddress> <ObjectID>xxxxxx</ObjectID> </RemoveAddress> <AddAddress> <AddressType>home</AddressType> <Street>123 Main St.</Street> <City>Hometown</City> ... </AddAddress> <AddAddress> <AddressType>work</AddressType> ... </AddAddress> </UpdatePerson> The context in which we use something like this would be a situation where there is a fair amount of collaborative workflow between our system and a CRM system at a remote location. To support these collaborations, we define a shared information model and rich messages that allow one or the other system to synchronize the other systems view of the model. Typically, one system is designated as the master and is the only one to make changes to the information. The information model -- and the processing model -- is abstracted from what is really going on. For instance, the information model presented is hierarchical from the point of view of a message, though it is stored in a relational db. The semantics of "RemoveAddress" is not that of an RPC call or a simple DB insert. It simply means that the shared information model must reflect that that address is no longer associated with the parent Person entity. In our implementation, there are various ways something like this might be handled. Many types of records are never actually deleted. They just get a marker indicating they are deleted and they don't show up in the UI anymore. But some others do actually get deleted. It might not even be just one record, even though it looks like one in the XML message. The AddAddress is similar. If this is a containment relationship, this might actually add a record to the DB -- and in this instance, the address would have to be added after the Person to ensure referential integrity. If it is a many-to-many relationship (which is actually the way we do addresses), it might just add a link to an existing Address record (and likewise the RemoveAddress action might simply remove a link rather than delete the record). If the Person-to-Address relationship is a many-to-one relationship (not that you do that with people and addresses, but just as an example), then adding the address would happen *before* adding the person to ensure referential integrity. These interpretations of "AddAddress" and "RemoveAddress" are up to us to define, not the client. The client only cares what the shared information model looks like after a command and all of its associated subcommands are applied. This is not RPC, and there is no more coupling than that necessary to support the requirements. If an integration does not require such fine-grained synchronization of a shared information model, then we would try to adhere to one top level action. This is actually what we used to do, but we moved to this pattern of nested actions in order to support more demanding requirements from customers that we not fitting well with such a simplistic scheme. If someone wants to show me a useful and practical way to collapse these sorts of granular actions into a single top-level URI, I'm all ears. I'd be happy to learn such an approach, but we have real world requirements that we must fulfill -- and I would add that one of those requirements is to keep things simple for customers, most of whom don't give a damn about the W3C or the semantic web. The above message, though, could be modelled in a more sophisticated manner to afford looser coupling between actions and data. For instance, you could have actions in one namespace and data in another. You could use "Address" elements and have the action indicated by an attribute in another namespace, or make the Address element the child of an action element. There is a lot of flexibility, here, when you start viewing the message as a composite rather than a monolithic whole. > Let's turn to the other approach - separate the action from the data. > One of the purported disadvantages of this approach was that it may be > difficult/impossible to express actions of various parts of the > message's data. However, yesterday Christian Nentwich proposed an > elegant solution - using XLink/XPointers to link an action to > its data. Or, alternatively, just IDREFs. > (I like this idea!). That's the approach I have taken below. <snip/> > 1. One of the arguments against this approach (separating the action > from the data) is that it didn't allow "rich messages where multiple > actions are specified". However, as we see here, with the XLink > approach we can have the message richness. Thus, doesn't > this approach > have all the benefits of the other approach, without its > disadvantages? > Am I missing something? No. I think this approach can support the same richness. It's essentially the same as what I was speaking of; just different syntax. The syntax can get messy, though. I think if I offered this to customers, many would balk and want to make things simpler (and keep the actions close to the data with which they are associated). Keep in mind, most of our customers don't even want to use namespaces (though that is starting to change a bit; we have started getting customers who are expressly interested in using namespaces and XML Schema, and even have had one that explicitly asked for a SOAP integration). We do what we can to appease our customers. For those who don't mind the extra syntactic clunkiness, though, I'd say go for it! I'd be happy to provide such an approach to a customer who wanted it. [1] http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/compos/inte nt.htm [2] http://www.fh-konstanz.de/studium/ze/cim/projekte/osefa/patterns/chain/inten t.htm 
|
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
|
|||||||||
