“Defining Message Formats” is the title of a message posted on the Service Oriented Architecture mailing list [1] which attracted a lot of attention. The post summarizes the dilemma faced by solution architects when they have to define a service interface:

1. Base the internal message format on the external message standard (MISMO for this industry). This message set is bloated, but is mature, supports most areas of the business, and is extensible for attributes specific to this company and its processes.
2. Create an XML-based message set based on the company’s enterprise data model, which the company has invested a great amount of money into, and includes a very high percentage of all attributes needed in the business. In a nutshell, we’ve generated an XML Schema from ER Studio, and will tinker with that construct types that define the payloads for messages.
3. Use MISMO mainly for its entity definitions, but simplify the structure to improve usability. We benefit from the common vocabulary, but would ultimately define dozens of transactions over the coming years that MISMO has already defined.

This article argues in favor of a variant of option 2 and provides details of how it can be implemented.

First, contrary to some architects recommend, I don’t think that an industry standard is a good option for internal integration. These standards tend to be bloated, ambiguous semantically or too generic. But most importantly, they tend to have one, grand view of the land when in fact different actors see entities In different ways. For example, in telecom, in the service layer a Service entity “uses” a Resource while in the resource layer, a Resource “hosts” Service(s). The TMF model models the first relationship but not the second.

Option 2 relies on the fact that the organization HAS an enterprise data-model. Sometimes there is a formally defined enterprise data-model with a significant effort allocated to maintenance and governance. But more often there is no formal model, instead the collection of all the data-models is the “de facto” enterprise data-model.

Data modeling can be done at several levels of abstraction: conceptual (or ontology), logical and physical. Another way to categorize the data model is by scope – often different sub-systems have different data-models. I call a “shared data-model” the intersection of the sub-system data-models. The “shared conceptual data-model” is in the realm of the enterprise architecture and business architecture. It translates in a shared logical data-model which is used by integration architects to create the service interfaces (XSD, Java or C# classes).

The “shared logical data-model” is the starting point for the definition of messages exposed by a service. But how to get from the data-model to the message format?

In the same message thread, Michael Poulin suggests [2] that each component should have a “personalized” view of the shared logical data-model. With this approach, the message format is the physical data-model (XSD) of the logical view used by the component. This is a sensible approach for message definition but not used regularly in practice. The challenge is creating views of a logical OO models -  a concept is very common to the database area but not in the OO domain. The rest of this article goes in more details of how to define views using an example.

The example we are going to use is application portfolio management. There are two subsystems: Application Portfolio Management (APM) – managing information about applications and Infrastructure Asset Management (IAM) – managing primarily infrastructure resources. A simplified component model is shown in the next diagram.

This diagram shows two entities, Application and Servers, that depend on each other and two components, ApplicationPortfolioManager and InfraAssetManager which are using but primarily one entity and a subset of the second entity.

 

 

 

 

 

APM has an “application-centric” view of the world with a data-model that looks like in the side diagram. Note that the Server entity contains only some of the attributes from the shared model and a “derived” attribute called BriefDescription.

 

 

 

 

 

IAM has a “server-centric” view of the world. The Application entity contains only the a few attributes from the shared data-model and has a “derived” attribute called BriefDescription.

 

 

 

Comparing the three data-models: shared, application-view and server-view and try to create XSDs out of them we see that they are similar but different. For example, the Application view in the application-view is not the same (in the OO sense) as the Application in the server-view.

One way to define the messages for the Application Manager and the InfraAssetManager interfaces is to create XSDs that contains all the attributes of the two views. This is a wrong approach because it tightly couples the two components: any change to the Application in the application-view will impact IAM even though this component is interested in only three attributes.

A better solution is to start from the shared data-model and create two namespaces: one for APM and one for IAM each containing only the elements required for that component. Below are the two XSD diagrams.

  

The two views have been created manually but they can be generated automatically. First, the attributes and connectors will have to be annotated with “view” information. Then, an MDA tool can traverse the model and generate the views. Another direction to  explore this topic is to look at the integration components. In this article, APM and IAM are cull-de-sac: there is no further propagation of the entities passed as arguments – at least not in the example. But what about the EnvironmentManager component that is an orchestration between APM and IAM? How do to define the message format for that component?

More to come on this topic soon!

 

References

1	Defining Message Formats. http://tech.groups.yahoo.com/group/service-orientated-architecture/message/14783.
2	Re: [service-orientated-architecture] Defining Message Formats. http://tech.groups.yahoo.com/group/service-orientated-architecture/message/14784.