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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: RE: [wsbpel] Topics for the "Review input from TC members" session of the F2FSome


+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" <satisht@microsoft.com> =====
>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:MMarin@filenet.com]
>Sent: Friday, May 23, 2003 9:02 AM
>To: Dieter Roller
>Cc: wsbpel@lists.oasis-open.org
>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:ROL@de.ibm.com]
>Sent: Thursday, May 22, 2003 9:12 PM
>To: Marin, Mike
>Cc: wsbpel@lists.oasis-open.org
>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                   rol@de.ibm.com
>
>
>
>|---------+---------------------------->
>|         |           "Marin, Mike"    |
>|         |           <MMarin@filenet.c|
>|         |           om>              |
>|         |                            |
>|         |           05/22/2003 09:01 |
>|         |           PM               |
>|         |                            |
>|---------+---------------------------->
>
>>-----------------------------------------------------------------------
>----------------------------------------------------------------------|
>  |
>|
>  |       To:       "Cummins, Fred A" <fred.cummins@eds.com>,
><wsbpel@lists.oasis-open.org>
>|
>  |       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:fred.cummins@eds.com]
>Sent: Thursday, May 22, 2003 11:53 AM
>To: Marin, Mike; wsbpel@lists.oasis-open.org
>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:MMarin@filenet.com]
>> Sent: Thursday, May 22, 2003 2:17 PM
>> To: wsbpel@lists.oasis-open.org
>> 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 | mmarin@filenet.com
>> eProcess Development | Costa Mesa, CA 92626  | mmarin@acm.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org




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