MIDDLEWARE TECHNOLOGY

ABSTRACT:
Requirements for faster development cycles, decreased development efforts , greater software reuse, and better end-to-end control over system resources are motivating the creation and use of middleware systems and middleware based architectures. Middleware is systems software that resides between the applications and the underlying operating systems, network protocol stacks, and hardware. Its primary role is to functionally bridge the gap between application programs and the lower-level hardware and software infrastructure in order to coordinate how application components are connected and how they interoperate. Furthermore, middleware enables and simplifies the integration of components developed by multiple technology suppliers. In this sense middleware systems are sets of services and abstractions that facilitate the development and deployment of distributed applications in heterogeneous, distributed, computing environments Next-generation distributed applications and systems will increasingly be developed using middleware. This dependency poses hard challenges, including latency hiding, masking partial failures, information assurance and security, legacy integration, dynamic service partitioning and load balancing, and end-to-end quality of service specification and enforcement. To address these challenges, researchers and practitioners need to discover and validate techniques, patterns and optimizations for middleware frameworks, multi-level distributed resource management, and adaptive and reflective middleware architectures.

INDEX

1. INTRODUCTION 1.1 INTER-PROCESS COMMUNICATION: A PREAMBLE 2. BRIEF HISTORY OF MIDDLEWARE 3. WHAT IS INVOLVED IN MIDDLEWARE? 4. MIDDLEWARE BASICS 5. PRIMARY APPLICATIONS 5.1 MIDDLEWARE AND COMPUTER TELEPHONY 5.2 JAVA MIDDLEWARE-EVOLVING USE OF EAI TECHNOLOGY 6. BUSINESS CONSIDERATIONS IN SELECTING MIDDLEWARE 7. CONTROLS & SECURITY CONSIDERATIONS 8. CONCLUSIONS 8.1 POTENTIAL CHALLENGES OF MIDDLEWARE 8.2 THE FUTURE OF JAVA MIDDLEWARE

1. Introduction
Middleware is software that functions as a conversion or translation layer. It is also a consolidator and integrator. Custom-programmed middleware solutions have been developed for decades to enable one application to communicate with another that either runs on a different platform or comes from a different vendor or both. Middleware, which is quickly becoming synonymous with enterprise applications integration (EAI), is software that is invisible to the user. It takes two or more different applications and makes them work seamlessly together. This is accomplished by placing middleware between layers of software to make the layers below and on the sides work with each other .On that broad definition, middleware could be almost any software in a layered software stack. Further, middleware is a continually evolving term. Middleware, or EAI, products enable information to be shared in a seamless real-time fashion across multiple functional departments, geographies and applications. Benefits include better customer service, accurate planning and forecasting, and reduced manual re-entry and associated data inaccuracies. Middleware is essential to migrating mainframe applications to client/server applications, or to Java or internet-protocol based applications, and to providing for communication across heterogeneous platforms. This technology began to evolve during the 1990s to provide for interoperability in support of the move to client/server architectures. 1.1 INTER-PROCESS COMMUNICATION: A PREAMBLE Middleware is also called as Inter-process communication. It makes the cooperating components of distributed system to interact through well-defined request/response architecture thus masking the issues related to heterogeneity, concurrency and distribution of components. The role of middleware is to make application development easier by: a) providing common programming abstractions. b) masking the heterogeneity and the distribution of underlying hardware and operating system. c) hiding low-level programming details. Thus middleware allows software engineers to focus on the actual application requirements. In recent years standardization solutions such as OMG.s CORBA(Common Object Request Broker

Architecture),SUN.s JMS(Java Messaging Service),MICROSOFT.s SOAP(Simple Object Access Protocol) with their implementations have been used in the development of large spectrum of applications.

2. Brief History of Middleware

