Planning_and_Impleme.. - didier beck weblog

Planning and Implementing SOA
www.butlergroup.com
From a functional perspective, where a service has a user interface, then usability testing may also be
appropriate. Testing may also involve using the same types of communication infrastructure (for example an
ESB) as would then be used in production, and here there may be issues with licensing, where development
and testing can be carried out within the terms of a licence, but it may require additional payment for
production.
Performance testing will be another area that should have careful attention paid to it – especially where
significant use is made of XML messaging. Although performance is improving over time, and various
technologies exist to speed up XML parsing, XML is still highly verbose. One method might be to enable the
message to be parsed in phases, so that the first part of the message can be acted upon whilst the rest of
it is still being processed. However, recent benchmarks indicate that performance may be less of a major
issue than it used to be.
A number of test tools are starting to emerge, and the well-known testing vendors are all starting to work
on testing for SOA, including Parasoft and Mercury. Another aspect for testing within a SOA will be
simulation, which will be especially relevant for services that have not yet been created or are not currently
available. The automatic generation of tests will also be valuable within a SOA project.
SOA and Agile can be complementary.
Agile software development first started to take off during the late 1990s, when Kent Beck promoted
Extreme Programming (XP); a set of values, principles, and practices for planning, coding, designing, and
testing software. Agile software development approaches tend to have a number of common values, such
as frequent inspection and adaptation, frequent delivery (with some proponents advocating nightly build
programs), collaboration and close communication with business users, and the emergence of requirements
(incremental), technology, and team capabilities rather than defining these up-front.
Developing SOA applications might appear to be an area where design all needs to be conducted up-front,
and therefore more compatible with a traditional ‘waterfall’ methodology rather than a more agile, iterative
approach.
However, in practice the two approaches are quite complementary. In a SOA the interfaces of a service will
need to be carefully planned and designed – and should then remain relatively stable. However, Agile
methodologies and software engineering practices can still be applied to the development of applications
that expose external service interfaces. It will be necessary to think very carefully about interfaces that are
being exposed at the end of any particular iteration. If, after a few iterations, a client needs one of these
interfaces to be changed, then it may well have to be changed, ensuring that the change has minimal
impact through techniques such as mediation and versioning.
IBM’s Developerworks Web site has some valuable articles illustrating how Agile can complement Web
services development in particular, and SOA on the whole.
A guiding principle of SOA is that services should ideally follow the same design philosophy, and once
created, assembling them should require less skill than other development models – assembly is often seen
as within the capabilities of a business analyst. Hence, service-oriented development will facilitate a much
more agile business in the future.
30 Section 1: SOA Deployment
December 2006