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] Interoperability


Apologies for the subject label in the last mail  - my spell checker
corrected BT-Spec and I unfortunately hit send just as I saw it!!!!!

> -----Original Message-----
> From: Mark Potts 
> Sent: Thursday, May 02, 2002 3:53 PM
> To: 'Geoffrey Brown'
> Cc: 'BT - spec'; William Z Pope (E-mail); Bill Flood (E-mail)
> Subject: [bt-spec] RE: [but-spec] Interoperability
> 
> 
> Geoff
> 
> There are conformance levels in the spec based on "roles" that you can
> implement  - for instance "Participant" or "Atomic Superior". 
> I would like
> to see vendors test the interoperability of theses roles across vendor
> implementations. I think this would start to show where the spec is
> ambiguous and could do with "tightening up". This is what I 
> would recommend
> we try and do initially. To do this we would need some test 
> scenarios based
> on the requirements and use cases we specified initially - 
> although these
> may rather out of date in light of where the spec now is.
> 
> I have liked the approach taken at the WS-I in terms of coming up with
> scenario and then a profile for the scenario. For example 
> (off the top of my
> head, so don't take this to be a literal example);
> 
> Scenario: Third Party Coordination
> Roles: Initiator/Terminator, Atomic Hub, Participant's)
> Description: An initiator of a transaction contacts the Atomic Hub to
> ascertain context for a transaction. Subsequently the 
> initiator invokes
> services and propagates the context, including the address of 
> the Atomic
> Hub. Participants enrol with the Atomic Hub. Once Context 
> Replies have been
> received from the services invoked the initiator confirms the 
> transaction
> with the Atomic Hub. The atomic Hub terminates the 
> transaction of behalf of
> the initiator, reporting back the result of the confirmation request.
> 
> Profile: Defines the interactions in terms of the specification in an
> unambiguous way, in essence definitively defining, for this 
> scenario the
> interaction in term of MUST", "MUST NOT", "REQUIRED", 
> "SHALL", "SHALL NOT"
> only, and avoids "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL".
> 
> We may not be able to go the "whole hog" initially with 
> defining profiles
> but we should at a minimum define the scenarios and test 
> cases to prove
> conformance and therefore interoperability. I think we have 
> dropped the ball
> on this a little and got this close to completing the spec 
> without some of
> this in place, but then we are all busy and it hard to get 
> all this done and
> spec out in timely fashion. FYI WS-I has set a target of 180 
> days for the
> basic profile that covers a simple set of scenarios  and a 
> single profile
> (covering HTTP 1.1, SOAP 1.1, WSDL 1.x, and UDDI x.x.)
> 
> Regards,
> Mark Potts
> 
> PS - for Sanjay's benefit! I too hate the use of the term Hub 
> - could we not
> make it Controller!
> 
> 
> > -----Original Message-----
> > From: Geoffrey Brown [mailto:Geoffrey.Brown@oracle.com]
> > Sent: Thursday, May 02, 2002 1:48 PM
> > To: Mark Potts
> > Cc: 'BT - spec'; William Z Pope (E-mail); Bill Flood (E-mail)
> > Subject: Re: [bt-spec] Interoperability
> >
> >
> > Mark,
> >
> > I agree, this makes a lot of sense .. other than issue 89
> > could you elaborate on
> > your thoughts ?
> >
> > Geoff.
> >
> > Mark Potts wrote:
> >
> > > Geoff
> > >
> > > With respect issues 89 is a parallel issues to ensuring
> > interoperability, we
> > > need to address / test interoperability between conformance
> > profiles based
> > > on the 1.0 spec even if it does not include serialized state.
> > >
> > > In terms of looking at interoperability between different
> > implementations of
> > > the conformance roles we need to sure up the SHOULD, MAY,
> > and at least
> > > define a minimum profile such that interoperability can be
> > achieved between
> > > conformant implementations of that profile.
> > >
> > > Regards,
> > >
> > > Mark Potts - Chief Technology Officer
> > > Talking Blocks
> > >
> > > Office : +1 415 395 9872  x2250
> > > Fax : +1 415 395 9777
> > > Cell : +1 415 606 9096
> > > Email :  mailto:mark.potts@talkingblocks.com
> > >
> > > > -----Original Message-----
> > > > From: Geoffrey Brown [mailto:Geoffrey.Brown@oracle.com]
> > > > Sent: Thursday, May 02, 2002 11:28 AM
> > > > To: Mark Potts
> > > > Cc: 'BT - spec'; William Z Pope (E-mail); Bill Flood (E-mail)
> > > > Subject: Re: [bt-spec] Interoperability
> > > >
> > > >
> > > >  Interoperability *HAS* to be addressed before v1.0 of the
> > > > specification is
> > > > finished, as you are aware I am trying to address this in
> > > > part with issue 89.
> > > >
> > > > Geoff.
> > > >
> > > > Mark Potts wrote:
> > > >
> > > > > Bill,
> > > > >
> > > > > Originally when the TC was set up a sub-committee was 
> formed for
> > > > > Interoperability, Conformance Testing, headed up by Mark
> > > > Hale at Interwoven.
> > > > > I know Mark has since moved on from Interwoven and at this
> > > > time is not a
> > > > > contributing member to the TC.
> > > > >
> > > > > I suggest we address this sub-group - their charter etc in
> > > > Newcastle.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Mark Potts - Chief Technology Officer
> > > > > Talking Blocks
> > > > >
> > > > > Office : +1 415 395 9872  x2250
> > > > > Fax : +1 415 395 9777
> > > > > Cell : +1 415 606 909
> > > > > Email : mailto:mark.potts@talkingblocks.com
> > > >
> >
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 


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


Powered by eList eXpress LLC