OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[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