ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Ode client API
Date Fri, 17 Mar 2006 23:47:38 GMT
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. 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