ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: Ode client API
Date Sat, 18 Mar 2006 17:15:36 GMT
I expect the great majority of use cases when using Ode's client API to be:

1- Transform an object tree to XML (using xmlbeans for example).
2- Pass the XML document to Ode's client interface for invocation.
3- If in/out get the result.
3- Transform the result to an object tree.

Keeping this in mind, building an abstraction layer on the client side
is overkill and will just complexify usage. If a user wants to query
the result (I can't see anybody querying the message to send), let him
use his preferred querying engine depending on the format he's using
in his application.

So normalizing the message around a javax.xml.transform.Source makes
sense. It's pretty stack neutral and it gives us a lot of flexibility
while keeping things simple. Don't you think?

Matthieu.

On 3/18/06, Lance Waterman <lance.waterman@gmail.com> wrote:
> I was thinking of an interface that is not content model specific ( i.e. XML
> ) and defines a query interface to the engine such that the engine can
> execute whatever query language is defined in BPEL.
>
> I have attached some JavaDocs from the Sybase donation as a reference point.
> The package I would like to refer to is "
> org.apache.ode.bpe.client.spi.interaction". The intent of
> this package is that a client application can wrap any data model ( DOM,
> NormalizedMessage, OMElement, SDOElement, JAXB ) and pass it into the engine
> where some query language ( from the BPEL ) will be applied against the
> wrapped data model ( it is also up to the client application to build in the
> query language support for their particular data model ).
>
> The Sybase donation contains a default DOM implementation.
>
>
> Lance
>
>
>
> On 3/17/06, Alex Boisvert < boisvert@intalio.com> wrote:
> >
> > Would a javax.xml.transform.Source suit your requirement, or are you
> > thinking along the lines of java.lang.Object?
> >
> > **
> > **Lance Waterman wrote:
> >
> > >I agree with these requirements and I would also like to add that the
> > >"payload" content must be opaque to the engine.
> > >
> > >Lance
> > >
> > >
> > >On 3/17/06, Alex Boisvert <boisvert@intalio.com> wrote:
> > >
> > >
> > >>Paul Brown wrote:
> > >>
> > >>
> > >>
> > >>>And in fact, I hope that we're running down a path where SOAP (and
> > >>>HTTP or anything else) is explicitly external to the engine.  It
> > >>>should be just as easy to inject a message exchange into the engine
> > >>>
> > >>>
> > >>>from a simple Java client as it would be from an RMI client as it
> > >>
> > >>
> > >>>would via a web service facade.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>Agreed.  As I understand it, there will be a need to send and receive
> > >>messages with:
> > >>
> > >>-a payload and possibly other message parts
> > >>-a set of optional headers to carry transaction, security, addressing
> > >>contexts and such
> > >>-an endpoint, interface and operation name to define what to do with the
> > >>message
> > >>
> > >>As well as the need to support two main message exchange patterns ("in"
> > >>and "in-out" in WSDL parlance) in both synchronous and asynchronous (w/
> > >>callback) manner.
> > >>
> > >>Are we in agreement with these requirements?
> > >>
> > >>alex
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>

Mime
View raw message