38

CHAPTER 7

Deployment Architecture

For most organizations, the following three options exist in regard to deploy-ment architecture.

7.1 TWO-TIERED CLIENT–SERVER ARCHITECTURE

In this type of architecture, two computer nodes are connected by a networkto do the work. The node that an end user uses is called Client. It providesgraphical user interfaces (GUIs) and event handling for user interactions. Inmany cases, it also has some business logic. This type of client is called richclient (or thick client, fat client). Client machines are typically desktop ornotebook PCs with a Microsoft Windows operating system. Some organiza-tions still use Macintosh or Unix workstations, and Linux is an emergingalternative. The backend node in the client–server architecture is the databaseserver. The chemical information database resides in this node. It may alsohost some business logic that is shared by all clients in a client–server archi-tecture. The business logic on the server node is typically implemented asdatabase triggers and stored procedures. In a chemical information applica-tion, a chemical registration application puts compound data into thedatabase, and a querying and browsing application gets the data out of thedatabase and presents the data to end users.

Figure 7.1 illustrates a client–server architecture.The biggest advantage of client–server architecture is probably its sim-

plicity. Because the client process can be single threaded, you do not need toworry about issues such as thread safety and deadlocks. The reliabilityrequirements are also not as stringent because although crashing or hangingof a single client machine is not desirable, it is not fatal to the overall systemas long as the server node is safe.

Developing Chemical Information Systems: An Object-Oriented ApproachUsing Enterprise Java, by Fan LiCopyright © 2007 John Wiley & Sons, Inc.

JWUS_Dcis_Ch007.qxd 10/13/2006 4:30 PM Page 38

THREE-TIERED (OR MULTITIERED) ARCHITECTURE 39

The client-server architecture imposes several limitations. First, the com-puting power (CPU, memory, IO) of the client machine is limited. A designerhas to carefully balance what business logic should reside on the clientmachine versus what business logic should reside on the server machine.Second, the resource utilization is not efficient because every client keeps aconnection to the database server. Third, deployment is a big burden becauseevery upgrade requires a new installation on all client machines. Fourth,although it does not happen very often in the chemical information spacebecause Oracle is overwhelmingly dominant, business logic implemented asdatabase stored procedures and triggers is not portable from one databasemanagement system (DBMS) to another.

7.2 THREE-TIERED (OR MULTITIERED) ARCHITECTURE

A three-tiered architecture includes one more node between the client and thedatabase server—the middle tier. In a three-tiered architecture, business logicis offloaded from the client and the database server nodes to the middle tier.In fact, you can choose to further distribute the business logic among morethan one middle tier node and still call it a three-tiered (or n-tiered) architec-ture because the idea is similar. Note that the tiers do not have to be physi-cally separated. You can have both the middle tier server and the databaseserver collocated on the same physical computer but running in differentprocesses with separate memory spaces. Modern hardware architecture canpartition a single hardware box into multiple virtually separate computers ordomains. Typically, a three-tiered architecture supports a Web-based thinclient although it can also work with a rich client.

Figure 7.1 A client–server architecture.

Client

Server

JWUS_Dcis_Ch007.qxd 10/13/2006 4:30 PM Page 39

Figure 7.2 illustrates a three-tiered architecture.The three-tiered architecture turns the disadvantages of the client–server

architecture into its advantages:

• The computing power of the middle tier is virtually unlimited. When itreaches its limit, by simply adding more hardware, the system should getback on track assuming the scalability of the software is good.

• Expensive system resources can be more effectively managed. Forexample, the middle tier can create a pool of database connections thatis shared by all clients. It can also implement a complex data cachingcapability to boost performance.

• It provides better performance for systems with high user load. • If a Web-based thin client is used, there is no client deployment needed.

The updated system is deployed to the middleware only, and the clientscan access it easily with a URL from a Web browser.

These advantages are not free. Three-tiered architecture has many chal-lenges:

• The three-tiered architecture is much more complex than a client–serverarchitecture.

