|
Sorry for the delay in responding, but I've
been at JavaOne and then on vacation.
On an upcoming enrol, there already is a unambiguous identifier
(the inferior identifier). This is
visible to the cohesions terminator, on
INFERIOR_STATUSES etc. If the terminator can work out which bit
of application work this belongs to, it has the unique handle to
it. So how to ensure that it can make the
link
The enrol could come
associated with some application message (e.g. it is the only ENROL in the soap header, and the
soap body contains the
bid/quote/reservation details etc.). The application can then know that
the inferior so enrolled (identified by
its identifier) is doing the
confirm/cancel for that work. Note that this association is strictly
part of the application protocol (or the
application+btp protocol, not part of btp. (
In fact the SOAP binding does say that a single enrol in the header
is associated to the body - an
argument can be made that this is
wrong and should be left to the app.
pcol and not included in the binding.)
As mentioned in an earlier email, this only works if
the ENROL comes back with the application response, which isn't necessarily
going to be the case all of the time.
OR The enrol could carry an inferior name
qualifier, which by some convention
known to the applications allows the app work and the enrollment to
be linked. I don't believe there is any
need or capability in making this
guaranteed unique, though it probably would be often unique. It would
be things like "Acme taxis", "BA 23+UA
658", "ABN AMRO:hp option". The point is it
must be meaningful to the application, and this more or less precludes it
being unique -(think peoples' names, versus their id
numbers)
We can make it unique by requiring a component of the
name to contain a unique identifier, so "Acme taxis:1234abcde" and "Acme
taxis:2345defab" can be differentiated by a "human" and yet remain
unique.
The application message
could carry a field that was known to be in the
ENROL - this could be the "inferior name", but the identifier would
probably be more use, precisely because
it is known to be unambiguous. (In fact, I'm
not so sure the inferior name is any use on thinking this
through). This is clearly an application
[protocol] responsibility - the identifier becomes a parameter on their
message.
All those are possible
with what we already have in the text. The possible improvements are:
there is no statement that an
ENROL can be directly associated with an
application message unless it is a related-group with context-reply.
It ought to be possible to associate
them directly, with a naked enrol in the
header (for example) - if the address usage makes this feasible. BUT,
since this association is really an
application matter, it can be argued that we
don't need to say anything, as it is already
implicit.
Maybe I'm missing something here, but you
still appear to be saying that an ENROL must come back on the application
response. True?
If the address usage
means that context-reply *must* be used to send the enrol back in association with the app
msg (i.e. the Superior address is not the same
as the applications, but they need to be sent together), then it is
possible there will be more than one
context-reply sent back, which means one (at least) must have a completion flag meaning
"not-completed" - which isn't a valid value
at the
moment.
In
fact, the description of CONTEXT_REPLY currently mis-uses "completed" in this
case, to mean (effectively) incomplete.
So,
I've put in a proposed solution (included in 0.9.2.4, 0.9.3) to add
"incomplete" as a value for the completion-status of
CONTEXT_REPLY.
Other clarifications are probably best considered as
review comments, especially on the model (or the
primer)
Again, maybe I've overlooked something, but how does
this solve the (common IMO) case of a client making an invocation on a service
within the scope of a cohesion and the service enrolling a participant with that
cohesion before returning a response to the client? In this situation, the
client (or BTP component thereof) doesn't see the ENROL: it just happens
transparently as a part of the invocation.
Mark.
----------------------------------------------
Dr.
Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna
Labs
Email: mark_little@hp.com
Phone: +44 191
2606216
Fax : +44 191 2606250
|