Till 1980 s most of computing was based on central host computers equipped with powerful processors and memory. Users interact with the host through the terminals that captures keystrokes and sends the information to host. A major bottleneck for this architecture was that the processing power was limited to that of central host system, over dependence on the vendor for application software, lack of support for GUI and access to multiple databases. The mainframes prevalent at that time were based on this architecture. With advent of PC s the files were downloaded from the shared location, processed and uploaded back to file server. This had major drawback as it generated too much of network traffic. However with emergence of client /server architecture, the computing power or process management was distributed between the client and server. For example client could query database server using relational database management system (DBMS) through standard query language (SQL). The results of query are sent to the client, which then manipulates and processes the data. This two-tier client/server architecture has limitation as the number of users grows beyond certain limit, due to the fact that server has to maintain a dialog of connection even when client is idle. Moreover any changes in application or parameter would entail changes at all clients like a change in VAT rate would need update on all the users workstation. To overcome these limitations middle-tier was added between the user system interface client environment and database management server environment. The middle tier or middleware is now one of the emerging technologies in client server paradigm. It provides for connectivity across heterogenous platform and for more generalization of Application Programming. Interface (API) than operating system or network services. Application Programming Interface (API): In order to fully understand middleware, one must first understand the concepts surrounding Application Programming Interfaces (APIs). The API, by definition, is a software program that is used to request and carry out lower-level services performed by the computers operation system or by a telephone systems operating system (Figure: API). In a Windows environment, APIs also assist applications in managing windows, menus, icons, and other GUI elements. In short, an API is a hook into software. An API is a set of standard software interrupts, calls, and data formats that application programs use to initiate contact with network services, mainframe communications programs, telephone equipment or program-to-program communications. For example, applications use APIs to call services that transport data across a network. Standardization of APIs at various layers of a communications protocol stack provides a uniform way to write applications. This technology is a way to achieve the total cross-platform consistency that is a goal of open systems.

FIG: Application Programming Interface (API)

3. What is involved in Middleware?

Middleware/EAI is very involved and complex, and incorporates every level of an enterprise system its architecture, hardware, software and processes. Middleware involves integration at the following levels: Business Process Integration (BPI): When integrating business processes, a corporation must define, enable and manage the processes for the exchange of enterprise information among diverse business systems. This allows organizations to streamline operations, reduce costs and improve responsiveness to customer demands. Elements here include process management, process modeling, and workflow, which involve the combination of tasks, procedures, organizations, required input and output information, and tools needed for each step in a business process. Application Integration: At this level of integration, the goal is to bring data or a function from one application together with that of another application that together provide near realtime integration. Application Integration is used for, to name a few, B2B integration, implementing customer relationship management (CRM) systems that are integrated with a company's backend applications, web integration, and building Web sites that leverage multiple business systems. Custom integration development may also be necessary, particularly when integrating a legacy application with a newly implemented application. Data Integration: In order for both Application Integration and Business Process Integration to succeed, the integration of data and database systems must be tackled. Prior to integration, data must be identified (where it is located), cataloged, and a metadata model must be built (a master guide for various data stores). Once these three steps are finished, data can then be shared/distributed across database systems. Standards of Integration: In order to achieve full Data Integration, standard formats for the data must be selected. Standards of Integration are those that promote the sharing and distribution of information and business data standards that are at the core of Enterprise Application Integration/Middleware. These include COM+/DCOM, CORBA, EDI, Java RMI, and XML. Platform Integration: To complete the system integration, the underlying architecture, software and hardware, and the separate needs of the heterogeneous network must be integrated. Platform Integration deals with the processes and tools that are required to allow these systems to communicate, both optimally and securely , so data can be passed through different applications without difficulty. For example, figuring out a way for an NT machine to pass information reliably to a UNIX machine is a large task for integrating an entire corporate system.

4. Middleware Basics
As seen above in (Figure :API), middleware works in concert with APIs. Further, it exists between the application and the operating system and network services on a system node in the network. Middleware services are sets of distributed software that provide a more functional set of APIs than does the operating system and network services. This increased functionality allows an application to:

service.

Middleware accomplishes the above tasks via one of the following forms: 1.Transaction Processing (TP) monitor technology : The most basic type of three tier architecture is used in Online Transaction Processing Technologies (OLTP) applications using middle layer consisting of Transaction Processing (TP) monitor technology. This is a type of message queuing, transaction scheduling and prioritization service where the client connects to the middle tier viz. TP monitor which in turn connects to the back end database. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing thus relieving the client. It has ability to connect to different DBMS in single transactions irrespective of whether it is flat file or non-relational DBMS. This architecture is considerably more scalable than a two tier.

FIG: Transaction Processing (TP) monitor technology

2. Message Servers:

