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: [bt-spec] Re Issue 87 - conformance (was RE: [business-transaction]Email votes - 7 Issues - Ends Tues April 9- Conformance)


[earlier part of this discussion was on the mainlist, as follow-on from the
vote]

After some further thought, and attempting to avoid using any words that
imply more or less than is meant, or that would need defining, I'd like to
propose the second paragraph of the Conformance section, be:

"An implementation may implement some roles and relationships in accordance
with this specification, while
providing the (approximate) functionality of other roles in some other
manner. (For example, an implementation
might provide an equivalent of the control relationships using a
language-specific API, but support roles involved in the outcome
relationships using standard BTP messages.)  Such an implementation is
conformant in
respect of the roles it does implement in accordance with this
specification."

but otherwise apply the changes in the "First vote solution" to 87 (which
are in 0.9.5)

On Bill Cox's comment: I see what you want to avoid, but I don't think you
can avoid the possibility of the three classes - conformant, almost and non
existing. What you can do, and I think we are saying here, is that "almost
conformant" is non-conformant as far as any testing consideration is
concerned.  The other way depends on precision in "something like this role"
(or, from the text above "... (approximate) functionality of [a] role"). An
implementation that supported the "Cohesive Superior" or "Atomic Superior"
role groups must in fact be offering something like the Terminator and
Decider capability internally. We certainly want to allow such an
implementation, and equally would not expect to btp testing of its support
for Decider message support.  If it used (say) its own CORBA idl to allow
separated Terminator and Decider-like processes, it would still be a
Cohesive Superior, not a Cohesive Hub. If it used slightly bent btp xml
messages over soap for that, but didn't claim it was using conformant btp,
its still not claiming to be a Cohesive Hub, and it would not be tested for
conformance of Decider. Only if it says it does do conformant Decider would
it be tested for such or should it be expected that it would interoperate
with a different Terminator.

Concerning Mark's original comment - does the paragraph above still appear
to you to imply something inappropriate about implementation:actor:role
cardinality ?

Peter


> -----Original Message-----
> From: William Cox [mailto:william.cox@bea.com]
> Sent: 10 April 2002 03:17
> To: zpope@pobox.com
> Cc: Peter Furniss; Mark Little; OASIS BTP (Main List)
> Subject: Re: [business-transaction] Email votes - 7 Issues - Ends Tues
> April 9- Conformance
>
>
> I'm uncomfortable with this.  What I think we'd like to say is "if you do
> something like this role, do it the btp way."  Bill's proposal
> (does his comment
> make it something like a 'word horseshoe'?) goes part way.
>
> What we're getting at is separability, but separating
> conformation from almost
> conformant from non-conformant behavior is going to be ugly,
> messy, and turns
> interoperation into an exponential testing exercise.  (or at
> least that's my
> fear)
>
> bill cox
>
> William Z Pope wrote:
>
> > Some suggested wordsmithing ...
> >
> >  An implementation may include multiple BTP roles, for instance
> >  combining Terminator and Decider.  An implementation of a role may
> >  be conformant while others in the same implementation are
> >  non-conformant.  Such an implementation is conformant in respect of
> >  the roles it does implement in accordance with this specification.
> >
> > =bill
> >
> > -----Original Message-----
> > From: Peter Furniss [mailto:peter.furniss@choreology.com]
> > Sent: Monday, April 08, 2002 7:06 PM
> > To: zpope@pobox.com; Mark Little; OASIS BTP (Main List)
> > Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues
> > April 9
> >
> > Sounds good.  "Interoperable" was the word used in the text I
> evolved this
> > from (see the change-marked version, 0.9.2.4), but actually
> non-conformant
> > implementations can interoperate - with other appropriately behaving
> > non-conformant implementations, so its a confusing use.
> >
> > Does making that paragraph say:
> >
> >  An implementation may implement the functionality of some roles in a
> >  non-conformant manner - usually combining pairs of roles, such as
> >  Terminator and Decider. Such an implementation is conformant in
> >  respect of the roles it does implement in accordance with this
> > specification.
> >
> > sufficient, or does it need some further minor surgery (amplifying or
> > dropping the "usually ..." phrase ?) for clarity ?
> >
> > Peter
> >
> > > -----Original Message-----
> > > From: William Z Pope [mailto:zpope@pobox.com]
> > > Sent: 08 April 2002 17:31
> > > To: Peter Furniss; Mark Little; OASIS BTP (Main List)
> > > Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues
> > > April 9
> > >
> > >
> > >
> > > I think you are both agreeing in concept.  This change is meant to say
> > > that an instance may implement a BTP role A in a conforming
> way, implement
> > > another BTP role B in a non-conforming way, and still be considered
> > > conforming with respect to role A.  I think would be better to
> > > use "conformant"
> > > rather than "interoperable" because that's what this section is
> > > talking about.
> > > Using "interoperable" obscures the point.
> > >
> > > =bill
> > >
> > >
> > > -----Original Message-----
> > > From: Peter Furniss [mailto:peter.furniss@choreology.com]
> > > Sent: Monday, April 08, 2002 10:14 AM
> > > To: Mark Little; zpope@pobox.com; OASIS BTP (Main List)
> > > Subject: RE: [business-transaction] Email votes - 7 Issues - Ends Tues
> > > April 9
> > >
> > >
> > > > >
> --------------------------------------------------------------------
> > > > >
> > > > > Issue 87: Conformance Level
> > > > >
> > > > > --------------------
> > > > > Proposed Resolution
> > > > >
> > > > > Change the second and third paragraphs of the conformance
> section to:
> > > > >
> > > > >     An implementation may implement the functionality of some
> > > roles in a
> > > > >     non-interoperable way - usually combining pairs of
> roles, such as
> > > > >     Terminator and Decider. Such an implementation is
> conformant in
> > > > respect of
> > > > >     the roles it does implement in accordance with this
> specification.
> > > >
> > > > Isn't this a bad choice of words since we've always said that
> > > > there are many
> > > > roles in the specification, but they don't need to be
> played by a unique
> > > > actor for each? Why should this affect conformance? An
> actor can (and
> > > > should) be allowed to perform more than one role without
> affecting the
> > > > conformance of an implementation.
> > >
> > > The paragraph was meant to mean that an implementation that,
> for example,
> > > used a library approach, rather than a coordination hub
> server, was "fully
> > > conformant" - avoiding the phrase "partial conformance". It is fully
> > > conformant in what it does (assuming it does those things right),
> > > and it is
> > > nobody elses business how it does other things. It is a full
> > > citizen in the
> > > BTP world, as a Superior and Composer (say), even if the
> Factory cannot be
> > > distinguished within it.
> > >
> > > I'd understood (and I hope the spec says) that an actor is
> approximately a
> > > process (or perhaps an object instance - it's really defined by the
> > > addressing), whereas an implementation is something you get on cd or
> > > download. Within an implementation, once running, there may be
> > > all sorts of
> > > actors, or just one, and that is orthogonal to which roles
> those actors
> > > perform.
> > >
> > >
> > > Peter
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> > >
> >
> > ----------------------------------------------------------------
> > 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