+1
I'm sure with WS-Reliability, WS-ReliableMessaging and a host of other
specifications that will eventually become standards, there'll be enough to
leverage in a fully-formed Web services architecture. There's enough work
within BPEL as it currently stands without having to define the entire
deployment environment on which it must work.
Mark.
>===== Original Message From "Satish Thatte" <> =====
>I think Fred's approach makes a lot of sense. It promotes a separation
>of concerns between business process logic and reliability
>infrastructure which makes everyone's job easier. B2B business
>protocols (e.g. RosettaNet PIPs) have historically tried to build
>reliability into the application protocol because they couldn't count on
>anything else to provide reliability, but we should take advantage of
>the opportunity in the web services space to solve the reliability
>problem separately and therefore more generally for all web services to
>use, not just BPEL processes.
>
>Satish
>
>-----Original Message-----
>From: Marin, Mike [mailto:]
>Sent: Friday, May 23, 2003 9:02 AM
>To: Dieter Roller
>Cc:
>Subject: RE: [wsbpel] Topics for the "Review input from TC members"
>session of the F2FSome
>
>
>Well, yes and no. It is not a problem for stateless idempotent WSDL
>operations. However, the whole point of BPEL is to support state full
>and potentially long running services to run real business stuff.
>Therefore, BPEL should suggest a solution or at least identify the
>problem for somebody to solve. There are several solutions to this
>issue, including the one mentioned by Fred (except that it does not work
>under the common case of SOAP under WSDL). Others include simple
>variations of two-phase commit to guarantee message delivery.
>
>--
>Regards,
>Mike Marin
>
>-----Original Message-----
>From: Dieter Roller [mailto:]
>Sent: Thursday, May 22, 2003 9:12 PM
>To: Marin, Mike
>Cc:
>Subject: RE: [wsbpel] Topics for the "Review input from TC members"
>session of the F2FSome
>
>
>Mike,
>
>I don't consider this a BPEL problem; this applies to any web service.
>
>Cheers,
>
>dieter
>
>Dieter Roller
>IBM Senior Technical Staff Member (STSM)
>Member IBM Academy of Technology
>Phone : +49-7031-164476
>Fax : +49-7031-164890
>e-mail
>
>
>
>|---------+---------------------------->
>| | "Marin, Mike" |
>| | <[email protected]|
>| | om> |
>| | |
>| | 05/22/2003 09:01 |
>| | PM |
>| | |
>|---------+---------------------------->
>
>>-----------------------------------------------------------------------
>----------------------------------------------------------------------|
> |
>|
> | To: "Cummins, Fred A" <>,
><>
>|
> | cc:
>|
> | Subject: RE: [wsbpel] Topics for the "Review input from TC
>members" session of the F2FSome
>|
> |
>|
> |
>|
>
>>-----------------------------------------------------------------------
>----------------------------------------------------------------------|
>
>
>
>Fred,
>
>With respect to topic "a"; I agree, but how do you do that using a SOAP
>binding on WSDL? (Or an HTTP binding for that matter). I think the
>specification should have some wording on this topic.
>
>--
>Regards,
>Mike Marin
>
>-----Original Message-----
>From: Cummins, Fred A [mailto:]
>Sent: Thursday, May 22, 2003 11:53 AM
>To: Marin, Mike;
>Subject: RE: [wsbpel] Topics for the "Review input from TC members"
>session of the F2FSome
>
>Mike,
>
>Such busiess operations should be implemented with reliable messaging.
>Thus the individual participants employ transactions to post and
>remove messages from their respective queues, and the reliable
>messaging protocol assures that messages are communicated from the
>sending queue to the receiving queue once and only once. In effect
>the reliable messaging protocol is the "transaction" protocol of the
>exchange.
>
>Fred Cummins
>EDS
>
>> -----Original Message-----
>> From: Marin, Mike [mailto:]
>> Sent: Thursday, May 22, 2003 2:17 PM
>> To:
>> Subject: [wsbpel] Topics for the "Review input from TC
>> members" session
>> of the F2FSome
>>
>>
>>
>> I have few issues that I will like to add to the list of "Review input
>> from TC members" for the F2F meeting.
>>
>> a- We don't have distributed transactions on web services yet. So how
>> do we insure that an activity such as an "invoke" is executed exactly
>> one time? The following example illustrates the problem:
>>
>> 1. Process A begins execution of an invoke instruction, and sends an
>> input message to Process B. There is no output message defined on the
>> invoke.
>> 2. Process B is defined with a receive instruction
>> corresponding to the
>> invoke of process A, and the receive instruction creates a
>> new instance
>> of the process. So upon receipt of the message from process A, a new
>> instance of process B is created, and this instance executes
>> the receive
>> instruction.
>> 3. The machine hosting process A crashes.
>> 4. Process B executes the next step, which is to debit an account and
>> update a database.
>> 5. Process B terminates. Process B has finished.
>> 6. The machine hosting process A is restarted. Process A then
>> re-executes the invoke instruction.
>>
>> On step 6, how can we prevent process A from executing the invoke a
>> second time, creating another instance of process B, and debiting the
>> account a second time?
>>
>> b- Invoking an operation, with input and output, that is
>> implemented by
>> a process using receive and replay requires the WSDL operation to be
>> asynchronous. A process may take days or weeks between the receive and
>> the reply, so the client cannot keep a connection open waiting for the
>> reply. Although WSDL 1.1 talks about asynchronous operations; it does
>> not seems to be any support for it in the WSDL specification.
>>
>> From the point of view of the process executing the invoke
>> the operation
>> is asynchronous in that the process blocks for the reply.
>> But, from the
>> point of view of the service implementing the receive reply pair; the
>> operation is asynchronous, and there is no way to prevent the time
>> between the receive and the reply from taking weeks. So, the invoking
>> process is blocked, but it cannot maintain a connection open.
>>
>> c- I am also concerned with the use of WS-Addressing for end point
>> references. I'm basically echoing the comment by Ron Ten-Hove.
>>
>> d- Just a note in the specification reference section,
>> reference [16] is
>> WS-Addressing. In appendix C, reference [16] seems to be for
>> WS-Transaction.
>>
>>
>> --
>> Mike Marin | FileNET Corporation | (714) 327-5134
>> Software Architect | 3565 Harbor Boulevard |
>> eProcess Development | Costa Mesa, CA 92626 |
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>For additional commands, e-mail:
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>For additional commands, e-mail:
