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 Sun, 19 Mar 2006 05:27:37 GMT
Hi Matthieu,

I hear what you are saying and I do agree the 80/20 rule probably applies
here, however we are seeing folks throw very large object trees  ( i.e. HL7
) at the process engine and expecting it to perform well. I think this is a
place where specific value can be added to the core engine if we create an
API that is extensible.

I have added a few comments inline.

Lance

On 3/18/06, Matthieu Riou <matthieu.riou@gmail.com> wrote:
>
> 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.


I think the abstraction layer only adds complexity should the client wish to
create their own implementation. I think we should ( and currently do )
supply a default implementation ( around DOM or
javax.xml.transform.Sourceif you like ). With a default implementation
I don't think the interface is
any more complex than Axis ( but I could be biased ;) I have attached a "How
to Use the BPE Client Doc" and if there is anything we can do to make the
API more intuitive I'm all for it.

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.


I completely agree and I am proposing we take this one step further and let
the user define ( should they want to ) how the BPEL engine queries the data
format. Your right, I don't see anybody querying the message to send,
however the process engine will query the input message and if the user can
define the preferred query engine for the input message format then the BPEL
engine can leverage this.

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
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message