synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: A few basic doubts..
Date Mon, 17 Oct 2005 10:15:30 GMT
Rajesh

I agree with the benefit of co-deploy and agent as you described. But I
think that everything you describe is in the model Sanjiva describes,
because (to quote from Sanjiva's note):
"They could all be in the same JVM."

So in that case it is not a question of extra hops, but the model Sanjiva
describes still keeps a level of logical/administration separation. So that
the Synapse administrator can define and deploy mediations independently of
the application instances admin. This is very important, because the aim is
to minimise changes to the deployment of already running applications.

Paul

On 10/17/05, Rajesh Koilpillai <rajesh@infravio.com> wrote:
>
>  Comments in lined.
>
>  -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Saturday, October 15, 2005 7:32 AM
> To: synapse-dev@ws.apache.org
> 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
> broker/mediator.
>
>  +1.
>
>  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 (http://example.com/axis2/blah instead of
>
> http://example.com/synapse/blah) <http://example.com/synapse/blah%29>. 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.
>
>  Sanjiva.
>
>    ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
>
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>

Mime
View raw message