Besides working with EDRA I am also very interested in technologies (or products) like Indigo and FABRIQ. Both of course different products, but with some concepts in common. For me it’s important to understand the concepts of these new technologies so I can use this knowledge in my current work when it comes to making architectural/design decisions that are as future proof as possible. To get familiar with the concepts in both Indigo and FABRIQ I decided to try to introduce some of these concepts on top of EDRA.

For the record: this is all just for my own fun! I have no intention to use the result of this in my current work that I am doing with EDRA.

It is my intention to change as little as possible in EDRA (preferable nothing), so all new functionality will be on top of EDRA. The ultimate goal is to build an (small) application that is using concepts like messages and ports similar as they are available in FABRIQ and Indigo but using EDRA ‘behind the scenes’. All of course in a very limited version. Just enough for me to understand the implementation consequences of these concepts within an architecture.

One of the first things I noticed when looking at FABRIQ and Indigo is the similarity in the concept of the ‘message’. Both products have a well defined message class. This is something that is not available in the current release of EDRA. In EDRA a message is based on a XSD, each message is of its ‘own’ type and is not derived from, for example, ‘EDRAMessage’ class. Because I think a well defined and consistent message structure has some advantages compared to the way messages are handled in EDRA, I decided to first introduce the concept of a message (like FABRIQ and Indigo) in my ‘study project’.

If we look at the Indigo message class (FABRIQ message looks very similar) we can see that this is actually a ‘wrapper’ around a SOAP envelope. The message basically consists of two different parts, the message content and a collection of message headers. The message content part is used for sending application specific data from one service to another. If we take a better look at the message content, we can see that this is some sort of a ‘free format’. This means it is an unspecified structure. This is no problem because, as long as the message sender and the message receiver understand the message, everybody is happy. The infrastructure doesn’t need to understand the message content!

In indigo, the actual message content is reachable by using the ‘reader’ property of the ‘content’ object of the message class (Message.Content.Reader). This property in fact returns an XMLReader positioned at the beginning of the ‘soap:body’ part (= actual message content) . Using an XMLReader for accessing the content of a message has some advantages. When Indigo (and FABRIQ) creates a message it uses an XMLReader to first read the ‘soap:header’ part of the message. As soon as it finished reading the header information it stops reading and leaves the XMLReader positioned at the beginning of the message content (soap: body). The message content is then available by using the reader property as shown above. Treating a message like this, saves an enormous amount of time (especially for large messages) because the whole message doesn’t need to be loaded in some sort of a DOM before the infrastructure can do its magic to process the message. In fact, the infrastructure doesn’t need the message content at all.

When we look at the message headers, the story is a bit different. Message headers are needed by the infrastructure to process the message. The infrastructure can even change headers if needed. Because headers are used by the infrastructure most of them are system defined. The message headers are reachable (Indigo) by using the ‘Headers’ property on the message class. Message headers are added (or even changed) to the message by the infrastructure and NOT by the sending or receiving application. Headers can be used by the infrastructure for, routing, security, etc. One very obvious header is the ‘to-header’. This header holds the URI of the receiving application (service) and is used by the infrastructure to deliver the message at the right spot. Preferably the ‘to-header’ isn’t populated by the sending application but by a part of the infrastructure (directory service). This guarantees location transparency between services or applications. Another very common message header is the ‘action-header’. This header isn’t used by the infrastructure but is used by the receiving service of the message. This ‘action-header’ can be used by the receiver of the message to internally map the message to the right  place in the service or application that is capable of handling that specific ‘type’ of message.

So, where are we? I used the above to organize some of my thoughts and learning’s about messages in Indigo and FABRIQ. Although the concepts of messages and headers are available in EDRA they are implemented in a very different way. My next step will be defining a (very basic) message class en probably two header classes (to- and action- header). The message class must be capable of wrapping an EDRA message (XSD typed message) and supports storing the headers. The implementation of the message class and headers must be just enough to support the concepts described above. After that I will dive into the concepts of ports and channels and implement these concepts in a very basic way. When this is finished I will try to map these things to the EDRA pipeline and see if I can get all off these things to work together….

Of course the big question is: is it worth it to spend time on the things I planned to do?

Well…..maybe not, but at least it helps me understand new concepts and gives me some fun!