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.
PRF2: I think we are pretty near on the
main idea. (btw, INFERIOR_STATUSES reports the inferior-name qualifiers,
though PREPARE_INFERIORS etc only uses the inferior ids - not sure if that was
covered in your "and
friends")
PRF2: Any "scheme"
is in fact going to have to repeat some information between the
enrol and the application response. The distinguishing characteristics of the
service are going to be stated in the application response (including things
like price etc), and any human-parsable field used in the inferior-name is
going to be some reference to that. but since its a reference, it doesn't
really have to be understandable. and there already is a unique
identifier.
PRF2: The more I think about this, the
more I suspect the only use of inferior-name is going to be where there isnt
any application response apart from it, and all the application/human
understandable reply is in the inferior-name
qualifier.
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?
PRF2:
yes
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.
PRF2: i think so, given the
qualifiers presence on
inf_statuses.
Peter
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
|