I talked about Message Oriented Architectures at the Norwegian .Net User Group (NNUG) on the 27th of May in Oslo. This was my second speaker appearance at NNUG, and this session was a very different experience from my last one. I found it a lot more challenging to talk about architecture than talking about dynamic SQL vs. stored procedures. It’s really hard to decide on what slides and bullet points to include when delivering an introduction to such a wide and exiting topic.

It was fun to share my thoughts on XML and modern messaging, loosely coupled designs and asynchronous messaging. I ended the talk with some slides on GXA and the XML message bus. After the presentation we had a very interesting discussion about some issues with asynchronous designs.

I’ve made the slide deck available here if anyone is interested.

Messaging as an application design pattern has been around in enterprise applications for decades, but recently it has been getting a lot of community press as web services are starting to roll out and service oriented architectures are climbing the preferred design ladder.

One of the most interesting aspects of a message oriented programming is the inherent ability to approach an asynchronous design. Yet, for some reason the transition from synchronous operations seem to be very hard. I suspect that it is not necessarily the added technical complexity, but rather the fear of loosing control that is the primary obstacle. Now that we are moving towards factoring our systems into services this is a situation we must learn to master.

Looking at the way business transactions are done today, and the way they have been done for ages, we can easily see that quite a few of them are asynchronous. Either it is a matter of message exchange via regular mail, fax, e-mail or some messaging product like Microsoft BizTalk Server. When for instance a user compiles a set of requests into an order with a procurement system the transaction is committed long before the order has reached the supplier, or even before the order has left the procurement system. In this particular scenario we are used to an asynchronous interaction, and it is indeed the only way.

Keeping in mind the before mentioned example it is strange that we seem to be unable to apply the same pattern within our own applications. I guess to some extent it is because we feel that we are the masters of our own system and that we have the ability and the right to perform synchronous operations, and that we should do so either to uphold consistency or to provide accurate and immediate user responses. Just because we can!

Even though a synchronous design may provide you with the comforting feeling of control, as business processes become more complex and the amount of users increase this will prove to be a troublesome preference. As we start refactoring our applications into services and begin to enjoy the dynamic nature of GXA it will be unreasonable to except a synchronous processing pattern for a variety of different reasons; some concerning processing time, load balancing, transactional boundaries, internal system restrictions and manual processing tasks just to name a few.

I guess what I am saying is that we need to learn to let go, to be able to trust individual part of our own systems as well as external systems and embrace the black box nature of services. It’s important to note that asynchronous messaging is in no way synonymous with unreliable messaging. If we are able to do this then at least the fear of loosing control may fade away, and I guess the immediate user response is a user education problem.

The blog community is discussing message oriented programming, service oriented architectures, and of course SOAP and RPC. It’s great to see so many smart people seeing the potential of these emerging architectural principles!

And for what it’s worth; I’m in the messaging camp!

When talking about service oriented architectures we basically talk about three fundamental pieces. There is a service consumer that queries a service registry or a service broker for a set of service providers that meet a set of supplied criteria. The service consumer then selects the preferred service based on a set of preferences, and the required operations are performed on the selected service.

The interesting thing about this is the fact that the industry has launched the vision of a global service registry where one could organize and resolve services using some sort of global taxonomy. Even though this approach might work for the most rudimentary of services what is increasingly interesting is the fact that their visionary samples tend to touch the area of B2B commerce. As most procurement managers know, one of the most important aspects of any supplier selection process is to establish a reliability level. When you find a supplier that satisfies your requirements you set up a trade agreement to ensure that the reliability level is agreed upon and maintained. You establish a trust relationship. The thing is that I fail to see how this is going to work with a global registry of supplier-like services. Where is the negotiation phase that is designed to establish a working business relationship with an implied two-way trust?

My point here is by no means to undermine the importance of a service broker or a service registry when it in fact is a hugely important part of any service oriented architecture. It will play an important role in making your application both pluggable and highly interoperable while effectively enforcing a much needed level of abstraction. But a successful registry has to be filled with a set of pre-approved services from a set of suppliers that the customer has established a healthy business relationship with. Providing such a private registry service makes perfect sense in any B2B architecture. Trying to solve the complexity of a negotiation phase in a machine readable service contract doesn’t.

Even though the industry is starting to address this issue, and somewhat shifted the focus towards local registries, I still see the oversimplified idea of a global registry in both technical writings and vision documents. Hopefully we will all accept that there is a reasonable complexity involved in streamlining current business processes.

Globalization has never been an easy aspect of any development project. Lately I’ve been evaluating the requirements needed to serve users from different time zones, and at first sight this appeared to be a fairly manageable task. After all it’s just about storing all your dates in UTC time and then adding or subtracting the time difference to get the users local time. Or so it seemed…

First of all, there is no nice way of retrieving the local time zone from the user’s browser, short of using Passport and forcing the user to share his or hers time zone information. So, the user will have to choose the time zone he or she wants to use, and I guess the time zone support is worth the extra seconds spent during user registration.

Then, I entered the domain of the DST (daylight savings time/ summer time) monster. At first I thought it would be fairly easy to find a standard for this, or that Windows or the .NET framework would be nice enough to provide me with the necessary functionality.

The .NET framework does not, to my knowledge, support the ability to have different time zones attached to different threads, like they have with CultureInfo. But Windows 2000 does have a function that allows me to convert a given UTC date to a specific local time zone, just as long as I supply the time zone information; UTC offset and DST information. And it’s even possible to extract this information for every registered time zone from the Windows Registry. It’s not elegant, but it should work as long as I inserted the time zone conversion in the user interface layer. And I could even write my own .NET TimeZone implementation.

This could have been the end of my problems, but of course it wasn’t. As it turns out DST settings tend to vary between countries, and sometimes between regions within the same country and time zone. And to top it off, it varies from year to year. I’m not talking about fairly deterministic things like the last Sunday in March, but more like the time when Sydney had special DST settings during the Sydney 2000 Olympic Games and the fact that several countries, including Norway, decided to ignore DST for several non-consecutive years. I guess that is why Microsoft decided to releases a time zone editor for Windows. At least I can find comfort in the fact that the European Union has created a DST standard, but it doesn’t help historic dates much though.

So, I guess the only way to handle this problem is to create a time zone for each different combination of DST settings and UTC offsets, and collect all the relevant time zone information in a large table. I was hoping it wouldn’t have to come to that :(