TP Monitors

In truth, TP monitors are first-generation application servers as well as transactional

middleware products. They provide a mechanism to facilitate the communication between
two or more applications (see Figure 6.12), as well as a location for application logic.
Examples of TP monitors include Tuxedo from BEA Systems, MTS from Microsoft, and
CICS from IBM. These products have a long, successful history and continue to process
billions of transactions a day.

TP monitors (and application servers) are based on the concept of a transaction a unit of
work with a beginning and an end. The reasoning here is that if the application logic is
encapsulated within a transaction, then the transaction either completes or is rolled back
completely. If the transaction has been updating remote resources, such as databases and
queues, then they, too, will be rolled back if a problem occurs.

Transactions have the advantage of being able to break an application into smaller portions
and then invoke those transactions to carry out the bidding of the user, or another
connected system. Because transactions are small units of work, they are easily managed
and processed within the TP monitor environment. By sharing the processing of these
transactions among other connected TP monitors, TP monitors provide enhanced
scalability. They can also perform scalability "tricks," such as threading and database
connection pooling.

There are two major services performed by the TP monitor. On the one side, a TP monitor
provides services that guarantee the integrity of transactions (a transaction service). On the
other side, a TP monitor provides resource management and run-time management
services (an application service). The two services are orthogonal.

TP monitors provide connectors to resources such as databases, other applications, and

queues. These connectors are typically low-level connectors that require some
sophisticated application development in order to communicate with these various
resources. Once connected, these resources are integrated into the transaction and
leveraged as part of the transaction. As a result, they can also recover if a failure occurs.

TP monitors are unequaled when it comes to supporting a high transaction processing load
and many clients. They take advantage of queued input buffers to protect against peaks in
the workload. If the load increases, the engine is able to press on without a loss in response
time. TP monitors can also use priority scheduling to prioritize messages and support server
threads, thus saving on the overhead of heavyweight processes. Finally, the load-balancing
mechanisms of TP monitors guarantee that no single process takes on an excessive load.

By taking advantage of these features, an application can provide performance as well as

availability and scalability.

TP monitors provide queuing, routing, and messaging features, all of which enable
distributed application developers to bypass the TP monitor's transactional features. As a
result, priorities can be assigned to classes of messages, letting the higher-priority
messages receive server resources first.
TP monitors' greatest performance value is in their load-balancing feature, which allows
them to respond gracefully to a barrage of transactions. A perfect example of this
advantage is end-of-the-month processing. As demand increases, the transaction manager
launches more server processes to handle the load even as it kills processes that are no
longer required. In addition, the manager can spread the processing load among the
processes as the transaction requests occur.

detailed structure of tp monitor

Application Coordination Using TP Monitors

ACID properties of transactions

Atomicity

All changes to data are performed as if they are a single operation. That is, all the changes are
performed, or none of them are.

For example, in an application that transfers funds from one account to another, the atomicity property
ensures that, if a debit is made successfully from one account, the corresponding credit is made to the
other account.

Consistency

Data is in a consistent state when a transaction starts and when it ends.

For example, in an application that transfers funds from one account to another, the consistency
property ensures that the total value of funds in both the accounts is the same at the start and end of
each transaction.

Isolation

The intermediate state of a transaction is invisible to other transactions. As a result, transactions that
run concurrently appear to be serialized.

For example, in an application that transfers funds from one account to another, the isolation property
ensures that another transaction sees the transferred funds in one account or the other, but not in both,
nor in neither.

Durability
After a transaction successfully completes, changes to data persist and are not undone, even in the
event of a system failure.

For example, in an application that transfers funds from one account to another, the durability property
ensures that the changes made to each account will not be reversed.

APPLICATION SERVER

The many new products touting themselves as application servers define the fastest-
growing segment of the middleware marketplace. What's interesting about this is that
application servers are nothing new (and TP monitors should be considered application
servers due to their many common features). Most application servers are employed as
Web-enabled middleware, processing transactions from Web-enabled applications. What's
more, they employ modern languages such as Java, instead of traditional procedural
languages such as C and COBOL (common with TP monitors).

