Mastering SOA


Part 4: Exposing Services Through Rich User Interfaces

by Jennifer Briscoe


Expose services using best practices for rich interface development with JavaServer Faces and standard portlets.


Downloads for this article:
 Oracle SOA Suite and Services Registry

Published August 2008

A rich user interface (rich UI) is an interface that is similar in look and feel to that of a desktop application. These types of interfaces carry advantages and disadvantages, but have the power to leverage Service Oriented Architectures (SOA) by exposing the advantages of such an architecture to end users rather than just to IT.

Recently, there have been a series of advancements in the rich UI space and with those advancements have come a variety of toolsets, lessons learned, and best practices. This installment of "Mastering SOA" will describe the advantages of a rich UI and how to successfully expose services within your SOA using experiences from Square Two Financial's SOA and rich UI initiatives.

Square Two Financial

Square Two Financial (formerly Collect America) provides asset management services and financial products that continually redefine best in class. Square Two Financial's architecture is an N-tier architecture supporting multiple commercial off the shelf applications and third party vendor interactions. The architecture is a SOA-based with several hundred services exposed both internally and externally, many of which participate in orchestration processes for automated as well as human workflow activities. Square Two Financial's end user application is required to be a dynamic interface that presents a responsive, consolidated view of several disparate data sources with an eye towards intuitive interaction.

Below is a high level overview of Square Two Financial's architecture.

Figure 1

What Makes an Interface Rich?

Although there is no universally accepted standard definition for rich UIs, there are some key characteristics that are typically found in applications that are considered rich in nature.

Increased responsiveness. Traditional web applications typically render pages in a top down fashion. This means that the length of time a page takes to load will be no less than the longest operation on the page. In addition, traditional web applications leave the data upon which it interacts on the server, resulting in elongated round trips even for simple activities such as sorting and filtering. Rich UIs typically cache data sets on the client side which make activities such as sorting and filtering much more responsive as no round trip to the server is necessary.

Asynchronous communication with the server. In addition to client side data caching, utilizing asynchronous communication with the server eliminates the traditional top down rendering of a page and can therefore give the perception of improved performance. Long operations can be done asynchronously and a callback mechanism will trigger the rendering of a particular section of the page once complete. This leads to a natural tendency to create fragments of markup (something both portlets and JSF make very easy) to take advantage of parallelization.

Behaviors not available in HTML alone. Rich UIs clearly differ from traditional web application in their look and feel and in how the end user interacts with and navigates the application. That look and feel cannot be produced through HTML alone. For example, HTML alone cannot open new windows or change color on mouse over. However, such dynamic features coupled with asynchronous behavior and parallelization crates a highly decorated window into an application. Figure A shows an example of using javascript to build dynamically build queries for searching. The results of the query are then displayed using technologies other than HTML (a partial result list is shown and the next list of items is fetched based on the user scrolling down).

Figure 2

However, the presence of each of these characteristics alone does not make an interface rich. The experience the user has must also be rich. That experience is a combination of the interface characteristics and the underlying architecture. Laid atop SOA, rich UIs can expose business processes as well as domain models. They can expose rich data sources that get richer as they are used. Most importantly, they expose the intelligence of underlying architecture.

Why Choose a Rich UI?

Rich UIs come with a variety of advantages. These advantages range from performance and enhanced functionality to maintainability and flexibility. But is a rich interface always the right answer?

In general rich UIs make sense in the following cases:

  • The application is complex and contains a range of loosely-related functionality that spans disparate data sources/systems yet needs a single interface aggregation.
  • The user often needs to work on things in parallel, gathering knowledge about one thing and using it to influence another.
  • It's not just different functionality, but different data that users need to work with in parallel.
  • Conversations need to be "rich" - they require conversational state to keep track of what's occurred so far and what can happen next, and they require interaction with the server.
  • It's important to retain the state of each conversation with the application - you don't want to invalidate one activity just because the user chose to initiate another.

In Square Two Financial's case the overarching business requirement centers around maximizing the data shown to the end user on a single screen. This required a large degree of aggregation into a single interface. In addition, when end users interact with the application the purpose is two fold; 1) to annotate an existing account with additional information and 2) to make decisions an account treatment strategies at varying points in time as the dataset around each accounts grows. The result is a very long running conversational state between disparate end users acting on a data set that gets richer and richer as it is being used. The conversational state, in Square Two Financial's case, spanned time, multiple users, and data sets making a rich UI a natural fit.

