SOA Patterns : Composite Frontend (PDF)
I got a few request for a PDF version of the pattern so here it is : Composite Frontend Pattern
Read MoreSOA Patterns : Composite Frontend
I am not blogging much these days – most of it is due to trying to get my bloody book finished. A case study and a finished anti-pattern chapter where recently pushed to the MEAP, and here’s one additional pattern from chapter 6 (service consumer patterns): When we try to think about service consumers, the obvious candidates are, of course, other services. Nevertheless there are other...
Read MoreEvolving Architectures – Part VII – Parallel
(This is part seven of a series. You might want to check the previous parts first) Parallel and Simplification are the yin and yang of architecture evolution. Simplification, as mentioned previously, is about having foresight and thus provides for,relatively, easy evolution (i.e. architectural additions and not changes). Parallel is about reacting to changes in requirements as they come (no...
Read MoreEvolving Architectures – Part VI – Simplification
[Edited: added explanation of the difference between upfront design with iterative implementation and Simplification] The previous installment in the series talked about leaps as a technique to change the architecture. Leaps are more of a revolution than an evolution and even though they are sometimes needed evolving an architecture is the more interesting topic. This and the next post deal...
Read MoreSOA anti-pattern: Transactional Integration
Transactional Integration It all starts with a business requirement – as it always should. We have an ordering system (say the same one from the Knot anti-pattern) and the business says they only want to confirm an order to the user if the item is already secured for that order in the stock. From the technical point of view we have 2 separate services – one handles orders the other...
Read MoreEvolving Architectures – Part V – Leaps
When talking about “evolving architectures” a “leap” is one of the worst things that can happen. In the previous installment in this series I defined Kent Beck’s “Leap” design strategy in the context of Software architecture as “Leap – is for when you know where you’re heading and you can afford to stop everything until the new way is in...
Read More
Me elsewhere