- What Is Architecture?
- Core Architectural Ideas
- Roles
- Components
- Examples of System Architecture
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Core Architectural Ideas
Architectures for commerce systems may look very different, but they all have to address the same issues. These issues must be understood no matter what approach is taken. In some cases, these common questions are considered explicitly during the design phase; in other cases, the questions and their answers are reflected in assumptions about various components in the architecture. In this section, we examine some of the primary elements that go into a commerce architecture, and we hope to make most of the issues explicit rather than leaving them as assumptions.
One word of caution: it may sometimes seem that what we describe in the architecture is so obvious that it need not be written down, or that we are drawing unnecessary distinctions. In our experience, leaving the obvious as implicit can often lead to later confusion and misunderstanding, precisely because everyone thought it was obvious but had different ideas of what was obvious. If we are to be successful at designing and building computer systems, we must be very precise, not only in describing the computational steps but also in our understanding and description of what we are trying to do. The processes of doing business may seem natural because they are so familiar to us, and because people can handle many unusual situations easily and effectively. When we design computer systems to manage some of those processes, we must be especially careful because computers cannot figure out how to keep a customer happy when something unexpected goes wrong.
Understanding of Roles
Two of the most basic questions for any computer system are "Who uses it?" and "What do they do with it?" For some programs, there are a few kinds of users who share similar goals. For example, novices and experts both use word processors with the same goal—producing documents. Internet commerce systems are more complicated: their users include the buyers of goods and services, the sellers of goods and services, and the people who operate all of the machinery.
Understanding the various roles and kinds of users for a system helps us to focus our attention on making sure that all users can use the system effectively to accomplish their goals, whether that is making a purchase or creating accounting reports.
Decomposition of Functions
A second important part of the system architecture is the way it decomposes the system into functional units. The specification of these functional units and the interfaces between them defines the architecture of the system. One of the differences between architectures is often the way that they group functions into units. Are all of the components integrated in a single system? Are the components distributed across multiple systems? What are the interfaces between functional units?
Linking Content to Transactions
The first two considerations for the system architecture, roles and decomposition, apply to the design of almost any computer system. A third part of the system architecture of an Internet commerce system is the way that content, such as a catalog, is linked to the transaction processing. In a paper-based system, the buyer transcribes item numbers and quantities onto an order form or requisition. Obviously, we would like to do this electronically.
There are several key issues in this linkage.
How the user makes the transition
In many cases, the user sees a Click here to buy button or can add items to a shopping cart for later purchase. The transition to the transaction takes place either at the Buy now point or at Checkout for the shopping cart.
How the information is verified
Depending on the underlying technology, it may be necessary for the transaction system to verify that the purchase information, such as price, item identification, and so on, was not modified when it was sent over the network. Because (as we shall discuss in more detail later) the Web uses a stateless protocol, a commerce system built on top of the Web must manage its own state. If that state is carried by the client in some way, the server must be able to ensure that it was not modified in transit.
How the information matches up
Some Internet commerce systems include a real-time inventory check to assure customers that items are in stock. If the system indicates that an item is in stock, however, how long is that indication valid? If the customer puts the item in a shopping cart for purchase at some later time, does the system promise that the item will be available when the purchase occurs? If the system does make such a promise, how long is it valid? What if the customer never returns to the site to buy the items in the shopping cart?
The answers to these questions help make design decisions for the system. Because different answers can lead to very different designs, it is important to think through the issues early in the design process.
Trust Models
In any distributed system, different components trust each other to a greater or lesser extent. Some components may trust others completely for all kinds of access (for example, both reading and writing data elements), whereas other components may disallow any remote access to their data. The specification of these relationships is called the trust model for the system. Any system has at least an implicit trust model, but specifying a trust model explicitly helps us to understand the details of the relationships between components when we need to analyze the security of the system.