Azeez, asking questions and asking to understand what the purpose of some code is not a criticism.
Of course there should be a sample! I only asked about it because to me a client side sample made more sense - and then it went into a discussion of when this should be used etc.. I would not only put the blog back but also use the opportunity to explain to "lazy developers" when and where one should use a circuitbreaker. That's 1000x more valuable than just the code on how to do it. Sanjiva. On Thu, Mar 31, 2016 at 8:00 PM, Afkham Azeez <az...@wso2.com> wrote: > The blog post has been removed. Sorry for all the confusion. This was only > done as part of the agreement we had during last week's meeting to > demonstrate certain features such as Spring support, JPA support, support > for patterns etc. in order to help developers understand how to implement > certain stuff with MSF4J. Our target community of MSF4J is primarily > developers, and developers like to refer to sample code segments in order > to proceed with implementing their solutions. We lazy developers love to > Google search for code segments, e.g. JDBC connection example, and then > copy, paste and modify those segments. What I have been trying to do with > the series of blogposts is to make available such code segments developers > could readily use. Since this post and mail thread has generated a lot of > negative feeling and confusion, I think it is better to get rid of this > controversial blog post. > > Thanks > Azeez > > On Thu, Mar 31, 2016 at 6:54 PM, Afkham Azeez <az...@wso2.com> wrote: > >> >> >> 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 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 > > -- 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
