You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Matthieu Riou <ma...@offthelip.org> on 2007/09/20 23:13:09 UTC
BPEL Simple
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
Re: BPEL Simple
Posted by Guillaume Nodet <gn...@gmail.com>.
Simplification and ease of use is always a good path.
+1
On 9/20/07, Matthieu Riou <ma...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: BPEL Simple
Posted by Paul Brown <pa...@gmail.com>.
On 9/20/07, Matthieu Riou <ma...@offthelip.org> wrote:
> 2. Build a simple language, sort of equivalent to BPEL but easier on
> the eyes. Something like:
> [...]
> What do you think?
I think it's a great idea. XML is neither human-readable nor
human-writable, so something a little (or a lot) more ergonomic would
be great.
--
paulrbrown@gmail.com
http://mult.ifario.us/
Re: BPEL Simple
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/20/07, Noel J. Bergman <no...@devtech.com> wrote:
>
> Luciano Resende wrote:
>
> > > 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)
>
> So conceptually similar to BSF? :-)
Mmmh what about:
class Options {
setTransactionManager(TransactionManager tm);
setDatasource(Datasource ds);
}
class Server {
init();
init(Options opt);
}
The init() with no options would of course have sensible defaults.
> would an embedded server work in the scenario where the application
> > is being deployed to an environment that already have an ODE instance
>
> Is there a reason why an Ode instance must be a singleton?
Actually not really. As far as ODE is concerned, you could have a full
server instance per process (as in BPEL process, not native process). If you
really want to have one single instance per VM I'd leave it to the client to
stick the reference to the server in whatever registry fits his needs. That
could be handled by the server itself but in a much clumsier way.
Matthieu
--- Noel
>
>
RE: BPEL Simple
Posted by "Noel J. Bergman" <no...@devtech.com>.
Luciano Resende wrote:
> > 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)
So conceptually similar to BSF? :-)
> would an embedded server work in the scenario where the application
> is being deployed to an environment that already have an ODE instance
Is there a reason why an Ode instance must be a singleton?
--- Noel
Re: BPEL Simple
Posted by Luciano Resende <lu...@gmail.com>.
> 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 <ma...@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
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: BPEL Simple
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/20/07, Paul Brown <pa...@gmail.com> wrote:
>
> On 9/20/07, Noel J. Bergman <no...@devtech.com> wrote:
> > What if Ode had a simple language that mapped directly to BPEL for flow
> > control (those BPEL operations you listed), but invoked a scripting
> > language, e.g., via BSF, for message manipulation?
>
> That is essentially what BPEL has now with extensibility for query and
> expression languages. (http://tinyurl.com/yrws9t) We just need the
> better syntax to wrap things in...
Yep, although queries and expression languages don't allow you to modify
the process state, you can only do that through assignment. A scripted
version of assignment could also be interesting. For example:
assignment {
names = customers.elements("name").map { |name|
"#{name.attribute("firstname")}
#{name.attribute("lastname")}" }
xml = Builder::XmlMarkup.new()
xml.people do
names.each { |name| xml.name = name }
end
message = xml.to_s
}
The only variables going in and out would be the ones associated with the
scope you run that in.
> I am assuming that you have already considered allowing Java to be used
> for
> > the purpose, too.
> >
> > process HelloWorld {
> > client.receive => request
> > var replyVar = java:MyClass.StaticMethod(request)
> > client.reply <= replyVar
> > }
>
> This isn't a bad idea, but it brings up a lot of potential questions --
>
> 1) Do we allow people to manipulate threads, transactions, sockets,
> etc. in that method? What about blocking or timing issues? (As is,
> ODE can context switch during an external invocation, even a
> synchronous one, and I suppose that we could do the same thing if we
> modeled apparent Java inlining as an invoke of sorts...)
> 2) To what extent is the class tied/versioned with the process?
>
> You can Google BPELJ if you're curious about one take on integrating
> Java into BPEL.
>
> -- Paul
>
Re: BPEL Simple
Posted by Alex Boisvert <bo...@intalio.com>.
+1 for simpler and more humanistic BPEL, WSDL and XSD encodings.
On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Yes, something similar .. but strictly adhering to the WSDL 2.0 component
> model so that in effect the new language is just a different serialization
> fo the same model. I would also probably drop reusable interfaces etc. in
> favor of the 80% case where one just defines the interface for a single
> service - then there's no need to name it, cross reference it etc..
>
> Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
> that's what James (Clark) keeps telling me .. I haven't argued the details
> out with him; but will one of these days.
>
> Its also possible to do something similar for a subset of XSD and get
> something quite useful I think.
>
> Interested? Shall we start an Apache Lab for it??
>
> Sanjiva.
>
> Guillaume Nodet wrote:
> > You mean something like that ?
> > http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
> >
> > Add RNC to it and the result would be awesome !
> >
> > On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while
> but
> >> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
> >> actually quite straightforward and likely a hell of a lot more usable
> for
> >> humans than the XML syntax.
> >>
> >> Sanjiva.
> >> --
> >> Sanjiva Weerawarana, Ph.D.
> >> Founder & Director; Lanka Software Foundation;
> http://www.opensource.lk/
> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >> Member; Apache Software Foundation; http://www.apache.org/
> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
Re: BPEL Simple
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Yes, something similar .. but strictly adhering to the WSDL 2.0 component
> model so that in effect the new language is just a different serialization
> fo the same model. I would also probably drop reusable interfaces etc. in
> favor of the 80% case where one just defines the interface for a single
> service - then there's no need to name it, cross reference it etc..
>
> Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
> that's what James (Clark) keeps telling me .. I haven't argued the details
> out with him; but will one of these days.
I'm not very convinced on RMC either, I like the block notation but all
those 'elements' and 'attributes' also add a lot of overhead and aren't
very non-parser friendly. I was thinking of something with a more "native"
feeling.
Its also possible to do something similar for a subset of XSD and get
> something quite useful I think.
>
> Interested? Shall we start an Apache Lab for it??
>
> Sanjiva.
>
> Guillaume Nodet wrote:
> > You mean something like that ?
> > http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
> >
> > Add RNC to it and the result would be awesome !
> >
> > On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while
> but
> >> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
> >> actually quite straightforward and likely a hell of a lot more usable
> for
> >> humans than the XML syntax.
> >>
> >> Sanjiva.
> >> --
> >> Sanjiva Weerawarana, Ph.D.
> >> Founder & Director; Lanka Software Foundation;
> http://www.opensource.lk/
> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >> Member; Apache Software Foundation; http://www.apache.org/
> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
Re: BPEL Simple
Posted by Paul Brown <pa...@gmail.com>.
On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
> that's what James (Clark) keeps telling me .. I haven't argued the details
> out with him; but will one of these days.
I think that we can take the perspective that the definition in the
WSDL should be for constraint purposes, i.e., any downstream client of
the XML can assume that it meets those requirements. Something like
an XML schema associated to the same document might be used as
annotations for binding to a local data structure, but that kind of
thing is (IMHO) best if done as lazily as possible, i.e., only when
necessary and by whom it is desired. ODE for example, just marshalls
text around, converting to other structures as necessary to apply
XPaths or other. It would be nice if the XML Schema for databinding
was an annotation on an endpoint rather than inherited from the
constraint expressed in the WSDL. (This then avoids lots of silliness
with subclasses, extension elements, local dialects, etc., by putting
the onus on the end consumer rather than the intermediary.)
Just thinking out loud.
--
paulrbrown@gmail.com
http://mult.ifario.us/
Re: BPEL Simple
Posted by Antoine Toulme <an...@toulme.name>.
Hi,
FYI the same idea is being discussed on the EMF list.
http://dev.eclipse.org/mhonarc/lists/emf-dev/msg00363.html
Hope this helps.
Antoine
On 9/25/07, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On 9/25/07, Noel J. Bergman <no...@devtech.com> wrote:
> >
> > Sanjiva Weerawarana:
> > > > Interested? Shall we start an Apache Lab for it??
> > > Definitely!
> >
> > Why a Lab, as opposed to here?
>
>
> I think Sanjiva was talking about a simple syntax for WSDL 2.0 when he
> proposed a Lab, which would be interesting inside ODE but also for quite a
> few other projects.
>
> BPEL would definitely be here.
>
> --- Noel
> >
> >
> >
>
--
http://antoine.toulme.name
http://www.lunar-ocean.com
http://www.requirements-tracker.com
Re: BPEL Simple
Posted by Alex Boisvert <bo...@intalio.com>.
On 9/27/07, Antoine Toulme <an...@lunar-ocean.com> wrote:
>
> FYI the same idea is being discussed on the EMF list.
>
> http://dev.eclipse.org/mhonarc/lists/emf-dev/msg00363.html
>
Related but different goal. The goal here is to have a human-friendly
syntax/encoding of BPEL, WSDL and XSD.
Using an EMF model would be one choice for implementing the converter
between the simple and XML syntaxes but there are other choices such as
Apache Woden, WSDL4J, Ode's O-model, Commons XmlSchema, ... that are all
models for their corresponding domains. Can EMF be used outside of the
Eclipse kitchen sink? :)
alex
Re: BPEL Simple
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Hi,
FYI the same idea is being discussed on the EMF list.
http://dev.eclipse.org/mhonarc/lists/emf-dev/msg00363.html
Hope this helps.
Antoine
On 9/25/07, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On 9/25/07, Noel J. Bergman <no...@devtech.com> wrote:
> >
> > Sanjiva Weerawarana:
> > > > Interested? Shall we start an Apache Lab for it??
> > > Definitely!
> >
> > Why a Lab, as opposed to here?
>
>
> I think Sanjiva was talking about a simple syntax for WSDL 2.0 when he
> proposed a Lab, which would be interesting inside ODE but also for quite a
> few other projects.
>
> BPEL would definitely be here.
>
> --- Noel
> >
> >
> >
>
--
http://antoine.toulme.name
http://www.lunar-ocean.com
http://www.requirements-tracker.com
Re: BPEL Simple
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi,
On 25/09/2007, Matthieu Riou <ma...@offthelip.org> wrote:
> BPEL would definitely be here.
>
as discussed yesterday with Matthieu, we've created a Wiki page
containing our first proposal. This page is aimed to collect and
discuss approaches to simplifying the BPEL syntax.
http://cwiki.apache.org/confluence/x/8Q4B
(hopefully it's not going to be exported to the public website yet)
Cheers,
Olly, Tammo
--
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
Re: BPEL Simple
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/25/07, Noel J. Bergman <no...@devtech.com> wrote:
>
> Sanjiva Weerawarana:
> > > Interested? Shall we start an Apache Lab for it??
> > Definitely!
>
> Why a Lab, as opposed to here?
I think Sanjiva was talking about a simple syntax for WSDL 2.0 when he
proposed a Lab, which would be interesting inside ODE but also for quite a
few other projects.
BPEL would definitely be here.
--- Noel
>
>
>
RE: BPEL Simple
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sanjiva Weerawarana:
> > Interested? Shall we start an Apache Lab for it??
> Definitely!
Why a Lab, as opposed to here?
--- Noel
Re: BPEL Simple
Posted by Tammo van Lessen <tv...@gmail.com>.
2007/9/21, Sanjiva Weerawarana <sa...@opensource.lk>:
> Interested? Shall we start an Apache Lab for it??
Definitely!
Tammo
--
Tammo van Lessen - tvanlessen@gmail.com - http://www.taval.de
Re: BPEL Simple
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Yes, something similar .. but strictly adhering to the WSDL 2.0 component
> model so that in effect the new language is just a different serialization
> fo the same model. I would also probably drop reusable interfaces etc. in
> favor of the 80% case where one just defines the interface for a single
> service - then there's no need to name it, cross reference it etc..
>
> Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
> that's what James (Clark) keeps telling me .. I haven't argued the details
> out with him; but will one of these days.
>
> Its also possible to do something similar for a subset of XSD and get
> something quite useful I think.
>
> Interested? Shall we start an Apache Lab for it??
Definitely.
Sanjiva.
>
> Guillaume Nodet wrote:
> > You mean something like that ?
> > http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
> >
> > Add RNC to it and the result would be awesome !
> >
> > On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while
> but
> >> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
> >> actually quite straightforward and likely a hell of a lot more usable
> for
> >> humans than the XML syntax.
> >>
> >> Sanjiva.
> >> --
> >> Sanjiva Weerawarana, Ph.D.
> >> Founder & Director; Lanka Software Foundation;
> http://www.opensource.lk/
> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >> Member; Apache Software Foundation; http://www.apache.org/
> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
Re: BPEL Simple
Posted by Paul Fremantle <pz...@gmail.com>.
I'd be willing to join the effort. I've been wanting to simplify WSDL
coding for a LONG time. Adding BPEL would make it really worthwhile.
Paul
On 9/21/07, Guillaume Nodet <gn...@gmail.com> wrote:
> Might be a good idea...
>
> On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > Yes, something similar .. but strictly adhering to the WSDL 2.0 component
> > model so that in effect the new language is just a different serialization
> > fo the same model. I would also probably drop reusable interfaces etc. in
> > favor of the 80% case where one just defines the interface for a single
> > service - then there's no need to name it, cross reference it etc..
> >
> > Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
> > that's what James (Clark) keeps telling me .. I haven't argued the details
> > out with him; but will one of these days.
> >
> > Its also possible to do something similar for a subset of XSD and get
> > something quite useful I think.
> >
> > Interested? Shall we start an Apache Lab for it??
> >
> > Sanjiva.
> >
> > Guillaume Nodet wrote:
> > > You mean something like that ?
> > > http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
> > >
> > > Add RNC to it and the result would be awesome !
> > >
> > > On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > >> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while but
> > >> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
> > >> actually quite straightforward and likely a hell of a lot more usable for
> > >> humans than the XML syntax.
> > >>
> > >> Sanjiva.
> > >> --
> > >> Sanjiva Weerawarana, Ph.D.
> > >> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > >> Member; Apache Software Foundation; http://www.apache.org/
> > >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> > >>
> > >
> > >
> >
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: BPEL Simple
Posted by Guillaume Nodet <gn...@gmail.com>.
Might be a good idea...
On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> Yes, something similar .. but strictly adhering to the WSDL 2.0 component
> model so that in effect the new language is just a different serialization
> fo the same model. I would also probably drop reusable interfaces etc. in
> favor of the 80% case where one just defines the interface for a single
> service - then there's no need to name it, cross reference it etc..
>
> Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
> that's what James (Clark) keeps telling me .. I haven't argued the details
> out with him; but will one of these days.
>
> Its also possible to do something similar for a subset of XSD and get
> something quite useful I think.
>
> Interested? Shall we start an Apache Lab for it??
>
> Sanjiva.
>
> Guillaume Nodet wrote:
> > You mean something like that ?
> > http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
> >
> > Add RNC to it and the result would be awesome !
> >
> > On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while but
> >> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
> >> actually quite straightforward and likely a hell of a lot more usable for
> >> humans than the XML syntax.
> >>
> >> Sanjiva.
> >> --
> >> Sanjiva Weerawarana, Ph.D.
> >> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >> Member; Apache Software Foundation; http://www.apache.org/
> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>
> >
> >
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: BPEL Simple
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Yes, something similar .. but strictly adhering to the WSDL 2.0 component
model so that in effect the new language is just a different serialization
fo the same model. I would also probably drop reusable interfaces etc. in
favor of the 80% case where one just defines the interface for a single
service - then there's no need to name it, cross reference it etc..
Yes adding RNC is not difficult but its not trivial to "data bind" RNC. Or
that's what James (Clark) keeps telling me .. I haven't argued the details
out with him; but will one of these days.
Its also possible to do something similar for a subset of XSD and get
something quite useful I think.
Interested? Shall we start an Apache Lab for it??
Sanjiva.
Guillaume Nodet wrote:
> You mean something like that ?
> http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
>
> Add RNC to it and the result would be awesome !
>
> On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while but
>> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
>> actually quite straightforward and likely a hell of a lot more usable for
>> humans than the XML syntax.
>>
>> Sanjiva.
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Re: BPEL Simple
Posted by Guillaume Nodet <gn...@gmail.com>.
You mean something like that ?
http://blogs.iona.com/ohurley/2007/05/this_is_not_wsdl.html
Add RNC to it and the result would be awesome !
On 9/21/07, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> +1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while but
> haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
> actually quite straightforward and likely a hell of a lot more usable for
> humans than the XML syntax.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: BPEL Simple
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Paul Brown wrote:
> On 9/20/07, Noel J. Bergman <no...@devtech.com> wrote:
>> What if Ode had a simple language that mapped directly to BPEL for flow
>> control (those BPEL operations you listed), but invoked a scripting
>> language, e.g., via BSF, for message manipulation?
>
> That is essentially what BPEL has now with extensibility for query and
> expression languages. (http://tinyurl.com/yrws9t) We just need the
> better syntax to wrap things in...
+1. I've been meaning to do a "normal" syntax for WSDL 2.0 for a while but
haven't quite gotten to it yet. Given the way WSDL 2.0 is defined its
actually quite straightforward and likely a hell of a lot more usable for
humans than the XML syntax.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
RE: BPEL Simple
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I am assuming that you have already considered allowing Java to be used
for
> > the purpose, too.
> This isn't a bad idea, but it brings up a lot of potential questions
> 1) Do we allow people to manipulate threads, transactions, sockets,
> etc. in that method? What about blocking or timing issues?
IMO, no. The environment should be restricted, which is why I had proposed
the use of a static method on the class. We could have rules and/or class
loader enforced limits on what can be used. It is certainly not unheard of
for container managed code to be significantly restricted in what it is
permitted to do.
The static method could be generated from embedded code, similar to the
BPELJ approach:
var x = java: { ... insert [language] statements ... }
That allows us to see the code in situ, and we could generate our own
support class and methods from those blocks. I leave open the option of
using other languages for those blocks.
The only logic in the code should be for purpose of doing its
manipulation/analysis of the message content; all other logic should be in
the BPEL. And I don't want it so rich that people are using it instead of a
business process. If we want that, define a local SCA/JBI component, and
invoke it from the BPEL process. I'm not looking for a lovely development
environment with inheritance, etc. I don't want to promote the idea of
people usingt the snippets for too much.
> 2) To what extent is the class tied/versioned with the process?
See above.
Note: unlikely that I'll reply to messages before Sunday evening.
--- Noel
Re: BPEL Simple
Posted by Paul Brown <pa...@gmail.com>.
On 9/20/07, Noel J. Bergman <no...@devtech.com> wrote:
> What if Ode had a simple language that mapped directly to BPEL for flow
> control (those BPEL operations you listed), but invoked a scripting
> language, e.g., via BSF, for message manipulation?
That is essentially what BPEL has now with extensibility for query and
expression languages. (http://tinyurl.com/yrws9t) We just need the
better syntax to wrap things in...
> I am assuming that you have already considered allowing Java to be used for
> the purpose, too.
>
> process HelloWorld {
> client.receive => request
> var replyVar = java:MyClass.StaticMethod(request)
> client.reply <= replyVar
> }
This isn't a bad idea, but it brings up a lot of potential questions --
1) Do we allow people to manipulate threads, transactions, sockets,
etc. in that method? What about blocking or timing issues? (As is,
ODE can context switch during an external invocation, even a
synchronous one, and I suppose that we could do the same thing if we
modeled apparent Java inlining as an invoke of sorts...)
2) To what extent is the class tied/versioned with the process?
You can Google BPELJ if you're curious about one take on integrating
Java into BPEL.
-- Paul
Re: BPEL Simple
Posted by Paul Brown <pa...@gmail.com>.
On 9/20/07, Guillaume Nodet <gn...@gmail.com> wrote:
> What about using RNG Compact syntax for the definition ?
> It's much easier to read than xml schema ...
Two thoughts:
1) RNC is one of the inspirations I had once upon a time for asking a
question similar to Matthieu's, so that's a good thought to keep in
mind.
2) RNC/RNG are preferable to XML Schema for describing BPEL, and I had
one around for BPEL4WS 1.1 once upon a time. I haven't updated it for
2.0 yet.
The real problem with using a schema-aware editor for BPEL is getting
the cross-references right, and that's been my biggest personal issue
with the BPEL/WSDL combo since the get-go.
--
paulrbrown@gmail.com
http://mult.ifario.us/
Re: BPEL Simple
Posted by Guillaume Nodet <gn...@gmail.com>.
On 9/21/07, Matthieu Riou <ma...@offthelip.org> wrote:
> On 9/20/07, Noel J. Bergman <no...@devtech.com> wrote:
> >
> > Matthieu Riou wrote:
> >
> > > 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
> > > }
> >
> > Is there anything existent that would be suitable? You want something
> > that
> > maps well with BPEL, but what else?
>
>
> Another DSL but definitely non XML-ish. With emphasis on terseness,
> readability (there's a good balance to find here) and smart defaults. I
> first thought of an internal DSL based on an existing flexible language
> (Ruby, Javascript) but that doesn't work. An external DSL is necessary.
>
> What are the available datatypes and operations in your theoretical
> > language? I have some thoughts, but want to see responses first.
>
>
> As I said it must map to BPEL and therefore to XML schemas. We can have
> primitive types for each xsd simple types (string, int, float, etc...) and
> native support for the XML datatype (like in E4X).
What about using RNG Compact syntax for the definition ?
It's much easier to read than xml schema ...
>
> The operations and control structures are the classic ones plus the ones we
> have in BPEL: if, while but also invoke, receive, scope (somewhat similar to
> a { ... } block), compensate, etc... Higher level constructs could also be
> interesting but I'd go with a basic set first and then see what can emerge.
>
> Similar to what you were thinking?
>
> Matthieu
>
> --- Noel
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
RE: BPEL Simple
Posted by "Noel J. Bergman" <no...@devtech.com>.
What if Ode had a simple language that mapped directly to BPEL for flow
control (those BPEL operations you listed), but invoked a scripting
language, e.g., via BSF, for message manipulation?
process HelloWorld {
client.receive => request
var replyVar = {
... some embedded script ...
}
client.reply <= replyVar
}
I am assuming that you have already considered allowing Java to be used for
the purpose, too.
process HelloWorld {
client.receive => request
var replyVar = java:MyClass.StaticMethod(request)
client.reply <= replyVar
}
--- Noel
Re: BPEL Simple
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/20/07, Noel J. Bergman <no...@devtech.com> wrote:
>
> Matthieu Riou wrote:
>
> > 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
> > }
>
> Is there anything existent that would be suitable? You want something
> that
> maps well with BPEL, but what else?
Another DSL but definitely non XML-ish. With emphasis on terseness,
readability (there's a good balance to find here) and smart defaults. I
first thought of an internal DSL based on an existing flexible language
(Ruby, Javascript) but that doesn't work. An external DSL is necessary.
What are the available datatypes and operations in your theoretical
> language? I have some thoughts, but want to see responses first.
As I said it must map to BPEL and therefore to XML schemas. We can have
primitive types for each xsd simple types (string, int, float, etc...) and
native support for the XML datatype (like in E4X).
The operations and control structures are the classic ones plus the ones we
have in BPEL: if, while but also invoke, receive, scope (somewhat similar to
a { ... } block), compensate, etc... Higher level constructs could also be
interesting but I'd go with a basic set first and then see what can emerge.
Similar to what you were thinking?
Matthieu
--- Noel
>
>
>
RE: BPEL Simple
Posted by "Noel J. Bergman" <no...@devtech.com>.
Matthieu Riou wrote:
> 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
> }
Is there anything existent that would be suitable? You want something that
maps well with BPEL, but what else?
What are the available datatypes and operations in your theoretical
language? I have some thoughts, but want to see responses first.
--- Noel