When you think about service consumers, the obvious candidates are other services.
But there are other software components that interact with services, such as legacy sys
tems, non-SOA external systems, and reporting databases. The Composite Front End pattern deals with yet another type of service consumer—the UI.
First, let’s clarify that UIs aren’t services. One reason is that they enable several business areas to converge. For example, a UI might let you enter an order, look up information about the customer, browse the product catalog, and view open invoices.
In addition to convergence, UIs are data producers instead of data processors.
NOTE There’s one exception to this, where the UI is the front of a “human service.” See the Orchestration pattern in chapter 7 for more details.
The main challenge caused by UIs comes from their main difference from services:
UIs try to aggregate or converge data from several services into a cohesive and useful whole; services want to keep their data isolated from that of other services.
149 Composite Front End (Portal) pattern
PROBLEM
To better understand the challenges involved in having UIs work with multiple ser
vices, let’s consider an example with just a single point of friction.
In a project I worked on, we designed a C4ISR (Command, Control, Communica
tions, Computers, Intelligence, Surveillance, and Reconnaissance) system for an Unmanned Naval Patrol Vehicle (UNPV). One of the services in the system was dubbed “Common Operational Picture” (COP). The COP’s responsibility was to han
dle anything that’s detected by sensors: ships, planes, radar stations, and so on. One of the main UI representations of the COP was a map that showed all the detections (see figure 6.5). Clicking on a map icon presents some related information the COP has about it, such as ID, nationality, and course.
The system had a few other services in addition to the COP, including the UNPV service. The UNPV service was responsible for anything related to the UNPV itself, such as setting its course and turning it around. The UNPV service had several UI screens that allowed the user to manage and monitor these functions. Another responsibility of the UNPV service was to send the UNPV’s location to the COP (locations are the COP’s responsibility, remember?), so in the COP UI, one of the icons on the map is the UNPV.
When a user clicks on the UNPV icon on the map, the desired outcome is to display a pop-up menu with options related to controlling the UNPV. In an object-oriented model of the COP, everything that is detected by a sensor (ships, submarines, radar sta
tions, and so on) might be considered a “detection.” Under this model, the UNPV might be a subclass of a detection, so it would accept the same events as any other detection but respond in a more specialized way, as appropriate to its particular sub
class. Here, however, the COP and the UNPV are completely different services, devel
oped by two different groups and maybe even two different companies.
Figure 6.5 A simplified illustration of a front end for a COP service for a naval command and control system. You can see a shoreline and some icons using NATO symbology: a radar, two submarines, and a ship (the UNPV).
You may be able to dismiss this specific example and solve it with a specific solu
tion: add an if statement somewhere to call up the correct commands and to interact with the correct services. The problem is that this example is just the tip of the ice
berg. How do you handle security? Do you need to log in for each service separately?
How do you handle things that all the services need? SOA’s premise is that you’ll have a sort of LEGO-like enterprise where you can compose different business processes easily. Is there any way you can get that in the UI?
How can you interact with multiple services, get an integrated, cohesive UI, and
? still preserve SOA principles and modularity benefits?
One option is to write client-specific code, as mentioned previously. Using this approach, an application is any specific composition of services. For the preceding example, the application would include the two services (COP and UNPV) and a UI that ties them together. The upside of this approach is that each application delivers a consistent experience for the user. After all, a specific or tailored application can be made to be very cohesive. Additionally there are many tried and tested ways to build flexible UIs with a proper separation of concerns, such as using model-view-controller (MVC) and its variations in a multitude of rich client and web technologies. You could probably reuse some of the UI-side logic from application to application.
Nevertheless, you do lose flexibility. Any service change that has UI aspects needs to be modified for each of its UI instances (applications). Similarly, because the UI ties multiple services together, changes in one service may cause another to malfunction within the unified UI. You also lose on composability—the ability to replace services and to create new business flows (relatively) easily. Overall, writing client-specific code is a bad option in the long term, but it can be made to work as a short-term solution.
A related option is to tie several services together, but instead of integrating the services together on the client side you can integrate them on the server side. This approach has the same pros and cons as the previous solution. Nevertheless, there are specific circumstances where it does make sense to follow this approach, and you can read about them in the next section on the Client/Server/Service pattern.
You can have independent UI components for each service. This will overcome the limitations I’ve mentioned because each service’s UI can evolve independently, and you can cram as many of them together as you like to create an application. Unfortu
nately, this approach won’t solve problems like the one in the example. It won’t pro
duce a cohesive UI that works across services.
SOLUTION
What you need, essentially, is to provide mechanisms to glue services together as a cohesive whole while still keeping them autonomous. That’s what the Composite Front End pattern is about:
Apply the Composite Front End pattern to aggregate services while still providing
� them with unified client-side services like layout and theming, as well as coordination services for client-side service integration.
151 Composite Front End (Portal) pattern
The Composite Front End pattern, illustrated in figure 6.6, is about taking the ideas (and sometimes the technologies) behind web portals and applying them to SOA services. Web portals provide unified access points that aggregate multiple web pages. They also provide single sign-on and personalization. SOA interfaces need that and more.
The Composite Front End pattern is composed of two main components: the port- let and the host.
Portlet
The portlets are the building blocks, the composites, that are fused together to form the UI. The portlets are made of at least two components: the UI logic (views and control- lers in MVC lingo) and the service proxy (or agent).
The service proxy is the more interesting component from an SOA perspective—
it’s a client-side representation of a service. The proxy serves as the model for the UI components. It’s usually recommended that you have a single proxy for each service, just as it’s recommended that each service maintain its own data store. From a product management perspective, the service proxy can be seen as part of the service itself.
Host
The host is the value-added part of the Composite Front End pattern. The host pro- vides the glue that ties the different portlets into a cohesive whole. As such, the host performs several roles:
Provides the canvas or surface on which the portlets are displayed
Controls the lifecycle of the portlets
Provides capabilities like interportlet communications and single sign-on Let’s revisit the problem discussed in the previous section. A right-click on a UI com- ponent (the map) should produce a context menu with options from two services (COP and UNPV). How would that work in the context of the Composite Front End pattern?
One option is that a click would be first intercepted by the host, which would then dispatch it to any registered portlet. Another option, illustrated in figure 6.7, is for the
Composite Front End
Service B Portlet
Proxy Service
interacon
Service A Inter-portlet
communicaons
UI host
UI Logic Layout
Single sign-on
Portlet lifecycle
Main window/surface
Figure 6.6 The Composite Front End pattern. Each Service has a Portlet which is a Service Agent combined with a UI logic (most likely Model in a MVC UI pattern).
The UI host provides services for the different portlets to weave them together into a coherent UI.
1.1: Render menu
Figure 6.7 Sample event flow in a Composite Front End. Events are intercepted by the UI 1: Right-click occurred
1.2: Render menu
Host <<portlet>> <<portlet>>
COP UNPV
2: Display menu
components of individuals portlets. The events are transferred to the host which dispatches them to registered portlets for handling. The host can then render the results for display.
click to be intercepted by the first portlet (the COP in the earlier example), the COP would then notify the host, and the host would ask all the portlets involved to render the right-click menu. The COP portlet should pass enough information as part of the event for the other portlets to do something meaningful with it. Both options are valid; the second is usually simpler to implement because you don’t have to interfere with the UI framework to ensure the host gets the events.
The Composite Front End pattern is a service consumer pattern, so the proxy will utilize the various service interaction patterns, like Saga, Request/Reply, and so on (see chapter 5). It can also benefit from the service composition patterns, such as Orchestration and Service Bus (see chapter 7).
You’ve probably noticed that I’ve been using the term portlet to describe the service agents, and you might be wondering why the pattern is named Composite Front End rather than Portal. The main reason is that the pattern can also be used with rich- client implementations and not just web implementations. We’ll explore that further in the technology mapping section.
TECHNOLOGY MAPPING
Normally, you won’t be developing your own Composite Front End container. Instead you’ll use existing products that provide the framework and usually also the tooling to help build the portlets.
The obvious examples are web portal frameworks. Modern enterprise web portals usually support anything from JSR 168/286 (Java Portlet Specification) to WSRP (Web Services for Remote Portlets) to open web standards like RSS, plain REST services, or OpenSocial. There are a lot of products in this area, both commercial like IBM’s Web- Sphere Portal Server and Microsoft SharePoint and open source like JBoss’s GateIn and Liferay Portal. Figure 6.8 shows the layout of the UI host as it’s implemented in GateIn.
Web portals aren’t the only option for implementing the Composite Front End pattern. You can also implement the concept for desktop (rich client) applications.
An example is the Prism framework from Microsoft’s Pattern and Practices group.
Prism implements the Composite Front End pattern for both Silverlight and WPF applications. It provides all the functionality of a UI host and lets you write portlets that consume these capabilities.
153 Composite Front End (Portal) pattern
Figure 6.8 The layout capability of a Composite Front End UI host as it’s implemented in JBoss’s GateIn Portal.
The following listing demonstrates how you could use an EventAggregator facility that allows interportlet communications (needed for the previous map component example):
Listing 6.4 Sample use of Prism’s EventAggregator [Export(typeof(SampleView))]
public partial class SampleView : UserControl {
[ImportingConstructor]
public SampleView([Import] IEventAggregator eventAggregator) {
InitializeComponent();
eventAggregator.
GetEvent<CompositePresentationEvent<ItemSelectedEvent>>().
}
Subscribe(OnItemSelectedReceived);
Subscribe to event
}
public void ItemSelectedReceived(ItemSelectedEvent item) {
//do something with item...
}
In addition to using web portal frameworks and desktop frameworks, you can roll your own implementation of Composite Front End. But it’s usually better to choose one of the available options, because it’s quite an investment to get it right.
QUALITY ATTRIBUTES
The main reasons to use the Composite Front End pattern are flexibility in adding and changing services and the desire for a well-integrated UI. Table 6.2 provides examples for both quality attributes.
Table 6.2 Composite Front End pattern quality attributes and scenarios Quality attribute Concrete attribute Sample scenario Usability
Flexibility
Operability
Changeability
Under normal system use, the end user wants to achieve business tasks fluently. The system should reuse entered data (like personal details) between different tasks.
Under normal conditions, changing the billing process to support a new credit card clearance provider should take less than one week.
The Composite Front End pattern is generally the preferred way to provide an SOA UI. But there’s still the problem of integrating UIs that aren’t SOA-aware. What hap
pens when you have an existing UI that you want to expose to services? The next pat
tern will try to answer that question.