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 Uid portion is assumed to be the enrol
id in my example. What I'm after is a scheme that, when requested, will allow a
coordinator to give to a user (decider) a list of inferior identifiers that
unambiguously relates them to the services for which they were enrolled. This
cannot simply be the inferior uid that was used during enrol, but must be a
combination of a "human parsable" name (e.g., "Acme") and the inferior iid. The
decider only sees the inferior identifier when calling prepare_inferiors and
friends, so it has to be this that is augmented. Perhaps we are talking about
the same thing.
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
Presumably you mean the return portion of an app
msg?
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.
*or* the inferior
identifier can contain context specific information like "Acme Taxi" such that a
subsequent inferior_statuses can return this information. I'm beginning to think
we are talking about the same thing, but need to double
check.
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
|