> 1. Build an ODE Interface Layer to support easy embedding. Basically
> you would do something like:
+1, This would be great and would allow Tuscany to use this simple
API, instead of creating it's own ODE EmbeddedServer. Also, should the
embedded server interface be flexible enough to allow injection of
resources already existent on the host environment (e.g TxManager,
etc)
A question I have is around how would an embedded server work in the
scenario where the application is being deployed to an environment
that already have an ODE instance up an running (e.g a web app
deployed to a Tomcat that has ODE deployed to it) ? Does the embedded
server actually starts a second instance ? Or they cooperate among
themselves ?
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
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
