Shades of common information model in SOA-based integration environments

SOA (service-oriented architecture) based architectural styles gets complex when combined with Common information model (CIM). This is because in reality the designer needs to extend the CIM for various reasons spanning the spectrum of including additional data elements for integration reasons to including elements required for carrying out business logics by the Service component. When the impact of such extensions on the core CIM is understood, it becomes easy to manage. Aspects related to the core CIM, extended CIM are discussed in this paper.

Gandhi Sivakumar (gandhis@au1.ibm.com), Senior IT Architect, IBM

Gandhi Sivakumar Gandhi Sivakumar is IBM Certified Senior IT Architect and works on complex SOA based integration projects. Gandhi is a member of IBM Academy and leads many communities in IBM. Gandhi has a deep liking towards innovations and has filed a number of patents.



24 August 2010

Also available in Japanese

Overview

The dichotomy of extended CIM

Extended CIM eventually can be classified into two layers: 1- The weaker CIM and 2- the weakest CIM. Each layer hosts different category of elements, has unique characteristics, and needs to be decoupled from each other.

When creating services using SOA-based architectural styles combining industry specific common information models (CIM), there is a need to extend the CIM. This is because the CIM is abstract and in most cases unsuited for direct implementation thus requiring extensions at attribute, object, relationship, operation, interface levels, etc. This means that in a typical SOA-based environment, there exists the core and extended CIM. The extended CIM in turn can be dichotomized as weaker and weakest CIM. Each layer possesses own category of entry points, has unique characteristics and needs to be maintained separately. Note that a service may typically encompass entities from all these three layers.


Introduction to common information models (CIM) layers

Figure 1 below shows the various layers within a CIM-based SOA environment. The bubbles depicted in each layer are the entry points into that layer. Entry points enable access to any of the previous layers; however the layer is confined to a particular category and does not entangle to the next above layer alone. In the subsequent sections we will discuss each entry point in detail.

Figure 1. CIM layers
CIM layers

CORE CIM Layer

The CORE CIM layer comprises of the raw industry published models such as the TeleManagement Forum's Shared Information Data model (SID) in telecommuication industry and the IBM financial services model names the IFW in finance industry which contains the abstract entities with attributes and relationships.

CORE CIM Characteristics

  • This layer is more or less static but the designer may customize the layer in certain situtations when few gaps are identified;
  • Gaps could be missing data definitions, missing unique name identifiers in relationships;
  • Tools which enable generation of service specifications from such as a CIM model should maintain this in a separate base layer; allowing entry points for the extension layers/service operation layers however decoupling this layer to enable replacement of future versions of the base layer;
  • Entry points provide access through the Core CIM objects, attributes of the objects, relationships, Interfaces of the Objects. While the weaker CIM can gain access to all these categories, weakest CIM and service layers can gain access only to the Core CIM objects/related interfaces with or without its own interface. A typical example to gain access to the Core CIM objects include:
    • Enabling Unstructured address through the "AddressDetails" attribute in the GeographicAddress object (Core CIM) by the weaker CIM in TMF Specified SID (see figure 2 below);
    • Enabling Service operation access in RetrieveAddressDetailsRequest or response to Address (Core CIM) object as shown in figure 3 below;
    • Enabling access for integration specific elements (weakest CIM) for example TransactionDefinition Object to contain TransactionIdentifier and System details, etc – however tied through the service operations as shown in figure 4. (Note: The weakest CIM may include a primitive element if not a complex element as described in the above example).
Figure 2. GeographicAddress
GeographicAddress
Figure 3. RetrieveAddressDetailsRequest
RetrieveAddressDetailsRequest
Figure 4. TransactionDefinition
TransactionDefinition

Weaker CIM Layer

This layer encompasses the extended CIM entities which convey pure business meaning for existence. We stress the term "Business meaning" because the modeler needs to always visualize the manifestation of these elements in the Service interface and not include unless otherwise warranted from business perspective, further represent them through a well abstracted terminology.

The weaker CIM can include the following entities:

  • Attributes
  • Objects
  • Relationships
  • Interfaces and method levels in models such as IFW

Weaker CIM Characteristics

  • This layer is dynamic and contains most of the extended business specific entities;
  • Enabling tools should maintain this layer separately however allow entry points for the service operation layer;
  • Entry points provide access through objects, methods, interfaces for service operations. The following is a typical examples to gain access:
    • Enabling access by Service operation "SearchPhoneNumberRequest" to TelephoneNumber object as shown in figure 5 below.
Figure 5. SearchPhoneNumberRequest
SearchPhoneNumberRequest
  • Enabling access through methods for service operations is shown in figure 6 below. This is an example selected from the IFW model where the service InvolvedPartyInformationMaintenance requires the getPassportRegistrationInformation method from the weaker CIM layer.
Figure 6. getPassportRegistrationInformation method
getPassportRegistrationInformation method

Weakest CIM Layer

This final layer includes objects, attributes, interfaces, and methods which are required purely for integration purposes. For example the message header related entities, entities which are required for controlling the results, connecting the service operations and the weaker/core CIM layers. Note that this final layer must always co-exists with the lower weaker and core CIM layers, but are connected through the service operations.

Weakest CIM Characteristics

  • This layer is also dynamic but the rate of growth is very less compared to the weaker CIM;
  • This layer is purely meant to hold entities which promote integration and controlling functions;
  • Tools should maintain this layer separately in order to enable extraction of the lower layers;
  • Entry points allow access to the service operations through standalone primitive elements, objects or Interfaces and methods as per the following examples:
    • Enabling access by specifying the number of results to be returned through the controller primitive element "returnResult" in the RetrieveAddressResponse service operation as shown in figure 7.
Figure 7. RetrieveAddressResponse
RetrieveAddressResponse
  • Enabling access by specifying ITransactionDefinition (Interface) to access the TransactionDefinition (weakest CIM object) to the Service operation as shown in figure 8 below. (Note that as stated earlier, weakest CIM cannot exist on its own and always depends upon the lower layers; however tied through the service operation.
Figure 8. ITransactionDefinition
ITransactionDefinition

Conclusion

Logical and physical separation of the CIM layers is key in SOA-based environments for enabling loose coupling and defined entry points by higher layers thus creating an easily main tenable enterprise wise ecosystem.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=502650
ArticleTitle=Shades of common information model in SOA-based integration environments
publish-date=08242010