Hi,
You can of course implement a processor (or an endpoint) that
encapsulates an execution engine powered by scxml (or bpel, or other
language for that matter).
That discussion however took place in a different context, externalizing
the dsl. But you are correct, we could implement support for scxml today
in 2.x. Supporting scxml as a camel first class dsl though would require
the refactoring we intend for 3.0.
In a similar context I had a few chats with Tammo from ODE, who has some
very interesting ideas about refactoring the model, based on use cases
they for BPEL with models simply too large to fit in memory (100+ Mb
iirc). I think camel doesn't come even close to support such usecases
because we don't support partial execution models.
I will talk about using Camel for long running processes at CamelOne
2013 [1] (thanks to organizers for accepting my talk) and I could
comment a bit on the need for partial execution models if there would be
any interest in that.
Cheers,
Hadrian
[1] http://fusesource.com/apache-camel-conference-2013/
On 05/04/2013 06:56 AM, Murray.hughes wrote:
[19:23:13] <hadrian> another thing i looked at recently is scxml, i'll
write a component for it too, probably at acon
Does scxml really need v3? Surely it can work just fine in camel 2?
I imagined two interfaces -
A producer that sends an event to an scxml executer, and a eventDispatcher
that receives sends from scxml, sending them to consumers.
examples using jexl:
<state id="state6">
<transition event="exchange" target="state7"
cond="_eventdata.getProperty('key') eq 7"/>
<transition event="exchange" target="state8"
cond="_eventdata.in.body eq 7"/>
</state>
<state id="state7" final="true"/>
A producer drives it by triggering an event:
//exchange.setProperty("key", new Integer(7));
Message message = new DefaultMessage();
message.setBody(new Integer(7));
exchange.setIn(message);
te = new TriggerEvent("exchange", TriggerEvent.SIGNAL_EVENT,
exchange);
exec.triggerEvent(te);
Which transitions from state6 to state7.
Exchange headers can be saved in the state context domain model:
message.setHeader("key", "val");
te = new TriggerEvent("exchange", TriggerEvent.SIGNAL_EVENT,
exchange);
exec.triggerEvent(te);
<state id="state9" final="true">
<onentry>
<assign name="dmone" expr="_eventdata.in.header['key']" />
</send>
</onentry>
</state>
But the exchange can't be updated and returned to camel (that I know of), so
its a one way trip.
To go from scxml to camel the scxml Send Event calls a custom
EventDispatcher:
<state id="state9" final="true">
<onentry>
<assign name="dmone" expr="_eventdata.in.header['key']" />
<send event="'body'" type="'t'" target="'jms:x'"
targettype="'camelEndPoint'" namelist="dmone dmtwo">
</send>
</onentry>
</state>
The scxml domain model items must be named on the send namelist (dmone,
dmtwo in the above example).
EventDispatcher eventDispatcher = new EventDispatcher() {
public void cancel(String sendId) {
}
public void send(String sendId, String target, String
targetType,
String event, Map params, Object hints,
long delay,
List externalNodes) {
}};
An implementation of the EventDispatcher should be able to create an
exchange, assign the event to the body, the params to the exchange
headers/properties, look up the endpoint.
Again its a one-way trip.
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-CAMEL-3-0-weekly-IRC-chat-at-02-12-2013-7-00PM-8-00PM-CET-tp5727462p5732013.html
Sent from the Camel Development mailing list archive at Nabble.com.
