synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mukund Balasubramanian" <muk...@infravio.com>
Subject Re: [Synapse]RE: CryptoFactory: Cannot load properties:crypto.properties
Date Wed, 22 Mar 2006 04:48:15 GMT
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 <deepalk@gmail.com>
To: synapse-dev@ws.apache.org <synapse-dev@ws.apache.org>
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: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
>
>
>  
>


-- 
Thanks,
Deepal
................................................................
~Future is Open~ 


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


Mime
View raw message