OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [bt-spec] Deferred BTP Issue 108 : Participant and serviceidentification


 
-----Original Message-----
From: Mark Little [mailto:mark_little@hp.com]
Sent: 08 April 2002 15:51
To: Peter Furniss; bt-spec@lists.oasis-open.org
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")  
 
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
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC