COM+ Programming. A Practical Guide Using Visual C++ and ATL

Enterprise Systems

An enterprise system typically consists of different programs on different computers interacting with each other. It is a large application, at least compared to a single desktop application, and typically integrates with databases. These applications are generally used in large organizations, and are accessed by hundreds of clients simultaneously.

Historically, developing enterprise systems has been a very long and very expensive process. This is primarily because of the requirements developers had to meet. Let s examine some of those requirements.

Security

Almost all enterprise applications care about security issues. Following are some security requirements:

• The application has to ensure that only authorized users can access the system.

• Some people have more privileges than others in accessing the system. The application has to maintain a table of individuals and their roles in accessing the system.

• The application has to authenticate the users, that is, verify that the users are indeed the ones they claim to be.

• If any sensitive information is being sent from one computer to another, the application has to provide some level of data encryption to prevent hackers from tapping the wire. The level of encryption increases with the sensitivity of the information.

Scalability

An enterprise system has to be designed such that hundreds of clients can access it concurrently, yet each client request should be serviced in a reasonable amount of time. Some requirements are as follows:

• The client load can frequently cause the application to outgrow a single computer. The application should provide some form of load balancing between multiple computers.

• If a database is frequently accessed, the application has to cache data, such as back-end tables in memory, to improve performance.

• In case of distributed computing, the application should continue to work even if the remote computer is not accessible.

• Frequently, just one instance of an application component is not enough to handle the client load. For such cases, the application has to create a pool of multiple instances of the component.

Sharing Resources

A resource such as a database table or some in-memory state of a component is often shared among many subsystems of an enterprise system. In such cases, the requirements are as follows:

• If two subsystems, or two instances of the same component, try to modify a resource concurrently from multiple threads, it may produce some inconsistency in the state of the resource. The application has to ensure the consistency of the data, perhaps by ensuring that only one subsystem can modify the data at a time.

• The application has to be designed such that a deadlock does not occur when two subsystems wait on each other for releasing a resource.

Transactions

An enterprise application typically deals with multiple databases. A transaction may require more than one database to be updated. However, if the update succeeds on one database and fails on another, the system may get into an inconsistent state. The possibility of this happening is pretty good, considering that the databases may reside at geographically dispersed locations, and given that power and network outages are facts of life.

A transaction must be such that it entirely succeeds or entirely fails. However many different operations the transaction involves, either everything must be updated successfully or nothing should be updated. This all-or-nothing proposition of a transaction is called atomicity.

Besides atomicity, a transaction has to meet three other requirements: consistency, isolation, and durability. These requirements are typically referred to as ACID rules (A = Atomicity, C = Consistency, I = Isolation, and D = Durability).

An enterprise system has to treat various operations across multiple databases as a single transaction and ensure the integrity of the system by meeting the ACID rules.