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

<exec language="EcmaScript" 
version="1.5">

    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:] 
Sent: Friday, May 23, 2003 5:36 
  PM
To: 
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:] 
Sent: Friday, May 23, 
  2003 2:37 
  PM
To: 
  
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

(919)254-7221 or 8-444-7221, Mobile: 
  919-624-5123