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.
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.
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.
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:
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:
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:
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.
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:
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.
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.
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.