Composite Retrieval Services

From ViaNovaArchitecturaWiki

Jump to: navigation, search


This pattern has been originally described in the article “Architecture Patterns for Enterprise-wide SOA” [Cace, 2008][1]

Image:klantbeeld0.jpg
Figure 1: ‘Klantbeeld Server Nul’ of #UWV (Dutch Social Security Agency)



Contents

Context

… Suppose you have organized your data in coherent data sets and have exposed it for retrieval through services like in the pattern Enterprise Data Retrieval Services. However, the need to create views over multiple sets will not be eliminated and may exist in multiple, service-consuming applications. In this case it is helpful to create centralized combined data views through composite services.

Problem, Forces and Tensions

Creating the same combined view over data from multiple sources may be required in multiple applications. How can we minimize the maintenance burden of accessing multiple data sources? How can we ensure that all applications use the same business rules if those are required while creating a combined view?

Some logically related data may span multiple systems. For example, some customer data would reside in a central data store, some in a corporate CRM system and the telephone contact history would be recorded in a separately developed call-center application. Multiple enterprise information systems may also contain their own, specific information about customers. Applications using this information often need combined views and, by the nature of these applications, most of these views are reusable. The self-service enterprise portal would typically require a set of views over customer data that is very similar or identical to that required by other channels, like the partner channel and the call center. Moreover, from the business perspective, each view must provide the same information, regardless of the channel being used; if a customer can access the same logical view through the enterprise self service portal and through the portal of a business intermediate (a partner) the information needs to be the same. The simplest service-oriented solution would be that all consuming applications access the data by invoking multiple operations of separate services.


composite_retrieval_f2_no_composite.jpg

Figure 2 Creating views over multiple information sources

However, this solution has several drawbacks:

  • The consuming applications use more contracts than ideally needed;
  • Changes in the way data is organized (like retiring legacy systems) need to be coordinated with all consuming applications;
  • If any business rules are needed while creating a view, those rules would be implemented in more than one application;
  • The number of dependencies may cause governance problems, especially if some service consumers are external to the enterprise (partners).



Therefore:

Solution

Expose the combined data views as composite retrieval services.

composite_retrieval_f3_composite_retrieval.jpg

Figure 3 Using the composite retrieval over multiple information sources

Resulting Context and Consequences

{needs editing}

Examples

UWV (Dutch Social Security Agency)

Application ‘Klantbeeld Server Nul’ (‘Customer View’ stage zero) developed in the first half of 2003, in production from August 2003. Original platform: Windows Server 2000 and .NET framework 1.0. Exposes one WS operation; requests are synchronously propagated (also via Web Services) to multiple back-end systems (up to five), depending on the index information retrieved from the sixth back-end system (GVI). The responses are consolidated based on a simple set of business rules. See Figure 1. (an original drawing from the project file)

Example {company name or another reference}

References

  • [Alexander, 1977] C. Alexander et al, “A Pattern Language”, Oxford University Press, 1977
  • [Cace, 2008] B. Cace, “Architecture Patterns for Enterprise-wide SOA”, Via Nova Architectura, 2008 [2]
  • [IBM, 2008] IBM’s developerWorks site, IBM Patterns for e-business, [3] and [4]
Personal tools