RE: Dubray paper comments + questions

>>The need for correlation is related to asynchronicity. If you are
going
>>to decouple request and response, you need a way of associating
response
>>with request. The initiator could issue multiple requests, and the
>>responder may return responses to any of these in an unpredicatable
>>order. (This may not be a common or familiar use case if you are
>>accustomed to synchronous request-reply, but it is usually how things
>>work with asynchronous protocols).
[JJ] Jon, I understand that perfectly but I prefer to use a protocol to
establish the correlation id rather than relying on message content for
that. The problem of relying on message elements is that this format can
change (you create an unfortunate coupling between collaboration
definition and message content preventing cross industry collaboration
definition), it is also harder to maintain transforms of the correlation
specification in synch with the transform of the incoming message schema
in case you use different semantics internally and externally.

I understand than using such protocol is a bit optimistic today but if
you don't make it available along with correlation mechanisms,
applications will still use correlation specification 50 years from now.

Within the boundaries of a company I think it is Ok to use correlation
protocols.
>>
>>
>>> [JJ] Sorry, I corrected, the end tag was meant to be DataFlow.
Again,
>>> the whole purpose of the paper was not necessary to detail the
process
>>> definition but rather to show the concepts and how they are related
to
>>> each other. (If there is an interest I can publish a more robust
spec).
>>> A separate data flow is proposed by BPSS and WSFL. BPML has a very
good
>>> data flow too.
>>
>>Ok ... one of the reasons I'm asking about this, and about BPEL4WS, is
>>that if this proposal is going to be taken seriously as an alternative
>>to other schemes, then IMO it has to be complete enough to compare
with
>>other, more fully specified alternatives. The existing specs have
flaws,
>>but their capabilities and limits are also easier to grasp.
[JJ] Honestly I don't know what is the objective of the ws-chor group.
Are they looking for proposals and they will end up choosing the one
that is closest to what people think ws-chor should be and then fix it a
bit? Or are they looking at starting from writing a specification from
scratch of course borrowing from the submissions or other sources.
Martin, Yves could you clarify this for me?

If you want a proposal I can probably get to one fairly quickly after
checking with OASIS/UN/CEFACT to see if it is okay that I use BPSS as a
starting point. 

Another possibility is that the ws-chor groups uses BPSS as a submission
because honestly I did not change it that much, I just showed that the
concepts of BPSS could be used in a wide range of choreography
specifications as opposed to just being useful in the context of ebXML.

Thanks,

JJ-
>>
>>--Jon
>>

Received on Wednesday, 26 February 2003 13:57:05 UTC