Hi Frank, Sorry, maybe we have not thought this through.
When I said "state transfer" I mean "full session state in the message (REST-style)" Q1: What can we do at the platform level to support "state transfer"? Q1. Case 1: for stateful Apps and Services written by end users - end user can choose to use state transfer, and platform can only do minimal ( please correct me if I am missing something) Q1. Case 2: What are we doing for stateful Apps/ Services that are part of the platform? Here we can choose to do "state transfer" Q2: How widely used is the state transfer? Would it make the message too big and make simple cases complex? --Srinath On Wed, Mar 23, 2016 at 3:37 PM, Frank Leymann <[email protected]> wrote: > 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 >> >> > -- ============================ 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
