Planning_and_Impleme.. - didier beck weblog

Planning and Implementing SOA
www.butlergroup.com
ANALYSIS
There is a trade-off possible between performance and long-term
agility, and this needs consideration before committing to a course
of action.
We need to be quite clear about the purpose of SOA: it is to provide improved utilisation of business
functionality as delivered by application programs. This improved utilisation may take the form of better
integration, creation of composite applications, automation of business processes, and the ability to allow
The purpose of SOA is
not to improve
performance, and
adding extra layers of
software will
inevitably have a
performance impact.
each of these to evolve over time as the business model changes. Because
SOA is layered on top of application resources, it is never going to increase
performance above the capabilities of the underlying systems. (Note, though,
that end-to-end times could be reduced through the ability to execute multiple
tasks in parallel instead of sequentially.)
The purpose of SOA is not to improve performance, and adding extra layers of
software will inevitably have a performance impact. However, everything has
its price, and IT must continue to meet the processing workload and
performance expectations of the organisation, SOA or not.
Much of the performance overhead of SOA stems from the use of Web services. The role that Web services
plays is to isolate the SOA control and run-time environment from the physical properties of the underlying
services. With Web services, the ESB neither knows nor cares what physical platform a service executes
on, what operating platform is used, or which language has been used to create the application. This
virtualisation is the source of the overhead with which we must contend.
Web services itself is built on top of XML, this being the commonly-accepted standard for technology-neutral
messages. The message body itself may become quite large, since a common way of exploiting SOA is for
the same basic message to be passed to each service in turn, with each enriching the message with the
results of its own activity. (In this way the message itself retains the context
required for subsequent operations.) Hence, in a complex multi-step process
the body gets larger and larger. Additionally, the SOAP envelope contains
information necessary for the routing of the message plus optional extensions
such as the style of messaging needed (e.g. guaranteed once-only delivery),
privacy requirements, public and private key tokens for encryption, and
potentially many more.
Thus the Web services message load can add significantly to the network
traffic, and particularly where encryption is needed, to the server overhead for
processing the message. For any but trivial use of SOA, encryption is likely to
be mandatory, even inside the firewall. Web services standards provide for
encryption of just sensitive parts of the message, and this option should
always be used to reduce the processing overhead.
We need to consider whether to compromise the logical design to accommodate the performance needed by
the business – but first there is a general rule in IT (which is re-learned in every new generation of technology):
The golden rule: Do not optimise unless you have to!
Thus the Web services
message load can add
significantly to the
network traffic, and
particularly where
encryption is needed,
to the server
overhead for
processing the
message.
In this case, Web services plays a major role in delivering the adaptability we seek from SOA. By abstracting
away the physical details of an application we gain great freedom to replace applications piecemeal,
outsource to a hosted service provider, provide hot-standby facilities for critical services, and many other
important capabilities. If we discard Web services in favour of more compact technology-specific messaging,
we lose these capabilities. Therefore, the best advice is to carry out performance modelling for the projected
system capacity and decide if it is truly necessary to optimise.
24 Section 1: SOA Deployment
December 2006