The system is divided into three logical layers:

	TC/4 branch delivery system (TC/4-DS): A GUI-based front-end delivery system (presentation layer) for the end-users to access the system.
	Transaction management sub-system (TMSS): A Unix / Linux-based back-end system (middleware) which manages transactions from business units (TC/4-DS) and other third party interfaces. This powerful utility ensures high scalability in terms of business units and transaction volumes. TMSS supports multithreaded transactions with a two-phase commit and ensures complete data integrity. A transaction may consist of two or more segments (debits and credits) and even if one of these segments fail, the entire transaction is rolled back. The TMSS system also ensures zero proofing of all transactions.
	Applications servers (TC/4-AS): These have the business logic; they are written in embedded SQL, and talk to the Oracle RDBMS. There are a set of applications servers to process transactions from various modules such as deposits, loans, general ledger, etc. Scalability in transaction volumes is achieved by automatically starting multiple instances of the desired application server. It has a powerful end-of-day scheduler to process a high volume of transactions and accounts, and uses various fragmentation and parallelism techniques to optimise the EOD processing time.

The middleware has been used only on the central host to minimise the cost of ownership. CMC has developed the communication software that connects the branch system with the central system. It uses a communication gateway system (CGS) at the branch, which connects with the branch workstations on one side and the central host on the other side. The CGS acts as a switch, and thereby reduces the active connections from branch workstations directly with the central host. It also provides security and privacy by encrypting the messages and compressing them for better bandwidth utilisation.

The TC/4 system is message-based (based on standard APIs, or application programming interfaces). Transactions from the workstations are transformed into messages and sent to the host. This framework allows an easy interface to any external system. The message-based architecture drastically reduces the response time and bandwidth requirements for the system. Typically, a TC/4 branch can work well on any communication media available at the branch (leased line, radio links, VSAT, ISDN, dial-up, etc).

TC/4 supports 24 X 7 availability by using the concept of main and shadow databases. This allows 'next day' transactions when the central system is processing 'end-of-day' scheduling. Therefore, it is not necessary to bring down the TC/4 application for the purpose of batch processing.

Parallel batch processing gives a better performance during EOD, thus reducing the duration of end-of-day processing. Individual processes handle multiple fragments of data. The front-end application database resides on the branch server. A facility for posting a limited set of transactions at the branch exists even when the central host is offline. Information flow between the front-end and the central host follows push / pull approaches (depending on the type of information). The front-end database stores the basic static data, transaction logs, and some information about customers and accounts (for off-line processing).

All aspects of database backup and recovery are handled by using the concept of disk mirroring and automated media backup approach. The TC/4 architecture and design allow easy integration with third party interfaces using standard APIs. The message formats and message APIs can be made available to interface external sub-systems or other third party products. Facilities like multi-language support are also available.

	Lower user response time
	High scalability
	Decreased network traffic
	Load levelling
	High security
	Fail over and disaster recovery system (DRS)
	Easy maintainability

TC/4 summary

TC/4 features

NOTES
Multithreaded transactions: One transaction having multiple sub-tasks or sub-activities, so that sub-tasks can be executed simultaneously.
Two-phase commit: If one transaction has multiple sub-tasks so that all sub-tasks have been committed except one. In such cases the sub-tasks which have been committed earlier will be rolled back to their previous states. This is known as a two-phase commit.
Zero proofing: Ensuring complete data integrity.