Hi,
We've been thinking recently of how scary ODE could seem for anybody who
hasn't an intimate (and slightly obsessive) relationship with an XML parser.
Tooling is good but if you can't show anything that get fed into the engine
because it's several pages long, it gets harder to encourage adoption. And
basically, everybody ends up writing pseudo-code that is kind of BPEL but
not really, using names for services that make sense without necessarily
caring about partner link types, ports and port types.
So I've been trying to see how we could make all that much simpler to get
into without necessarily breaking what we have already (not completely
breaking BPEL) but making both needs cohabit. And that's probably not so
hard. For now I see principally two directions:
1. Build an ODE Interface Layer to support easy embedding. Basically
you would do something like:
EmbeddedServer ode = new EmbeddedServer();
ode.deploy(some_bpel);
ode.send(some_xml_message);
This would allow developers to come and mess around and also would
encourage people to use orchestration directly inside their app without
needing a full blown server and remote layers. There's a lot of
simplifications that are possible here as people would just have to
implement a couple of interfaces to get messages back from ODE or have ODE
invoke their services. So I think we could go there essentially without WSDL
(by mocking it).
Making both modes (local invocations and remote invocations) cohabit
could be a bit more tricky but I think that's doable. And then, call me
crazy, but a local ODE could talk to a remote ODE, both invoking all kind of
services and all sort of fun things could be built.
2. Build a simple language, sort of equivalent to BPEL but easier on
the eyes. Something like:
process HelloWorld {
client.receive => request
var replyVar = concat('Hello ', request)
client.reply <= replyVar
}
That's just a dumb example and it would require some thinking to have
a nice little language that supports all use cases with some syntactic sugar
sprinkled on top. But writing a parser for this would then be pretty
straightforward and as long as it can be translated to our internal object
model we'd be able to execute it. Ideally we'd even be able to round-trip
BPEL to and from it.
I think these 2 things could be very helpful in helping developers stop
wondering which namespaces to use or why a complex-typed message on a
doc/lit service doesn't work. And maybe some of them could start actually
think of solving real problems.
What do you think?
Matthieu
