On Fri, Jun 6, 2008 at 3:19 AM, Marc Bischof <[EMAIL PROTECTED]> wrote:
> Hej devs,
>
> I've another question to the SimPEL grammar.
> I don't understand the usage of correlations and their mappings in the
> grammar.
>
> Correlations are only used in the receive_base rule, but the BPEL-spec
> states
> that for example invoke also has such correlations.
> I wonder why they are missing there.
>
> Why is that modeled as:
>
> corr_mapping : f1=ID ':' expr
>
> The BPEL-spec provides only three types of attributes (set, initiate and
> pattern)
>
> What was your idea behind the modeling of correlation sets? Can you give me
> some insight on how to model a correlation set with all attributes?
>
So if you think of BPEL correlation, the closest thing would be a kind of
special hash. This hash has a set of properties and all those properties
must be set all at once. The way to set them is a set of xpath expressions
that apply on a message. Then the hash acts as a sort of compound key for
your process.
The mechanism, while it guarantees a few things, is also a bit awkward, both
to use and understand. First there's the "all properties have to be set at
once" thing. It doesn't really matter if they're set at once or not as long
as, when a message comes in and needs to be confronted to the property
values, they're all there.
Second, the only chance you have to set a correlation is when messages gets
in and out, which is even more limiting.
Finally, there's a lot of indirection and overhead involved. What you're
interested in is the property and its value but actually those properties
only make sense as part of the hash, so in your process you end up
manipulating the hash extensively but not the properties. Even if the hash
only has one single property (which is the most common case). Then each
property has a a way to get extracted and this way is different for each
message type. Even if the real XPath expression ends up being the same
(which also often happens).
So instead of duplicating the correlation mechanism as is, we started
thinking of what was the bare minimum a BPEL engine needed to find a given
instance from the data of a received message. That mechanism is actually a
simple matching: you have some data as part of your process and you'd like
that data to be matched against some part of the message. So in a sort of
specialized SQL, that would be:
select instance where instance.orderId = extractOrderId(message);
In order for the process engine to find instances quickly it really must be
able to generate a real SQL query that sort of replicates this one. The
extraction function is the easy part, it doesn't need to be run in the DB
but the matching itself has to. What does this mean?
- orderId has to be a unique value
- orderId has to be flat data (no XML)
And that's it! To reflect those two constraints we've created the 'unique'
flag in SimPEL to clearly indicate which variables comply to those
assumptions. Then you just need to set that value somehow (from another
message, from some computed data, from wherever) and tell a receive how to
map it with an incoming message:
function orderIdFromOrder(order) { return order.orderId; }
process OrderManagement {
var orderId unique;
// do stuff
orderId = ...;
receive(partner, continue, {orderIdFromOrder: orderId};
}
Here we just tell the engine how to extract the needed data from the message
and which process data to map it to, which is sufficient information and I
think, much easier to explain and understand than correlation.
The auction example here can show you a slightly more complex use case (from
the spec):
http://svn.apache.org/repos/asf/ode/sandbox/simpel/src/test/resources/auction.simpel
It could be optimized a bit (I wrote it what seems now like a while ago) but
I think it's clear enough.
Cheers,
Matthieu
> Cheers,
> Marc
>
