Types of Middle Ware

Types of Middleware There are several different categories of middleware. The most common are: Transactional Middleware Message-oriented Middleware RPC

Each of these types of middleware addresses five basic requirements in their analysis. They are: Network Communication requires the transformation of the complex data

structures into a suitable format, which can be transmitted using transport protocols. These transformations are called marshalling and unmarshalling. Coordination required to control multiple communication points, which

exist in distributed systems. The Synchronization and Activation mechanisms are used to aid in coordinating middleware objectives. Reliability There are several types of reliability. Best effort service, where

requests do not give any assurance of the execution of the request. At-most-once service where requests execute only once but may not execute at all. At-leastonce service requests are guaranteed to be executed once, and may be executed multiple other times. Exactly-once service, where requests are executed a single time, no more, no less. Error detection and correction mechanisms are need to reduce the unreliability caused by errors. There is also a trade-off between middleware performance, and reliability. Scalability How well a software system can adapt to a changing

environment and demands. The main task of scalability is to provide changes in the distributed system without changing its architecture or design. A scalable middleware needs to be able to support several types of transparencies, which are:

1

Access Transparency, Location Transparency, Migration Transparency, and Replication Transparency. Heterogeneity How diverse the components of a distributed system are.

When there are differences in anything from hardware, operating system platforms, and programming languages, the middleware must resolve them Transactional Middleware Transactional Middleware 1. Introduction 2. TP Monitor 3. Requirements: 4. Transactional Middleware Advantages: 5. Transactional Middleware disadvantages include: 6. Other features of Transactional Middleware 7. XA and X/Open 8. Building Transactions 9. Application Servers 10. Evolving Transactions 11. Future of Transactional Middleware 12.Examples 1. Introduction The main function of Transactional Middleware is the coordination of requests between client and servers that can process these requests. The Transactional Middleware then clusters the requests into groups of similar items called transactions Transactional middleware, which includes TP monitors and application servers, provide benefits to distributed computing and EAI that cannot be found in traditional development tools.

2

2. TP Monitor Transaction Processing or TP Monitor is a control program that monitors, controls and manages a transaction as it passes from one stage in a transaction process to another through various local and remote terminals and various application programs ensuring that the transaction process is completed and the transaction is not lost in between. The TP monitor ensures that all databases are updated from a single transaction. The TP monitors also handle the load balancing operations in the three-tier architectures where the transaction is forwarded to the available or the idle server. These transactions must follow ACID (Atomic, Consistent, Isolated, and Durable) properties. Atomic ensures that transactions are processed in an all or nothing basis. If there are any problems with the data, the entire transaction will be dropped. Consistency holds the system in a constant state, regardless of the status of on-hand transactions. Isolation is the ability of one transaction to work independently from other transactions that have come from the same TP monitor. Durability is the ability of a complete transaction to survive if there are any system failures. Transactional Middleware controls transactions from beginning to end, from client to the resource server and then back again. 3. Requirements: Network Communication Requests are transported via the network and client and server components can be established on different hosts.

3

Coordination Synchronous and asynchronous communication are supported, which allows for more coordination when executing requests. Decreased application downtime with support failover and restart capabilities. Reliability Transactions only take places if both parties are ready to commit; if they are not ready, the transaction will be aborted. This can increase reliability, however it causes performance problems. The failure/recovery service increases fault tolerance, which in turn increases reliability. Scalability Load balancing and replication allows for increased scalability. The system allows multiple transactions to be run simultaneously, which provides shorter and more consistent response times for a large number of transactions. Heterogeneity Supports hardware and software heterogeneity however does not support data heterogeneity because it cant express complex data structures. 4. Transactional Middleware Advantages: Scalability Fault Tolerance Reliability Centralized application processing architecture provide virtual systems and single logon capabilities and in many cases, has the ability to reduce the overall system cost. ensures delivery of information from one application to the next and supports a distributed architecture (see Fig. 8.1)

System Stability and Consistency TP monitors perform better than other types of middleware TP monitors can dispatch, schedule and prioritize multiple cost for applications. Well established standards based technology

4

Built specifically to support transactions Help minimize the use of resources for transaction processing

5 Transactional Middleware disadvantages include: None of the TP monitors or application servers that exist today support either outof-the-box content transformation or message transformation services, at least not without programming. Transactional middleware requires that complex applications be divided into small size units called transactions. Transactional middleware controls transactions from their beginning to their end, from the client to the resource server and then back again.

Limited User/Client Capacity Less platform compatibility (only UNIX and NT server) Reduced data portability Rely on the 2 phase commit protocol to manage transactions Less flexible than message queuing for applications that dont require transactional integrity No support for asynchronous communication

6. Other features of Transactional Middleware Scalable Development Transactional middleware processes transactions on behalf of the client or node and can route transactions through many diversified systems, depending on the requirements of the EAI problem domain.

