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.
PRF: this is
an alternative to the other mechanisms, snipping off bits of the problem
space.
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.
PRF: I don't see why
it needs to be unique. The enrol already carries a unique identifier, so
in combination, inferior name "Acme taxis" and an inferior identifier
that is a URN are "understandable" and unique. To *guarantee*
uniqueness you need a whole registration structure (and using URI's
neatly makes use of the existing URI and DNS registration schemes); all that
is needed for the name is a useful level
of differentiation.
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?
No, there are three
cases:
i) ENROL & app
msg
ii) ENROL carries inferior-name qualifier that
provides "meaning" as well as identifier that provides unambiguity; app msg
and ENROL can come different ways (there may not even be any app msg, if the
qualifier carries sufficient information)
iii) app msg contains inferior-identifier, thus
pointing to the separate ENROL
ii is provided for with the inferior-name qualifier.
iii is up to the application protocol. i has text supporting the single
case, but could cause difficulties if there are multiple messages. This
is only if, for other reasons, the application + btp protocol definition has
decided to work that way.
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.
PRF: The returning
application response needs to carry an identifier that is unambiguously
associated with the participant. Since the inferior-identifier has that
property, that's all that needs to be returned. Exactly *how* this is
carried with, by or in the application response is, in general, a matter
for the application protocol. I suppose one could, as part of a binding
specification, allow a single btp identifier to appear in the soap-header of
the response, with the meaning that it was thus associated or related to the
whole content of the application response. (There would be opposition to this
from some, who hold that the existing binding *already* says too much about
appmsg and btp msg assocation).
Mark.
----------------------------------------------
Dr.
Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna
Labs
Email: mark_little@hp.com
Phone: +44 191
2606216
Fax : +44 191 2606250