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