• The infrastructure and development cost of three-tiered architecture ishigher than client–server.

• Because the middle tier handles concurrent requests from many usersessions, architects and developers are forced to consider threadingissues that are considered difficult for many junior developers.

• Session management has to be implemented to make sure every userstate is maintained between method calls.

40 DEPLOYMENT ARCHITECTURE

Figure 7.2 A three-tiered architecture.

Client

Database Server

Middle Tier Server

JWUS_Dcis_Ch007.qxd 10/13/2006 4:30 PM Page 40

• Because more networked layers are introduced, performance may sufferif the architecture is not designed properly.

A more robust solution is to introduce a load balancer between the clientsand a farm of identical middle tier servers. The load balancer routes requeststo one of the middle tier servers based on the load and netweork topology. Ifone middle tier server fails, it can reroute the request to another to preventsingle point of failure (fail-over). This architecture requires that the servers inthe middle tier farm synchronize user sessions with each other in case one hasto take over a client from another.

Figure 7.3 illustrates a three-tiered architecture with a load balancer.By the same token, the database server can also be clustered, which is not

illustrated in Figure 7.3. Both client–server and three-tired architectures can be developed using

either Java or .NET technology, although .NET is a more natural choice for arich client on Windows-based client PCs. It is also possible to take a hybridapproach—develop rich client in .NET but business logic in Java, and inte-grate both using SOAP-based Web services. MDL’s Isentris, for example,takes the hybrid approach.

Which architecture to choose should be determined on a case-by-casebasis. No single architecture fits all situations. Each organization shouldcarefully evaluate the pros and cons of each architecture and make decisionsbased on requirements, budget, technical expertise, infrastructure, technologystandards, and so on.

THREE-TIERED (OR MULTITIERED) ARCHITECTURE 41

Figure 7.3 A three-tiered architecture with a load balancer.

Workstations

Load Balancer

Middle Tier

Database Server

MiddleTier

JWUS_Dcis_Ch007.qxd 10/13/2006 4:30 PM Page 41

This book focuses on a three-tiered architecture, on which Enterprise Javais based.

7.3 SERVICE-ORIENTED ARCHITECTURE

Service-oriented architecture (SOA) is a hot topic these days and is consid-ered by many people to be the enterprise computing framework of the future.In SOA, each software unit runs on a piece of hardware as a service that canbe called by many different consumers. For example, a compound registra-tion service can be called by a library enumeration tool and a chemistry e-notebook to fulfill compound registration tasks. The most popular SOA isWeb services that are based on HTTP and XML or SOAP standards althoughSOA as a concept has existed for awhile and is not limited to Web services.SOA has a lot of advantages, the most important of which is code reuse andimproved productivity. However, it also presents a lot of challenges.

There are two types of code reuse; one is code libraries that are deployedwith every single application that uses them. Another is services that aredeployed and run independently somewhere in the network. The notion ofdesigning with SOA in mind is very important. Service is not about simplywrapping a piece of code that is designed for a standalone application with aservice API and exposing it to the public. It represents unique requirementsand challenges such as the following:

• Security: Transparent authentication and authorization across applica-tion boundaries.

• Performance: In general, a service performs more poorly than an in-process method call due to network latency and bandwidth constraints.To make things worse, a service may call other services to fulfill itsresponsibilities—a chain of services. Performance has to be a designconsideration throughout the development cycle.

• Availability and scalability: A service does not know how many clientswill use it and when. It has to be very resource efficient and able to han-dle unpredictable user load. Caching and resource pooling should beused more widely in these systems. It should also be deployed into aclustered environment. There also must be a monitoring and alertingmechanism to make sure it is always in a healthy state.

• Make sure distributed transactions are atomic. • A service also poses challenges to its clients: The clients have to be able

to recover themselves if the service or network goes down.

All of these requirements require diligent design and rigorous testing.SOA will not be a reality without these issues being addressed.

42 DEPLOYMENT ARCHITECTURE

JWUS_Dcis_Ch007.qxd 10/13/2006 4:30 PM Page 42