Deepal: Either you don't understand my message or are trying to belabor a point.
I am not interested in marketing the X-broker. It was donated for a very good reason. Suffice it to say that this and other arguments are not helping us get to the finishing line any faster. To be clear: I do NOT want to market the X-Broker on this list I do NOT want to violate any of your rules. I WANT synapse to be full featured. I WANT synapse 1.0 to be released ASAP. Are we on the same page? Can we crank out some code and get this done? -----Original Message----- From: Deepal jayasinghe <[EMAIL PROTECTED]> To: [email protected] <[email protected]> Sent: Tue Mar 21 20:39:34 2006 Subject: Re: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties Hi all; I really dont like to see this kind of mails , if someone want to market his products its unfair to use this mailing list :) . Hmm may be you are not so familiar with Apache openources policies :) Mukund Balasubramanian 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] > > > > -- Thanks, Deepal ................................................................ ~Future is Open~ --------------------------------------------------------------------- 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]
