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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-btp message

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


Subject: [ebxml-cppa-btp] RE: Fletcher 11/28/2002: Comments on Draft BTP CPPAExtension


Dear Monica,

Thank you very much for these comments, and my turn to apologise for
being a bit slow in acknowledging them.  I realised that a response
would some time and thought - and so kept putting off!  (Have a little
time on the train now so I am making amends).  Please see responses in
line below.

The main one is that the parameters mentioned are BTP ones and not from
other components.

Best Regards     Tony
A M Fletcher
 
Cohesions 1.0 (TM)
 
Business transaction management software for application coordination
 
Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787         Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com <mailto:tony.fletcher@choreology.com>
(Home: amfletcher@iee.org)


-----Original Message-----
From: Monica Martin [mailto:mmartin@certivo.net] 
Sent: 29 November 2002 21:53
To: tony.fletcher@choreology.com
Cc: Monica Martin
Subject: Fletcher 11/28/2002: Comments on Draft BTP CPPA Extension


Sorry it took me a bit to get this. Some brief comments, Tony:
*	In your Transaction Management proposal for CPPA, there appear
to be several items that will be negotiable and therefore, this should
be coordinated with the CPPA-Negot team (v 1.0 set for release by end
2002).
<AMF> Yes, this is true, however, I do not see the BTP extension
specification being agreed as stable let alone on its way to approval by
the end of December, so I think adding in to the negotiation spec. and
making t negotiable in a standard manner is likely to be work for the
(continuation) TC in the New Year. </AMF>

*	Explain what a BTP Superior and Inferior are, or reference it
back to the BTP specification. As these are Actor roles,  how or do they
map to those in BPSS?
 <AMF> Yes, OK I must try to remember to add specific reference in.
Superior and Inferior are BTP terms and are intended to be used here as
defined in BTP.  Please raise again if you do not see a change in the
next revision.  Yes they are Actor roles.  There is a relationship with
the BPSS roles, but I am not sure that it will be possible to spell out
all the possibilities with out being inadvertently unnecessarily
restrictive so may have to leave something to common sense / mutual
agreement of the parties. </AMF>

*	On Message_Timeout_Range, how does this map to ebMS, and BPSS
elements (and CPPA RetryInterval)?
<AMF> This is the message time out that the BTP state machine will apply
each time it sends a message out.  If it expires then it will take
whatever action is permitted / dictated by the BTP state tables, which
could be to re-send the message, send a different message, make an up
call on its interface with whatever is driving it and so on.  So no
*required* relationship to any internal timers that messaging might use
for its own reasons or with any that BPSS might set.  Having said that
there may well be sensible (ands not so sensible!) relationships between
timers used at different levels - so you may have a point.  I guess we
could add guidance that in general it might be best to set Application
(e.g. BPSS) timeouts >= BTP timeouts >= messaging timeouts  ?? </AMF>

*	On Standard_Qualifiers, how does this map to TimetoPerform in
BPSS and TimeToLive in ebMS?
<AMF> Similar answer to the one above.  The time related standard
Qualifiers are advisory times in BTP nothing actually has to happen if
they expire.  The guideline relationships could be:
  TimetoPerform (BPSS and BCP) >= Transaction timelimit
 TimetoPerform (BPSS and BCP) >= Transaction timelimit + Minimum
inferior timeout >> TimeToLive (ebMS)
TimetoPerform (BPSS and BCP) >> Minimum inferior timeout>= inferior
timeout </AMF>

*	Appears to be duplication or overlap in function in the BTP
extension and other specification elements at the process and the
application transport level.  Is this practical?  Please differentiate
or validate.
 <AMF>See above, but no - the intention is for the extension to provide
the configuration information for the BTP implementation and any other
parts of the system that are related to the BTP implementation or
impacted by it.  Anything already covered in the existing CPP/A
specification does not need to be (and will not be) covered in this
extension.
</AMF>

Thanks, Tony and Have a Nice Holiday...I am.
Monica
<AMF>Good - you have earned it.  I am looking forward to Christmas, and
I wish all readers a happy, peaceful and Blessed time then too. From
Tony  </AMF>




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


Powered by eList eXpress LLC