An organization is looking to improve the methods it uses to develop and integrate IT systems into its operations.
An organization needs common definitions to exchange information for multiple purposes.
Mature organizations typically have many existing applications, each supporting a particular business function. Within an application, valuable data and capability is often locked within an individual application’s unique data structures and interface styles. When the business wants to integrate these applications together so the information and functions they contain can be shared, it must reconcile the different data structures and naming conventions.
This information sharing is typically achieved through integration interfaces called information services or application programming interfaces (APIs). Each interface describes a number of operations that enable the caller to perform functions and create, update, retrieve, and delete information. Each operation typically has a set of parameters or structures to pass information to the operation and a structure to return the results.
What is the best way to structure a common information model to help developers create consistent interfaces?
GKDMR Travel wants to provide a consistent set of business interfaces that enable mobile and web applications to call their business applications to request details of a customer and to exchange information about holiday packages, bookings, and payments. Specifically, it wants the representation of common entities such as holidaymaker and booking to be consistent wherever they appear in the business interfaces. The business interface implementations will then map these common structures to the actual structure used by the application being called.
- Many concepts are related and decisions need to be made on how these relationships will be represented.
- In creating these common definitions, choices need to be made on terminology used in the business interface as well as data structure and the valid values for each field.
- Documenting how each of the actual application interfaces maps to the common model is necessary.
- The information needed to support a particular business interface operation may need to come from multiple applications.
Create a common information model that defines small clusters of related concepts that can be used as structures for exchanging information.
Each of the clusters of concepts is independent of one another with relationships to concepts in different clusters being defined as holding the identifier of the referenced concept rather than a link to the type. This is illustrated in Figure 3.7.
Figure 3.7 Structure of an encapsulated views common information model
A key characteristic of this pattern is that the encapsulation provides a means of restricting access by an interface to a partition of the model rather than the entire model, which is a valuable step toward defining service or message payload structures in a consistent manner.
- This pattern provides a common information model that supports a service-oriented approach to integration. The data is modeled in discrete units that can be used directly in interface definitions as request or response parameters.
- This pattern is particularly important when integrating existing components because it seeks to reconcile the inevitable difference between these components.
The same concept may need multiple definitions so it can appear in messages as follows:
- A small number of attributes to identify an instance of a concept. This is used on find queries, or to represent a link to the instance.
- A summary of the concept, for reports or to populate a menu or table.
- A complete definition of the concept when all details are required.
Figure 3.8 shows examples of variations of models of the person profile concept. Person Profile Id just includes the identifier and is used for passing a reference to an object. Person Profile Locator defines the attributes used to query for a particular Person Profile. Person Profile Summary includes the core attributes of a Person Profile, and the full details are described in the Person Profile structure.
Figure 3.8 Variations on the model of Person Profile
Defining theses variations simplifies the use of the common definitions, and consequently increases the consistency in which they are used.
GKDMR Travel creates encapsulated view models for the following concepts:
- Holiday Package
Each of these views includes multiple variations of the model for each concept to cover references, summaries, and queries, as well as the complete definition of the concept.
OMG’s Common Object Request Broker (CORBA) standards defined a set of encapsulated views that heterogeneous systems can use to integrate their operations. See http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture and http://www.corba.org.
For the travel industry, the OpenTravel Alliance provides standardized XML messages for exchanging information between organizations working in the travel industry, so this seemed a reasonable starting point. See http://www.opentravel.org.
The concept beads pattern provides an excellent starting point for encapsulated views.