synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soumadeep" <soumad...@infravio.com>
Subject RE: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Date Wed, 22 Mar 2006 03:27:16 GMT
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.

Thanks
Soumadeep

-----Original Message-----
From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
Sent: Wednesday, March 22, 2006 8:45 AM
To: synapse-dev@ws.apache.org
Cc: wss4j-dev@ws.apache.org
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 <mukund@infravio.com> 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:sanjiva@opensource.lk]
> Sent: Tuesday, March 21, 2006 6:55 PM
> To: synapse-dev@ws.apache.org
> Cc: Xinjun Chen; wss4j-dev@ws.apache.org
> 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:ruchith.fernando@gmail.com]
> > Sent: Tuesday, March 21, 2006 9:02 PM
> > To: Xinjun Chen
> > Cc: wss4j-dev@ws.apache.org; synapse-dev@ws.apache.org
> > Subject: Re: CryptoFactory: Cannot load properties: crypto.properties
> >
> > Hi Xinjun,
> >
> > On 3/21/06, Xinjun Chen <xjchen001@gmail.com> 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: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org



---------------------------------------------------------------------
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