RE: [Requirements] Non-requirement for MEPs

Dear Colleagues,
 
I should make it clear that I was not thinking in terms of WSDL at all.
(I guess that by its nature this group will have to map onto WSDL as a
'lower' thing and so hopefully we can make use of WSDL's basic MEPs - we
may just need a simple 'send' and 'receive' at the WSDL level (i.e. only
2 of its current 4 / 7 patterns) and we compose those at will to make
other patterns at the WS-Chor spec level).
 
I was thinking in terms of the message pattern that is built into BPSS.
This called a Business Transaction and is a Request ( only mandatory
part) from 'Requester' to 'Responder' followed by an (optional)
receiptAcknowledgement from 'Responder' to 'Requester'  followed by an
(optional) acceptenceAcknowledgement from 'Responder' to 'Requester'
followed by an (optional) Response from 'Responder' to 'Requester'
followed by an (optional) receiptAcknowledgement from 'Requester' to
'Responder' .  The Request and Response are messages compiled by the
driving application (/process).  The Acknowledgements are pre-defined
messages structures were only the values are supplied on the fly.
 
So in BPSS a Business Transaction (that which I was meaning as a MEP) is
the lowest layer of message sequencing.  Business transactions can be
composed into sets known as binary collaborations (which will have a
particular purpose) and can be built into higher level binary
collaborations (with a wider purpose) and so on.  The highest layer of
BPSS adds in multiple roles and the sequencing of the binary
collaborations into a complete multi role collaboration.
 
The folks who designed BPSS believe that the Business Transaction
message exchange pattern is all that is required to provide any
*business* message exchange and are thus prepared to live with its
restriction.  They may be correct, but personally I am not sure and feel
that it may be safer to allow the users of the WS-Chor language to have
freedom to design their own business message exchange patterns.
 
I do think that specifying some standard 'messages' (the things that
BPSS calls signals) that users of the language can readily call up and
invoke would be useful and should be added to the requirements
 
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   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of ChBussler@aol.com
Sent: 17 March 2003 15:38
To: steve@enigmatec.net; Fletcher, Tony; public-ws-chor@w3.org
Cc: ChBussler@aol.com
Subject: Re: [Requirements] Non-requirement for MEPs


Hi,

I think it is preferrable not to be restricted to WSDL, but also allow
for the inclusion of other definitions/mechanisms.

Christoph

In a message dated 3/17/03 7:04:24 AM Pacific Standard Time, 
steve@enigmatec.net writes:




Subj:RE: [Requirements] Non-requirement for MEPs 
Date:3/17/03 7:04:24 AM Pacific Standard Time
From:steve@enigmatec.net
To:Tony.Fletcher@choreology.com, public-ws-chor@w3.org
Sent from the Internet 



Tony,

I think that there is an implication of this exclusion. It is that the
choreography would be tied to WSDL based MEP's. If however we make MEP's
part of the scope then we could extend the reach of the groups
work to include non-WSDL based formalisms.

Cheers

Steve T



-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
Sent: 17 March 2003 13:26
To: public-ws-chor@w3.org
Subject: [Requirements] Non-requirement for MEPs


Dear Colleagues,

Just to put in a message what I stated at the inaugural F2F.

Non- requirement for MEPs:
It presently seems to me that it is a 'non-requirement' to standards
message exchange patterns (MEP) as part of the WS-Chor work.  MEPs act
as a constraint on what you can do, so if one, or more, are defined we
will have to be very sure that users of the technique can live within
that set of constraints without having to 'jump through hoops' such as
extending the standard MEPs or having to chain them together to get the
pattern they actually need.

Requirements:
We certainly need to specify the 'construct'  for sending a single
message so that should be added to the requirements list.

We may also wish to standardise as part of the specification (in a
normative appendix perhaps) some standard business messages, such as a
generic error reporting message and an acknowledgement message

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   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)








------------------------------------------------------------------------
---------------------------------
Christoph Bussler
ChBussler@aol.com
hometown.aol.com/ChBussler/
www.google.com/search?q=bussler
www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky
------------------------------------------------------------------------
----------------------------------