The reason for using presentation services versus direct access to the cache is that they can be reused for similar types of interfaces or widgets. That is, they can be reused in different RIAs or parts of RIAs. If presentation services are owned by the RIA, coupling presentation services with business service programmatic interfaces is not recommended. For example, RIA might have independent widgets that refer directly to the business process (the user journey) implemented by the RIA; such business process can obtain needed business functionality from different business services that might have been unknown when the RIA was designed. At the same time, there's the case of a UI being bundled with a SOA business service; we will discuss that in the next section.

SOA Meets RIA
In one of his very interesting publications, John Crupi said:

"What I really want is a user-based composite application, not a middleware-based composite application....Direct connect SOA conveys the ability  to punch through the traditional curtain of portals and heavyweight process engines and directly (at least conceptually...) access SOA services. I don't just mean Web services either. It could be BPEL orchestration
services, coarse-grained POJO services, RSS feeds, or anything else that can be exposed as a ‘service,' albeit at the right level of business granularity."

This is quite the right approach to so-called social or community applications. However, it's difficult and dangerous to allow a user to compose applications in the financial, manufacturing, pharmaceutical, medical, and similar industries without strict control over the composition. I'm talking about composite applications, not about their interfaces.

The danger comes from unknown and uncontrolled resulting RWE - we cannot assume that all end users know and understand all interdependencies between SOA services when they start working on compositions. Plus, the behavior of SOA business services depends on the execution context. A composition represents a new context and service provider must test the service before promising that its behavior hasn't changed in the context. For example, a service execution context contains a policy that may be dependent on the locale - the country where the service is used. Financial laws in the U.S. and U.K. are different and application of related policies can result in different RWEs for the same business service operation and data. We have to remember that a SOA business service is not the same thing as a Web Service's WSDL with a couple of operations named after the business functions.

Saying this, I can only imagine one possible user-driven service composition - the one that is preliminarily tested and represented to the end user as a limited set of combination variants. That is, a meaningful business-driven approach (or RWE compatibility) constrains the presentation capabilities, especially in a rich user interface.

This line of logic lets me look at the RIA-SOA relationship from the service-oriented perspective. As we know, OASIS has started a stream of standards that recognizes a SOA service as a business-oriented consumer-centric serving entity that has its own behavior, which provides certain business functionality and enables consumers to reach a concrete RWE. A SOA business service has programmatic interfaces such as Web services, CORBA, and DCOM. At the same time, some business services can have related user interfaces that include Web-based interfaces. The conciliator mentioned above is a means to attach a UI to the programmatic interfaces of the business service. In this case, the conciliator is owned by the business service.

The richness of a Web-based UI for a business service depends on two factors: the complexity of the business functionality offered by the service and the specifics of the end-user audience. Combining business services in the form of an aggregate service or a business process leads to the composition of related user interfaces. Alternatively, an aggregate service or a business process can be represented as a new service with its own UI that may or may not include the UI from the engaged business services.

Creation of a service's UI composition appears to be a very special task that sometimes gets disconnected from the composition reasons and becomes error-prone. If we want RIA to collaborate with SOA, we have to agree that a rich interface assumes the use of multiple SOA business services as the RIA "application" part. However, SOA business services, in turn, dictate their service-oriented vision of the world - even a rich interface is just the interface to the service. At the same time, the richer the user interface in its capabilities, the easier you can integrate multiple UI from different business services together. In other words, business-driven service compositions can benefit from the user-centric UI integration capabilities of RIA. Figure 3 illustrates this conclusion.

What I said in this section is not really new. RIA is a client/server model but attention has been concentrated on the client side so far. An RIA application may be perfectly service-oriented but we shouldn't forget that the application defines its clients. Otherwise, we'd have to agree that people take flights because pilots exist not because airplanes exist.

Summary
This article discussed a discrepancy between RIA and SOA business services that looks like a mismatch in objective requirements, granularity, and data formats. An RIA-SOA collaboration design pattern was proposed to resolve the problem. The pattern's conciliator module was defined and illustrated in two examples of possible implementations. Finally, the article described SOA business services with bundled user interfaces and their aggregation in the RIA.

• Direct RIA + Google App Engine = Simplicity + Scalability