Planning_and_Impleme.. - didier beck weblog
Planning_and_Impleme.. - didier beck weblog
Planning_and_Impleme.. - didier beck weblog
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
www.butlergroup.com<br />
<strong>Planning</strong> <strong>and</strong> <strong>Impleme</strong>nting SOA<br />
The capacity planning exercise will show where there is a need to apply optimisation. The minimum<br />
optimisation to meet targets is a more appropriate target than reducing the run-time overhead to the<br />
absolute minimum. The first targets for optimisation should be the situation where a number of small, lowlevel<br />
services are aggregated to create a widely-used service, <strong>and</strong> where there is little or no requirement for<br />
direct use of the low-level services. In this instance, direct native calls to the low-level services can be made<br />
with little adverse impact. In fact, this interchange could bypass the ESB entirely, with the high-level service<br />
making direct RPC calls to the required applications.<br />
The important step in this optimisation is that the original logical model should be retained, <strong>and</strong> the nature<br />
of the optimisation, together with the reasons for the decision to optimise should be recorded. The Chief<br />
Architect should review all such cases to ensure the best compromise has been reached.<br />
Other optimisation considerations include:<br />
Ensuring that encryption is truly necessary, <strong>and</strong> only applying encryption to the sensitive portions of a<br />
large message.<br />
<br />
<br />
<br />
Consider breaking multi-function services down into several simpler single-function services (as the<br />
simpler service will have simpler <strong>and</strong> smaller message requirements).<br />
Consider using alternative messaging protocols to HTTP for inside-the-firewall deployment.<br />
Consider the use of Binary XML or compression to reduce the size of XML messages.<br />
Consider physically relocating services to minimise network overheads.<br />
Whatever trade-offs are made for the sake of performance, it is important that it is not treated as a one-person<br />
decision that is the responsibility of a technical architect. The impact on agility <strong>and</strong> the ability to meet the<br />
forward plans of the business must be considered, alongside each compromise of the ideal architecture.<br />
SERVICE-ORIENTED DEVELOPMENT<br />
CATALYST<br />
A key challenge to organisations when getting to grips with SOA is in the development area. It is no longer<br />
about application development, it is about service development, yet underst<strong>and</strong>ing the impact on the<br />
development function can be complex.<br />
SUMMARY<br />
There is a SOA lifecycle in the same way as there is an application development lifecycle.<br />
<strong>Planning</strong> the infrastructure for SOA will require careful thought.<br />
Services within a SOA may be combined in unforeseen ways.<br />
SOA <strong>and</strong> Agile can be complementary.<br />
ANALYSIS<br />
There is a SOA lifecycle in the same way as there is an application<br />
development lifecycle.<br />
Development pressures in the past have always meant that applications are developed with little thought<br />
for reuse, change, or integration. This mindset will need to change in a SOA environment. However, it is<br />
clear that there is a lifecycle for SOA just as there is for earlier types of application development.<br />
December 2006 Section 1: SOA Deployment 27