----- Original Message -----
Sent: Tuesday, April 09, 2002 12:05
AM
Subject: RE: [bt-spec] Deferred BTP Issue
108 : Participant and service identification
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")
<ml>Yes.</ml>
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.
<ml>The identifier has to be understandable
(or at least a component of it does). Simply having "foobar:1234abcd" doesn't
convey enough information to a decider that "foobar" is actually "Acme taxi". So
as long as the "handle" the decider uses has this parse-ability it doesn't
matter about the name IMO.</ml>
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.
<ml>I think the confusion could be my fault if I
was using name instead of identifier in text. Meant "whatever handle the decider
has to control termination", which is the
indentifier.</ml>
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
|