RIA-SOA Collaboration Pattern

J2EE Journal, 2008

Reads: 28,812

Resolving RIA-SOA Conflict

A friend of mine said, when we discussed the RIA-SOA topic, that he was fully entitled to have a service that provided a merchant’s price to his RIA. The price was assumed to be taken from a back-end data store. I agreed with him but thought that the interface should not be concerned with where the price value had come from until it was correct. Besides, would it make sense talking about the merchant’s price in isolation from the presentation context? It was very likely that the merchant had to be represented on the RIA screen by its other characteristics provided by a sort of business service running behind the scenes. All these gave me the idea for the RIA-SOA collaboration pattern that I am going to discuss.

From the first days of Rich Internet Application (RIA) technology, many enthusiasts found an analogy between RIA and service-oriented architecture (SOA). Some of them talked about the benefits of a would-be-wonderful use of SOA in RIA; others saw RIA as a SOA face. Nonetheless, there are experts who see a discrepancy between RIA and SOA concepts.
The major disagreement between RIA and SOA is in the fine-grained operations in RIA and the coarse-grained type of interfaces of SOA business services. Let’s take a closer look at this problem.
In a glance we can see that the RIA spectrum is wide. It includes applications with interfaces for information reporting, modifying predefined business data, collecting and inserting new data into the systems, fast and frequent exchange of information in social/community-oriented Internet applications, and setting commands in the processing systems. Depending on the task, RIA might require a frequent and fine-grained information exchange between an RIA client, such as a browser and a RIA application that is deployed on the server. At the same time, the RIA client can perform relatively coarse-grained interactions, e.g., display Web content of large size. In all cases, we can assuredly say that RIA emphasizes the user interface (UI), which means that RIA has to meet UI requirements such as:
• Human comprehensive information exchange
• Information representation/report
• User operational tooling for the systems
• User experience requirements
At the same time, the “application” part of RIA remains foggy. This creates an impression that the “application” part exists either to serve the interface, which is a bit strange (interface to what?) or the “application” part is the interface itself and somebody else has to provide for support of the end-user operations in the interface.
We also know that SOA business services represent business model services, business functions, business features, and business processes. All these entities operate on smaller or larger sets of business data. Business services implement business logic and provide access to business functionality and resources and result in real-world effects (RWE). Thus, SOA business services are supposed to meet business functionality requirements comprising:
• Business logic
• Business resources
• Business data processing
To meet these requirements, business services have to provide relatively coarse-grained interfaces. Moreover, to minimize difficulties caused by change management support and simultaneously allow for reuse, the service interfaces have to become a kind of pipeline, which only strengthens the coarse granularity.
Thus, RIA and SOA business services have two major discrepancies – approach to the granularity and no shared requirements. This means that “would-be-wonderful use of SOA in RIA” requires proof.
Figure 1 illustrates a scenario in which RIA screen widget events originate RIA requests. Depending on the application, they may be more or less fine-grained. If such requests directly contact the points of invocation of SOA business services (service clients), then two inefficiencies happen:
• Business service interfaces and returned data get unutilized, reducing the power and defeating the purpose of the SOA business services
• Business services have to be called much more frequently than they could be with adequate interface usage; this also overwhelms communication channels/network
A friend of mine said, when we discussed the RIA-SOA topic, that he was fully entitled to have a service that provided a merchant’s price to his RIA. The price was assumed to be taken from a back-end data store. I agreed with him but thought that the interface should not be concerned with where the price value had come from until it was correct. Besides, would it make sense talking about the merchant’s price in isolation from the presentation context? It was very likely that the merchant had to be represented on the RIA screen by its other characteristics provided by a sort of business service running behind the scenes. All these gave me the idea for the RIA-SOA collaboration pattern that I am going to discuss.
RIA-SOA Collaboration Design Pattern
Problem Summary:
• RIA requests mismatch the granularity of the SOA business service interfaces
• RIA and SOA requirements have no common points suitable for integration
Problem Explanation: See the discussion in the previous section
Solution:
• Use a conciliator module between RIA requests and SOA business service interfaces
• Conciliator module responsibilities:
-Bridge business functionally provided by SOA business services and business user interface functionality
-Convert data structures from the business service interface format into a user interface format for a particular RIA widget, and vice versa
-Provide a way to optimize usage of the SOA business service as well as prompt and correct responses to the RIA requests
The most trivial optimization of business service usage is using it as designed – with a coarse-grained interface and related business data model. In addition, since some RIA/UI functionality may be dependent on the changes in the business environment, the SOA business service may be used in a “subscription” mode. That is, RIA can send a subscription request via the conciliator, and the business service starts monitoring for particular business events or business data changes and delivers the appropriate information to the conciliator. The latter can share this information between interested RIA requests. Figure 2 illustrates the RIA-SOA collaboration design pattern.
The RIA-SOA collaboration pattern has some similarities with the known J2EE front controller pattern: the conciliator, as a controller, deals with remote client (browser) requests and responses. However, this is where the similarity ends. A front controller pattern operates as a dispatcher, performing view/templating selections while the conciliator’s major task is to make granularities, data formats, and invocation models conform. The conciliator can include a front controller pattern similar to how a proxy pattern can include a delegate pattern when needed.
Implementation Examples

