ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Ode client API
Date Sat, 18 Mar 2006 00:00:41 GMT
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