On Thu, Mar 31, 2016 at 5:03 PM, Frank Leymann <fr...@wso2.com> wrote:
> Yes, all the stability patterns (that Nygard describes, the circuit > breaker being just one of them) > is not associated with microservices, but applies to all distributed > applications. In fact, Nygard's > book has been published in 2007, loooong before the microservice > discussion came up ;-) > > Yes Frank, agreed. With the hype about microservices, people have started talking about these a lot and during the evaluation phase, people look at features available in frameworks. I don't understand the excitement here. We are not saying CircuitBreaker etc have to be used. That is as stupid as saying every object instantiation has to be done via a Factory. > Applying these patterns to each and any invocation would be a complete > misuse. > Yes, it would very stupid for someone to design a system like that or to suggest something like that, like I said it would be like asking to instantiate all objects using the Factory pattern! Patterns are just part of the toolkit of architects & developers. Knowing to use the appropriate one at the appropriate place requires proper judgment. This sample nor this mail thread is not suggesting to use these everywhere, and I don't understand what gave the impression that we are suggesting such a thing. > And it will very likely > result in performance hits... The circuit breaker pattern, for example, > is recommended to be applied > to "out-of-spec errors", i.e. errors that you don't cover in the spec > (because the errors are too unlikely ;-)) > of the invoked function or in the spec of the program making the call (aka > client). Often, these are errors > that never happen during testing unless you really set up a badly behaving > test environment. And it has > impact on the design/implementation of the circuit breaker itself (or > clients), for example "critical work" > not accepted by the circuit breaker has be queued (by the client? by the > circuit breaker?) for later use > (automatic replay?). > > Thus, using one of the stability patterns is a (architecture/design) > decision with implications on other > components architecture/design. > > Documenting a sample use of the circuit breaker pattern should also > discuss these ramifications. > > Thanks. We will include these recommendations in our documentation. > > Best regards, > Frank > > 2016-03-31 9:12 GMT+02:00 Sanjiva Weerawarana <sanj...@wso2.com>: > >> Agreed. However I had understood that the circuit breaker pattern was >> advocated primarily for service clients in MSA (and of course it has >> nothing do with being micro). >> >> The general story of better failure handling applies to all code and is >> of course not MSA specific. >> >> Anyway .. Sample is fine. >> On Mar 31, 2016 9:19 AM, "Afkham Azeez" <az...@wso2.com> wrote: >> >>> >>> >>> On Thu, Mar 31, 2016 at 9:04 AM, Sanjiva Weerawarana <sanj...@wso2.com> >>> wrote: >>> >>>> That's why I said "fancy try catch" :-). >>>> >>>> However, are you SERIOUSLY saying that we for example should be >>>> wrapping all our DB access code in this stuff? If not who exactly should be >>>> doing this? What are the perf implications? >>>> >>> >>> No I am not saying that. However, there will be use cases where people >>> want to use this pattern and this is a simplified sample that demonstrates >>> how to use this pattern. In Nygards book about how an SQL statement >>> execution failure resulted in an entire checking in system in an airline >>> failing because the failure propagated is a good example of uncontrolled >>> failure propagation (Release It, Chapter 2: Case study: The exception that >>> grounded an airline, for those of you who have the book). So my example was >>> somewhat inspired by that case study and is highly simplified. >>> >>> If a sample is too complicated, people get lost in the implementation >>> details rather than seeing how the core concept or pattern is implemented. >>> I certainly can implement another sample which demonstrates client->service >>> or service->service calls, it certainly would add more code but the core >>> concept demonstrated would be the same. >>> >>> >>> >>>> >>>> Of course wrapping remote service calls in this stuff makes sense - >>>> great way to adjust to transient issues. In that case the overhead is >>>> heavily masked by the latency - I'm not so convinced that is the case for >>>> transactional JDBC calls but maybe it is. In that case WE must use it >>>> internally. >>>> >>>> Sanjiva. >>>> >>>> On Thu, Mar 31, 2016 at 8:53 AM, Afkham Azeez <az...@wso2.com> wrote: >>>> >>>>> Equating these fault tolerance patterns to Java 8 Optional or >>>>> try-catch, is a highly oversimplified view. What Hystrix and these >>>>> patterns >>>>> provides is a framework for building fault tolerant systems. Something >>>>> that >>>>> is useful in the toolkit of an architect & developer. >>>>> >>>>> On Thu, Mar 31, 2016 at 8:36 AM, Sanjiva Weerawarana <sanj...@wso2.com >>>>> > wrote: >>>>> >>>>>> This is almost kinda like that stupid new Java8 thing of "we removed >>>>>> null by wrapping it in a fancy object" ;-). >>>>>> >>>>>> On Thu, Mar 31, 2016 at 8:32 AM, Sanjiva Weerawarana < >>>>>> sanj...@wso2.com> wrote: >>>>>> >>>>>>> So this is not what I expected the real use case to be ... this is >>>>>>> basically a fancy try catch. >>>>>>> >>>>>>> Don't we want to show a client side example? >>>>>>> >>>>>>> On Thu, Mar 31, 2016 at 6:28 AM, Afkham Azeez <az...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Timeout is related to the actual operation taking more time than >>>>>>>> anticipated. In such a case, without waiting indefinitely, the >>>>>>>> operation >>>>>>>> times out and the fallback of the Hystrix command will be invoked. The >>>>>>>> circuit will be open for a fixed period of time configured by >>>>>>>> https://github.com/Netflix/Hystrix/wiki/Configuration#circuitBreaker.sleepWindowInMilliseconds >>>>>>>> >>>>>>>> On Thu, Mar 31, 2016 at 2:53 AM, Harshan Liyanage <hars...@wso2.com >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi Azeez, >>>>>>>>> >>>>>>>>> Does this timeout in open state occurs in exponentially (first >>>>>>>>> timeout in 10 secs, next in 20 secs etc) or linearly when >>>>>>>>> transitioning >>>>>>>>> back to half-open state? For example if the state is in "Open" and >>>>>>>>> now the >>>>>>>>> timeout (lets say 10secs timeout) occurs. Then the state is moved to >>>>>>>>> "half-open" state. But the next request is also a failure and breaker >>>>>>>>> state >>>>>>>>> is moved back to "open". In this occasion the what will be the timeout >>>>>>>>> value? Is it 10 secs or 20 secs? >>>>>>>>> >>>>>>>>> Having an exponential timeout might be beneficiary here as it >>>>>>>>> might save lot of resources if the service is continuously failing. >>>>>>>>> But I >>>>>>>>> think it would be better if we can provide both options in a >>>>>>>>> configurable >>>>>>>>> manner. So it is up to the developer to decide which method to use. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Harshan Liyanage >>>>>>>>> Software Engineer >>>>>>>>> Mobile: *+94724423048* >>>>>>>>> Email: hars...@wso2.com >>>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>>>> lean.enterprise.middleware. >>>>>>>>> >>>>>>>>> On Wed, Mar 30, 2016 at 5:05 AM, Afkham Azeez <az...@wso2.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I have written a sample which demonstrates circuit breaker in >>>>>>>>>> action; >>>>>>>>>> http://blog.afkham.org/2016/03/microservices-circuit-breaker.html >>>>>>>>>> >>>>>>>>>> On Sat, Mar 12, 2016 at 6:09 PM, Afkham Azeez <az...@wso2.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> This is a feature supported by some microservices frameworks. On >>>>>>>>>>> the server side, in this case MSF4J runtime, failure counts are >>>>>>>>>>> kept track >>>>>>>>>>> of and then if the failures exceed certain thresholds, the circuit >>>>>>>>>>> trips >>>>>>>>>>> and rather than dispatch to the service, it returns service >>>>>>>>>>> unavailable. >>>>>>>>>>> >>>>>>>>>>> Can you explain why this is not needed in a container >>>>>>>>>>> environment? >>>>>>>>>>> >>>>>>>>>>> On Sat, Mar 12, 2016 at 12:56 PM, Sanjiva Weerawarana < >>>>>>>>>>> sanj...@wso2.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't understand what server side circuit breaker means. How >>>>>>>>>>>> does the server adjust itself? Where's that bit of logic running? >>>>>>>>>>>> >>>>>>>>>>>> IMO this is not needed in a container world. >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez <az...@wso2.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yes, that is client side circuit breaker. What Aruna is >>>>>>>>>>>>> implementing is server side circuit breaker. Yes, we need both. >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana < >>>>>>>>>>>>> lak...@wso2.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Did you looked at [1] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Netflix Hystrix <https://github.com/Netflix/Hystrix> is an >>>>>>>>>>>>>> incredibly useful library for writing code that invokes remote >>>>>>>>>>>>>> services. >>>>>>>>>>>>>> Hystrix times out calls that exceed the specified threshold. It >>>>>>>>>>>>>> implements >>>>>>>>>>>>>> a *circuit breaker* pattern, which stops the client from >>>>>>>>>>>>>> waiting needlessly for an unresponsive service. If the error >>>>>>>>>>>>>> rate for a >>>>>>>>>>>>>> service exceeds a specified threshold, Hystrix trips the circuit >>>>>>>>>>>>>> breaker >>>>>>>>>>>>>> and all requests will fail immediately for a specified period of >>>>>>>>>>>>>> time. >>>>>>>>>>>>>> Hystrix lets you define a fallback action when a request fails, >>>>>>>>>>>>>> such as >>>>>>>>>>>>>> reading from a cache or returning a default value. If you are >>>>>>>>>>>>>> using the JVM >>>>>>>>>>>>>> you should definitely consider using Hystrix. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://github.com/Netflix/Hystrix >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Mar 11, 2016 at 2:42 PM, Aruna Karunarathna < >>>>>>>>>>>>>> ar...@wso2.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Devs, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Scenario* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The deployed services in a MSF4J may fail to serve the >>>>>>>>>>>>>>> requests due to various factors. e.g, >>>>>>>>>>>>>>> 1. Less resources in the server. >>>>>>>>>>>>>>> 2. High Load in the server >>>>>>>>>>>>>>> 3, Some services take more time to respond etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this kind of a situation, if the server is getting >>>>>>>>>>>>>>> requests though there is no resources to serve those requests, >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> eventually the server will get unusable. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Solution* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The Circuit Breaker design pattern can save the server from >>>>>>>>>>>>>>> above scenarios, The typical design can be illustrated as in >>>>>>>>>>>>>>> the following >>>>>>>>>>>>>>> diagram. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So as in the above diagram, when number of failures of a >>>>>>>>>>>>>>> particular resource exceeds the Max Failure Count, then the >>>>>>>>>>>>>>> state of that >>>>>>>>>>>>>>> resource is moved to the open state with a timeout value (Trip >>>>>>>>>>>>>>> Breaker). At >>>>>>>>>>>>>>> this point the requests coming to the server is routed back >>>>>>>>>>>>>>> without passing >>>>>>>>>>>>>>> the internal to process further. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> After the timeout has reached, the state is moved to >>>>>>>>>>>>>>> Half-Open state, and if the consecutive request pass to the >>>>>>>>>>>>>>> server to >>>>>>>>>>>>>>> process (Attempt Reset), if success then close the circuit >>>>>>>>>>>>>>> (Reset Breaker), >>>>>>>>>>>>>>> If fail then again move the state to the Open with a timeout >>>>>>>>>>>>>>> value (Trip >>>>>>>>>>>>>>> Breaker). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any thoughts, suggestions regarding the above approach? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> References >>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>> http://www.javaworld.com/article/2824163/application-performance/stability-patterns-applied-in-a-restful-architecture.html?page=2 >>>>>>>>>>>>>>> [2]. >>>>>>>>>>>>>>> http://ssagara.blogspot.com/2015/05/timeout-and-circuit-breaker-pattern-in.html >>>>>>>>>>>>>>> [3]. https://pragprog.com/book/mnee/release-it >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Aruna >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Aruna Sujith Karunarathna * >>>>>>>>>>>>>>> WSO2, Inc | lean. enterprise. middleware. >>>>>>>>>>>>>>> #20, Palm Grove, Colombo 03, Sri Lanka >>>>>>>>>>>>>>> Mobile: +94 71 9040362 | Work: +94 112145345 >>>>>>>>>>>>>>> Email: ar...@wso2.com | Web: www.wso2.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Lakmal Warusawithana >>>>>>>>>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>>>>>>>>> Mobile : +94714289692 >>>>>>>>>>>>>> Blog : http://lakmalsview.blogspot.com/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *Afkham Azeez* >>>>>>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>>>>>>> * <http://www.apache.org/>* >>>>>>>>>>>>> *email: **az...@wso2.com* <az...@wso2.com> >>>>>>>>>>>>> * 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 >>>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>> email: sanj...@wso2.com; 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 >>>>>>>>>>>> Architecture@wso2.org >>>>>>>>>>>> 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: **az...@wso2.com* <az...@wso2.com> >>>>>>>>>>> * 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: **az...@wso2.com* <az...@wso2.com> >>>>>>>>>> * 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 >>>>>>>>>> Architecture@wso2.org >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> Architecture@wso2.org >>>>>>>>> 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: **az...@wso2.com* <az...@wso2.com> >>>>>>>> * 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 >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>>>> email: sanj...@wso2.com; 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sanjiva Weerawarana, Ph.D. >>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>>> email: sanj...@wso2.com; 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 >>>>>> Architecture@wso2.org >>>>>> 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: **az...@wso2.com* <az...@wso2.com> >>>>> * 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 >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sanjiva Weerawarana, Ph.D. >>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>> email: sanj...@wso2.com; 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 >>>> Architecture@wso2.org >>>> 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: **az...@wso2.com* <az...@wso2.com> >>> * 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 >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > 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: **az...@wso2.com* <az...@wso2.com> * cell: +94 77 3320919blog: **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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