This implementation, also known as Message-oriented middleware (MOM), provides programto-program data exchange with intelligent messages sent asynchronously. It is similar to email exchanged between the programs. It requires recipient programs to interpret these messages and take appropriate action. MOM increases flexibility of architecture by enabling applications to exchange messages with each other without need to bother about the underlying operating system or the processors. MOM is most appropriate for event-driven applications

Fgi: message servers

3. Remote Procedure Call (RPCs): enables the logic of application to be distributed across the network. Program logic on remote systems can be executed by simply calling a routine. For example network printer or shared folder can be located across the network as locally attached resource

FIG: Remote Procedure Call (RPCs):

4. Object Request Broker Architecture: This refers to specification and implementation framework forinteroperability and reusability of distributed objects. These initiatives are driven by two rival camps Microsoft with COM/DCOM technology and Object Management Group (OMG) with Common Object Request Broker Architecture (CORBA). These defines application program interface (API) through which various components interact independent of language or platform.

FIG: Object Request Broker

5. Application Servers: There is a shared host on which business logic, computation and data retrieval engine resides. The GUI component resides on the front-end client making this architecture highly scalable, secure and lends itself to changes easily. For example in banking scenario in which interest rates change frequently. This would entail changing a parameter only on shared host without change at teller end or at database end.

FIG: Application Servers The fig above shows clients accessing the web server which optimized to serve web pages while application server based on the inputs from clients and business decision logic residing on it, queries the database. The results are pushed on the web server for serving to user browser.

5. PRIMARY APPLICATIONS 5.1 Middleware and Computer Telephony

Middleware in computer telephony tends to be software that sits right above that part of the operating system that deals with telephony. This is the Telephone Server Application Programming Interface (TSAPI) in NetWare and the Telephone Application Programming Interface (TAPI) in Windows. Further, the middleware sits below the user interface and thus, invisible to the user. TSAPI was described by AT&T, its inventor, as standards-based API for call control, call/device monitoring and query, call routing, device/system maintenance capabilities, and basic directory services. TAPI is also called the Microsoft/Intel Telephony API. As stated above, the API is a software program that is used to request and carry out lowerlevel services performed by the computers operation system or by a telephone systems operating system. In the case of the TAPI, it is the telephone systems operating system. The TAPI set of functions allows windows applications (i.e. Windows 2000, NT) to program

telephone-line-based devices such as single and multi-line phones (both digital and analog) and modems and fax machines in a device-independent manner. TAPI essentially does for telephony devices what the Windows printer system did to printers makes them easy to install and allows many application programs to work with many telephony devices, irrespective of the device manufacturer. TAPI is an evolutionary API providing convergence of both traditional PSTN telephony and IP Telephony. IP Telephony is an emerging set of technologies which enables voice, data, and video collaboration over existing LANs, WANs, and the Internet. TAPI enables IP Telephony on the Microsoft Windows operating system platform by providing simple and generic methods for making connections between two or more machines, and accessing any media streams involved in the connection. In addition, TAPI also supports standards based H.323 conferencing (these standards define realtime multimedia communications for packet-based networks now called IP Telephony) and IP multicast conferencing. Further, TAPI utilizes the Windows operating systems Active Directory service to simplify deployment within an organization, and includes quality of service (QoS) support to improve conference quality and network manageability.

5.2 Java Middleware Evolving Use of EAI Technology

Java middleware encompasses application servers like BEA WebLogic, messaging products like Active Software's ActiveWorks and Push Technologies' SpiritWAVE, and hybrid products that build on a DBMS legacy and add server-based Java object execution features. Further, even among application servers there is quite a spectrum, including those that are primarily servlet servers as well as those that are ORB-based or OODB-based. Drawing a line between all these products proves increasingly difficult. The unifying feature, however, is that they all attempt to solve the multitier application deployment problem by using Java and Internet technologies. The business case to use Java in middleware is compelling. Among the advantages offered by Java middleware are the following: internet to economically interconnect offices and organizations.

entralized application management, including startup, shutdown, maintenance, recovery, load balancing, and monitoring.

