[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