synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiranya Jayathilaka <hiranya...@gmail.com>
Subject Re: Supporting Multiple SSL Configurations at Sender
Date Wed, 22 Jul 2009 08:39:27 GMT
Hi Folks,

I just finished a second implementation of this feature which uses a custom
IOEventDispatch and a single IOReactor instance. I have uploaded the patch
at [1].

However with this we are no longer able to configure SSL requirements at
endpoint level. We need to configure everything at transport level. Under
the HTTPS sender configuration we can define zero or more SSL profiles and
associate each profile with one or more servers. See the sample
configuration below.

<transportSender name="https"
class="org.apache.synapse.transport.nhttp.HttpCoreNIOSSLSender">
        <parameter name="non-blocking" locked="false">true</parameter>
        <parameter name="keystore" locked="false">
            <KeyStore>
                <Location>lib/identity.jks</Location>
                <Type>JKS</Type>
                <Password>password</Password>
                <KeyPassword>password</KeyPassword>
            </KeyStore>
        </parameter>
        <parameter name="truststore" locked="false">
            <TrustStore>
                <Location>lib/trust.jks</Location>
                <Type>JKS</Type>
                <Password>password</Password>
            </TrustStore>
        </parameter>
    *<parameter name="customSSLProfiles">
        <profile>
            <servers>localhost:19002, www.testserver.com:80</servers>
            <KeyStore>
                <Location>/home/hiranya/cert/B/service.jks</Location>
                <Type>JKS</Type>
                <Password>123456</Password>
                <KeyPassword>123456</KeyPassword>
            </KeyStore>
            <TrustStore>
                <Location>/home/hiranya/cert/B/client.jks</Location>
                <Type>JKS</Type>
                <Password>123456</Password>
            </TrustStore>
        </profile>
    </parameter>*
</transportSender>

The above configuration creates one SSL profile and associates it with two
destination servers. The transport sender will lookup the available SSL
contexts and pick the correct one when creating a SSL IO session.

I believe this implementation achives our goals and gives a fair amount of
control over how certificates are used to connect to different endpoints.
Please provide your feedback.

Thanks,
Hiranya


On Wed, Jul 22, 2009 at 10:56 AM, Supun Kamburugamuva <supun06@gmail.com>wrote:

