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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

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


Subject: RE: re - BTP Issue 108 (was RE: [business-transaction] Email votes -7 Issues - Ends Tues April 9 = RESULT)




> > On 108 itself, I would assert:
> >
> > the concerns are really application protocol issues, not BTP ones. More
> > precisely, they
> > are concerns of BTP-using applications, and therefore need to
> be addressed
> > in the
> > specification of the application+btp contract between the parties.
>
> In as much as they make cohesions useable in a standard way, then I agree.
> However, this should not be taken as a reason to not do something
> in the 1.0
> specification. I think we are close to agreeing on the solution. If we do
> not do this then cohesions will IMO not be used.
>
> > "applications" in this sense includes the btp-supporting infrastructure
> > (such a interceptors/filters etc that deal with the application
> messages,
> > containers or whatever that keep track of thread-associated
> contexts, and
> > transaction-conscious resources that determine what enrollments are
> > necessary)
>
> Yes.
>
> > no change is needed in the normative spec; the existing fields and
> > qualifiers provide the necessary information signals between the parties
> > involved - there are unambiguous identifiers that can be quoted by
> > application (or application-associated) messages, and there is an
> > application-determined inferior-name that can be as precise as
> is pleased.
>
> Yes, but we need to specify how it should be set in order to allow an
> application to use a cohesion.

But, as we've discussed, there are several different ways it can be done,
some of which will work with some applications, some with others. The
general requirement is to allow the Terminator (an application element) to
determine which application work at the service will be confirmed/cancelled
by which Inferior (Participant). That isn't just a question of having an
interpretable identifier for it, but of associating the unambiguous
identifier for the Inferior with the work done, as expressed in some
application-protocol-defined data that passed between the Terminator (i.e.
the client application element) and the Service.

(I've tried to be strict there in using "application" to mean the joint
purpose of both sides, application element to mean the software involved in
that within a single party, and application protocol to mean the definition
of what passes between the elements.)

The application protocol could specify that all the data is passed in the
inferior-name, but probably more common, application protocols would define
their own complete messages which contained, as a field, an inferior-name or
the inferior identifier and the Terminator application element used this
field to correlate the received application protocol message with the
Inferiors it could see in the Composer. But an application protocol might
define its own specific qualifier that went on the ENROL, containing
structured information. (Suitable for "invitation to tender" applications,
perhaps, where the invitation stated all the terms, and all the bid needed
to say was who and how much)

> > Explaining how to define an application+btp contract/protocol is not
> > something that needs to be in the spec itself.
>
> Totally disagree here. There needs to be a statement on how users can use
> cohesions. Simply giving them loads of XML and implying that that's all
> they'll need does readers, implementers and users of all kinds a
> disservice.
> After having worked long and hard on putting these damn things into the
> specification let's not fall at the last hurdle by making them
> un-useable or
> throwing away interoperability. We already have propsective customers who
> are turning away from them for precisely this reasons.
>
> > I'm not at all sure we know
> > all the ramifications (in fact, I'm quite sure we don't), still
> less agree
> > on them. Some of this is going to be in user guides for BTP-using
> products.
> > It might be specified in some way in WSDL or similar, that stated the
> > expectation and nature of a service.
>
> I'll say it again: standard and interoperable!

But we are talking about the interoperability of the application protocol,
which is clearly not our province. There are implications for what a BTP
implementation (including the BTP-supporting infrastructure, in this case)
needs to do (e.g. if an application protocol designer has chosen to use
app-specific qualifier, the BTP-accessing API better have a way of setting
and accessing them), but again that would only appear as advice in our
document.


If I haven't convinced you :-), can you suggest text ?

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX



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


Powered by eList eXpress LLC