Simply put, application servers provide for application logic sharing and processing, and for
connections to back-end resources (see Figure 6.13). These resources include databases,
ERP applications, and even traditional mainframe applications. Application servers also
provide user interface development mechanisms. In addition, they usually provide
mechanisms to deploy the application to the Web platform.

Application server vendors are repositioning their products as a technology that solves
application integration problems (some without the benefit of a technology that works!). This
being the case, application servers, as well as TP monitors, are sure to play a major role in
the application integration domain. Many of these vendors are going so far as to incorporate
features such as messaging, transformation, and intelligent routing, services that are
currently native to integration servers. This area of middleware is in the throes of something
more than an evolution. It is in the throes of a genuine revolution.

Integration servers

Integration servers represent the nirvana of application integration-enabled middleware. At

least, the potential of integration servers represents that nirvana. Integration servers can
facilitate information movement between two or more resources (source or target
applications), and can account for differences in application semantics and platforms. As
such, they are a perfect match for application integration (see Figure 6.14).

Integration servers can also join many applications by using common rules and routing
engines. They can transform the schema and content of the information as it flows between
various applications and databases.

Integration servers, as we have already discussed in previous chapters, are servers that
broker messages between two or more source or target applications. In addition to
brokering messages, they transform message schemas and alter the content of the
messages. They may, indeed, have many additional functions, including a process
integration engine and interface, as well as a management mechanism.
The importance of integration servers is a function of their place within the enterprise. In
general, integration servers are not an application development-enabling technology.
Rather, they are a technology that allows many applications to communicate with one
another without any application necessarily understanding anything about the other
applications it shares information with. In short, integration servers "broker" information
between applications and databases. By doing so, they broker information between the
various source and target systems

Rules Processing

• The rules processing engine provides the ability to create rules to control the processing and
distribution of messages.

• It is an application development environment supported by the message broker to address the special
requirements of integrating applications.

• By using rules engine, it becomes possible to implement intelligent message routing and
transformation.

• The logic for sharing information.

Message Transformation Layer

• The message transformation layer understands the format of all messages being passed among the
applications and transforms those messages while they move.

• It provides a common dictionary that contains information on how each application communicates
outside itself, as well as which pieces of information have meaning to which applications.

Intelligent Routing

• A message broker can identify a message coming from the source application and route it to the
proper target application, transforming it if required.

• Builds on the capabilities of both the rules layer and the message transformation layer.

• This happens virtually instantaneously, with as many as a thousand of these operations simultaneously

Message Mining and Integrity

• Data mining – Allows extraction of business data to support decision making – For example, the
amount and characteristics of new customer information processed through the broker – Rules can be
applied to alter the messages prior the storing, e.g., for the data to make sense to business users

• Message integrity – A persistent buffer or queue for messages on the event of system failures (or for
other reasons) – The messages may be resent or compared with other warehouses on the network to
insure integrity

Adapters and APIs

• API is nothing more than the mechanism that allows an application to access the services of a message
broker.

• Adapters link deeply into an application without having to invoke the native interfaces.

– Layers between the message broker interface and the source or target application

– For example, set of libraries that map the differences between two distinct interfaces – Adapters for
different source and target applications(SAP R/3, Baan, Oracle, PeopleSoft,…)

– Adapters for certain types of databases (Oracle, Sybase, DB2,..)

https://books.google.com.ph/books?id=ezGpef3NaywC&pg=PA135&lpg=PA135&dq=RPCs+are+slow,
+but+their+blocking+nature+provides+best+data+integrity+control&source=bl&ots=dMfEZnGteJ&sig=A
CfU3U0C7b3ok6N1vmiS-
4y9IyzL4abGnA&hl=en&sa=X&ved=2ahUKEwjx2ty_iOnvAhXHdXAKHYbfB40Q6AEwAnoECAIQAw#v=onep
age&q=RPCs%20are%20slow%2C%20but%20their%20blocking%20nature%20provides%20best%20data
%20integrity%20control&f=false