5

It also provides load balancing, thread pooling, object recycling and the ability to automatically recover from typical system problems. Database Multiplexing is one of the main benefits of transactional middleware. It has the ability to multiplex and manage transactions that result in the reduction of the number of connections and processing loads that larger systems place on a database. With transactional middleware in the architecture, it is possible to increase the number of clients without increasing the size of the database server. By funneling the clients requests, transactional middleware removes the process per client requirements (see Fig. 8.4)

Load Balancing When the number of incoming client requests surpasses the number of shared processes that the system is able to handle, other processes start automatically. Some transactional middleware can distribute the process load over several servers at the same time dynamically or distribute the processing over several processors in multiprocessing environments. This load balancing feature of transactional middleware also enables transactional middleware to prioritize. Fault-Tolerant Transactional middleware was built from the ground up to provide a robust application deployment environment with the ability to recover from any number of system related problems. Transactional middleware provides high availability by employing redundant systems.

6

The transactions work through a two-phase-commit protocol to ensure that the transactions complete and to guard against transactions becoming lost electrons when hardware, operating systems, or network fail. Communications Transactional middleware provides a good example of middleware that uses middleware, which includes message brokers. It communicates in a variety of ways, including RPCs, distributed dynamic program links (DPLs), inter-process communications, and MOM. Because transactional middleware is simply an API within an application, developers have the flexibility to mix and match all sorts of middleware layers and resource servers to meet the requirements of an application or EAI problem domain. 7. XA and X/Open The standards that define how transactional middleware functions are the International Standards Organizations (ISO) and X/Opens Distributed Transaction Process (DTP) specifications. The outcome was XA Interface which defines how a transaction manager and a resource manager (such as a database) can communicate. The XA Interface is a set of function calls, split between the transaction manager and the resource manager. Among the features XA provides are those functions provided by the transaction manager, which allow the resource manager to tell the transaction manager whether it is ready to work with a transaction or whether it is in a resting state and unable to respond. 8. Building Transactions Building transaction services simply requires that you programmatically define the functions that the service will perform when accessed by the required TP monitor APIs. 9. Application Servers They not only provide a location for application logic, they also coordinate many resource connections (see Fig. 8.5) Application servers were created for web based transactions and application development, but their usefulness to EAI is obvious, given the back end integration capabilities (their ability to bind together several source and target applications through a series of connectors provided by the applications server vendors-for example SAP, PeopleSoft, relational databases and middleware)

7

10. Evolving Transactions The benefit of applications servers is clear. By placing some, or most, of the application logic on a middle tier, the developer can insert increased control over the application logic through centralization. Such a placement increases the ability to scale the application through a set of tricks, such as database multiplexing and load balancing. The end result is a traditional 3-tier client/server computing model.

Fig. 8.6 Application Architecture, using an application server

8

11. Future of Transactional Middleware TP monitors will remain the dominant transactional middleware because they provide the best mix of standards, scaling features and reputations Traditional TP monitor environments, as well as the new line of Java-enabled application servers, will provide to be the best place for EJB. The coupling of transactional middleware with EAI is clear. EAI problem domains that need to support transactions between applications, share logic as well as data, and are willing to incur cost of changing all connected applications, are perfect for transactional middlewaretype solutions. 12.Examples i. IBM CICS ii. IBM IMS iii. Digital ACMSxp

9

Message-Oriented Middleware 1. Introduction 2. What is MOM? 3. Types of MOM model 4. Requirements: 5. Message-Oriented Middleware Advantages 6. Message-Oriented Middleware Disadvantages 7. Examples

1. Introduction Message-Oriented Middleware is software that connects separate systems in a network by sending and receiving messages from both parties.

2. What is MOM Message Oriented Middleware (MOM) makes it possible for applications to communicate with each other through messages, which are usually asynchronous. MOM doesnt use an Interface Definition Language to specify operations and parameters. Messages are strings of bytes The messages can contain data, software instructions, or both. Once a message is sent from a network component to the server, the server responds with another message containing the results of the service execution. Message-Oriented Middleware infrastructure is normally built around a queuing system. This system stores messages that are awaiting delivery and keeps track of whether and when they have been delivered. The developer uses an API to send and receive messages.

10

MOM-Based System MOM-based systems allows communication to happen through the asynchronous exchange of messages, The basic elements of a MOM system are clients, messages, and the MOM provider, which includes an API and administrative tools. The MOM provider uses different architectures to route and deliver messages: it can use a centralized message server or it can distribute routing and delivery functions to each client machine. Some MOM products combine these two approaches. Once it has sent the message, the client can continue to do other work, confident that the provider retains the message until a receiving client retrieves it. The message-based model, coupled with the mediation of the provider, makes it possible to create a system of looselycoupled components. The underlying MOM is unaware of the content of the messages, and does not perform any translations or manipulations on the messages. Most MOM products support several network protocols. 3. Types of MOM model MOM products support one or more of the following communication models: i. Message Passing ii. Message Queuing iii. Publish and subscribe Message Passing, a direct program-to-program communication model. Allows instructions and requests to be passed directly between 2 applications in the form of messages, which may contain either data or control information. Message passing may be either synchronous or asynchronous, but it is always connection oriented (ie: a logical connection must be formed between the 2 applications using message passing). Advantages: a.Supports both synchronous and asynchronous communication b. Works well for event driven transactions Disadvantages:

