There really is no single answer to that question. There are so many types of business solutions being built using Internet technology that there are probably thousands of different types of Internet-based applications. However, there is one question we can probably answer: what are the basic characteristics of these applications?

Internet Application Requirements

In general, an Internet-based application will:

• Present a unified view of data from multiple data sources
• Allow a user to update data
• Provide full e-commerce capabilities
• Be fast
• Be scalable to thousands of concurrent users

Now let's take a look at each of these characteristics in a little more detail.

Presenting a Unified View of Data From Multiple Data Sources

Presenting a unified view of data coming from multiple sources creates a number of problems. A lot of businesses have multiple types of data stores, ranging from mainframe-based VSAM applications, to SQL Server databases, to Oracle databases, to e-mail stores and directory services. There needs to be a way to "tie" all of this data together. So obviously we are going to need a robust data access mechanism, which allows us to access multiple types of data sources that might even reside on different platforms. In addition, we might need host, or mainframe, integration capability. Just getting data from a mainframe application to a web page is a huge technical feat.

Allowing a User to Update Data

If our application allows a user to purchase something, or initiate financial transactions, or update personal data, we're going to need transactional capability. By having transactional capability, we need to somehow make certain that either all parts of a piece of work, or transaction, complete successfully or none of the transaction is allowed to occur.

To make matters more complicated, we already know that the likelihood of having data in multiple sources is fairly high. The consequence is we will need the ability to define transactions that span multiple data sources, while still having full two-phase commit and rollback.

Full e-Commerce Capabilities

Providing full e-commerce capability is a must these days. If you're selling products over the Internet, you will need a framework that provides a shopping cart, and management tools to manage product catalogs, run promotions and sales, and present cross-selling opportunities to your users. Additionally, you will need this framework to be extensible so you can incorporate your own business logic, such as calculating taxes in foreign countries. It would also be really nice if this e-commerce framework used the same transactional capability described above when users commit their purchases.

Fast

You might get users to your web site the first time, but if your site is so slow that they have a bad user experience, they might never come back. So you're going to need to be able to architect a solution that solves your business problem, but is fast at the same time.

Being able to distribute requests among many machines is one way to help achieve a speedy solution. Other design characteristics, such as performing work asynchronously, can also help speed up things.

An example, albeit a crude one, might be an online purchasing application. When a user actually places an order, they probably don't need any kind of response other than "we received your order, here is your confirmation number". You could then place the order on a queue and process it later. The user doesn't know their order won't be processed until later, but they've got the result they wanted quickly.

The implication here is that you'll need a queuing or messaging mechanism at your disposal, so you can incorporate it into your application design.

Scalable to Thousands of Concurrent Users

Not only does your site need to be fast, it probably needs to support thousands of concurrent users. Again, load balancing across multiple machines will help solve this problem. Not only will load balancing help you handle more users, it will also improve your "uptime", and help ensure you are running 24x7x365 like all users expect these days.

Platform Capability Requirements

So now you have a better picture of some characteristics of applications being built today. There's obviously a lot of infrastructure needed to build these applications. What we can do now is take these characteristics, and from them create a list of the capabilities we're going to need from our platform. These include:

• A web server
• Transaction processing and object brokering
• Message queuing
• A data access mechanism
• Security
• Load balancing capabilities

We'll see later in the book that Windows 2000 provides these, but that's jumping the gun a little. We should probably turn our attention first to identifying the things that drive us when designing applications.

Application Design Goals

For most Internet-based applications you can usually identify two sets of goals:

• 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.