RE: Questions (RE: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC fac

Aspect#1: Assuming a session based communication protocol and WS-Addressing as a way of initiating the session using some form of handle explicit correlation might eventually become unnecessary. We should work out the details of what it would take to get this simplification. However, in general we probably cannot assume session-based communication. There are scenarios like multi-start activities (example in spec) where correlation is not avoidable.

Aspect#2: This seems to relate to multi-start activities. There is no “ghost instance” semantics here, but there is rendezvous semantics. The idea is to make the expression of rendezvous easy, but that does mean more work for the infrastructure (effectively providing the service you mention as an implicit part of the bus).

Aspect#3&4&8: In my book, the items you mention are deployment related and not in scope for BPEL.

Aspect#5: I believe this type of binding is ruled out by the charter.

Aspect#6: I agree this type of pattern is a requirement.

Aspect#7: I am not aware of any use cases where other-than-reverse order is needed for compensating looped activities. Do you know of such a case?

Satish

From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Wednesday, May 28, 2003 12:59 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Cc: 'Diane Jordan'
Subject: Questions (RE: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC face to face)

Sorry for not being able to attend the face to face in person. Here are a list of questions regarding aspects of the specification that we like to better understand (We will try to dial in).

Aspect #1:

Correlation Sets. Are they necessary? Can we use a conversation id/cookie instead? WS-addressing has all the pieces needed to make correlation a plumbing problem. Given that services need to create a lookup table for the callback location, isn't it as easy to save the conversation id in that table as well?

Aspect #2:

Multiple <receive>s to initiate a flow. Are they necessary? The current BPEL spec all the developer/designer to specify that an processes should be enacted when 2 separate messages are received. This makes the system very difficult to manage in some cases: Let's imagine that the system has received message M1 but still requires M2 to enact a process instance. Then that ghost instance is difficult to manage. Couldn't matching be instead another service living on the bus?

Aspect #3:

Unified Meta Data. Priority, instance id, status. There are a set of meta data that make sense for all BPEL processes. Could we standardize them? Can we offer getters for them? BPEL 1.1 event handler offer a solution to implement 1-off this functionality but it is not a very elegant solution to the problem.

Aspect #4:

Logging. Should there be a default logger activity built-in as part of the standard BPEL activity set. <log....>

Aspect #5

Procedural Extension. Based on the use case we have seen it would be very useful to have an <exec> activity that would allow execution of code within the execution of the flow

var order = getVariableData( "purchaseOrder" );

....

</exec>

EcmaScript, C#, Java, Python, etc... people could select their favorite language and retain portability as long as the engine that they use to run their BPEL script has support for that language. The alternative to injective snippets of procedural code within the flow are very cumbersome.

Aspect #6

FlowN and sophisticated join patterns. Here is the use case: I receive a request for quote, I query a database for a list of partner (number of partners not known at design time). I need to send a request to each of the partner and wait in parallel for them to get back to me with a quote. If the 3 first partners that are invoked are within 10% of the target price requested by the customer, I want to cancel the remaining conversations and complete the flow with the first 3 partners. We need some type construct to perform N activities in parallel. We need a construct for joining M activities based on conditions.

Aspect #7

Scope and Scope instance. In the spec, scope names are used to reference scope instances. The combination of compensate and while highlight the type of limitations we might run into. Is that association done in purpose?

Aspect #8 (Nice to have)

Base Deployment Descriptor. a .bpel is not enough to deploy and run a BPEL process. We need a way to link the .bpel to its .wsdl (public interface). We need a way to link some of the partnerLink to actual end points.

Thank you!

Edwin

From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Friday, May 23, 2003 5:36 PM
To: wsbpel@lists.oasis-open.org
Cc: Diane Jordan

Dear F2F attendees,

I would like to solicit input on any specific aspects of the BPEL specification that you would like to see explained (goals/motivations, conceptual clarifications, etc). Or else you might end up with a boring tutorial on stuff everyone understands (or more likely a much shorter presentation, which of course might be the best case outcome ;-)).

Satish

From: Diane Jordan [mailto:drj@us.ibm.com]
Sent: Friday, May 23, 2003 2:37 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC face to face

Hello All,
As promised, here is an update to the proposed agenda for Wed/Thurs.
We now have about 40 folks coming in person and about 15 calling in. It should be a good session. I look forward to meeting everyone who can make it.

Regards, Diane
IBM Dynamic e-business Technologies
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123

wsbpel message