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] Questions (RE: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC face to face)


I unfortunately did not get the time to do this during the presentation.  We could do this on a call for Q&A on this specific topic or during one of the regular phone meetings (might as well have some real technical content to those meetings ;-)).

 

Satish


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

 

Satish,

 

Thank you for this morning's presentation. I have updated this list to contain information collected this morning (and added one more question). What would be the best way to drill down into some of the content of slide 11 "WS-TX Business Activity Protocol - A Model for Nested Scopes in BPEL "?

 

Thank you,

 

Edwin

 


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'

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? 

[Satish Presentation Slide 8] In the example you pictured this morning regarding rendez-from 3 incoming intiating messages. Let's imagine that the process is implemented as <sequence><flow><receive><receive><receive></flow><the rest> do you envision that a full blown instance is created on the receive of the first message or do you expect that the system would queue the messages up until the 3 messages are received before enating a process instance.

 

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, 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  (see WSDL Java Binding, etc..) .

[Satish Presentation] Would this be considered as hardware/software binding and therefore out of scope?

 

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.  

 

Aspect #9

Is <fire> missing? Is there a specific reason why we would NOT want the flow to fire events internally.  

 

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



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