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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-implement message

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


Subject: Re: [wsbpel-implement] Face-to-Face scenarios


Rajesh Pradhan wrote:

>Hi Rania,
>
>This sounds good to me. The Loan Approval example is our starting scenario
>too :). How do you envision the processes split over multiple engines ?
>  
>
mm1: The Loan Approval example sounds good although we have had several 
significant issues raised about multi-start activities (issue 13, 2, etc).
In that regard, if we wish to showcase capability and add value, perhaps 
we can work with the use case group who may take on the challenges 
associated with multi-start.

Thoughts?

>Should we create some diagrams to make sure we are all on the same page ? Do
>you already have sample BPELs, WSDLs etc ?
>
>One of the questions I forgot to ask during the call was about the
>infrastructure. Do we get our own or will we have a setup at the F2F ?
>
>Thanks,
>
>Rajesh.
>
>-----Original Message-----
>From: rkhalaf [mailto:rkhalaf@watson.ibm.com]
>Sent: Tuesday, October 28, 2003 7:47 AM
>To:
>Subject: [wsbpel-implement] Face-to-Face scenarios
>
>
>Hi all,
>
>I'd like to start up a discussion of what people would like to try out
>at the face-to-face. The idea there is to meet and try out a few BPEL
>files on different engines to exercise the spec.
>
>I would suggest starting with a few BPELs that show different behavior:
>correlation with a multi-start example, calling other services and the
>use of links such as in  the loan approval example, and  more than one
>BPEL interacting, perhaps we can run one on each engine. For this we
>could start with a chaining echo: one client starts it off, then a chain
>of processes do rcv/inv/reply where the invocations kick of an instance
>of the same process running on a different engine until finally one just
>invokes a process that is the plain echo (rcv/reply).
>
>I also propose having an additive scheme to a simple rcv/inv/reply
>process: creating different versions of it to concentrate on exercising
>different areas without getting overloaded with complexity.
>
>That's the approach I would take in getting this off the ground.  I'm
>looking forward to everyone's suggestions/input/discussion.
>
>thanks,
>Rania
>
>
>  
>




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