11

a. Lacks standards b. Connection oriented nature makes it a poor choice for loosely coupled time independent applications [ISG 13] II. Message Queuing, an indirect program-to-program communication model that allows applications to exchange messages via a message queue. Message Queuing allows applications to communicate through the use of message queues instead of having to send messages directly from application to application. This allows 2 applications communicating via message queues to run independently at their own rate while still insuring that requests are fulfilled. This makes message queuing asynchronous and connectionless by nature.

Advantages: a. Support for a range of QoS levels b. Can provide limited support for transaction processing c. Can provide support for triggers and network session concentration which can limit the amount of resources used Disadvantages: a. Lack of standards b. Can only support transactions that occur in the message queues which it manages

III. Publish & Subscribe, also called the event model; in this model clients and servers communicate only though event channels and are unaware of each others existence. Publish and Subscribe: Breaks out of the current client/server model by allowing computers to be either publishers who offer data or subscribers who consume the data. Publish subscribe helps to maximize communications efficiency because publishers do not need to

12

receive requests from clients. When a publisher changes its data offerings, the data is automatically collected by all subscribers who are interested in it. This allows for a high degree of dynamic reconfiguration in publish/subscribe systems.

Advantages: a. Provides for rapid and b. Can minimize resource usage c. Systems do not need to even Disadvantages a. Does not support transactions

dynamic system through the use be aware of each

reconfiguration of multicasting others existence.

b. Does not support traditional client/server request/reply type application architectures c. Does not support synchronous communication Examples i. Message passing: 1. PeerLogic PIPES 2. Aspen Systems MPI/Pro ii. Message Queuing 1. BEA systems DecmesageQ 2. IBM MQSeries 3. Microsoft MSMQ iii. Publish / Subscribe 1. RTI NDDS 4. Requirements: Network Communication Based on messages. Messages are strings of bytes, and are therefore easily transported across the network. Coordination Supports both synchronous and asynchronous communication. Supports activation on demand when a request is received it automatically starts the application program, decreasing the required resources to execute requests. Reliability Supports Quality of Service which ensures reliable message delivery, guaranteed message delivery, and non-duplicate message delivery. Scalability Location transparency is supported, however, access transparency has limited support which translates into a lack of migration and replication transparency. This causes 13

scalability to increase in complexity. Hard-coded queues lead to inflexible and poorly adaptable architectures. Heterogeneity Marshalling is not supported unless added by programmers, therefore data heterogeneity is limited. 5. Message-Oriented Middleware Advantages Atomic Group Communication Either all clients receive a message, or none. This eliminates missing data in the clients affected by the failed messages. Persistent message deliveries increase reliability High product support from vendors are common Supports many network protocols Precise message deliveries decrease redundant messages, therefore increasing reliability even further. a messaging provider mediate messaging between clients is that by adding an administrative interface, you can monitor and tune performance. 6. Message-Oriented Middleware Disadvantages Limited scalability and heterogeneity Poor portability and product standards Limited Message-Oriented Middleware to Message-Oriented Middleware

compatibility Centralized server Translated into a single failure point Limited capacity of communication links

7. ExamplesExamples of MOM systems are Oracle Advanced Queueing, Arjuna Messaging, IBM MQSeries, and Microsoft MSMQ.

14

1.1

Remote Procedure Call

RPCs are not procedure calls at all, they are truly process invocations. The invoked program runs across the wire in a different resource domain

A client process calls a function on a remote server and suspends itself until it gets back the results. Parameters are passed like in any ordinary procedure. The RPC, like an ordinary procedure is synchronous. The process (or threads) that issue the call waits until it gets the results. Under the covers, the RPC run-time software collects values for the parameters, forms a message, and sends it to the remote server. The server receives the request, unpacks the parameters, calls the procedure, and sends the reply back to the client. While RPCs make life easier for the programmer, they pose a challenge for the NOS designers who supply the development tools and run-time environments. The Common issues are:

How are the Server functions located and started?

Server starts the process, when a remote invocation is received with necessary parameters and returns the response to the client.

15

What happens when multiple clients invoke the same function? Now an environment is needed to start and stop servers, prioritize requests, perform security checks, and provide some form of load-balancing. Each incoming requests invokes a thread in the server side. A server loop is created to manage the pool of threads waiting for work rather than create a thread for each incoming request. TP Monitors are really need on the server side, which provides more functions than a NOS.

