ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: BPEL Simple
Date Thu, 20 Sep 2007 22:14:18 GMT
Simplification and ease of use is always a good path.

On 9/20/07, Matthieu Riou <matthieu@offthelip.org> 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

Guillaume Nodet
Blog: http://gnodet.blogspot.com/

View raw message