synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajesh Koilpillai" <>
Subject RE: A few basic doubts..
Date Mon, 17 Oct 2005 05:12:43 GMT
Comments in lined.


-----Original Message-----
From: Sanjiva Weerawarana [] 
Sent: Saturday, October 15, 2005 7:32 AM
Subject: Re: A few basic doubts..


On Fri, 2005-10-14 at 12:25 -0700, Mukund Balasubramanian wrote:

> Interestingly, I agree about the services being logically remote but stil
believe that

> you can, without losing architectural cleanliness and functionality, plug
synapse into

> axis 2. Why would we preclude that? 


> it us commonly termed the "agent" or "co-deploy" model of a




I'm not precluding that .. that's why I said "logically" remote. We can

of course allow arbitrary services to be dropped into Synapse but that

will confuse the mission of Synapse. Do you agree?


What I feel is its better to keep Synapse focused on the mediation

function and keep pure services logically remote .. that means they get

dropped in a different location (on the file system) and get deployed

into a separate AxisConfiguration object and you look at them with a

different URL ( instead of So when you look at it from the

outside the mediation agent is separate from the service runtime but

They could all be in the same JVM.


[RK] I agree with your point above, but in certain cases it's better to
adopt a particular model for service mediation. For example


1.    co-deploy (mediation components reside in the same instance as the
native provider web service is)

a.    Simple Logging

b.    Security

                                              i.      XML Signature
(Processing signed elements within the SOAP envelope)

                                          ii.      XML Encryption
(Processing encrypted elements within the SOAP envelope)

                                      iii.      Authentication
(Authentication of user credentials against an identity management system)

2.    agent (proxy mode of mediation)

a.    advanced routing

                                              i.      fail over (Achieving
fail over between multiple provider services)

                                          ii.      deprecation (Deprecation
rules enable you to mediate between multiple provider services)

                                      iii.      Routing based on a style
(round-robin, execute-until-success...)


It's actually possible to do all of the mediations mentioned for 'co-deploy'
on the 'agent' mode, but doing so on the 'co-deploy' mode removes the extra
hop of calling the native provider service itself from the mediation engine
and embeds all the mediation components on the same VM as the native
provider service.







To unsubscribe, e-mail:

For additional commands, e-mail:

View raw message