How are parameters defined and passed between the client and the server?

The better NOSs provide an Interface Definition Language (IDL) for describing the functions and parameters that a server exports to its clients. An IDL compiler takes these descriptions and produces source code stubs (and header files) for both the client and server. These stubs can then be linked with the client and server code. The client stubs packages the parameters in an RPC packet, converts the data, calls the RPC run-time library and waits for the servers reply. On the server side, the server stubs unpacks the parameters, calls the remote procedure, packages the results, and sends the reply to the client.

How are failures handled?

Both the sides of the RPC can fail separately, it is important for the software to be able to handle all the possible failure combinations. If the server does not respond, the client side will normally block, timeout, and retry the call. The server side must guarantee only once semantics to make sure that a duplicate request is not re-executed. If the client unexpectedly dies after issuing a request, the server must be able to undo the effects of that transition.

16

How is security handled by the RPC?

Modern NOSs, like DCE make it easy to automatically incorporate their security features into the RPC. All you need to specify is the level of security required; then the RPC and security feature will cooperate to make it happen.

How does the client find its server?

The association of a client with a server is called binding. The binding information may be hardcoded in the client. The client can find its server by consulting a configuration file or an environment parameter. A client can also find its server at run time through the network directory services. The server must, of course, advertise their services in the directory. The process of using the directory to find a server at runtime is called dynamic binding RPC can be used to find a server. The RPC client stub will locate a server from a list of servers that support the interface. This is called automatic binding.

How is data representation across systems handled?

17

The problem here is that different CPUs represent data structures differently (Ex: bigendian Vs little endian) To maintain machine independence, the RPC must provide some level of data format translation across systems. Example: Sun RPC requires that clients convert their data to a neutral canonical format using the External Data Representation (XDR) APIs. In contrast, DCEs Network Data Representation (NDR) service is multicanonical, meaning that it supports multiple data format representations. The client chooses one of these formats, tags the data with chosen format, and then leaves it up to the server to transform the data into a format it understands. In other words, the server makes it right. It lets the client to do translation, which makes the life easy for the server. With Sun, all clients look the same to the server: The Client makes it right.

Permalink Leave a Comment

1.2

RPC, Messaging and Peer to Peer

January 15, 2008 at 3:27 am (Unit 1) (Client/Server, Communication Stacks, Messaging, Peer-to-Peer, RPC)

Client/Server applications are split across address spaces, physical machines, networks and operating systems. All NOSs offer peer-to-peer interfaces that let applications communicate using close to the wire send/receive semantics. Most NOSs provide some form of RPC middleware that hides the wire. An alternative type of model message queueing or simple MOM incredibly helpful in situations when the tight synchronization is not needed between the clients and servers.

Communication Stacks

RPC Application Presentation Session Messaging Named Pipes Peer-to-Peer DCE NDR Peer-to-peer service API NetBIOS Sockets TLI CPI-C/APPC NetBEUI Common Transport Semantics TCP/IP SPX/IPX LU6.2 /APPN SUN XDR

Transport Network

18

LLC MAC Physical

IEEE802.2 IEEE 802.5 (Token Ring) Fiber Optic NDIS (OR) ODI IEEE 802.3 SDLC (Ethernet) Coax

ISDN Twisted Pair

Each layer has a well-defined set of APIs and Protocols. With these mix-and-match can be done. Practically, an entire stack of from a single vendor. The lowest layer of the communication software belongs to the device drivers that provide an interface to several types of communication hardware adapters. Real products dont have any notion of architectural boundaries or reference models they just get a job done. At the lower layers, they interface to the hardware using MAC protocols defined by IEEE. The LLC provides a common interface to the MACs and a reliable link service for transmitting communication packets between two nodes. The transport layer provides end-to-end delivery service.

1.3

I. RPC Based

RPC Based Middleware functions by allowing a client computer to execute a procedure on a remote server computer as if it were a local procedure. This is managed by what are called stubs. A stub is a placeholder procedure that invokes an actual business application at the server level. The stub is standardized so that writing a client to call it is a simple process which can invoke a much more complex procedure at the server level. The server returns the results of this procedure by calling client stubs which activate routines on the client which receive the results from the server. RPCs are known as a synchronous blocking type of architecture because once the client calls a stub procedure on the server, it is blocked from calling anymore procedures until is receives the results of the last call from the server. This synchronous blocking communication alleviates problems of synchronization.

19

Advantages: 1. Automatic Datatype Format Conversion 2. Allows programming in an applications native APIs 3. DCE provides a standard for the use of RPCs Disadvantages: 1. Compiled nature of IDL lacks flexibility 2. No support for asynchronous communication 3. Relies heavily on TCP/IP transport protocols Examples: DCE

20