[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bt-spec] URIs and address-as-X (MAJOR)
We've looking
through the BTP 0.9.1 spec, with an eye to implementation
within Web Services (since this is the area we're targetting). Apologies to Mark Potts who we think raised some of these issues in the past and we're just catching up ;-) It appears to us that things like addresses, identifiers and handles haven't really be considered from the point of view of the transport medium, only from the XML. In fact, the XML for certain messages seems to be used simply as an addendum to a description of what the message is intended to do and how it should be implemented, i.e., fields appear in the XML that simply wouldn't be there in the pure BTP message. It's similar to describing an OTS message in terms of TCP/IP+IIOP layer all the way up to the IDL signature. What we would like to suggest is: (i) that we take a long look at the message set (included below) and factor out BTP message content from delivery mechanism. (ii) remove all occurrences of address that are intended purely to identify the specific end-points for that message's request-response instance (e.g., target address). Any others (i.e., used at the application level for fail-over routing) replace with URIs. (iii) replace all Identifiers and Handles with URIs. There really isn't much point in maintaining a separate address and Identifier "thing" for a superior/inferior. If we move to URIs across the board then we have the necessary uniqueness for a "tid" and it avoids some of the complications in understanding the specification plethora of address-as-X! Unless you're implementing on raw TCP/IP then this separation doesn't give you anything and doesn't really fit into the world of Web Services. 1. Context Problem: The transaction here is uniquely identified by a "set of BTP addresses" and superior identifier. This is way too complex and in my mind breaks encapsulation since I don't actually care that this transaction is present at/managed by by a number of BTP superior addresses. Remedy: Remove Superior Identifier and Superior Addresses, replace with URIs (which at the back-end may well map onto a number of places where the transaction can be managed). 2. Context_Reply Problem: Asside from the fact that the spec is almost inpenetrable as to the meaning of this message, again superior identifier plus superior address is overkill. Remedy: Merge each superior address and superior identifier into a single URI. 3. Request_Status Problem: Target Address, Reply Address, and target identifier all appear here. Target address and reply address are transport issues. Target identifier is useless without the target address. Remedy: Target identifier becomes a URI. Reply address and target address disappear. The request_status operation is invoked on the endpoint described by target identifier and the reply address is implicity assumed to be the same endpoint as the entity that issued the message (this is easily catered for in most common transports like HTTP and SMTP). The situation where a reply address is actually different from the sender's address can be handled by the sender simply redirecting replies on behalf of the real recipient. 4. Status Problem: Target address, responder's address, and responder's identifier all appear in this message. I can see how the responder's identifier is useful here because it means I can get a tree of statuses back and make sense of it, but the other stuff is useless if URIs are used to describe endpoints and addressing is left to the transport binding. Remedy: Remove target address and responder's address. Change responder's identifier to a URI which uniquely identifies a responder. 5. Fault Problem: Target address, superior identifier, inferior identifier all appear here. Remedy: Delegate the target addressing stuff to the transport bindings. The identifiers become URIs which uniquely identify the inferior/superior that is involved in this fault. 6. Request_Inferior_Statuses Problem: Target address, reply address, target identifier, inferiors list. Remedy: The target and reply addresses can be delegated to the transport. The target identifier and inferiors list should be URI-based. 7. Enrol Problem: Target address, superior identifier, reply address, address as inferior, inferior identifier are all either underpowered or superfluous. Target address is a transport binding thing. Superior identifier needs the target address to work properly, reply address is implicit in the transport (response), inferior identifier and inferior addresses are too verbose. Rememdy: Scratch target address, superior identifier is a URI, scratch reply address, inferior addresses and inferior identifier simply become a single URI. 8. Enrolled Problem: Target address (again!), inferior identifier, inferior handle. Why do I need a separate inferior handle and identifier? If we assume the inferior identifier is a uri, then it is quite unique enough. Remedy: Scratch the target address and the inferior handle, turn the inferior identifier into a URI. 9. Resign Problem: The usual, target address isn't right here. Superior identifier doesn't get me to the superior without tagging on to the target address. Address as inferior and inferior identifier are too verbose. Remedy: Stick with the superior identifier as URI, then just extract the necessary bits to get the target address. Address as inferior plus inferior identifier can be rolled into a single inferior identifier if that identififer is a URI. 10. Resigned Problem: Target address & inferior identifier, unneccessary and not enough respectively. Remedy: Devolve the target address down to the transport, inferior identifier becomes a URI, and thus becomes capable of driving the transport. 11. Prepare Problem: Target address and inferior identifier. Remedy: Same issue and remedy as (10) above. 12. Prepared Problem: Target address and superior identifier is used to reply, address-as-inferior and inferior identifier used as unique inferior identifier. Remedy: Superior identifier becomes a uri and thus is capable of drving the target address at the transport level. Inferior identifier becomes URI and thus acts as a unique identifier for the inferior. 13. Confirm Problem: Target address and inferior identifier used to uniquely identify the inferior. Remedy: Inferior identifier becomes a URI and thus at a stroke is able to uniquely identifier the inferior, and is able to drive the transport level (target address). 14. Confirmed Problem: Target address and superior identifier used to identify the superior. Address as inferior plus inferior identifier used to identifier the inferior. Remedy: Superior identifier becomes URI, inferior identifier also becomes URI. All problems solved. 15. Cancel Problem: Target address plus inferior identifier. Remedy: Inferior identifier becomes URI, solves at a stoke the uniqueness and verboseness problem. 16. Cancelled. Same problem and remedy as (14) above. 17. Confirm_One_Phase Problem and remedy, see (15) above. 18. Hazard Same problem and remedy as (14) above. 19. Contradiction Same problem and remedy as (15) above. 20. Superior_State Same problem and remedy as (15) above. 21. Inferior_State Same problem and remedy as (14) above. 22. Redirect Problem: The redirect message seems overly complex. The mechanism isn't too bad per se (new addresses for the same identifiers), however it may be possible reconcile redirection with the new URI-based philosophy. Remedy: Ditch the new and old addresses. Instead go for a (set of?) new superior/inferior identifiers as URIs. 23. Begin Problem: Target address and reply address are transport level issues. Remedy: Relegate the target and reply addresses to the transport level. 24. Begun Problem: Target address, address-as-decider plus transaction identifier, inferior handle plus address-as-inferior, are all too verbose and/or mix BTP-level constructs with transport level issues. Remedy: Target address is a transport issue. Transaction identifier becomes a URI which uniquely identifies the transaction without the address-as-decider, the inferior handle becomes an inferior identifier (URI) which dispenses with the inferior handle plus address-as-inferior. Issue: do alternate addresses (e.g., list of address-as-decider) contain the primary end-point as well as the alternates, or just the alternates? 25. Prepare_Inferiors Problem: Target address, reply address, transaction identifier, inferior handles are all too verbose and impinge on transport level issues. Remedy: Simply send the transaction identifier (as URI) with inferior identifiers (also URIs). Target and reply addresses are handled at the transport level. 26. Confirm_Transaction Same problem and remedy as (25) above. 27. Transaction_Confirmed Problem: Target address not appropriate, address-as-decider plus transaction identifier verbose. Remedy: Relegate the target address to the transport, combine address-as-decider and transaction identifier into a single transaction identifier (URI). 28. Cancel_Transaction Problem: Target address plus transaction identifier verbose, reply address can be taken care of by the transport. Remedy: Transaction identifier becomes URI and is thus able to drive the transport. Reply address is factor of transport by default. 29. Cancel_Inferiors Same problem and remedy as (28) above, with the exception that the inferiors list should be composed from URIs, not inferior handles. 30. Transaction_Cancelled Problem: Target address and address-as-decider plus transaction identifier are verbose. Remedy: Target address is a transport issues, address-as-decider plus transaction identifier is too verbose and can be shortened to just a transaction identifier (being a URI). 31. Inferior_Statuses Problem: Responders address and responders identifier is verbose. Target address is a transport issue. Status values inferior handle plus status is not self-sufficient. 32. Begin + Context Problem: The Begin + Context is verbose, since to identify a transaction within which to begin a new transaction all that is needed is the identifier of that transaction (a URI). Remedy: Relegate context to be a bolt-on to application messages only. This simplifies the BTP model since we now only deal with BTP messages and not awkward combinations, and makes the process of creating a new transaction less verbose. Remedy: Again delegate target address and the responders identifier (a URI) to the transport. The status list should contain URIs which key status values and qualifiers, not inferior handles. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC