BTP issue - ex-9 - proposed resolution ( for participant identification in context-reply)

Title: Message

I 
propose that we apply the first solution below, allowing a CONTEXT-REPLY to 
contain an inferior identifier and define an additional related group 
CONTEXT_REPLY & Application Message, whose meaning is defined as (this is 
modified from the CONTEXT_REPLY & ENROL & Application Message text at 
7.9.4):

 

This 
related group applies only if the CONTEXT_REPLY message contains an inferior 
identifier value. In this case the transmission of the Application Message (and 
application effects implied by its transmission) has been associated with the 
Inferior whose identifier is in the CONTEXT_REPLY and the effects will be 
subject to the outcome delivered to that Inferior.

 

(The 
rest of the text for the related group is left to the editing process (i.e. I'm 
not going to do the fiddly bits until I know if this is 
accepted))

 

Peter

  

  
-----Original Message-----
From: Furniss, Peter 
  
Sent: 23 March 2004 15:55
To: 
  
Subject: 
  [business-transaction] Issue - ex-9 - participant identification in 
  context-reply

  
This issue has been added to the btpex issue list. The issues list is 
  posted as a Technical Committee document to the OASIS 
  BTP TC pages on a regular basis. The current edition, as a TC document, is 
  the most recent document with the title in the "Issues" folder of the 
  BTP 
  TC document list - the next posting will include this issue. The list 
  editor's working copy, which will normally include an issue when it is 
  announced, is available at this 
  constant URL. 
  Issue - ex-9 - participant identification in 
  context-replyStatus: open
Date added: 23 Mar 
  2004
Submitter: Peter 
  Furniss
Date submitted: 23 March 2004
Description: 
  CONTEXT is commonly sent in association with an application message, 
  propagating the business transaction and telling the receiving application 
  that work performed as a result of the application message should be part of 
  the business transaction. However, with cohesionss, there is a need in some 
  applications to identify a particular inferior (participant) as being 
  responsible for some piece of application work. For example, an invitation 
  (say request for quote) may be 'broadcast' (in some way) with an associated 
  context for a cohesion. Responding applications can submit as many quotes as 
  they wish, each corresponding to a separately enrolled inferior. The 
  initiating application then chooses the successful quote(s) and confirms only 
  those. To do this, the initiating application of course needs to know which 
  inferior (as visible to it, via the coordinator) corresponds to which quote. 
  
There are already several ways that this can be done with BTP, but they are 
  all rather application-specific. At present, one could: 
  
    
set the inferior name qualifier on the enrol to a field that is present 
    in the application response (such as the quote number) 
    
put the inferior identifier as a field of the application message 
    
send the ENROL message in the header of the application message (using 
    the one-shotting optimisation - if the carrier supports it, and it is 
    appropriate for the configuration). 

  
None of these could readily be supported by generic software in the way a 
  propagated context could be in the opposite direction. There should be some 
  general way. 
Submitter's proposal: A possibility would be to allow 
  an inferior identifier to be placed in the CONTEXT-REPLY, which would have 
  similar semantics to having an CONTEXT-REPLY&ENROL&application message 
  related group as far as association was concerned. 
  
Alternatively, the presence of an inferior name qualifier on a 
  CONTEXT-REPLY could be defined as having the similar meaning. 
  
Note that both of these are essentially using CONTEXT-REPLY as just the 
  standardised carrier of this information, rather than invent another message 
  (REVERSE-CONTEXT ?) just for this purpose.
Changes: 23 Mar 2004 - 
  new issue

  

  
To comment on this issue, please follow-up to this announcement on the 
   list (replying to this message 
  should automatically send your message to that list), or ensure the subject 
  line as you send it starts "Issue - ex-9 - [anything]" or is a reply to 
  such a message. 
  
To add a new issue, please email to the issues list maintainer 
  (Peter Furniss). 
  
To unsubscribe from this mailing list (and be removed from the roster of 
  the OASIS TC), go to 
  http://www.oasis-open.org/apps/org/workgroup/business-transaction/members/leave_workgroup.php.