10.5. Service Orientation

Service-Oriented Architecture (SOA) could very well be the most popular buzzword of the last couple of years. While universal definitions of SOA are still being debated in forums small and large, I will see how it could apply to RIA. In this section, I choose five patterns that belong to the realm of service orientation and illustrate them. These patterns are worthy of consideration as they can positively impact RIA architectures and make them more maintainable and better in terms of desired output.

The five patterns are:

• Concurrent contracts

• Cross-domain utility layer

• Functional decomposition

• Rules centralization

• State repository

Let's take each in turn and discuss it briefly.

10.5.1. Concurrent Contracts

Multiple contracts should be created for a single service, each targeted at a particular type of consumer. It is highly likely the enterprise data and systems will be shared by consumption points besides the RIA and so it makes sense to create multiple contracts.

Sometimes it makes sense to create a service façade to act as the front end for the requests to the service. The façade can then choose the correct contract to service the client.

Further to different use cases, multiple contracts and endpoints can also simultaneously support consumption using multiple protocols and data formats. So, one could define an HTTPService, a WebService, a RemoteObject. or a JSON-based endpoint for a single service. That way the same service can allow multiple types of consumers, even if they were all Flex applications.

10.5.2. Cross-Domain Utility Layer

From a consumption standpoint, it's best if an RIA connects to a service layer that dis-intermediates two or more domains, thereby providing a common service layer and shielding service consumption points from dealing with multiple domain inventories at the same time.

A cross-domain utility layer on the service end simplifies access for disparate enterprise systems. This becomes increasingly relevant when an RIA spans divisions or functional verticals. A good example is a corporate performance dashboard.

10.5.3. Functional Decomposition

A large enterprise-grade RIA both on the client and server end needs to be decomposed into smaller functional bundles. Using modular server-side architectures and dynamically loaded modules on the client is advisable.

Functional decomposition has a positive side effect of making your application modular and easier to extend and maintain.

10.5.4. Rules Centralization

Sometimes it makes sense to keep business rules in a central repository from which the different functional modules can access and use them. The central rules repository applies well to server-centric logic that does the heavy lifting of implementing business rules, process constraints, and application-wide validations.

Using a rules engine in association with a centralized rules repository makes an enterprise-grade Flex and BlazeDS application easily extensible. It also makes them more maintainable.

10.5.5. State Repository

Although keeping all state in one place would classify as an anti-pattern in a RIA, storing state in a central repository for collaborative applications may actually be an advantage.

In applications that share data state across multiple clients, keeping the state at a server-side repository makes it possible for all or multiple clients to listen to changes.

This section only lists a few service orientation–related recommendations quickly. The next section is on caching.