Example 1 – Direct Cache Conciliator
An implementation of a conciliator is a web cache. If the conciliator does not find the information to respond to an RIA request in the cache, it invokes a related business service “on demand.” The returned service results are accumulated in the cache. Analogous requests never go further than the cache. Each service result has a timeout and is subject to a refresh. The conciliator takes care of the refresh schedule while the service delivers results.
For RIA requests representing three types of UI requirements – information exchange, information representation/reports, and user operations against the systems – the conciliator acts accordingly, i.e., it only caches responses that might be reused. Among others, the conciliator provides a mechanism for data format transformation where necessary. That is, the conciliator caches service results after the transformation.
It would be an insufficient solution if we required SOA business services to return data in the format of an external UI because the service may have associations with many interfaces. In the service-oriented approach, the interface serves the business service, not vice versa; the business service is the driver, i.e., the “A” part of RIA drives its “R” part. The service defines which business functionality to expose via this or that interface, rich or not; the interface adds only the user experience capabilities.
This is why we need a bridge between presentational (RIA) and processing (business service) data formats. Moreover, the interface or client part of RIA isn’t supposed to be aware of the data models and formats that the application operates on and that persist. So a statement like “my RIA (client) needs the merchant price stored in a particular field of a particular database” violates the principle of separation of concerns. Of course, the interface must have the price value but where it comes from is the service’s “business” in service-oriented applications.

Example 2 – Presentation Services Conciliator
The conciliator may have a more complex implementation than just a Web cache. It may include fine-grained presentation services serving the remote actions and events of the RIA widgets while working against the Web cache. Presentation services run in the presentation tier and serve UI exclusively. They also add flexibility to the Web cache and can support the federation of distributed Web cache affinities. That is, the power of the distributed Web cache can be dynamically increased or decreased in accordance with the richness of RIA.
Presentation services can perform the data format transformation described in Example 1. They can also invoke infrastructure services like security, for example, for end-user authentication, simple business services like currency conversion that is fine-grained by definition as well as operation statistics services. However, what the presentation services must avoid are the same bad habits found in regular Web applications – for instance, the direct engagement of resource drivers, like database drivers, straight from the presentation tier. Straightforward retrieving and storing data in the persistent storage has nothing to do with service orientation and, if applied, should not be called business service actions. If somebody wants to couple a UI, even a rich UI, with a database, we’re not talking SOA.
Since SOA is usually an enterprise, or a line of business, or business unit solution, it crosses several applications that might have shared data stores. SOA assumes the use of a Data Access Layer (DAL) in between the business services and data stores. Data access services working in DAL don’t replace store drivers but provide RWE via accumulating, aggregating, and composing business data from the sources, according to the preliminary defined business rules. Still, data access services are considered infrastructural services because they might depend on specific data stores or legacy applications.
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

A friend of mine said, when we discussed the RIA-SOA topic, that he was fully entitled to have a service that provided a merchant’s price to his RIA. The price was assumed to be taken from a back-end data store. I agreed with him but thought that the interface should not be concerned with where the price value had come from until it was correct. Besides, would it make sense talking about the merchant’s price in isolation from the presentation context? It was very likely that the merchant had to be represented on the RIA screen by its other characteristics provided by a sort of business service running behind the scenes. All these gave me the idea for the RIA-SOA collaboration pattern that I am going to discuss.

