Thanks for the excellent clarifications, they help a lot.
I think I understand where you are coming from. I also mostly agree with all the problems you describe.
> In Synapse they go in the places defined by WS-*. If we don't put them there, then we need to define
> alternative places, and spend a lot of effort mapping between our places and the SOAP places.
I am afraid you're right. I suspect that what we see differently is the scope and the effort required. I assume you also agree then that the usefulness of Synapse for systems other than soap (such as corba) will be serverly limited because the mapping must be done somehow, somewhere.
I see in Synapse a lot of potential for being used for non SOAP and not even WS based systems, just XML document based systems. My views were influenced a lot by the fact that, from what I see, most of the mediators already implemented do not actually care about the nature of the message. I therefore assumed that if Synapse could be refactored in a core that is not SOAP aware and other (pluggable) components that are SOAP (or something else) aware, this potential could be better realized. Otherwise Synapse will probably do a great job at covering just the niche it was originally intended for.
I guess it is up to you now to decide if you want to explore this avenue or, based on your previous experience, you might consider it a futile endeavour. Personally I know it's feasible after spending a couple of weeks trying it out. If we are to continue this debate, I think we should start a fresh thread.
Kind Regards
Hadrian
On 8/4/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Imho Synapse mediators should deal *only* with the logical part of wsdl (as
> BPEL does for instance) and delegate everything that's related to the
> physical part to the component that knows best how to deal with that, which
> is the particular instance of SynapseEnvironment. I would start with
> clarifying our views around this aspect. There MAY be exceptions to this
> and have mediators that are aware or assume (implicitly or explicitly) a
> particular environment of policy, but imho they should be exactly that,
> exceptions (and personally I can't think of any such case at the moment, but
> I acknowledge that the world is not just black and white).
Hadrian
Actually this isn't the design point we are aiming for with Synapse.
We wanted to create a router that was very aware of SOAP. In
particular, Synapse can be used to mediate SOAP headers, mediate at
the transport level, etc. I know you refute the JBI link, but JBI is
exactly what you describe - a model that logically deals with the WSDL
message and not the SOAP headers, transport, etc. The details of the
transports, headers etc are dealt with by the components.
I'm afraid I'm a bit of a SOAP bigot. I've seen other attempts to
build messaging systems and SOA that tried to avoid any specific
model, such as SOAP. Unfortunately you end up having to define things
such as security, reliability, addressing, headers, etc. All of those
have to go somewhere. In Synapse they go in the places defined by
WS-*. If we don't put them there, then we need to define alternative
places, and spend a lot of effort mapping between our places and the
SOAP places.
The SOAP infoset we use is fundamentally an abstract model of
messaging that has been agreed by all the main software vendors. That
is effectively our design model.
Here's a quote from our charter:
This project will provide an implementation of a distributed services
mediation framework based on Web Services specifications. While it
will support connections to external systems, the fundamental model of
this architecture will be based on the core Web Services standards,
including SOAP, WSDL, WS-Addressing, WS-Policy, WS-Security and
WS-ReliableMessaging. Where possible this project will re-use existing
Apache implementations of these specifications, as well as the AXIOM
object model from Axis2.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
