Site Infrastructure  «Prev 

Specific Middleware Solutions

You have already read about the connectivity architectures provided by Microsoft, Oracle, and IBM. However, many different applications exist to implement these architectures. These are called application servers. Some are relatively dedicated Java servlets, whereas others are multifunctional services and daemons you can use in many different ways.
Application servers connect directly with back-end services, such as databases and legacy systems.
Generally, a Web server passes information from the user to an application server, which then communicates with the database or legacy systems.
In such an arrangement, the Web server does not interact directly with the database or the legacy system. This is why it is often called middleware.

Heterogeneous hardware, network, and operating system platforms

Client-server architectures require the use of heterogeneous hardware, network, and operating system platforms. Application programmers do not want to rewrite their code for each type of platform. A middleware layer hides the complexity of the underlying platform by providing a standard programming interface and abstraction (such as CORBA) of platform-dependent system services. Examples of a system service include open a file, close a file, read data from a file, write data into a file. The ability to access a common set of system services allows programmers to focus more of their attention on application development. These concepts have also led to the development of network operating systems (NOS), which allow users to access remote OS-level resources directly, and distributed operating systems, which provide the same level of functionality in a fully transparent way .

Another factor that led to the development of middleware systems was the need for integrated, enterprise-wide computing. This is the enterprise integration problem. An example of how this problem came into being is from the history of PC-based file and printer sharing. A company or organization could buy several PCs, connect them together with a LAN, and then allow files and printers to be shared electronically, perhaps through a local file server. As the popularity of these systems grew it became desirable for users to access files, printers, and programs on different servers supported by different LANs. In practice, even within a single organization or department, the servers and the supporting LANs ran different hardware or software. Sometimes the LANs themselves were isolated from a wide area network (WAN) that could be used to provide cross LAN connectivity. This made sharing files and resources difficult to do, complex to program, and expensive to develop. To address these problems of heterogeneity, developers needed software to solve interoperability and portability issues that was scalable and that was independent from specific network and operating system technologies. Specifically, programs running on one type of system must be able to access programs and data on another type of system in a way that maintains reasonably good performance levels, thus providing the illusion of locality.