Skip to main content

On Defining Messages

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

I am arguing 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 enterprise data-model, instead the collection of all the data-models is the “de facto” enterprise data-model.

Data modelling 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-model. 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 can/should have a “personalized” view of the shared logical data-model. Based on the recommendation, 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 and often used in practice. The challenge is creating views of a logical OO model. While the concept is very common to the database area, it is not used at all in the OO domain.

The decision on how to define the API is project specific. In my experience I found that starting from a shared logical data model of the critical applications in the ecosystem to be a practical and extensible approach.

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.

Labels:

Popular posts from this blog

View - A Functor for Web App Design

This blog is about practical applications of Category Theory to the development of Java + Spring applications. I am looking at a design approach to simplify the development of web applications. Traditionally, this kind of back-office application is based on the Web 1.0 technology stack, using Spring Boot and Thymeleaf. My approach is to keep using Spring Boot but replace the generation of HTML with J2HTML and higher-order views. From a Category Theory point of view, we can look at web applications as mappings from the Category of Business Entities and the Category of UI Widgets. If we go one step further, both business entities and UI widgets are mapped to Java classes. Thus, we can view a web application (or a part of it) as an endofunctor in the Category of Java Classes. We define the View-functor as follows: domain(V) - Java classes representing business entities - e.g., Invoice, User - and, codomain(V) - Java functions that render the business entity as a DomContent object (DomCont...
Read more

Web Application Development following Functional Programming Principles

After studying category theory and functional programming, I decided to put these concepts into practice by developing a simple web application. This project was inspired by the example in Chapter 11 of 'Programming in Haskell' by Graham Hutton. My goal was to take these theoretical programming ideas and see how they work in creating a real-world web application. The key concepts of functional programming are: Prioritize creating pure functions as much as possible. These are functions without side effects, making them simpler to test Use composition of pure functions to construct more intricate functions Use Functors, Applicatives, and Monads in scenarios that require pure functions, such as error handling or managing missing values, and when working with collections like trees and lists. I wrote this application in Java, utilizing the Spring Boot framework. This decision was influenced by my previous work in developing enterprise applications with this technology stack. My obj...
Read more

Reading J2HTML

J2HTML (j2html) is a Java library used to generate HTML I have been using it to create Web 1.0 applications in Java. Web 1.0 is server-side rendering pages with minimal Javascript. As I got deeper into using the library I started to read the actual source code of this library with an eye on following Java best practices and to my pleasant surprise, this code follows many of them. I am going to show here some examples of using interesting Java features, beyond the basics. 1. Functional Interface People are aware that Java supports some form of Functional Programming, and here is an example of using it: @FunctionalInterface public interface Indenter {     String indent( int level , String text ); } public static Indenter indenter = ( level , text ) -> String. join ( "" , Collections. nCopies ( level , FOUR_SPACES )) + text ; Things that I noticed: String has a method called join. I used before StringUtils.join, but now that is in the standard library I don’t n...
Read more