<strong>Planning</strong> <strong>and</strong> <strong>Impleme</strong>nting 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, <strong>and</strong> here there may be issues with licensing, where development <strong>and</strong> 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, <strong>and</strong> 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, <strong>and</strong> the well-known testing vendors are all starting to work on testing for SOA, including Parasoft <strong>and</strong> 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 <strong>and</strong> 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, <strong>and</strong> practices for planning, coding, designing, <strong>and</strong> testing software. Agile software development approaches tend to have a number of common values, such as frequent inspection <strong>and</strong> adaptation, frequent delivery (with some proponents advocating nightly build programs), collaboration <strong>and</strong> close communication with business users, <strong>and</strong> the emergence of requirements (incremental), technology, <strong>and</strong> 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, <strong>and</strong> 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 <strong>and</strong> designed – <strong>and</strong> should then remain relatively stable. However, Agile methodologies <strong>and</strong> 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 <strong>and</strong> versioning. IBM’s Developerworks Web site has some valuable articles illustrating how Agile can complement Web services development in particular, <strong>and</strong> SOA on the whole. A guiding principle of SOA is that services should ideally follow the same design philosophy, <strong>and</strong> 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
www.butlergroup.com Technology Management <strong>and</strong> Strategy Report SECTION 2: SOA in Action Butler Group a Datamonitor Company
Change language