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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
