Critical. Authoritative. Strategic.


CBR is proudly produced & published
by Technews
Issue Date: April 2008

AnalystWatch: Application development challenges in SOA

April 2008
Michael Azoff, Butler Group analyst

The adoption of service oriented architecture continues apace with the expectation that application development and application integration will improve and the IT department becomes better aligned with business needs and is able to react more flexibly to changes.

For those companies that are now in SOA, has also come the realisation that while the aspirations can be met there is a price to pay - surely you did not imagine it was all going to be an easy ride!
The shift of chaos and complexity has moved from pre-SOA lower-level mixed point-to-point, hub-and-spoke, and Web integrations to post-SOA higher-level management of the environment. Of course, if you have the right tools and processes then these problems can be addressed, but it is a painful learning process to understand exactly what these problems are and how best to deal with them.
One of the consequences of SOA is that the traditional approach to application development where applications have a recognisable beginning and end and there is control over the source code, makes way for a new paradigm of composite applications created from diverse services and components where source code is not always accessible. There are two areas in application lifecycle management where this has a major impact: testing and change management.
Testing SOA applications is problematical for a number of reasons. Can you believe that a web service will actually deliver what it says it will, and will it do so to your standards of robustness and security standards, as well as comply with your company policies?
While web service standards evolve you need to act now, so in-house certification processes need to be implemented to ensure trust in web service consumption. Letting service/component consumers leave feedback for other consumers as well as the provider/creator is worthwhile. If a service goes out of commission and it is part of a long chain of services then you might want to restrict chaining depth until there is a signalling mechanism in place to alert changes that may compromise the ultimate composite application.
Change management in pre- and post-application development is essential to filter out duplicate changes, to help prioritise changes, and to resolve conflicting changes. Within SOA there is a greater need to manage change as the existence of change is guaranteed and the distributed environment makes keeping track of changes difficult, this is the new SOA management complexity.
The problems identified above in SOA lead to the need for three areas to move closer together: ALM, application performance management (APM), and IT governance. For change management there is a need for a single point to act as an information source on all changes in the environment, for discovering what web services and components exist, who are the owners, and which services and components are actually consumed and by which applications/business processes.
This kind of transparency is essential if the chaos and complexity is dealt with, otherwise all SOA has done is shift the problem from the low level to the higher level.
The same applies to testing SOA applications and business processes.
Many of the latest generation APM tools have the capability to trace performance along chains of web services. There are also specialist vendors in SOA testing such as Mindreef and iTKO: the former has SOAPscope Tester and the latter has iTKO LISA 4 SOA Testing and Validation Suite. Both of these products are geared toward multitier, SOA applications, setting up continuous testing and validation for example, to ensure the high reliability and quality of composite applications.

Others who read this also read these articles

Others who read this also read these regulars

Search Site

Search Directory

  • Search for:


Previous Issues