FYI... wss4j bounced it!! Had to subscribe ;-) -----Original Message----- From: Soumadeep [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 10:55 PM To: [email protected]; Xinjun Chen Cc: [email protected] Subject: [Synapse]RE: CryptoFactory: Cannot load properties: crypto.properties
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/securi 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]
