Service oriented architecture (SOA) is gaining momentum as an approach to organizing and building enterprise IT infrastructures, and rightly so. SOA addresses key twin business needs: lower IT costs and greater flexibility. It makes it easy to exploit software assets from many types of components in sophisticated new solutions, without complex integration projects.

	express delivery
	• print  • comment
	SOA's core principles of re-usable, well-defined services and loose coupling aren't applied at the UI level. This is a waste. David Davies is VP of products at Corizon, whose software platform allows businesses to define, implement and monitor user activities across application boundaries, while re-using and re-combining existing user interface components.
	Glossary terms: SOA, composite application, loose coupling, orchestration, development, lookup tool Sponsored links: your text link here

Current SOA thinking, however, focuses on the lower levels of an enterprise IT infrastructure — how to create, manage and combine business services that provide data and logic. Its core principles of re-usable, well-defined services and loose coupling aren't applied at the User Interface (UI) level. This is a waste. UI is treated as an item to throw away and then redevelop from scratch as needed. The result is that composite solutions for users are unnecessarily complex and expensive to build and maintain.

In an SOA, the integration and re-use of data and logic is simplified by adopting two principles:

• Firstly, business services are created with defined interfaces so that functionality can be built once and then consumed as required. Instead of confining assets to functional stovepipes, services package up both new and legacy functionality to make it more readily available for reuse as needed.
• Secondly, the provision of the services is separated from their consumption — the building blocks don't need to 'know', for example, how they will be recombined and orchestrated. This is the only way to make re-use scalable and efficient. With complex implementation code hidden behind the business service interface, the orchestration process becomes comparatively rapid and lightweight to develop.

Unfortunately SOA does not treat the user interface as a re-usable resource in the same way as business logic. Creating a UI for a group of users in an SOA involves fresh bespoke development to leverage the business services. This leads to unnecessary complexity and effort. It either means developing and maintaining separate stovepipes of UI functionality for each individual requirement and user group, or alternatively, attempting to cater for all possible permutations in a single complex UI development. In either case, the solution is locked in an escalating amount of code, which makes it inflexible, slow to build, and unresponsive to business and user group need. Working, fit-for-purpose UI in a business is an expensive asset that embodies both domain knowledge and complex code. Locking it up in this way undermines many of the benefits sought from implementing an SOA.

The problem becomes more acute when the rate of change increases, especially when it is necessary to present permutations or local variations of the same sets of functions to different types of users — for example, in a call centre where one group of call handlers may perform very different roles to another.

A related problem for SOA adopters not addressed by the current data-centric approach is what to do with valuable existing application UIs — bespoke or packaged, internal or partner-provided — when they are needed in the context of an integrated solution. The implicit assumption — that the UI should be thrown away and the functionality recreated all over again in the SOA — has not been widely challenged but presents a major barrier to delivering business requirements. This is hardly in keeping with the philosophy of pragmatism and exploiting available assets usually proposed for SOA. For many organizations, a more palatable solution would be to combine old and new at the UI level to support their users.

Service-enabling the UI

Proliferation of stovepipes; incorporation of legacy functions; tight coupling of UI development to its consumption by different user groups. All these problems with composite application UI development echo the issues that SOA was introduced to solve at a data and business service level. They should be addressed by extending SOA principles to the UI. Two steps are needed:

• The first step is to introduce the idea of 'service-enabled UI' in addition to the more commonly understood data-oriented services. UI services constitute building block components of UI functionality, which means that presentation, validation and low-level user tasks can be embodied in code once and provided for re-use as running services.
• The second requirement is the ability to easily combine and tailor this service-enabled UI into a seamless solution for each user group, with no involvement by the service provider. This requires 'UI orchestration', with specialized user-centric capabilities distinct from those provided by conventional BPEL-style orchestration of data services.

Until recently, this functionality has not existed, but it does now. New software solutions can break down the presentation layer of existing applications — browser or Windows based — into service-enabled components, and then recombine them with UI functionality from other applications along with elements that leverage the business services. The end result is a new composite UI that more closely matches the everyday business needs of end users.

As a result we can now extend the SOA concept to include a new class of re-usable assets — the extremely valuable application UI. Integration projects are cheaper and easier, because pulling together existing UI functions makes for simpler development and maintenance than creating them again each time they are needed. The promise of flexibility bears fruit, too: different user groups can be provided with highly functional, optimized UIs.

Going all the way

So it is possible to take SOA to its next step: bringing service-abstraction concepts to the UI level, thus making full use of the substantial development that has gone into those previously discarded UIs. This incremental approach will help those involved in managing enterprise infrastructure to achieve the savings SOA promises, and deliver flexibility and functionality to different user groups.

The pace of modern business calls for an unprecedented level of support from its IT systems. With rapidly changing business processes, and desktop complexity a serious issue for businesses, SOA needs to take this step beyond the data and logic levels to reach its full potential. Service-enabling the UI is the missing link that will help address many of the issues faced in making services accessible to end users.

More on this topic