OK... But B.(ii) has disadvantages (performance, garbage collection,...). We need to argue that the benefit of platform/server supported state transfer outweighs the disadvantages.
Best regards, Frank 2016-03-23 7:04 GMT+01:00 Srinath Perera <[email protected]>: > Hi Frank > > Agreed, > > IMO, we should go for session affinity model ( Option A) as default, and > let him enable Option B (II) if he need. > > Regarding B (I) "state transfer", I think user can choose to do it ( as > it does not need any help from the platform). That is zero work for us. > > --Srinath > > On Mon, Mar 21, 2016 at 5:45 PM, Frank Leymann <[email protected]> wrote: > >> Hi Srinath, >> >> I am not at all arguing in favor of session replication or session >> persistence either. >> >> I think in many situation it's fine that a client fails when a session >> dropped and the client has to reconnect explicitly - this is option A. >> >> Otherwise (as a second option B), "state transfer" is to be used. And >> this can be achieved by (i) including the full session state in the message >> (REST-style), or (ii) including only the session id in the message and hold >> the full state in a DB (which is used for session restore if server >> affinity has been lost). >> >> Option B.(ii) has quite a bunch of disadvantages: a DB is involved with >> obvious performance impact; garbage collection of sessions no longer >> needed; DBMS as single point-of-failure;.... >> >> >> >> Best regards, >> Frank >> >> 2016-03-18 7:08 GMT+01:00 Srinath Perera <[email protected]>: >> >>> Hi Frank, >>> >>> Proposal is when the session parameter has changed, framework (e.g. >>> Servelt runtime, or MSS framework) will write the update to the disk >>> asynchronsly. >>> >>> Since we are a middleware platform, impact of losing a session depends >>> on the kind of the application end user is running. >>> >>> However, AFAIK session replication or pressitance that is in WSO2 AS was >>> rarely used. ( Azeez, please correct me if I am wrong). >>> >>> --Srinath >>> >>> On Thu, Mar 17, 2016 at 11:42 PM, Frank Leymann <[email protected]> wrote: >>> >>>> Sorry for jumping in late in the discussion.... >>>> >>>> Session affinity in general is bad (scalability, HA) - I guess that's >>>> what we all agree on. But in certain scenarios, sticky sessions may be >>>> fine. Thus, what is the underlying scenario in the case we discuss? >>>> >>>> As far as I understand, persisting session state requires the >>>> application to be aware of this. Or is the proposal that provide an >>>> environment that reconstructs the session state on behalf of the >>>> application? As Srinath points out we are loosing data if a session aborts >>>> and the application is not a transaction: is that critical in our scenario? >>>> >>>> >>>> Best regards, >>>> Frank >>>> >>>> 2016-03-17 10:21 GMT+01:00 Srinath Perera <[email protected]>: >>>> >>>>> Let's not do session replication. It is very hard to make it work IMO. >>>>> >>>>> I would like to propose a variation to Azeez's version. >>>>> >>>>> We can do local session + session affinity + asynchronously save the >>>>> session state to a DB >>>>> >>>>> If a node cannot find the session, it will go and reload session from >>>>> the DB. ( This should happen if the node has failed, or we have moved >>>>> session away due to high load). >>>>> >>>>> With this model, there is a chance that you might loose last update to >>>>> the session. However, that will be very rare. I would keep "asynchronously >>>>> save the session state to a DB" off by default, so user will enable it for >>>>> complex scenarios. >>>>> >>>>> --Srinath >>>>> >>>>> >>>>> >>>>> On Sat, Mar 12, 2016 at 6:25 PM, Afkham Azeez <[email protected]> wrote: >>>>> >>>>>> Of course the simplest solution is similar to what Tomcat does, local >>>>>> sessions (no replication) & in a cluster, have session affinity >>>>>> configured >>>>>> at the load balancer, so that should be the default. If the node that had >>>>>> the session dies, the clients connected to that instance would get errors >>>>>> or have to login again. For HA deployments, we would need session >>>>>> replication or session persistence. >>>>>> >>>>>> On Sat, Mar 12, 2016 at 12:58 PM, Sanjiva Weerawarana < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Azeez we cannot have a model where every simple server (cluster) >>>>>>> deployment requires Redis. >>>>>>> >>>>>>> Please indicate what you think the right solution is .. its not >>>>>>> clear to me. >>>>>>> >>>>>>> On Thu, Mar 10, 2016 at 7:34 PM, Afkham Azeez <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Storing everything as cookies may not work always and there could >>>>>>>> be sensitive runtime data that you don't want to save on the browser. >>>>>>>> In >>>>>>>> addition, when it comes to Java programming models, using the HTTP >>>>>>>> session >>>>>>>> to store serializable objects is the natural way of programming. Yes, >>>>>>>> your >>>>>>>> solution would work for certain cases, but it doesn't cover all cases. >>>>>>>> >>>>>>>> On Thu, Mar 10, 2016 at 6:48 PM, Joseph Fonseka <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I think we should go with 3 to keep things simple. >>>>>>>>> >>>>>>>>> To solve HA problem ( without session persistence or replication ). >>>>>>>>> >>>>>>>>> 1. Use SSO to authenticate the user. >>>>>>>>> 2. Use the session to store the claims return from IdP. ( Ex >>>>>>>>> user_id, roles ) >>>>>>>>> 3. DO NOT store app specific data on the session instead use >>>>>>>>> cookies, local storage in the browser. >>>>>>>>> 4. In case the container get terminated and user get redirected to >>>>>>>>> another container it will initiate a SSO flow and repopulate a new >>>>>>>>> session >>>>>>>>> with user claims. Then the app can continue as normal. >>>>>>>>> >>>>>>>>> WDYT? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Jo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 10, 2016 at 2:21 PM, Lakmal Warusawithana < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> My order of preference - 3, 2. >>>>>>>>>> >>>>>>>>>> For simple deployment, session affinity work fine. But if we want >>>>>>>>>> to deploy large distributed deployment with HA, we need to go for >>>>>>>>>> option 2. >>>>>>>>>> >>>>>>>>>> On Thu, Mar 10, 2016 at 10:41 AM, Afkham Azeez <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I forgot to add earlier our design decision about using Redis to >>>>>>>>>>> store sessions; the Kubernetes scheduler may decide to kill & >>>>>>>>>>> container & >>>>>>>>>>> start up different instance if its health checks detects problems. >>>>>>>>>>> So in >>>>>>>>>>> such a case, if we had used affinity, the clients connected to that >>>>>>>>>>> instance which was killed will lose their session data. So as a best >>>>>>>>>>> practice they recommend using an external service with session >>>>>>>>>>> persistence. >>>>>>>>>>> Of course this is not the simplest case, so yes, the default should >>>>>>>>>>> be >>>>>>>>>>> local sessions with affinity. >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 10, 2016 at 10:23 AM, Afkham Azeez <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Petstore is #2. We use the Redis service to store the session. >>>>>>>>>>>> For an HA deployment such a model is required, but yes, for the >>>>>>>>>>>> simplest >>>>>>>>>>>> case, we can have local sessions and then use session affinity >>>>>>>>>>>> capabilities >>>>>>>>>>>> of the LB. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 10, 2016 at 10:17 AM, Sanjiva Weerawarana < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Manu, #1 is not a no-session story. What Azeez has done for >>>>>>>>>>>>> the petstore is a model where session state is in a DB. >>>>>>>>>>>>> >>>>>>>>>>>>> Session as a service is the same thing ... basically a data >>>>>>>>>>>>> service in front of a DB. >>>>>>>>>>>>> >>>>>>>>>>>>> So really the basic question is can you do without a session? >>>>>>>>>>>>> My answer is no, not practical. If you go full HATEOS you can do >>>>>>>>>>>>> without >>>>>>>>>>>>> sessions but even then you have to re-authenticate every call >>>>>>>>>>>>> which is not >>>>>>>>>>>>> practical. >>>>>>>>>>>>> >>>>>>>>>>>>> So its #3 :-). >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 9, 2016 at 8:01 PM, Manuranga Perera < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Options >>>>>>>>>>>>>> 1) No session. Everything is in DB or Window.localStorage. >>>>>>>>>>>>>> Authentication via a token validation endpoint. (We keep the >>>>>>>>>>>>>> token in a >>>>>>>>>>>>>> front end cookie) >>>>>>>>>>>>>> 2) Session as a service >>>>>>>>>>>>>> 3) The session is local, works with session affinity >>>>>>>>>>>>>> 4) The session is distributed >>>>>>>>>>>>>> >>>>>>>>>>>>>> My personal order of preference - 1, 2, 3, 4 >>>>>>>>>>>>>> Azeez says 2 (or 1? ) >>>>>>>>>>>>>> Sanjiva says 3, with 4 being plug-able >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think 1 is doable. >>>>>>>>>>>>>> Yes, there will be some development overhead. >>>>>>>>>>>>>> But it'll be scalable/simpler at run time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 6:59 PM, Sanjiva Weerawarana < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not practical Azeez - you're massively complicating the >>>>>>>>>>>>>>> deployment and second its far less performant than replication. >>>>>>>>>>>>>>> Earlier we >>>>>>>>>>>>>>> did global replication which we really shouldn't do. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not suggesting replication .. I'm saying we support >>>>>>>>>>>>>>> non-HA sessions by default but make that part pluggable so we >>>>>>>>>>>>>>> can plug in a >>>>>>>>>>>>>>> replicating model (or even a DB model) if needed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 6:43 PM, Afkham Azeez <[email protected] >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What if we follow an approach of persisting the session to >>>>>>>>>>>>>>>> a datastore, like we've done in the petstore sample, that way >>>>>>>>>>>>>>>> you don't >>>>>>>>>>>>>>>> need to worry about affinity or the node having the session >>>>>>>>>>>>>>>> failing. In >>>>>>>>>>>>>>>> memory session replication is costly & leads to a whole lot of >>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>> issues, like the ones we've seen with replicated caches, so it >>>>>>>>>>>>>>>> best to >>>>>>>>>>>>>>>> avoid it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 6:32 PM, Sanjiva Weerawarana < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Manu's question is in the context of the reusable UI >>>>>>>>>>>>>>>>> framework stuff we're working on. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fundamentally, is it necessary to have sessions to write a >>>>>>>>>>>>>>>>> UI? Can we use HATEOS for some stuff, browser local storage >>>>>>>>>>>>>>>>> for some stuff >>>>>>>>>>>>>>>>> etc. and not have sessions at all?? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I feel we need sessions as a lot of simple things become >>>>>>>>>>>>>>>>> hard without them. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Then comes the question of how do we do sessions and >>>>>>>>>>>>>>>>> whether we do some kind of replication or rely on affinity >>>>>>>>>>>>>>>>> based routing. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 5:23 PM, Afkham Azeez < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> With such a model, you don't have to worry about things >>>>>>>>>>>>>>>>>> like session replication in order to achieve HA. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 3:32 PM, Manuranga Perera < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Should we aim to do the same in the UIs we ship, such as >>>>>>>>>>>>>>>>>>> products ES? >>>>>>>>>>>>>>>>>>> There will be some extra effort. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 2:12 PM, Afkham Azeez < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> In the petstore sample, the sessions of the frontend >>>>>>>>>>>>>>>>>>>> apps are stored in Redis. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 1:57 PM, Imesh Gunaratne < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Manuranga, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yes, what you are saying it true! We should only use >>>>>>>>>>>>>>>>>>>>> session aware load balancing for existing applications >>>>>>>>>>>>>>>>>>>>> which has session >>>>>>>>>>>>>>>>>>>>> management features built into them. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Ideally when implementing new applications those >>>>>>>>>>>>>>>>>>>>> should be designed in a way to store their sessions >>>>>>>>>>>>>>>>>>>>> outside the application >>>>>>>>>>>>>>>>>>>>> (irrespective of they run on containers or not). This can >>>>>>>>>>>>>>>>>>>>> be done with >>>>>>>>>>>>>>>>>>>>> either using a database or a service (ex: Redis). In that >>>>>>>>>>>>>>>>>>>>> way we can scale >>>>>>>>>>>>>>>>>>>>> the application and session management service separately >>>>>>>>>>>>>>>>>>>>> and also route >>>>>>>>>>>>>>>>>>>>> request without handling sessions at the load balancer >>>>>>>>>>>>>>>>>>>>> level. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wed, Mar 9, 2016 at 1:12 PM, Manuranga Perera < >>>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We are currently using sessions and session affinity >>>>>>>>>>>>>>>>>>>>>> in our apps. But going forward, especially in Micro >>>>>>>>>>>>>>>>>>>>>> Services/Docker model >>>>>>>>>>>>>>>>>>>>>> does it make scene? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Eg: If we bring up a new container due to high load, >>>>>>>>>>>>>>>>>>>>>> requests will still route to old continents due to the >>>>>>>>>>>>>>>>>>>>>> session. If we kill >>>>>>>>>>>>>>>>>>>>>> a container that is associated with some session where >>>>>>>>>>>>>>>>>>>>>> should the request >>>>>>>>>>>>>>>>>>>>>> go? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We have written (I think) a session aware router for >>>>>>>>>>>>>>>>>>>>>> Docker. It's ok for external apps, but I think it >>>>>>>>>>>>>>>>>>>>>> defeats the purpose of >>>>>>>>>>>>>>>>>>>>>> containerization, due to about reasons. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think the correct way to do this in our apps is to, >>>>>>>>>>>>>>>>>>>>>> have authentication as a service. A micro service will >>>>>>>>>>>>>>>>>>>>>> translate the >>>>>>>>>>>>>>>>>>>>>> session-id to a token. App depends fully on the token. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> With regards, >>>>>>>>>>>>>>>>>>>>>> *Manu*ranga Perera. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> phone : 071 7 70 20 50 >>>>>>>>>>>>>>>>>>>>>> mail : [email protected] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> *Imesh Gunaratne* >>>>>>>>>>>>>>>>>>>>> Senior Technical Lead >>>>>>>>>>>>>>>>>>>>> WSO2 Inc: http://wso2.com >>>>>>>>>>>>>>>>>>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>>>>>>>>>>>>>>>>>> W: http://imesh.io >>>>>>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> *Afkham Azeez* >>>>>>>>>>>>>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>>> Member; Apache Software Foundation; >>>>>>>>>>>>>>>>>>>> http://www.apache.org/ >>>>>>>>>>>>>>>>>>>> * <http://www.apache.org/>* >>>>>>>>>>>>>>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>>>>>>>>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>>>>>>>>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>>>>>>>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>>>>>>>>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>>>>>>>>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>>>>>>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> With regards, >>>>>>>>>>>>>>>>>>> *Manu*ranga Perera. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> phone : 071 7 70 20 50 >>>>>>>>>>>>>>>>>>> mail : [email protected] >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> *Afkham Azeez* >>>>>>>>>>>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>>>>>>>>>>> Member; Apache Software Foundation; >>>>>>>>>>>>>>>>>> http://www.apache.org/ >>>>>>>>>>>>>>>>>> * <http://www.apache.org/>* >>>>>>>>>>>>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>>>>>>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>>>>>>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>>>>>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>>>>>>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>>>>>>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>>>>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>>>>>>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; >>>>>>>>>>>>>>>>> http://wso2.com/ >>>>>>>>>>>>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 >>>>>>>>>>>>>>>>> 11 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 >>>>>>>>>>>>>>>>> 5099; voip: +1 650 265 8311 >>>>>>>>>>>>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> *Afkham Azeez* >>>>>>>>>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>>>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>>>>>>>>>> * <http://www.apache.org/>* >>>>>>>>>>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>>>>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>>>>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>>>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>>>>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>>>>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>>>>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; >>>>>>>>>>>>>>> http://wso2.com/ >>>>>>>>>>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 >>>>>>>>>>>>>>> 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; >>>>>>>>>>>>>>> voip: +1 650 265 8311 >>>>>>>>>>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> With regards, >>>>>>>>>>>>>> *Manu*ranga Perera. >>>>>>>>>>>>>> >>>>>>>>>>>>>> phone : 071 7 70 20 50 >>>>>>>>>>>>>> mail : [email protected] >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 >>>>>>>>>>>>> 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; >>>>>>>>>>>>> voip: +1 650 265 8311 >>>>>>>>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Afkham Azeez* >>>>>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>>>>>> * <http://www.apache.org/>* >>>>>>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>>>>> >>>>>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Afkham Azeez* >>>>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>>>>> * <http://www.apache.org/>* >>>>>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>>>> >>>>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Lakmal Warusawithana >>>>>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>>>>> Mobile : +94714289692 >>>>>>>>>> Blog : http://lakmalsview.blogspot.com/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Joseph Fonseka* >>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> mobile: +94 772 512 430 >>>>>>>>> skype: jpfonseka >>>>>>>>> >>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Afkham Azeez* >>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>> * <http://www.apache.org/>* >>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>> >>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 >>>>>>> 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 >>>>>>> 265 8311 >>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Afkham Azeez* >>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>> * <http://www.apache.org/>* >>>>>> *email: **[email protected]* <[email protected]> >>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>> <http://twitter.com/afkham_azeez> >>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>> >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> ============================ >>>>> Srinath Perera, Ph.D. >>>>> http://people.apache.org/~hemapani/ >>>>> http://srinathsview.blogspot.com/ >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://home.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
