ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Szefler <...@intalio.com>
Subject Re: Ode client API
Date Mon, 20 Mar 2006 15:59:37 GMT
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
View raw message