Where and How Do Rich UIs Fit in SOA?

The principles of SOA are fairly familiar at this point:

  • Policy Based Behavior Negotiation
  • Explicitness of Boundaries
  • Autonomy
  • Contract Exchange
When services have explicit boundaries the entities never trust each other and they don't share data. Services can impose their own security policies. In addition, the notion of autonomy implies that services are self-governing, location transparent, mutually independent, and loosely coupled. Such characteristics make exposing independent discreet modules of functionality very easy. Indeed, the advances in rich UI technology and frameworks such as JSF and portlets enhance the rich user experience by offering up the underlying architecture in a manner that can be composed and re-composed in any number of business processes.

However, such loosely coupled services without the addition of events to tie them together results in a vertical siloing of functionality that can be difficult to have business processes span. Rich UIs help span these vertical silos by providing an eventing framework on top of an SOA; they provide a way to visualize and make tangible to end users the benefits of that architecture.

For example, portlets provide an excellent way to expose the underlying services to the end users. End users can see the flexibility and indeed the underlying intelligence of the architecture by having the ability to pick and choose what should reside on a page or screen. In addition, the end user obtains the power of re-use.

Development Processes and Considerations

Now that we've examined how SOA and rich UIs compliment one another, let's discuss implementation. The key considerations in developing a rich UI are:

  • Business Process Analysis
  • High Level Interaction Design
  • Framework/toolkit selection
  • Training
  • Testing and Diagnosis

One key area in developing either a SOA or a rich UI is the business process analysis. This analysis not only serves to ensure that service level granularity is appropriate; it also more clearly defines the interaction and navigational paths through the user interface. Careful emphasis should be placed on thorough business process analysis.

Once you have created a library of business process models the service granularity begins to take form. The next step is to focus that same analytical process on the interaction design. The interaction design must be intuitive. People will only use what they understand and what they can learn quickly. For example, the screenshot below represents several services exposed through a single page in the Square Two Financial application. Each pod exposes different data sets and different views of the data provided by the underlying services. In this manner, a single page is able to present a great deal of data without causing disorientation on the user's part. In addition, correct service granularity ensures maximum re-use for subsequent pages and/or applications.

Figure 3

Upon completion of the Interaction Design enough should be known about what is needed for implementation to choose a framework or toolkit. When choosing that framework consider the following:

  • Network bandwidth
  • Display manipulation
  • Web remoting
  • Use of Web services
  • The need for DOM Manipulation
  • Ability to optimize performance
  • Maintainability

Many frameworks have varying degrees of built in support for each of these in the form of widgets and packaged visual effects. The right framework can offer a massive productivity gain. For example, when choosing the framework to be used for the Square Two Financial development efforts productivity gain was a major consideration. The screenshot below is an example of the homepage used within Square Two Financial's application. The graphs are implemented using an out of the box widget found within Oracle's ADF Faces implementation, resulting in a considerable development time savings.

Figure 4

Training in the selected tool is also an important consideration. As the flexibility offered by these toolsets and frameworks increases so does complexity and the need for training.

Finally, testing and diagnosis methodologies need to change to reflect the use of the chosen toolset or framework. Diagnosis techniques such as DOM inspection, instrumenting javascript with logging, javascript debuggers, and traffic sniffing all need to be tools readily available for use.

In addition, when considering testing on the whole, several approaches are possible. Service simulation provides an excellent way to decouple the front end from the back end, thereby aiding in agile development. In addition, consider how to automate unit testing of JavaScript in much the same way that Junit automates server side unit testing. Furthermore, consider automating testing at the service level instead of only the method or class level. Lastly, consider system test automation on the whole with toolsets that test Web application behavior and embedded Ajax modules.


Over the past few years, we have seen an explosion in available toolkits and frameworks for a rich user interface. As these frameworks have been integrated into enterprise applications, a set of best practices and design patterns is beginning to emerge. With careful consideration and planning up front the concept of a rich UI can take the power of SOA and place it in the hands of the end user.

Jennifer Briscoe Jennifer Briscoe is VP and CTO at Square Two Financial. She is responsible for the technical and strategic direction of Square Two Financial's IT software platforms. Currently, she is leading the ground-up design and construction of the next generation enterprise platform to be used in managing the life cycle of assets while maximizing liquidation rates and minimizing costs.