ACID is a term coined by Andrew Reuter in 1983, which stands for Atomicity, Consistence, Isolation and Durability.
ACID property is the basic property for transaction processing.
A - atomicity
C - consistency
I - isolation
D - durability
In 2-tier Client/Server systems, the application logic is either burried inside the user interface on the client or within the database on the server.
Example: File servers and Database servers with stored procedures.
Transparency really means hiding the network and its servers from the users and even the application programmers.
This new model of Client/Server consists of thin, protable, "universal" clients that talk to superfat servers. In the simplet form, a web server returns documents when clients ask for them by name. The clients and server communicate using an RPC-like protocol called HTTP.
With a database server, the client passes SQL requests as messages to the database server. The results of each SQL command are returned over the network. The server uses its own processing power to find the request data instead of passing all the records back to the client and then getting it find its own data. The result is a much more efficient use of distributed processing power. It is also known as SQL engine.
These are fully-loaded machines which includes multiprocessors, high-speed disk arrays for intervive I/O and fault tolerant features.
MOM allows general purpose messages to be exchanged in a Client/Server system using message queues. Applications communicate over networks by simply putting messages in the queues and getting messages from queues. It typically provides a very simple high level APIs to its services.
MOM's messaging and queuing allow clients and servers to communicate across a network without being linked by a private, dedicated, logical connection. The clients and server can run at different times. It is a post-office like metaphor.
TP lite, based on stored procedures.
TP heavy, based on the TP monitors.
There is no commonly accepted definition for a TP monitor. According to Jeri Edwards' a TP Monitor is "an OS for transaction processing".
TP Monitor does mainly two things extremely well. They are Process management and Transaction management.
They were originally introduced to run classes of applications that could service hundreds and sometimes thousands of clients. TP Monitors provide an OS - on top of existing OS - that connects in real time these thousands of humans with a pool of shared server processes.
Interprocess communications (IPC)
Local/Remote Interprocess communication
High performance file system
Efficient memory management and
Dynamically linked Run-time extensions.
With a transaction server, the client invokes remote procedures that reside on the server with an SQL database engine. These remote procedures on the server execute a group of SQL statements. The network exchange consists of a single request/reply message. The SQL statements either all succeed or fail as a unit.
In the transaction server, the client component usually includes GUI and the server components usually consists of SQL transactions against a database. These applications are called OLTP (Online Transaction Processing) OLTP Applications typically,
Receive a fixed set of inputs from remote clients.
Perform multiple pre-compiled SQL comments against a local database.
Commit the work and
Return a fixed set of results.
It includes the communication stacks, distributed directories, authentication services, network time, RPC, Queuing services along with the network OS extensions such as the distributed file and print services.
SQL is a powerful set-oriented language which was developed by IBM research for the databases that adhere to the relational model. It consists of a short list of powerful, yet highly flexible, commands that can be used to manipulate information collected in tables. Through SQL, we can manipulate and control sets of records at a time.
With an object server, the Client/Server application is written as a set of communicating objects. Client object communicate with server objects using an Object Request Broker (ORB). The client invokes a method on a remote object. The ORB locates an instance of that object server class, invokes the requested method and returns the results to the client object. Server objects must provide support for concurrency and sharing. The ORB brings it all together.