On 3/22/06, Soumadeep <[EMAIL PROTECTED]> wrote:
Mediators are one unique entities that are going to grow exponentially as Synapse grows. Paul, as the release manager, has put on the M2 todo list what we should expect on M2 release. Security and RM is must.
As this is a ASF project, if you guys are writing mediators, please be kind enough to *write a descriptive note* to this mailing list before committing any code, otherwise it will be like the thread on SynapseObject, where there are other proven alternative technologies exist than SynapesObject itself.
When i read your response, you have mentioned some mediators that ain't exist in M1 or M2 candidate. So IMHO we should try to stick to what we have now and what we have agreed to do on.
As Synapse started from scratch with no string attached, let it be a good code base to other developers to develop.
Thank you
Saminda
Hi Ruchith,
That's a good observation. The features that were listed have not been
committed as yet because we are still in the process of doing so. We will
keep you posted.
Mediators are one unique entities that are going to grow exponentially as Synapse grows. Paul, as the release manager, has put on the M2 todo list what we should expect on M2 release. Security and RM is must.
As this is a ASF project, if you guys are writing mediators, please be kind enough to *write a descriptive note* to this mailing list before committing any code, otherwise it will be like the thread on SynapseObject, where there are other proven alternative technologies exist than SynapesObject itself.
When i read your response, you have mentioned some mediators that ain't exist in M1 or M2 candidate. So IMHO we should try to stick to what we have now and what we have agreed to do on.
As Synapse started from scratch with no string attached, let it be a good code base to other developers to develop.
Thank you
Saminda
Thanks
Soumadeep
-----Original Message-----
From: Ruchith Fernando [mailto: [EMAIL PROTECTED]]
Sent: Wednesday, March 22, 2006 8:45 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
properties:crypto.properties
Hi,
I downloaded Synapse [1] and I couldn't find any of the security
related mediators in it.
Thanks,
Ruchith
Ref:
[1] https://svn.apache.org/repos/asf/incubator/synapse/trunk/java
On 3/22/06, Mukund Balasubramanian < [EMAIL PROTECTED]> wrote:
> Sanjiva:
>
> The X-Broker codebase was contributed to seed Synapse. The feature
> functions listed here are those which were available in the commercial
> version of the X-Broker and are now being built into Synapse.
>
> I think this a perfectly valid response on the mailing list and hope it
> addresses your concerns.
>
> Mukund Balasubramanian
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 21, 2006 6:55 PM
> To: [email protected]
> Cc: Xinjun Chen; [email protected]
> Subject: Re: [Synapse]RE: CryptoFactory: Cannot load
> properties:crypto.properties
>
> Um, r u talking about Synapse or your product? Please be sure you are
> clear what you're talking about .. its not appropriate to use ASF
> mailing lists to advertise your products.
>
> Sanjiva.
>
> On Tue, 2006-03-21 at 22:55 +0530, Soumadeep wrote:
> > Hi,
> >
> > The mediation framework, which is Synapse, can take care of the use
> cases
> > that you mentioned. It's a proxy-based model and acts as a policy
> enforcer,
> > which can be configured and enforced using the mediators. If you want
> more
> > information you can also post your queries at
> > http://www.infravio.com/community/ for our existing broker
> architecture on
> > which the mediators are based.
> >
> > Just to give you a background we have the following mediators:
> >
> > ConsumerIdentificationMediator: This mediator will identify the client
> who
> > sent the request. The ways to identify the clients are:
> > IP
> > IP-Range
> > WS-SEC Token
> > HTTP Token
> > Certificates
> > LDAP
> >
> > SecurityMediators:
> > VerifySignatureMediator: This mediator will verify signature if
> required.
> > SignMediator: This mediator will sign the request if required
> > DecryptMediator: This will decrypt the message
> > EncryptMediator: This will encrypt the response if configured
> >
> > RoutingMediators:
> > FailoverMediator :
> > Failover is the act of switching to a secondary service in case the
> primary
> > service fails.
> > Hence, logically, we can configure failover only when we have 2 or
> more
> > endpoints providing similar
> > services.
> > The failover process can be initiated on timeout and or faults.
> > In case of 'failover on faults' the FailoverMediator keeps switching
> to
> > secondary services,
> > until all the secondary services are tried or one of them returns a
> > successful result.
> > In case of failover based routing on timeout is active, the
> participating
> > end-points would be given
> > timeout values and the connection would be forced to close and a fault
> would
> > be returned if no
> > response arrives within that many milliseconds and then 'failover on
> fault'
> > logic kicks in.
> >
> > LoadbalancingMediator:
> > Loadbalancing is the act of distributing the load, the requests
> for a
> > particular service across
> > various service endpoints.
> > In case a provider has more than one endpoint that provides the same
> > service, he would like the
> > load of requests being made to be distributed across them.
> >
> > The strategy being supported now is round robin i.e. requests would be
> sent
> > to the various participating
> > services in a round-robin, one after another fashion.
> > In case the service that was invoked fails to respond, the mediator
> switches
> > to the next one in the line.
> > Its a mere pass, hence the next request will get directed to the one
> which
> > was supposed to handle it if
> > the previous service didn't fail.
> >
> > DeprecationMediator:
> > This mediator validated if a service has been deprecated
> (date wise) and
> > depending on it routes it.
> >
> > SLAMediator: Depending on the ConsumerIdentification mediator a
> priority
> > is selected for the clients and based on it the
> > request is queued.
> >
> > ManagementMediator: This mediator will gather management related
> information
> > and notify management reporting application, currently we are planning
> to
> > implement it using JMX.
> >
> > LoggingMediator: Will gather logging information and log it to
> appropriate
> > log4j appender
> >
> >
> > Thanks
> > Soumadeep
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 21, 2006 9:02 PM
> > To: Xinjun Chen
> > Cc: [email protected]; [email protected]
> > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> >
> > Hi Xinjun,
> >
> > On 3/21/06, Xinjun Chen <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Hi Ruchith,
> > > Thank you for your reply.
> > > If I use the security module, is it possible that we use different
> > security
> > > policies for different client, i.e., the security policy is a
> contract
> > > between the service and a specific client or group of clients. What
> I want
> > > to do includes two kind of things: first kind is to receive a
> SOAPEnvelope
> > > which contains client information in the header part. According to
> the
> > > client information, I apply predefined security policy to the
> SOAPEnvelope
> > > (this may include add username token, signature, and/or encryption
> based
> > on
> > > the client info), and send the SOAPEnvelope to the destination EPR.
> >
> > I think this is a scenario where you have an intermediary service
> > which will be the client to the actual service that the original
> > client wants to invoke.
> > IMHO this certainly can be supported with the existing axis2 security
> > module.
> > Basically when the client send the request to the intermediary service
> > it can configure the how the request should be configured
> > dynamically to invoke the secured service. You can use the
> > InflowConfiguration and OutflowConfiguration objects to configure [1].
> >
> > > The other scenario I want to add addressing information to the
> message
> > > before client send out the SOAPEnvelope. The addressing information
> may be
> > > retrieved from database according to the client info.
> > > Can I still use the security module and addressing module to realize
> my
> > > tasks?
> >
> > Axis2 comes with the addressing module ... you can configure things
> > like wsa:To and wsa:Action using the axis2 client API.
> >
> > BTW your scenarios sound a lot like scenarios that can be supported
> > using Synapse... so Synapse experts what do u guys think? (CC'ed the
> > synapse-dev list as well)
> >
> > Thanks,
> > Ruchith
> >
> > Ref:
> > [1]
> >
> https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/se
> curi
> > ty/src/org/apache/axis2/security/handler/config/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
