“re”-Building systems as Connected Systems

I am currently seeing the end of the weeds here and getting the nod to start working on a new version of the system we have built. A bit of history is in order.

History of architecture

Not architecture proper, as in Greek columns and Roman ampitheaters, but solutions architecture. When I started our current system, I had two other resources to lean on. The first was a mid-level developer with very few .NET skills and a lack of Object Oriented training. The second was my dev manager. As architecture has to look at both time (not enough) and skills of the participants (a bit lower than desired for "not enough" time), concessions were made on the project. 

The end result is an application that has way too much code in CodeBeside file (.NET 2.0 version of CodeBehind). While there are some libraries (primarily generated) and a few helper classes in App_Code, the application is far too flat for future needs.

Just recently, the executives have come on board that we have to redesign the system. The push comes from a larger view of the world, however. Not only is the web ap going to be retailored to classes and a thin UI (to also make it possible to SmartPhone and PocketPC the application), but the back end bits are going to be strengthened and the system is going to tie in to other systems, including a custom ERP application, an help desk system and our accounting system.


In our arena, I have two viable options to connect our systems. The first is to tie the back ends using Service Broker. As all of the databases are in SQL Server 2005, this is not a major issue. This will certainly work for the two databases on our colo servers and if the firewall needs are not too great, we should be able to use it for the systems in the corporate office, as well.

if you are not familliar with Sevice Broker, it is the SQL Server 2005 means of asynchronous communication. It relies on XML messages to create communication between two databases. Done properly, you create the message schema and adhere to it tightly. This is known as "contract first" development. Now, I have had discussions with people who disagree with adhering to schema, as it hurts performance. And, I agree with this statement, but there is value in making sure you are not dealing with garbage messages. Remember, a toilet allows water through much faster than a water filter, but which water would you rather drink?

At this point, you might think "I am using SQL Server 2005 and SQL Server 2000", so this has no value to me. I respect that, but you do hav the ability to set up SQL SERver 2005 Express on a machine at the SQL Serer 2000 end of your pipe and have it relay communication. Yes, this adds a bit more of a performance hit, but it also adds queues at both ends, which increases message reliability.

I am not stating that this solution works for everyone and may not be the solution (or perhaps may not be the whole solution) for this system. My other option is web services. One again, they slow things down from a pure performance standpoint, but monolithic apps are your best option if performance is all you are looking at. Compile it all into one huge function and it will burn. You won’t be able to maintain it, but it will fly.

Web services do give me the ability to do a lot of things, however. If I register with an internal UDDI server, for example, I can move them to other servers at any time (for example, I notice the current server needs maintenance). They are also easy to configure end points, especially since Visual Studio 2005 puts the web service URL in the config file. And, if I have legacy web services, I can port them to WCF and make simple config changes to take advantage.


 The concept I am talking about here is Service Oriented Architecture (or SOA). And, web services is a major component. But, please do not think that SOA is merely changing your interfaces to web service interfaces. CRUD over web services is not SOA … it is a mess. In order to complete my system, I am working on what messages need to go across. The UI side of the equation has to gather all of the information to complete a task prior to sending it across. As it stands right now, the system is already designed this way on most pages (very few small calls), so there is not a huge amount of work. I will update the blog as I get deeper. Perhaps next time, i will think the entry through before typing so it is less jumbled.