• Business Goals: Faster time to market Low cost
• Architecture Goals: Interoperability Adaptability

Obviously, these are traits we would like for any type of application. You're probably thinking to yourself that these are common sense – so what's the big deal?

Look at the demands being placed on application developers today, and the software they write. These goals are no longer just expected – they are demanded. This fast-paced, Internet economy has turned loose a whole new group of users. These users are not just people in the cubes down the hall – they are your customers!

These folks don't understand, nor do they care, how hard it is to write Internet software that integrates with all of the other systems in your company. They don't care that we work 18 hours a day to meet our deadlines. They don't care that some of us have invested millions of dollars in developing mainframe- based software using 25+-year-old technology, and we need to make our web servers talk to it! These users want to be able to do everything with a click of the mouse instead of talking to a person on the telephone. They want all of the functionality currently available via phone and paper to be available on the company web site, and they want it now!

Whew! The world of the software application developer has changed drastically over the last 5 years. Once the Internet burst onto the scene, and we started developing applications that were being used by people outside the walls of our companies, the pressure was turned up substantially. Couple all of those demands with the fact that these people want all of this available to them all day, every day, and it appears that we as software developers are in big trouble.

Let's take a moment to look at some of the goals in more detail:

• Faster time to market – why build it if you can buy it? If you're a software developer in this Internet world, this should be the first question you ask yourself on a daily basis. Time is too precious to be spent building infrastructure or functionality you can buy off the shelf. You need to spend the majority of your time solving the business problem at hand, and not worrying about how to build infrastructure such as a transaction-processing monitor. Do you get the idea?
• Low cost– whether you're working at a newly formed dot-com company or a Fortune 500 corporation, cost will always be an issue. The question we asked earlier, "Why build it if you can buy it?" should have a cost element attached to it. The next question you probably need to ask is "How much will it cost to buy this infrastructure?" Wouldn't it be nice if you could get as much infrastructure as possible from the operating system? In other words, if you pay good money for an operating system, wouldn't it be nice to inherit a great deal of functionality without paying extra for it? Not only is it cheaper to buy infrastructure, the people signing your paycheck are going to be happier if you spend your time solving business problems instead of unnecessarily building infrastructure.
• Interoperability– unless you're working at a brand new company with no computer systems at all, you're going to need to make more than one piece of software "talk" to another piece of software. As stated earlier, you're going to have to integrate systems that reside on multiple platforms, and present a unified view of data to an end user. From an architecture standpoint, we need to be able to produce a set of services that allow us to integrate disparate computer systems on disparate platforms, whether it be the mainframe, UNIX, AS400, etc. Instead of reworking existing systems so they can be used on the Internet, we want to leverage existing investments in these existing systems. We can also take advantage of software that is created for a special purpose, such as accounting software or bill-processing software, and just build an interface to "talk" to it.
• Adaptability– the world is moving pretty fast these days and the pace of business is keeping up with it. Just when you think you have done a good job of gathering requirements and turning them into functional specifications, the situation changes. The software we write today has to be able to be changed quickly to meet rapidly changing requirements, and take advantage of opportunities when they arise. If you are reading this book, you probably agree with the concept of n-tier architecture or a component-based architecture. We need an architecture and a platform that allows us to take an application and separate it into tiers, or layers, of functionality. Where have you heard that before?

Now that we've looked at our own common application design goals, we're going to examine some of the problems inherent in designing network applications, and then go on to see how architecture has evolved to try to solve these problems.

If you had to pick a single concept to represent Windows DNA, "network applications" would be the one you'd pick. Any single technology in Windows DNA can be applied to specific problems or features, but taken together, the tools that make up the DNA architecture are all about applications that live on, use, or are accessed by networks.

Formally speaking, we'll define network applications as software applications that require or substantially benefit from the presence of networked computers.

You could run a multi-user database (like SQL Server) or a directory service without a network, but what would be the point? Web-based applications effectively require a network.

Breaking applications into their functional pieces and deploying them across a network lets us make the best possible use of an organization's resources. Once you do this, however, you become reliant on the network for the full use of your applications. This implies requirements for reliability, scalability, and security, and soon you realize you need a well-planned architecture. In our case, that's Windows DNA. It's about adopting network applications as the future of general purpose computing, then developing an architecture that supports them.

The definition of network applications given above is rather vague. You probably know what is meant intuitively, but intuition doesn't go very far in programming. So let's look at the characteristic problems that network applications will need to deal with.

Network Application Characteristics
We've just said that network applications break their implementation into functional modules and rely on (or at least substantially benefit from) the presence of a network of computers. Some characteristics follow from that:

• Communications
• Concurrent usage
• State management
• Latency
• Rigorous encapsulation

Let's look at these in more detail.

Communications
The first point is essentially a given one – if my applications work through a network, they must have some means of communication. However, as we'll see in a little while, communications can become a deep topic. There are issues of protocols and data formats that arise in network applications. Simply running a cable between two computers and configuring them for the network is the easy part. Life for the application programmer can get very interesting.