How to build a distributed application: Why Practice Matters

"In theory, theory and practice are the same. In practice, they aren't even close."

 

I have no idea who said that first, but they are words that an application architect should live by. As I mentioned in my last post, I really do think it is important to have a strong theoretical underpinning to serve as a guide for developing a distributed application. It is also true that our ultimate goal as application architects is deliver working code that solves real business problems. Building actual systems is a continuous process of trade-offs, compromises, and imperfect choices. With this post, I start applying my theory to real application scenarios. The rest of this series will focus on a mix of scenarios from a slightly abstracted version of an application that is currently in development and pieces of applications I've helped build in the past. My goal is to show how to apply a simple set of constructs and processes to solve real-world challenges familiar to most business application architects and developers. The goal of the application architect is to supply an underlying infrastructure that lets developers concentrate on delivering business functionality without getting lost in the morass of conflicting forces that must be balanced to design and develop an effective distributed application.

 

 

I think of distributed applications as a set of technological artifacts constructed to support one or more business processes. I'm not going to attempt to define a business process. If you are a business application developer or architect, I hope you know what your organization does and you have a pretty good handle on the business process(es) that your application is supposed to support. If not, you're reading the wrong blog. From an architectural perspective, I recommend modeling your distributed application as a combination of user tools, documents, messages, and services. No doubt, this will strike many of my readers as a bit odd. There are no objects, protocols, databases, frameworks, APIs, or platforms in sight. All of those are implementation details. We'll get to them eventually, but you should start at a higher level. Let's look at each of the four constructs in more detail and try to make a few technological decisions along the way. Because most of my experience has been on the Windows platform, my examples will use Microsoft technologies, but the principles apply more generally.

 

 

You may be more comfortable with terms like user interface, presentation layer, or rich/smart/thick/thin/dumb/browser-based client. I think it's more useful to think of the tools your users need to fulfill their roles in the business process. This puts the focus on your users and what they need, rather than concepts driven by technical constraints. Ideally, you want to choose a computing platform and developer tools that let your business developers deliver the best possible user experience. In reality, many times your choices are limited by things like corporate standards, application requirements, and developer expertise. This is the area where I've experienced the most painful of those trade-offs, compromises, and imperfect choices that I mentioned above. You have to weigh a wide variety of conflicting forces in a constantly changing environment. For the purposes of this series, I'm assuming one of the best possible environments for developing a distributed application: a corporate environment with managed desktops running Windows XP SP2 with automated deployment of the .NET framework 2.0. Given that environment, there is no doubt that Windows Forms is the best way to deliver user tools for internal users. I'll assume the use of a cross-browser compatible web application for our user tools for external users. If your environment is substantially different, your choices for user tools may be quite different and it can have a substantive impact on your architecture. I'll try to point out some of the differences as we work our way through various scenarios.

 

 

Most business processes revolve around users manipulating documents: purchase orders, customer information, vendor information, service requests, etc. Fortunately, most of the technical world has settled on a single technology for representing business documents that is straightforward and well supported: XML. Unfortunately, most of the technical world has settled on a single technology for representing the structure of business documents that is overly complex and unevenly supported: XML Schema. I recommend embracing XML in your architecture and frameworks. Some application developers will want an OO façade around XML documents and others will want to work directly with the XML document. Let them make that choice and do the work. XML Schema, on the other hand, should be treated like MSIL. Folks should know it is there and understand how to get to it, but nobody should be building it by hand and you should realize that you can accomplish everything you are likely to need by using only a very small part of its capabilities.

 

 

Your user tools and services will communicate using messages. Typically, messages represent interactions focused on documents (i.e. requests for documents, commands with documents, etc.). Most discussions about distributed application design get bogged down in arguments about how to best send, receive, and represent messages. Mostly these are what I like to call "artichokes and roses" arguments. If you don't know what I mean, just ask the next 10 people you meet which are better, artichokes or roses? You won't get a coherent answer (and most people will decide that you are a bit loony) because the question is meaningless without some context. Handling messages and network communications is where the application architect should really earn their keep. In my next post, I'll show you how to design a communications API that is easy for developers to understand and fosters good distributed application design. I'll use SOAP as the underlying messaging model (mostly because it gives us a good interop story), but completely hide it from the application developer.

 

 

Services are where most of the work of the distributed application happens. Services allow you to harness all the power of server-based computing to solve real business needs. The biggest challenge facing most service developers is the difficulty of multithreaded programming. Answering that challenge will be the ultimate goal of this series. I just wish I knew for sure how it turns out in the end.

 

 

In my next post, I'm going to try deliver something of real value in building a distributed applications (about time, after all this theory and modeling stuff): A message-based communications API for user tools. I'll follow that up with a complementary API for services to use.