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 Sat, 18 Mar 2006 00:13:58 GMT
inline ...

On 3/17/06, Assaf Arkin <arkin@intalio.com> wrote:
>
> The Law of Leaky Abstractions:
> http://www.joelonsoftware.com/articles/LeakyAbstractions.html
>
> I vote for Axis2 as the good enough abstraction for this project.
>
> Whenever you create an abstract API, besides the effort required to
> document, maintain and test it, you run the risk that the API is too
> abstract to be useful, or not abstract enough to be a worthwhile
> abstraction. Most of the time it ends up looking like an API you could
> have
> reused. Add do that all the duct tape and rope required to actually get it
> working.
>
> Since the majority of cases we deal with are Web services, we get the best
> leverage from using an API designed for those use cases.


I don't agree with this generalization. I don't see all ESB implementations
using Web services as a core bus architecture ( Synapse excluded ;)


Every communication
> problem a process has to deal with, is a communication problem Web
> services
> have to deal with. So why not let the Web service experts address that,
> and
> reuse their work?
>
> I'm just worried that Ode would be the 100th project to offer its own
> unique, sometimes interoperable, not fully documented, way of talking to
> Web
> services, when instead we should be focusing on building the best process
> engine.
>
> Assaf
>
> 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