Agreed. FWIW I do like the NormalizedMessage & MessageExchange from JBI
http://java.sun.com/integration/1.0/docs/sdk/api/javax/jbi/messaging/package-summary.html which are pretty simple interfaces defined by the JBI Spec. My only real beef with them is that it'd have been nice for the NormalizedMessage to just have a body property of type Object rather than a JAXP Source being the only possible body (as you may have marshalled into a JAXB POJO and want to grab it directly etc). It might be best if Ode makes its own little API (e.g. a simple cut down version of JBI / Axis2) that borrows heavily from some of the others, that should also be easy to adapt to JBI / Axis2 / Tuscany / Celtix etc - yet keep dependencies simple with Ode. James On 3/17/06, Bill Flood <[EMAIL PROTECTED]> wrote: > forking the thread to Ode-dev... > > In theory I agree with you Alex...better to pick an existing API if it makes > sense. Practically speaking, we have a choice of a stack neutral API like > BPE, PXE, or something tied to a protocol stack that inherintely implies > pulling in other elements of that "borrowed" API. > > If we used the Axis2 API for Ode, we would be going down a path where Ode > usage would requrie Axis2. That requirement might be a major issue for > users of Ode and unless we can find a way around the inheritence of the > Axis2 stack, I'm inclined to prefer a stack neutral approach (e.g., BPED) as > well. > > On 3/17/06, Alex Boisvert wrote: > > > > > > Lance, > > > > As a general rule, I think it's better to pick an existing API that > > encompasses your requirements rather than reinventing your own. There's > > already a fair number of APIs out there that try to abstract the same > > problem domain. Unless we have divergent or additional requirements not met > > by exisiting framework, my preference would be to leverage existing work. > > > > I'm looking forward to your abstraction goals document and I will gather > > our own requirements in the mean time. > > > > alex > > > > PS: I don't mind reposting this to ode-dev; just trying to move > > discussion forward... > > > > > > > > Lance Waterman wrote: > > > > Hi Alex, > > > > I am open to shaping the API into whatever makes the most sense, however I > > don't think ODE should have any dependencies on a specific > > protocol/binding/bus stack ( ServicMix, Axis, Tuscany, Celtix, etc ... ). I > > think we should focus on defining a simple API ( note - I will send out a > > document that outlines some of our data abstraction goals around our client > > API ). If another project wants to "plugin" ODE then I think the plugin code > > should live in that project. Let me know your thoughts. Also, do folks think > > we should move these discussions out to the ode-dev mailing list? Might be > > good to get input from the larger audience. > > > > Lance > > > > On 3/16/06, Alex Boisvert wrote: > > > > > > > > > Hi Lance, > > > > > > Ok, I will take a look. > > > > > > Just to toss ideas around, I'm wondering if we could consider borrowing > > > (from) Axis2's client API > > > > > > http://ws.apache.org/axis2/0_94/api/org/apache/axis2/client/package-summary.html > > > > > > > > > alex > > > > > > > > -- James ------- http://radio.weblogs.com/0112098/
