Just
quickly, before I have time to go through it all carefully:
I
think most of this is what is in the proposed solution for 78, 77 - making the
identifiers globally unambiguous in concept, URI's in practice, and removing all
the addresses that are only there to disambiguate.
These
are in the draft 0.9.1.1 that I put up last night (after a big fight with the
websites ftp server)
Peter
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.
|