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 Thu, 23 Mar 2006 23:38:21 GMT
Maciej,

Thanks for the clarification and yes to date I have been focused on the
latter bullet point. It appears that there is some consensus around the need
to define such an API.  I have floated some thoughts around the shape of the
API, however I have not spent much time looking at the PXE interface. Does
PXE have similar abstractions and if so could someone point me to them -
thanks.

>From another thread Alex mentioned that a "PM-API" was under heavy
development. Could someone explain the PM-API?

Thanks,

Lance

On 3/20/06, Maciej Szefler <mbs@intalio.com> wrote:
>
> My take on this is as follows:
>
> * If what we mean by "client API" is a method of invoking (that is
> delivering messages to) BPEL services from /diverse/ client applications
> (something an web-app developer might write) then we want to stick to
> existing technologies (such as AXIS). I see little point to providing
> yet another method for such clients to invoke a BPEL service.
>
> * We do want to provide integration flexibility: that is, the engine
> should not be married to any specific client API. If someone wants to
> write a new client API and backend that to the engine, there should be a
> nice simple integration/binding API to let them do that (this same API
> would be used to integrate into the AXIS handler chains). I believe this
> API should have the characteristics that Lance describes.
>
> -maciej
>
>
>
> On Sat, 2006-03-18 at 22:27 -0700, Lance Waterman wrote:
> > 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.Source if 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/alternative (inline, None, 0 bytes)
View raw message