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”.
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.
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 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
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.
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.
- Participate in the discussion forum.
- Learn more about the
telecommunication
industry body information model (Common Information Model) - TeleManagement Forum Information Framework
- Read further about the
finance and banking industry information model
- Visit the IBM ESB and Connectivity Patterns Wiki
Kerard Hogg is an IBM Executive Architect from Australia, and works as lead architect on large system integration programmes.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