RIA-SOA Collaboration Design Pattern
Problem Summary:

• RIA requests mismatch the granularity of the SOA business service interfaces
• RIA and SOA requirements have no common points suitable for integration

Problem Explanation: See the discussion in the previous section

Solution:

• Use a conciliator module between RIA requests and SOA business service interfaces
• Conciliator module responsibilities:
  -Bridge business functionally provided by SOA business services and business user interface functionality
  -Convert data structures from the business service interface format into a user interface format for a particular RIA widget, and vice versa
  -Provide a way to optimize usage of the SOA business service as well as prompt and correct responses to the RIA requests

The most trivial optimization of business service usage is using it as designed – with a coarse-grained interface and related business data model. In addition, since some RIA/UI functionality may be dependent on the changes in the business environment, the SOA business service may be used in a “subscription” mode. That is, RIA can send a subscription request via the conciliator, and the business service starts monitoring for particular business events or business data changes and delivers the appropriate information to the conciliator. The latter can share this information between interested RIA requests. Figure 2 illustrates the RIA-SOA collaboration design pattern.

The RIA-SOA collaboration pattern has some similarities with the known J2EE front controller pattern: the conciliator, as a controller, deals with remote client (browser) requests and responses. However, this is where the similarity ends. A front controller pattern operates as a dispatcher, performing view/templating selections while the conciliator’s major task is to make granularities, data formats, and invocation models conform. The conciliator can include a front controller pattern similar to how a proxy pattern can include a delegate pattern when needed.

Implementation Examples
Example 1 – Direct Cache Conciliator
An implementation of a conciliator is a web cache. If the conciliator does not find the information to respond to an RIA request in the cache, it invokes a related business service “on demand.” The returned service results are accumulated in the cache. Analogous requests never go further than the cache. Each service result has a timeout and is subject to a refresh. The conciliator takes care of the refresh schedule while the service delivers results.

For RIA requests representing three types of UI requirements – information exchange, information representation/reports, and user operations against the systems – the conciliator acts accordingly, i.e., it only caches responses that might be reused. Among others, the conciliator provides a mechanism for data format transformation where necessary. That is, the conciliator caches service results after the transformation.

It would be an insufficient solution if we required SOA business services to return data in the format of an external UI because the service may have associations with many interfaces. In the service-oriented approach, the interface serves the business service, not vice versa; the business service is the driver, i.e., the “A” part of RIA drives its “R” part. The service defines which business functionality to expose via this or that interface, rich or not; the interface adds only the user experience capabilities.

This is why we need a bridge between presentational (RIA) and processing (business service) data formats. Moreover, the interface or client part of RIA isn’t supposed to be aware of the data models and formats that the application operates on and that persist. So a statement like “my RIA (client) needs the merchant price stored in a particular field of a particular database” violates the principle of separation of concerns. Of course, the interface must have the price value but where it comes from is the service’s “business” in service-oriented applications.

Example 2 – Presentation Services Conciliator
The conciliator may have a more complex implementation than just a Web cache. It may include fine-grained presentation services serving the remote actions and events of the RIA widgets while working against the Web cache. Presentation services run in the presentation tier and serve UI exclusively. They also add flexibility to the Web cache and can support the federation of distributed Web cache affinities. That is, the power of the distributed Web cache can be dynamically increased or decreased in accordance with the richness of RIA.

Presentation services can perform the data format transformation described in Example 1. They can also invoke infrastructure services like security, for example, for end-user authentication, simple business services like currency conversion that is fine-grained by definition as well as operation statistics services. However, what the presentation services must avoid are the same bad habits found in regular Web applications – for instance, the direct engagement of resource drivers, like database drivers, straight from the presentation tier. Straightforward retrieving and storing data in the persistent storage has nothing to do with service orientation and, if applied, should not be called business service actions. If somebody wants to couple a UI, even a rich UI, with a database, we’re not talking SOA.

Since SOA is usually an enterprise, or a line of business, or business unit solution, it crosses several applications that might have shared data stores. SOA assumes the use of a Data Access Layer (DAL) in between the business services and data stores. Data access services working in DAL don’t replace store drivers but provide RWE via accumulating, aggregating, and composing business data from the sources, according to the preliminary defined business rules. Still, data access services are considered infrastructural services because they might depend on specific data stores or legacy applications.

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