frastructure; this necessitates using open APIs and protocols, which are widely supported across most infrastructure products. -architecture applications. plication space, so that system managers can make infrastructure decisions without being hampered by applications that depend on proprietary protocols or features. e the need for advanced tool-building expertise within projects. -oriented expertise by extending it into the server realm. Hence, newer object-oriented server products and object-to-relational bridges. Since the goal of middleware is to centralize software infrastructure and its deployment, Java middleware is the next logical step in the evolution of middleware building upon the client/server roots. Organizations are now commonly attempting integration across departments, between organizations, and literally across the world. The key to building such integration is to leverage the existing technology of the internet. The internet has enticed businesses with its ability to serve as a global network that lets departments and partners interconnect efficiently and quickly. Java provides a lingo that allows for easy interconnection of data and applications across organizational boundaries. In a distributed global environment that allows an organization no control over what technology choices partners make, smart companies choose open and platform-neutral standards. Companies cannot anticipate who will become their customers, partners, or subsidiaries in the future, so it is not always possible to plan for a common infrastructure with partners. In this uncertain situation, the best decision is increasingly thought to be the use of the most universal and adaptable technologies possible. Java allows for the reduction of the number of programming languages and platforms that a staff must understand. This is because Java is now deployed in contexts as diverse as internet browsers, stored procedures within databases, business objects within middleware products, and client-side applications.

6. Business Considerations in selecting Middleware:

While middleware increases the level of abstraction, developers need to be prudent enough in their choice of services in deciding which components are to placed on which tier. Though the

middleware implementations are suppose to be platform independent, many of these are vendor specific like COM/DCOM from Microsoft. Thus they need to be compiled for a specific platform or need an interpreter. The availability of development tools like C++, Visual Basic, Java are key for customized development middleware services. The components in general and those that involve business logic should be easily replaceable. Another consideration is that a good middleware should not be visible to client. It should seamlessly connect the client to back end. While these are technical and aesthetic considerations, there are also strategic business factors to be considered. Normally in an enterprise there are islands of application developed over period of time. They reside on heterogeneous platform across various functional units of an organization. As businesses become competitive, there is crucial need by business owners to have information on state of business at any moment. Moreover the need for better customer service demands integration of these applications. This is where middleware has to play an important role in Enterprise Integration.

7. Controls & Security Considerations:

The scope of middleware deployment is broad and as such should be tackled from business perspective rather than fromonly technical one. When middleware deployment should focus on these issues:

leveraging the power of middleware, certain controls existent may not be relevant or has to be reengineered. Data, which hitherto was accessible only to select few in an enterprise, there is a risk of it being available to malicious hackers.

communicate with other programs, messages need to be authenticated, encrypted and authorized by MOM managers. As various applications publish their messages, due care has to be taken as which recipient applications can subscribe to these messages. Similarly in application servers communication with front end webserver and back-end database server need to protected from unauthorized access and network eavesdropping

FIG: Authentication and Authorization

Similarly in TP monitors, transaction context type in database need to be secured. In this, the context or permissions to select, insert, update, delete and execute needs to be controlled.

through logs and reporting tools. This includes unauthorized access, enhancing the privilege attempts and application warning messages. Besides middleware code-review should be done through assistance of expert application programmers.

8. Conclusions:
Middleware technology is firmly entrenched in distributed computing horizon. It is enabler for enterprise application integration in today s state of business at the moment paradigm. While functional units across the enterprise may operate independently, middleware technology can be leveraged to provide integrated solution for better customer service and enhanced management information services. 8.1 Potential Challenges of Middleware Middleware product implementations are unique to the vendor. This results in a dependence on the vendor for maintenance support and future enhancements. Reliance on vendors, in this manner, could have a negative effect on a system's flexibility and maintainability. However, when evaluated against the cost of developing a unique middleware solution, the system developer and maintainer may view the potential negative effect as acceptable. Also, as Java and internet protocol middleware technologies evolve, many of these potentially detrimental issues will dissolve. 8.2 The Future of Java Middleware Java technology is still somewhat immature. On the other hand, we may now be in an era when products never truly reach maturity because the underlying technologies on which they're based change so rapidly. In fact, there are significant documented problems with virtually every middleware product, including those supposedly mature products that have been on the market for years. The point is, by the time a vendor manages to fix problems, new features have been added. The cycle for adding new features is now much shorter than it has ever been. The result is that products do not have enough time to become stable before they include the next major feature set. This problem may be something that continues into the future. Further, the burden for determining the strengths and weaknesses of all chosen products will likely be a vital component of any application design and prototype cycle.