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
