Application Integration Technology IT 490

Middleware Basics  Middleware provides a mechanism that allows one entity (application or database) to communicate with another entity or entities.  Middleware is the best hope for moving information between applications and databases. Unfortunately, traditional middleware as it exists today (Remote Procedure Calls – RPCs, Message Oriented Middleware-MOM) can provide connections between applications, but in order to facilitate the use of middleware, changes to the source and target systems become unmanageable and inflexible.

Middleware Basics  New types of middleware came into play, including application servers and message brokers.  As a definition, middleware is basically any type of software that facilitates communications between two or more software systems.

Types of Middleware: - RPCs  the oldest type of middleware but they are the easiest to understand and use. Basically RPCs provide developers with the ability to invoke a function within one program and have that function actually execute within another program or another remote machine

- RPCs are synchronous. They stop the execution of the program in order to carry out remote procedure calls. Because of this, RPCs are also knows as blocking middleware. - Because carrying out a remote procedure call requires a lot of overhead in the systems, RPCs require more bandwidth than any other types of middleware. Fig. 7.2 RPCs: Local Functions Executing on Remote Machines

- The best known type of RPC is Distributed Computing Environment (DCE) from Open Software Foundation (OSF). It provides a very sophisticated distributed RPC mechanism with many layers of services (such as security services, directory services, and the ability to maintain integrity between applications). - DCE requires a lot of overhead so the performance of such system is very poor. - The main RPC advantage is the simplicity of the systems and integration. The main disadvantage is their requirement for more processing power. - RPCs require anywhere from 10,000 to 15,000 instructions in order to process a remote request. All these add to the cost of the overhead.

- Message-Oriented  MOM was created to address some shortcomings of RPCs through the use of messaging. Traditional MOM is typically queuing software, using messages as a mechanism to move information from point to point. - Because MOM uses the notion of messages to communicate between applications, direct coupling with the middleware mechanism and the application is not required.

- MOM products use an asynchronous paradigm and because it’s decoupled from the application, they allow the application to function independently. - The asynchronous paradigm is much more convenient for developers and users because it does not block the application from processing, although the model is a bit more complex than the synchronous model.

- MOM is able to ensure delivery of a message from one application to the next through several sophisticated mechanisms, such as message persistence. - The use of messages is also an advantage because messages are small byte-sized units of information that move between applications.

- Messages have a schema (structure) and data (content). - There are two models supported by MOM: 1. Point-to-Point 2. Message Queuing (MQ)  this has several advantages over standard RPCs. First of all MQ lets each participating program proceed at its own pace without interruption from the middleware layer. Another benefit to MQ is that the program can broadcast the same message to many remote programs without waiting for the remote programs to be up and running.

- Distributed-Objects  are also considered middleware because they facilitate inter- application communications. But at the same time they are also mechanisms for applications development, providing enabling technology for enterprise-wide method sharing. - Distributed Objects are really small application programs that use standard interfaces and protocols to communicate with one another

- There are 2 types of distributed objects on the market today: CORBA (created by OMG in 1991 is more of a standard than a technology) and COM (created by Microsoft, is a distributed object standard). Just like CORBA, COM provides rules for developers when creating COM-enabled distributed objects.

- Database-Oriented  is any middleware that facilitates communications with a database, whether from an application or between databases. Developers use them as a mechanism to extract information from either local or remote databases.

- They work with 2 basic database types: a) call-level interface (CLI) b) at-native database middleware - While CLIs provide access to any number of databases through a well defined common interface and are common APIs that span several types of database, they work most typically with relational databases (for example Microsoft’s ODBC) Fig. 7.6 Microsoft’s OLE DB

- Transaction-Oriented  (for example TP monitors and application servers) do a pretty good job at coordinating information movement and method sharing between many different resources. Typically it creates a tightly coupled EAI solution, where messaging solutions are more cohesive in nature. In addition, the source and target applications will have to be changed to take advantage of this transactional middleware. - TP Monitors  are the first generation applications servers and a transactional middleware product. They provide a location for application logic in addition to a mechanism to facilitate the communication between 2 or more applications - TP monitors are based on the premise of a transaction  is a unit of work with a beginning and an end. The reasoning is that if application logic is encapsulated within a transaction, then the transaction either completes or is rolled back completely.

- An advantage of using transactions is the ability to break an application into smaller portions and then invoke those transactions to carry out the binding of the user or another connected system. - TP monitors provide connectors that allow them to connect to resources such as databases, other applications and queues. - 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 messages receive server resources first. - TP monitors’ real performance value is in their load- balancing feature, which allows them to respond gracefully to a barrage of transactions.

- Application Servers  is not new but is the fastest growing segment of the middleware marketplace and it’s defined by the many new products calling themselves applications servers. - Most Application Servers are employed as Web-enabled middleware, processing transactions from web-enabled applications. They also employ Java rather than traditional procedural languages like C or COBOL (which are common with TP monitors) - Application Servers are servers that not only provide for the sharing and processing of application logic, but they also provide connections to back-end resources. - These resources include databases, ERP applications and even traditional mainframe applications. They also provide user interface development mechanisms.

- Message Brokers  can facilitate information movement between two or more resources (source or target applications) and can account for the difference in application semantics and platforms. Message Brokers can also join many applications using common rules and routing engines. They can transform the schema and content of the information as it flows between various applications and databases.

Middleware Models - The Logical Middleware Model  depicts how the information moves throughout the enterprise conceptually. - The Physical Middleware Model  depicts how the information actually moves and the technology it employs. - There are a few messaging models we will look at in order to understand the physical middleware model: - One-to-One vs Many-to-Many  Middleware can work in a point-to-point as well as many-to many configurations - 1. Point-to-Point Middleware  allows one application to link to one other application via a simple pipe. When communication is desired, the two applications communicate via the pipe using a procedure call or message (see Fig. 7.10)

- While it is possible at this time to connect together more than 2 applications using traditional point-to-point middleware, doing so will generate a chaos inside the network because of the redundant point to point connections

- Many-to-Many Middleware  links multiple applications to many other applications. That’s why this is the best fit for EAI and is the current trend in the EAI world. It is also the most powerful logic middleware model in that it provides both flexibility and applicability to the EAI problem domain.

3. Synchronous vs. Asynchronous: - Asynchronous Middleware moves information between one or many applications in an asynchronous mode-that is, the middleware software is able to decouple itself from the source or target applications and the applications are not dependent on the other connected applications for processing. A major advantage is that the middleware will not block the application for processing. - Synchronous Middleware is tightly coupled to applications and the applications are dependent on the middleware to process one or more function calls at a remote application. As a result the calling application must halt processing in order to wait for the remote application to respond  this is called “blocking” middleware.

4. Connection-Oriented and Connectionless - Connection-oriented communications  two parties connect, exchange messages and then disconnect. This is a synchronous process usually but sometimes can be asynchronous. - Connectionless communications  the calling program does not enter into a connection with the target process.