Bracing Techniques when Common Information Model Meets the Message Layer in a Service Oriented Architecture (SOA)

When leveraging the common information model (CIM) standard for middleware environments, creation of service components requires slicing and adapting the appropriate entities within the CIM. While slicing is normally driven by the business process, adaptation needs to be performed using a special technique termed as the “bracing technique”. In this article we will explore the bracing technique in detail; which in turn will enable service designers to create service interfaces that are highly flexible and easily consumable.

Kerard Hogg (kerahogg@au1.ibm.com), Executive Architect, IBM

Kerard HoggKerard Hogg is an IBM Executive Architect from Australia, and works as lead architect on large system integration programmes.



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.



Faried Abrahams (farieda@au1.ibm.com), Distinguished Engineer, IBM

Faried AbrahamsFaried Abrahams is an IBM Distinguished Engineer, IBM USA and works as Technical Lead on Large Australia Telco Transformation Program.



13 April 2009

Introduction

In a typical Service Oriented Architecture (SOA) environment leveraging the common information model, creation of service components requires slicing the appropriate entities in the CIM and adapting them. While slicing the CIM is important, equally important is the adaptation process. By adaptation you introduce relevant entities over and above CIM entities in order to make it conducive to the SOA environment. We term this technique as the “bracing technique”.


Why Common Information Model?

Positioning CIM in an SOA environment has its own advantages: easy plug and play of applications and a decrease in integration costs. With new organizations entering the market and increasing competition for many businesses, positioning CIM within an SOA environment is justifiable across a wide range of industries including financial services, telecommunication, and insurance.

Bracing techniques

Entities introduced in the process of adaptation of the CIM (discussed subsequently) serve as clamps (braces) and hold the CIM slice to be exposed as services to external consumers.

In SOA based environments, each service operation will require only a portion of the CIM. However, the CIM must be sliced and adapted properly. A poorly adapted CIM slice will not maximize the benefits of SOA by not having agility or being easily consumable.

Note: Most of the industry published CIM standards are abstract and are not ready for direct implementation. During the implementation process, the designer is expected to extend it along various dimensions. We term the resulting entities as extended entities in our discussion.


Bracing elements

Bracing elements which serve as a clamp to fasten the message operation with common information model can be generalized into three major categories:

  • Bracing Element category 1:
    Encapsulating Element: When a service request or the response message is a collection of the objects of interest, and requires more than 1 root element, the “encapsulating” category of the bracing element needs to be leveraged; thereby constraining the objects contributing to a particular message to one.
  • Bracing Element category 2:
    Bridging Element: When the service request mandates the use of two or more discrete attributes (which belong to two different objects separated in the CIM) then a bridging element will be introduced. This element bridges the two discrete attributes for easy implementation when the distance to contact each other, through the CIM, is very long. As a rule of thumb when the number of nodes to be traversed is more than 5, this bracing element will be introduced.
    A typical example, from the Telecommunication based SID (a widely used Common Information Model), is when the Service Inventory expects both a telephone number and address identifier to return the list of available services. The telephone number and address identifier are discrete attributes and reside more than 5 elements apart in CIM. In this case, the bridging element will be introduced to enable easy implementation.
  • Bracing Element category 3:
    Chromatic Element: In the real world there are many “application flavored” elements which are required to be exposed in service messages. Application flavored elements shall not be entertained ideally in a SOA based CIM environment; however for integration reasons when the business decides to expose such attributes there needs to be a trade off and optimal means to handle these elements in the middleware environment. In this scenario the chromatic element will be introduced (to merely hold elements which are strongly application doped). It may be noted that there is a marginal difference between the purpose of having an encapsulating element and chromatic element. The former will be introduced to handle the cardinality and will always have many relationships to the operation while the latter may have one to many relations with the operation.

Figure 1 below shows the diagrammatic representation of the bracing element categories.

Figure 1. Common Information Model Entities
Common Information Model Entities

The blue boxes in Figure 1 represent a high-level view of how service operations relate to the CIM entities. The various types of bracing are expanded in detail by the representations on the right hand side of the diagram.

The significance of bracing elements can be understood by the following sample use cases:

Use Case 1: The Encapsulating Element:
Front end CRM application makes a query to an inventory management system requesting for a list of available telecommunication services given an address Id.

Inventory system sends a list of available services.

This list can contain a number of attributes which have equivalent CIM entities or extended entities. In this case all the attributes repeat for each of a number of PSTN services. It is necessary to introduce an encapsulating element which will relate one operation to many repeating groups of CIM based attribute collections.

Use case 2: The Bridging Element:
For the purpose of this Telecommunication based example assume a service design expects address identifier and telephone number in the request to retrieve addressStructure. In this case traversing from AustralianPropertyAddress to NetworkAddress/NetworkTelephoneNumber in the CIM involves traversing many nodes and will be easier from implementation perspective if an additional object ie bridging element is introduced between the two CIM entities.

Use case 3: Chromatic Element:
For the purpose of this Telecommunication based example assume a service needs to integrate with a legacy provider system and the response from the legacy system includes the following attribute bunch - TransactionId, ApplicationId, DateTime, UserId.

These attributes have little business meaning and are much more about the mechanics of the solution, hence they are not represented by the CIM and are unsuitable for extensions to the CIM. If it is a requirement that the service operations expose these attributes by fitting both together with the CIM based structures under the one operation will result in a disorganized interface particularly if collections of these attributes are required. This results in a requirement to introduce an element called Chromatic Element in between the operation and the non CIM based attributes.


Conclusion

Bracing techniques enable a service designer to create highly flexible and easily consumable service interfaces in CIM based environments. The technique proposed has been implemented in IBM‘s largest SOA implementation project in the southern hemisphere.

Resources

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. 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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=379727
ArticleTitle=Bracing Techniques when Common Information Model Meets the Message Layer in a Service Oriented Architecture (SOA)
publish-date=04132009