> Hi,
>
> On Wed, Jul 22, 2009 at 8:20 AM, indika kumara <indika.kuma@gmail.com>wrote:
>
>> Ruwan , It is not reactors that proportional to the users , but all
>> resources consumes by reactors.  Did you see java doc from
>> ‘AbstractMultiworkerIOReactor’.
>>
>> <javadoc>
>> *Usually it is recommended to have one worker I/O reactor per physical
>> CPU core.*
>> <javadoc>
>>
>> I believe because It is few SSL profiles this may be acceptable. But , It
>> is better to get feedback from some one using Synapse in a real production
>> environment.
>>
>
> I think this comment is about server side use of reactors. But here it is a
> client side use. Anyway these are not things that can be decided that
> easily. Better to ask some one in production.
>
> Thanks,
> Supun..
>
>
>>
>> Indika
>>
>> On Wed, Jul 22, 2009 at 6:12 AM, Ruwan Linton <ruwan.linton@gmail.com>wrote:
>>
>>> Indika,
>>>
>>> This might not be the approach that we need to do but I just wanted to
>>> get concrete in this discussion and see how we can implement this. I agree
>>> with you, this might not be a scalable solution but on the other hand we
>>> will have only a few SSL profiles, but not many in a given server.. so we
>>> are not talking about hundreds of reactors it will be like 3-5, also it is
>>> not proportional to the users in the system.
>>>
>>> Thanks for the review and I think this is very valuable. Hiranya, I
>>> suggest we wait for few other reviews and do the modifications to the code
>>> so that we gets to the sub optimal solution. You may investigate on the
>>> IOEventDispatcher approach in the mean time as well.
>>>
>>> Thanks,
>>> Ruwan
>>>
>>>
>>> On Tue, Jul 21, 2009 at 11:34 PM, indika kumara <indika.kuma@gmail.com>wrote:
>>>
>>>> I didn’t look details at code level of patch. Patch is an implementation
>>>> of approach that uses MultiworkerIOReactor per SSLContext .
>>>>
>>>> Reactor is the heart of the Reactor pattern. It is all about
>>>> scalability. Generally, multiple reactors use for load balance between
>>>> reactors to match CPU and IO rates. By default, we use a
>>>> MultiworkerIOReactor which is a multi reactor implementation. In above patch
>>>> we use collections of MultiworkerIOReactors. I don’t know how much resources
>>>> it consumes. A system with n users to be scalable, the quality of physical
>>>> resources required to support them should be at most O(n). Therefore,
>>>> without increasing in loads, if physical resources consumption is increased,
>>>> it is not a scalable system.
>>>>
>>>>
>>>>
>>>> BTW, this will be only needed by some set of users. General users may
>>>> not be affected. Therefore, usually there will be a one
>>>> MultiworkerIOReactor. So, this approach may be an option. But, it depends
on
>>>> actual users that need this feature. Would they like to have many
>>>> MultiworkerIOReactors in a Single Server? If they like, this solution may
be
>>>> OK.
>>>>
>>>>
>>>>
>>>> Please look at following doc which is from Javadoc of
>>>> ‘AbstractMultiworkerIOReactor’.
>>>>
>>>>
>>>> <javadoc>
>>>>
>>>> *Generic implementation of that can run multiple instances in separate
>>>> worker threads and distribute newly created I/O session equally across those
>>>> I/O reactors for more optimal resource utilization and a better I/O
>>>> performance. Usually it is recommended to have one worker I/O reactor per
>>>> physical CPU core.*
>>>>
>>>> <javadoc>
>>>>
>>>>
>>>>
>>>> It is better to *ask from Oleg*?. He has written all these core codes.
>>>> If he thinks this is OK, then I believe, this approach may be OK.
>>>>
>>>>
>>>>
>>>> Indika
>>>>
>>>>
>>>> On Tue, Jul 21, 2009 at 8:56 PM, Ruwan Linton <ruwan.linton@gmail.com>wrote:
>>>>
>>>>> If it is going to require IOEventDispatcher changes and a KeyManger
>>>>> impl that is too complex...
>>>>>
>>>>> Why don't we be concrete and have a look at the patch provided and try
>>>>> to overcome the drawbacks of the implementation (if there are any)?
>>>>>
>>>>> Asankha/Oleg, can you please have a look at the patch?
>>>>>
>>>>> Thanks,
>>>>> Ruwan
>>>>>
>>>>>
>>>>> On Tue, Jul 21, 2009 at 6:03 PM, indika kumara <indika.kuma@gmail.com>wrote:
>>>>>
>>>>>> I didn’t investigate the details of any suggested solution. Just
said
>>>>>> what comes in to my mind. Possible approaches for complete solution
may be
>>>>>> based on OEventDispatch and Keymanger.
>>>>>> You can go deep and suggest what the easy yet complete solution is.
>>>>>> Then, everyone will agree with that.
>>>>>>
>>>>>> Indika
>>>>>>
>>>>>> On Tue, Jul 21, 2009 at 5:56 PM, Hiranya Jayathilaka <
>>>>>> hiranya911@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 21, 2009 at 5:42 PM, indika kumara <
>>>>>>> indika.kuma@gmail.com> wrote:
>>>>>>>
>>>>>>>> Even when using IOEventDispatch (What I suggested as my first
>>>>>>>> solution), we have to get information from IOSession to pick
correct Cert-
>>>>>>>> possibly remote domain name and ip. These things can get
from SSLSession too
>>>>>>>> - may be more.
>>>>>>>>
>>>>>>>> BTW, simple approach is best if it solves the problem.
>>>>>>>>
>>>>>>>> Any way, X509ExtendedKeyManager is in com.sun.net.ssl.internal.ssl
,
>>>>>>>> it may be an issue to wrap this class. So , IOEventDispatch
solution may be
>>>>>>>> only feasible one.
>>>>>>>
>>>>>>>
>>>>>>> The X509ExtendedKeyManager abstract class comes from the
>>>>>>> javax.net.ssl package. It's implementations are JDK specific.
But
>>>>>>> technically that shouldn't prevent us from wrapping it. Need
to dig deeper
>>>>>>> into the API to get a clear idea on this.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hiranya
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Indika
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 21, 2009 at 5:23 PM, Ruwan Linton <
>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Do we have the required control of figuring out the right
identity
>>>>>>>>> certificates over the endpoint in this approach?
>>>>>>>>>
>>>>>>>>> For example can we provide the certificate to be used
for a
>>>>>>>>> particular endpoint (may be as an alias) in the endpoint
configuration? I
>>>>>>>>> guess that is the initial requirement.
>>>>>>>>>
>>>>>>>>> Ruwan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jul 21, 2009 at 4:31 PM, indika kumara <
>>>>>>>>> indika.kuma@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> +1 for this approach if possible. It seems possible
(cannot tell
>>>>>>>>>> exactly). Within SSLIOSessionHandler (httpcore),
in the following method
>>>>>>>>>>
>>>>>>>>>> *public void initialize(SSLEngine sslengine, HttpParams
params) ,
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> we can put application specific thing into SSLSession,
then access
>>>>>>>>>> within KeyManager implementation to pick the correct
alias .
>>>>>>>>>>
>>>>>>>>>> BTW, the actual implementation of the X509ExtendedKeyManager
is in
>>>>>>>>>> *com.sun.net.ssl.internal.ssl*.
>>>>>>>>>>
>>>>>>>>>> Indika
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 21, 2009 at 4:11 PM, Andreas Veithen<
>>>>>>>>>> andreas.veithen@gmail.com> wrote:
>>>>>>>>>> > A quick look at the Javadoc shows that X509ExtendedKeyManager
>>>>>>>>>> has
>>>>>>>>>> > access to the SSLEngine from which the SSLSession
can be
>>>>>>>>>> retrieved. On
>>>>>>>>>> > the other hand, SSLSession has methods
>>>>>>>>>> getValue/putValue/removeValue
>>>>>>>>>> > to store "application layer data". This could
be a proper
>>>>>>>>>> solution. To
>>>>>>>>>> > be investigated.
>>>>>>>>>> >
>>>>>>>>>> > Andreas
>>>>>>>>>> >
>>>>>>>>>> > On Tue, Jul 21, 2009 at 12:32, Paul Fremantle<pzfreo@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> >> I agree. Maybe we could wrap the key manager
and then be able
>>>>>>>>>> to
>>>>>>>>>> >> implement any kind of complexity (e..g multiple
key stores,
>>>>>>>>>> etc)
>>>>>>>>>> >> behind that. The only question I have is
whether you can pass
>>>>>>>>>> context
>>>>>>>>>> >> when you call across the key manager API.
We need to pass some
>>>>>>>>>> context
>>>>>>>>>> >> so that the wrapper can do the right thing.
Maybe thread local
>>>>>>>>>> context
>>>>>>>>>> >> would allow us to pass some context over
that boundary.
>>>>>>>>>> >>
>>>>>>>>>> >> Paul
>>>>>>>>>> >>
>>>>>>>>>> >> On Tue, Jul 21, 2009 at 11:22 AM, Andreas
>>>>>>>>>> >> Veithen<andreas.veithen@gmail.com>
wrote:
>>>>>>>>>> >>> On Tue, Jul 21, 2009 at 12:08, Hiranya
Jayathilaka<
>>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>> >>>> Hi Folks,
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I did some testing using two Axis2
instances each using its
>>>>>>>>>> own
>>>>>>>>>> >>>> certificates. I managed to get Synapse
to connect to both
>>>>>>>>>> servers using a
>>>>>>>>>> >>>> single truststore. I had to put
both client certs as well as
>>>>>>>>>> the CA cert in
>>>>>>>>>> >>>> the Synapse truststore for this
scenario to work. So I guess
>>>>>>>>>> our current
>>>>>>>>>> >>>> implementation is good enough for
a great extent.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> However the problem I have is the
way Synapse (or rather the
>>>>>>>>>> Java SSL API)
>>>>>>>>>> >>>> selects the client cert at runtime.
As Andreas has mentioned
>>>>>>>>>> it seems to be
>>>>>>>>>> >>>> using some data sent by the server
in selecting the correct
>>>>>>>>>> client cert. I
>>>>>>>>>> >>>> tried to find some documentation
which properly explains this
>>>>>>>>>> procedure but
>>>>>>>>>> >>>> still couldn't find something satisfactory.
However according
>>>>>>>>>> to most
>>>>>>>>>> >>>> resources and explanation provided
by Oleg, it seems that
>>>>>>>>>> client can decide
>>>>>>>>>> >>>> which cert to present the way it
wishes. In that case the
>>>>>>>>>> above scenario
>>>>>>>>>> >>>> might fail in certain situations.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> So IMHO the best option (most scalable
and robust) we got is
>>>>>>>>>> to implement a
>>>>>>>>>> >>>> custom IOEventDispatch. WDYT?
>>>>>>>>>> >>>
>>>>>>>>>> >>> Personally, I think that the HTTP(S)
transport is already
>>>>>>>>>> complex
>>>>>>>>>> >>> enough and that we should only add to
that complexity if there
>>>>>>>>>> is a
>>>>>>>>>> >>> good reason to do so. Assuming that
the client certificate
>>>>>>>>>> selection
>>>>>>>>>> >>> algorithm doesn't give the expected
results, I think that
>>>>>>>>>> implementing
>>>>>>>>>> >>> a custom IOEventDispatch is only the
second best solution. We
>>>>>>>>>> should
>>>>>>>>>> >>> first investigate the possibility to
change the behavior of
>>>>>>>>>> the key
>>>>>>>>>> >>> manager. Since this is the component
that selects the client
>>>>>>>>>> >>> certificate, from a design perspective
it would be the right
>>>>>>>>>> place do
>>>>>>>>>> >>> implement custom behavior. This approach
would also have the
>>>>>>>>>> advantage
>>>>>>>>>> >>> of isolating the changes from the core
of the transport.
>>>>>>>>>> >>>
>>>>>>>>>> >>> Andreas
>>>>>>>>>> >>>
>>>>>>>>>> >>>> Thanks,
>>>>>>>>>> >>>> Hiranya
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> On Tue, Jul 21, 2009 at 3:25 PM,
Andreas Veithen <
>>>>>>>>>> andreas.veithen@gmail.com>
>>>>>>>>>> >>>> wrote:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> On Tue, Jul 21, 2009 at 11:30,
Oleg Kalnichevski<
>>>>>>>>>> olegk@apache.org> wrote:
>>>>>>>>>> >>>>> > On Tue, Jul 21, 2009 at
11:22:58AM +0200, Andreas Veithen
>>>>>>>>>> wrote:
>>>>>>>>>> >>>>> >> > Well, if not through
different stores, how can we let
>>>>>>>>>> the KeyManager
>>>>>>>>>> >>>>> >> > know
>>>>>>>>>> >>>>> >> > what cert to use
for this particular endpoint?
>>>>>>>>>> >>>>> >>
>>>>>>>>>> >>>>> >> If I remember well,
this is how it works: during the
>>>>>>>>>> handshake, the
>>>>>>>>>> >>>>> >> server presents a list
of trusted CAs to the client. The
>>>>>>>>>> client than
>>>>>>>>>> >>>>> >> selects the certificate
that is signed (directly or
>>>>>>>>>> indirectly) by
>>>>>>>>>> >>>>> >> that CA and uses that
to authenticate. I'm pretty sure
>>>>>>>>>> this is what
>>>>>>>>>> >>>>> >> happens when you create
a java.net.URL with the https
>>>>>>>>>> scheme and call
>>>>>>>>>> >>>>> >> openConnection on it.
Since behind the scene this uses an
>>>>>>>>>> SSLContext,
>>>>>>>>>> >>>>> >> chances are high that
it also works with our HTTPS
>>>>>>>>>> transport (or that
>>>>>>>>>> >>>>> >> it would be pretty
easy to make it work).
>>>>>>>>>> >>>>> >>
>>>>>>>>>> >>>>> >> Of course this only
satisfies the requirement if the two
>>>>>>>>>> endpoints use
>>>>>>>>>> >>>>> >> different CAs, which
should be the usual case.
>>>>>>>>>> >>>>> >>
>>>>>>>>>> >>>>> >> Andreas
>>>>>>>>>> >>>>> >>
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > Hi Andreas
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > I may be wrong about it
but I believe the client can
>>>>>>>>>> present whatever
>>>>>>>>>> >>>>> > client
>>>>>>>>>> >>>>> > cert it pleases. That cert
does not _have_ to be signed by
>>>>>>>>>> one of the
>>>>>>>>>> >>>>> > trusted
>>>>>>>>>> >>>>> > CA certs sent to client
by the server. For instance,
>>>>>>>>>> common browsers
>>>>>>>>>> >>>>> > simply pop
>>>>>>>>>> >>>>> > up a UI dialog and let
you pick any client certificate
>>>>>>>>>> available in the
>>>>>>>>>> >>>>> > certificate store, if the
server requests client
>>>>>>>>>> authentication in the
>>>>>>>>>> >>>>> > course
>>>>>>>>>> >>>>> > of SSL context negotiation.
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > Oleg
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> That is possible, but it is
only relevant for a scheme where
>>>>>>>>>> the
>>>>>>>>>> >>>>> consumer of the service creates
a certificate himself
>>>>>>>>>> (typically a
>>>>>>>>>> >>>>> self-signed certificate) and
somehow registers that with the
>>>>>>>>>> provider
>>>>>>>>>> >>>>> of the service. This implies
that the provider has to manage
>>>>>>>>>> a list of
>>>>>>>>>> >>>>> recognized client certificates
to authenticate the client. I
>>>>>>>>>> don't
>>>>>>>>>> >>>>> think that is a usual scheme
for Web services (BTW, how
>>>>>>>>>> would you do
>>>>>>>>>> >>>>> that with Axis2?), but that
it is more usual for the
>>>>>>>>>> provider to issue
>>>>>>>>>> >>>>> certificates to the consumer,
so that authentication is
>>>>>>>>>> based on the
>>>>>>>>>> >>>>> signature on the client certificate.
But again, this is a
>>>>>>>>>> question
>>>>>>>>>> >>>>> about the requirements.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Andreas
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> >>>>> >> To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@synapse.apache.org
>>>>>>>>>> >>>>> >> For additional commands,
e-mail:
>>>>>>>>>> dev-help@synapse.apache.org
>>>>>>>>>> >>>>> >>
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> >>>>> > To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@synapse.apache.org
>>>>>>>>>> >>>>> > For additional commands,
e-mail:
>>>>>>>>>> dev-help@synapse.apache.org
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>>>>> >>>>> For additional commands, e-mail:
>>>>>>>>>> dev-help@synapse.apache.org
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> --
>>>>>>>>>> >>>> Hiranya Jayathilaka
>>>>>>>>>> >>>> Software Engineer;
>>>>>>>>>> >>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>> >>>> E-mail: hiranya@wso2.com;  Mobile:
+94 77 633 3491
>>>>>>>>>> >>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>> >>>>
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> >>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> --
>>>>>>>>>> >> Paul Fremantle
>>>>>>>>>> >> Co-Founder and CTO, WSO2
>>>>>>>>>> >> Apache Synapse PMC Chair
>>>>>>>>>> >> OASIS WS-RX TC Co-chair
>>>>>>>>>> >>
>>>>>>>>>> >> blog: http://pzf.fremantle.org
>>>>>>>>>> >> paul@wso2.com
>>>>>>>>>> >>
>>>>>>>>>> >> "Oxygenating the Web Service Platform",
www.wso2.com
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>>>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>>>>> > For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ruwan Linton
>>>>>>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Hiranya Jayathilaka
>>>>>>> Software Engineer;
>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ruwan Linton
>>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>>> WSO2 Inc.; http://wso2.org
>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>> blog: http://ruwansblog.blogspot.com
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ruwan Linton
>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> WSO2 Inc.; http://wso2.org
>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>> blog: http://ruwansblog.blogspot.com
>>>
>>
>>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>


-- 
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com

Mime
View raw message