- 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
Examples of System Architecture
As we have suggested previously, different answers to different issues can result in very different system architectures. In this section, we look at four different architectures and discuss how they are constructed. The four architectures are a Web server with an order form, an approach to distributed transactions originally created at Open Market, a large-scale federated commerce system, and an approach to business-to-business commerce originally developed by the Open Buying on the Internet (OBI) Consortium. There are, of course, many other approaches to Internet commerce; we chose these to illustrate many of the points discussed in this chapter.
For analysis of architecture, we have found it convenient to consider four primary components of Internet commerce systems.
Client
The client is a computer system, typically a personal computer, connected to the Internet either directly, through an Internet service provider (ISP), or indirectly, through a corporate network. The buyer uses the client computer for browsing and purchasing.
Merchant
The merchant is the computer system or systems that contain the seller's electronic catalog and, in the case of online goods, products for over-the-Net fulfillment.
Transaction system
The transaction system is the computer system or systems that process a particular order and that are _responsible for payment, record keeping, and other business aspects of the transaction.
Payment gateway
The payment gateway is the computer system that routes payment instructions into existing financial networks such as for credit card authorization and settlement.
Various architectures use these four components in different ways. In some systems, some of these components are combined into a single computer system, whereas in others these four system components are implemented by separate computer systems.
Once the designers of a commerce system have selected a gross division of function, there are still many decisions to be made at lower levels of functionality. For example, the order aggregation function, which permits the assembly of individual items into a complete order, can be implemented as part of the merchant, the transaction system, or the client.
Web Server with Order Form
Building a Web server with catalog pages and an order form is one of the simplest ways to construct an Internet commerce system. This approach is typically called a merchant server. A diagram of a representative system is shown in Figure 6-1, and a logical _diagram of the structure of the merchant server is shown in Figure 6-2. Many of the technical details will become clearer as we discuss the technology in later chapters, but we will sketch the basic ideas here.
)
FIGURE 6-1. Merchant Server: Physical View
)
FIGURE 6-2. Merchant Server: Logical View
In this example, a single Web server provides both the catalog content and the order form. In other words, the merchant server and transaction server are combined into one system, and there is no explicit payment gateway. The catalog might consist of a set of Web pages describing items for sale, with embedded pictures, drawings, specifications, video or audio clips, and so on. The Web pages might be created as static pages using an HTML editor, or they might be created dynamically from a database of items and descriptive information. Next to each item is a button that the customer can click to buy the item or add it to a shopping cart for later checkout. When ready to buy the item (or items, if more than one is present in a shopping cart), the customer clicks a Checkout button that starts the payment part of the transaction.
Payment by credit card is by far the most common method used on the Internet today for consumer transactions (as we discuss in detail in Chapter 15). A simple order form might consist of a listing of the items being purchased and a set of fields for the customer to enter credit card payment information, including the card number, the expiration date, and the address for delivering the items, if they are physical goods. The form might also ask for the billing address, because some credit card systems use the billing address as part of the verification of the holder of the credit card.
It is possible, of course, that the Web server might use a different payment mechanism. In the simplest version of this model, the Web client has no special capabilities for commerce, so the commerce application does not require additional software for payment mechanisms. Credit cards, purchase orders, and other kinds of account-based payments may be used with such systems, thus taking advantage of the basic security capabilities common on the Web today.
This basic architecture may be appropriate and sufficient for some kinds of Internet commerce applications. Its primary virtue is its simplicity. On the other hand, it may be more difficult to expand it as the online business grows, or to incorporate new technologies and components as they become available.
Open Market Distributed Commerce Architecture
The core architectural idea of this architecture is to separate the management of content from the management of transactions through a technology called SecureLink. This idea permits multiple catalog servers to share the capacity of a single transaction engine and allows the content-oriented parts of the system to scale independently from the transaction-oriented parts of the system. Separation of these functions allows separate management of several system facilities—most notably, security. This approach also permits service organizations to provide transaction management services on an outsourced basis for other companies. Figure 6-3 shows the physical architecture of this approach, and Figure 6-4 shows how functionality is distributed across different elements of the system. In this architecture, the transaction server is separated from the merchant server, and there may or may not be a separate payment gateway depending on which payment methods are supported.
)
FIGURE 6-3. Open Market Distributed Commerce Architecture: Physical View
)
FIGURE 6-4. Open Market Distributed Commerce Architecture: Logical View
Federated Commerce System
A federated commerce system (FCS) is a system made up of servers operated by different organizations and tied into an overall, perhaps global, commerce system by Web services and a collection of service agreements. In this system, consumers are members of communities of interest, which provide authentication services and customer service points of presence. When a consumer buys something, the necessary payment and shipping information is routed from her home community to the seller. The seller may also use some of the federated services for payment and other functions. At the conclusion of the transaction, a record is posted to the consumer's online statement held by her home community. From the consumer's point of view, only the home system is responsible for keeping online information. The essential architecture of this system is shown in Figure 6-5.
)
FIGURE 6-5. Federated Commerce System
The federated commerce system includes
Clearinghouse
The FCS clearinghouse is responsible for tying the network together. It permits the seller to locate a buyer's home community and helps establish peer-to-peer connections among the various participants.
Customers
Customers browse for information, make purchases, and request customer service.
Home communities
Consumers join home communities on the basis of interests, services offered, or the degree of privacy protections offered.
Sellers
Sellers include merchants, service providers, and publishers.
Payment provider
The payment provider provides support for various payment mechanisms as a Web service. It uses a common interface, which helps make sellers more independent of the payment systems.
Logistics provider
The logistics provider handles shipping, returns, and other services.
We will return to this example in an extended form in Chapter 21.
Business-to-Business Purchasing
A closely related problem is managing purchases between businesses using the In_ternet. One architecture for such systems was proposed by the Open Buying on the Internet (OBI) Consortium, which was formed in 1996 to develop standards in this area. The consortium is a group of buy-side organizations, sell-side organizations, payment organizations, and technology companies that is addressing the problem of business-to-business commerce on the Internet. The core idea of OBI is to split the functionality of the commerce system between buy-side activities and sell-side activities so that each organization manages those functions logically connected to it.
The OBI design is based on a model of business commerce shown in Figure 6-6. In this model, the logical breakdown of activities is to place the customer database, _requisitioner profiles, and approval processes on the buy side, and to place the catalog, order management, fulfillment, and payment activities on the sell side. This structure results in the architecture shown in Figure 6-7. The key idea in OBI relevant to our functional components is the splitting of the transaction server into its sell-side and buy-side parts.
)
FIGURE 6-6. OBI Business-to-Business Purchasing Process
)
FIGURE 6-7. OBI Architecture
In order to make this architecture work, two elements of interoperability are needed between the buy-side and sell-side components: requisitioner authentication and order handling.
Requisitioner authentication
Because the buy-side organization assumes the responsibility in the OBI model for managing the pool of requisitioners, the sell side must have a standardized means of authenticating prospective requisitioners as authorized by the buying organization. OBI uses public-key certificates for this purpose. When the requisitioner browses the supplier catalog, he presents a certificate signed by the buying organization to validate himself. This approach implies that at the time the trading relationship between the companies is set up, the supplier catalog must be configured to accept the certificates.
Order handling
In OBI, the requisitioner builds up an order by interacting with the supplier catalog. That order is then sent in a standardized format called the OBI order request from the sell-side OBI server to the buy side. Once it is there, any necessary approval processes proceed. After the order is finalized, it is returned to the sell side as an OBI order for fulfillment.
The real benefits of the OBI choice of placing functionality can be seen only when there are multiple buy-side companies trading with multiple sell-side companies. When this happens, the buy side is able to manage its requisitioner database and approval system centrally, and it can use those systems seamlessly with multiple trading partners. Similarly, the selling organization can leverage a master catalog and order management system against multiple purchasers. In this ideal situation, information is not duplicated on either side.
Transaction Flow in the OBI Model
In this section, we walk through an OBI transaction. The descriptions in the following list correspond to the numbered arrows in Figure 6-8.
)
FIGURE 6-8. OBI Transaction Flow
The requisitioner uses a Web browser to connect to the buying organization's purchasing server and selects a hyperlink to the selling organization's catalog server.
The selling organization's catalog server authenticates the requisitioner based on a digital certificate and then allows the requisitioner to browse, select items, and check out.
The content of the order is transferred from the catalog server to the selling organization's OBI server.
The sell-side OBI server maps the order into an OBI order request, encapsulated in an OBI object (with optional digital signature), and transmits the order request to the buying organization's OBI server over the Internet.
The requisitioner specifies any necessary annotations to the order, and internal approval processes take place.
The completed and approved order is mapped to an OBI order format, encapsulated as an OBI object, and transmitted back to the selling organization via the Internet.
The selling organization obtains payment authorization, if necessary, and begins order fulfillment.
For additional information on OBI, see http://www.openbuy.org.