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:]
Sent: Wednesday, May 28, 2003 10:19 AM
To: ;
Satish Thatte;
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:]
Sent: Wednesday, May 28, 2003 12:59 AM
To: 'Satish Thatte';
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:]
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
