Today I attended a great session of Arvindra Sehmi and Beat Schwegler. First Arvindra talked about the “new” way of modelling connected systems. He explained there is a need for a “Service Oriented Architecture Model” (SOAD)  that sits between the business model and the technical model. While the business model is used to describe the needed capabilities (the “what” part) the SOAD model is al about modelling the contract of the service. At the end we have the Technical model that covers the technical details, like service interface, service implementation, etc. Of course the story covered a lot more details than the above description and it sounded pretty good.

The second part of the session was covered by Beat. He talked about the technical model. Currently he is working together with Cristhian Weyer and Maarten Mullender on a series of articles (first one can be found here) that will provide us with a set of recommendation for designing and implementing connected system (services). In this session Beat showed us that he is already working on the actual implementation of the recommendations. He showed us a Software Factory that is suports building services (by using the GAT). Pretty cool stuff!!!

From what you could see from the demo this series of articles (and implementation) will really show you some of the best practices for building these kinds of systems. Beat defined 8 steps that you have to do to design a service:

1. Design the data
2. Create the data classes
3. Design the messages
4. Design the interfaces
5. Create the transport interfaces (for example web services)
6. Create the adapters
7. Implement the internals
8. Connect the internals to the adapters

The artifacts of the above steps all formed a separate Visual Studio project within 1 solution.

I will not cover all of the above steps but some of the things were pretty interesting:

Within the first step (design the data) we create the XSD schema. This is actually the “data on the wire”. Based on these schemas the data classes are created by using for example XSD.exe. This of course is nothing new, but what we see most of the time now is that the product of step 1 is referred to as the messages. Beat actually showed us that in step 3 we create the actual message class that has a public field (result of step 2) which is actually the message payload. This messages class uses some techniques that I wrote about before to support for versioning and flexibility.

Another interesting thing is that in the “technical model”, when talking about the “service interface” we actually mean the interface definition (public interface IOrderService {}). Besides this the service has some “transport interfaces”, these are the actual implementations of the interface for a specific transport type (web service, Enterprise Service, etc.). Maybe nothing new here but is a good thing that is “written down” as a piece of guidance.

The last thing that I will write about is the introduction of “adapters”. These are actually a “layer” between the service interface (transport) and service internals. By using this technique the service implementation “knows” nothing about the actual message which makes it easier to change the message without breaking the service implementation. Of course in that case the adapter needs to be changed.

All of the artifacts that were created in the above 8 steps were supported by the “Software Factory”. Although it was very early work that Beat was showing it looked really cool, so makes sure to follow the series of articles!