ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Ode client API
Date Sun, 19 Mar 2006 14:02:41 GMT
Lance,

Have u looked at AXIOM? We've moved it our of Axis2 and is completely
standalone. Synapse guys needed it. Designed specifically for very
large object trees.

thanks,
dims


On 3/19/06, Lance Waterman <lance.waterman@gmail.com> 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
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
>


--
Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message