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