Simplification and ease of use is always a good path.
+1
On 9/20/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> 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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
