Common Information Model (CIM) is gaining popularity and is being leveraged in the industry for known advantages. CIM manifests in different forms and it is important to understand the characteristics, advantages and disadvantages of each form. This article explores such details and will enable the designer to choose the appropriate pattern depending upon the tool and expertise capability of the enterprise.


Lennox Thomas (, Associate Partner GCTME, IBM

Lennox ThomasLennox Thomas (Lenny) works as a Principal consultant for GBS Global Telco Center of Excellence in IBM USA. He has served as Chief Architect for a number of complex telecom solutions worldwide. He holds a MS in Applied Mathematics/Computer Science. Lenny is recognised for his innovative skills internally and externally to IBM.

Gandhi Sivakumar (, IBM certified Senior IT Architect, IBM

Gandhi SivakumarGandhi Sivakumar is IBM Certified Senior IT Architect and works on complex SOA based integration projects. Gandhi is an executive member of IBM Academy and leads many communities in IBM. Gandhi has a deep liking towards innovations and has filed a number of patents. Gandhi is also a state board member of Australian Computer Society.

31 October 2012

Also available in Japanese


Leveraging Common Information Model (CIM) in building applications or components (which enable integration and are normally hosted in the middleware) has a spectrum of advantages spanning easy consumption to easy plug and play of applications thus reduced efforts. An organization may decide to adopt CIM purely in the Message layer only (termed as Crust CIM in this paper) or both in the Core layer and the Message layer (termed as the Mantle CIM in this paper). For easy understanding Crust CIM is defined to be purely message specific and focused on the syntax, semantics and handshaking mechanisms during the integration of applications. Internal components may not comply with the syntax and semantics of entities in the message layer. On the other hand Mantle CIM is defined to encompass both implementation and message syntactically and semantically but may not define handshaking mechanisms. Mantle CIM is the scope of this paper and we intend to analyze its allotropes. The term “allotrope” in this context means the existence and manifestation of the CIM in its different forms.

The allotropes of CIM

There are two main allotropes of the mantle CIM:

  • Traditional Allotrope (TA)
  • Sheared Allotrope (SA)

The TA is two dimensional, easy to comprehend, flexible and needs to be processed for implementation whilst the SA is simple, uni-dimensional, and relatively rigid and is inclined more towards implementation.

Traditional Allotrope

TA is normally an object oriented model encompassing a constellation of objects, attributes, relationships. TA normally is a single fabric where all the entities are related to each other in some way. The component designer needs to select the relevant entities of interest and knit them to the respective operations request and response of the component. The TeleManagement Forum’s (TMF) Shared Information Data model (SID) and IBM Financial services model (IFW)’s logical layer are very good examples of Traditional Allotrope.

Figure 1. Common Information Model/Layer
CIM Layer

Figure 1 shows TA with a sample component operation request and response which knit on the anchor object E. (Note: Anchor object is the CIM object(s) on which the request/response operations get tied directly. Request and response may knit to one or many objects termed as anchor objects as it was discussed in the “Exploring vector behavior of relationship's article earlier).

The entities shown in green are the in-scope ones for the sample component.

As we could see TA enables a number of benefits as follows:

  • Any concrete object (s) within the fabric can serve as anchor object driven by the business need of the component. For example ProductOrder could be an anchor object knitted directly to the request and response operation say CreateProductOrder;
  • Traversal to reach the required object(s) can be achieved through “N” number of hops throughout the fabric and is achieved by instantiating the intermediate members. In other words there is no need to traverse until the end of the terminal object in that path. Terminal object means the last object within the chosen path of interest;
  • Traversal is flexible enabling the designer in the desired direction for example, considering the above figure the designer is able to traverse from C to G or C to K based upon the need.

Thus TA is flexible and enables the designer to pick and choose the relevant entities of interest to form the component. On the other hand TA imposes the following complexities:

  • The picked objects need to be processed through transformation process for creating the component façade. (Note: Façade is the interface which is seen by external consumers);
  • Complex and flexible tools are required to handle objects both in the fabric layer as well as the façade layer
  • Similarly a highly skilled modeler is required to create solution components using Traditional allotrope of CIM.

Based upon practical experiences, medium and large scale enterprises possessing an ecosystem of many applications and requiring interaction with external supplier partner applications as well as possessing capability to leverage complex tools and technical expertise adopt this allotrope.

Sheared Allotrope

The Sheared Allotrope is a flattened model where the relationships are unidirectional i.e. defined in one direction only. Sheared Allotrope can adopt two forms:

  • Façade Oriented Sheared Allotrope;
  • Object Oriented Sheared Allotrope;

Façade Oriented Sheared Allotrope (FOSA)

Façade Oriented Sheared Allotrope is directly inclined towards implementation as shown in figure 2.

Figure 2. Façade Oriented sheared allotrope
Façade Oriented sheared allotrope

It possesses the following features:

  • FOSA elements are directly created for the façade and are relatively simple;
  • Objects possess uni-directional relationships and are normally created as fragments. Whenever required they are coupled with relevant fragments.
  • FOSA elements do not require transformation and are ready to be coupled with relevant similar fragments and assemble with the appropriate request/response thus forming a façade. The above figure shows ProductOrder and CustomerDetails fragment and coupled together for ManageProductOrder operation request;
  • FOSA normally is created as XSD representation


  • Fragments are already inclined towards implementation and do not require to undergo a transformation process; hence a simple xml tool can handle FOSA;
  • A designer competent in handling XSD design would be enough to work with this allotrope;

FOSA has the following demerits:

  • Unlike TA where any concrete object can serve as anchor object(s), only the top most objects can serve as anchor object. If there any other object within the fragment is required to serve as an anchor object, a new fragment has to be created;
  • As the directionality is pre-determined for a change impacting directionality a new fragment with a new relationship has to be created. Consider the ProductOrder fragment in figure 2. If there was a business need to create a service say ProductOrderItem a new fragment with a new relationship to traverse from ProductOrderItem to ProductOrder has to be created while in TA the designer would have used the existing bi-directional relationship from ProductOrderItem to ProductOrder and have created a fragment.

Based upon practical experiences small enterprises which have limited tooling budgets adopt this allotrope.

Object Oriented Sheared Allotrope (OOSA)

OOSA encompasses a fabric with objects, attributes but uni-directional or defined relationships. Any concrete object could serve as an anchor object enabling easy knitting with the component operation request and response. OOSA normally gets manifested as an intermediate step during the transformation from TA to the façade of the component. However few enterprises may decide to adopt OOSA model for their enterprise grown Common Information Model. A typical example where OOSA gets manifested as an intermediate is the physical model layer of IBM IFW.

Figure 3. Object oriented sheared allotrope
Façade Oriented sheared allotrope

Figure 3 shows OOSA which is similar to TA but the directions are nailed. OOSA has the same benefits of TA but it is purely uni-directional. Considering the example in figure 3, the designer will not be able to traverse from C to K whereas he/she will be able to traverse only to G. The picked objects still need to undergo the transformation process for generating the façade though the skill level required for handling OOSA directly may be relatively lesser compared to TA.


Mantle CIM exists in various forms and each genre possesses its own merits and demerits. The adoption level depends upon the size of the enterprise, tooling capability and experience capability.



  • TM Forum has good information on Information Framework (SID)
  • Learn about the Vector behavior of relationships in common information model (CIM) based service-oriented architecture (SOA) environments in IBM DeveloperWorks article
  • Read about various Bracing Techniques when Common Information Model Meets the Message Layer in a Service Oriented Architecture (SOA) in this developerWorks article.

Get products and technologies


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


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. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. 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

Zone=SOA and web services
ArticleTitle=Allotropes of Common Information Model