IT managers today are more troubled than ever. The IT skills shortage and shorter business cycles are making the development process more difficult. This is forcing developers to try and reuse more elements of their software. Reusing tried and tested, high performance legacy resources is just as important as reusing newer program components developed in a client server environment, and yet intelligently bridging the gap between legacy and open system resources is no mean feat. Simply screen-scraping mainframe data onto a GUI is not smart, because it makes it harder to change applications as time goes on. Altering applications slightly, so that different clients in different departments are served in different ways, becomes impossible because they are all served by the same host. Instead, the past couple of years has seen the rise of the three-tier architecture. Many companies have abandoned the two-tier architecture (consisting of a mainframe and a fat client), instead extracting the code containing the "business rules" - the part of the program that needs to change to meet new commercial challenges. They have placed this code on a new tier sitting between the desktop presentation layer and the back-end mainframe resource that does the high-performance "donkey work", such as serving database queries. As commercial conditions change, this enables developers to alter the business rules that direct the mainframe processes more easily, using client server tools and techniques. Resting on the middle-tier, middleware provides a means of communication between many different types of proprietary back-end systems and the more standard client server environments. It can also be used to link disparate middle-tier resources together. Rosemary Rock-Evans, a freelance consultant working closely with market research company Ovum, has defined six types of middleware. Remote Procedure Calls (RPCs) constituted one of the first kinds of middleware. This is a standard way of calling software routines on other systems across the wire. The Distributed Computing Environment (DCE) is another, older type of interconnectivity that can be called middleware. Developed by the now defunct Open Software Foundation, it was supported by a number of players including DEC, Hewlett Packard (HP), IBM and Transarc. It is very complex, however, and although still widely supported, it suffers from a lack of GUI interface and sluggish further development. Another type of connectivity that Rock-Evans terms middleware are database gateways, through which databases from different vendors can talk to each other. However, even she admitted that this is more of a point-to-point solution than an infrastructural answer to the problem. Perhaps more significant for today's corporate customers are the other three types of middleware on Rock-Evans' list: transaction processor monitors (TPMs), messaging middleware and Object Request Brokers (ORBs). TPM software is designed to manage the transactions between different types of system. Typical examples include BEA's Tuxedo and IBM's CICS and Encina environments. Although many databases include their own transaction monitor software, third-party TPMs are used to manage transactions effectively. Messaging-oriented middleware (MOM), which generally works on an asynchronous basis, passes messages between applications, enabling them to pass instructions and therefore work together. Examples of this type of middleware include Tuxedo (which combines MOM with its TMP capabilities) and IBM's MQSeries, which was recently merged with Distributed CICS and Encina into a hybrid middleware system called TXSeries. Keith Hodgson, managing director at systems integrator SX Consultancy, believes MOM is the most popular form of middleware because of its reliability. Hodgson, who helped put together Dell's UK manufacturing system using MOM, says MOM can guarantee delivery of an application message because of its message queuing capabilities. Typical examples of the Object Request Broker (ORB) are products such as Visigenic's Visibroker and Iona's Orbix. The ORB acts as a hub for communication between software objects, which are a central part of the reuse process. ORBs are based on the Common Object Request Broker Architecture (CORBA) standard which, in addition to defining intra-ORB communication standards, also defines the standard for ORB communication across platforms. This means that objects can communicate with objects on other systems via their respective ORBs. This is done using the Interface Definition Language (IDL) and, along with the other types of middleware, provides another method for achieving distributed applications. One of the major thorns in CORBA's side is Microsoft's Distributed Component Object Model (DCOM). DCOM, which competes directly with CORBA, is soon to be replaced with COM+, the latest development in the whole COM architecture that will include more sophisticated services. Until recently, the difference between the two technologies was that Microsoft's technology was only NT-based, whereas CORBA straddled a number of platforms. A recent development from Software AG, called EntireX, is designed to put ActiveX, and therefore DCOM, onto other platforms, according to the firm's director of marketing and strategic partners, Roopinder Singh. However, this is a white elephant on anything else other than the mainframe, according to Ovum analyst, Neil Ward-Dutton. "I wouldn't advise people to jump on the bandwagon straight off. You are talking about people that buy version three or four of a product. These guys are not early adopters," he warned. Similarly, the fact that Software AG is giving away EntireX licenses on Unix, indicates that the firm's real aim is to use the product to hook CICS on IBM's MVS host environment into Windows NT. Software AG's revenues are traditionally mainframe-based. In spite of the continuing war between DCOM and CORBA, there is light at the end of the tunnel. HP's ORB X product is designed to bridge the gap between the two systems, and the OMG has also just ratified the protocol for bridging between the two products - although when COM+ emerges, the whole thing looks as though it could go pear-shaped again. For now, however, many companies are concentrating on the next stage of middleware integration, which is to provide integrated legacy and client server services to intranet and Internet clients. BEA's Jolt product is designed to do this through Java applets, according to Garth Eaglesfield, senior architect for the company. "At the front end, our Jolt product allows you to create a Tuxedo client that is a Java applet and that can make use of the services at the back-end without making any changes to it," he said. "Instead of using a C API you're using a Java API. When the applet downloads to the browser, it establishes a direct connection to Tuxedo, acting as though you've tunnelled into your original environment." There are also ways to connect Web clients to middle tier and back-end resources using ORBs. A key factor here is the Internet Inter-Orb Protocol (IIOP), which can be used for CORBA communications across Internet-based networks. Iona has been selling its OrbixWeb product for two years, according to senior product manager, John McGuire. "You have two worlds - the Internet Java base and also the mature base using legacy systems. The IIOP plumbing is bringing these two together," he said. OrbixWeb connects Java applets to legacy resources via CORBA using IIOP. Corporate customers may have difficulty making sense of all these middleware options. Compuware's product marketing manager, Ian Meakin, thinks that he has the answer in the form of the Universal Request Broker (URB) - effectively a "meta-middleware" product that acts as a bridge between the different types of middleware. Using the URB, customers can hook together ORBs, DCOM and messaging systems among others. This could prove useful within a merger or acquisition scenario, for example, where one company had taken a different middleware approach to the other. Components are sections of code forming reusable business services. Meakin believes even mainframe components can be brokered by the URB in this way by "wrapping" them to be identifiable to the rest of the system. However, he admits his product cannot "componentise" legacy code. While the URB may be able to drastically reduce development times by using mainframe components in existing developments, extrapolating legacy code into components can be a difficult task, as developers have to examine existing source code and documentation (assuming it is still available) to identify functional strands within the code. He is unable to provide any time and materials-based investment analyses for this task. In a world where IT managers have to respond to business needs quickly, developers must ask themselves how easy it would be to construct a granular, component-based view of their system. The ability to do this will vary from company to company. The options open to developers choosing middleware solutions are almost as complex and diverse as the systems that they are trying to hook together. Nevertheless, the basis for using the newer middleware systems such as ORBs and DCOM lies in implementing three-tier solutions that enable them to make the best use of legacy resources. The success of such an operation depends on how easy it is for a company to separate business logic from fixed mainframe processes, such as database queries. If this can be done, then the ultimate goal can be achieved - a fixed set of core, back-end resources with a highly flexible middle tier which can serve ever-shifting client needs. MIDDLEWARE: CASE STUDY One organisation that has successfully implemented middleware to bring together disparate systems is the Social Security Department of the City of Tilburg in Holland. IT manager Bart Verwyst, explains that there are 9000 people claiming social security from the department. In the process of making a claim, customers needed to answer literally hundreds of questions which were then entered into a system. In 1994, the department needed to develop a back-end application to make it easier for staff to access and alter this information. The organisation originally went to IBM, which pledged to develop a front-end using what, at the time, was its VisualGen product. It would use CICS to integrate information held on the department's back-end DB2 and Oracle databases, each of which ran on an IBM RS/6000 server. Although the main back-end application was constructed in Oracle, much of the data was held on the DB2 system. "It was a terrible disaster. The application was too big and had so many problems with it that the tools they used couldn't get it done," he complained. "There was no performance, and database access was very limited. We were one of the first users of CICS 6000. They bought out some people from the US to assist developers over here but it wasn't doing well. After seven months we decided to stop the project and look for some other tools. "We wanted to create a multi-tier application, doing something with the GUI, separating the business and access rules. Business rules change very often in this department and we wanted to do a complete separation." He started working with Microsoft's Visual Basic at the front end and added that by this stage he also needed to connect into SQL Server, which also ran on an RS/6000, holding documents as part of the department's document management system. Although Microsoft's Object Database Connectivity (ODBC) universal database gateway was an option, he didn't feel that it would be robust enough to cope with the 200 concurrent users that would be accessing the system. Instead, the department turned to Entera, Borland's middleware product based on RPC technology. Verwsyt explained that he also tested IBM's MQSeries messaging product, but RPC appealed to him more than messaging technology because he was worried that the asynchronous nature of MQSeries would yield poor response times. "When you issue an RPC to another system, you know immediately whether you will get it back or not. If the system is not available or down then you get notification. With message queuing, your call will be stored on the other machine and you have guaranteed delivery - but you don't know when it will be," he said. He also explained that the department received application management software with Entera, and he felt that it was easier to change business rules with the RPC product. The base functionality for the product was completed in December, and also includes two other NT servers - one containing the business logic and another handling log-in routines. Even before the project was completed, he explained that the department sold it to CIOB, a software house in Eindhoven, which then worked jointly with the department on developing software modules for the product. As part of the department's internal development, it is gradually moving much of the DB2 data to Oracle, but the Entera middleware is allowing it to handle this in a relaxed manner rather than forcing it to conduct the migration all at once.
Found by calculating the strength of the material deep inside the crust of neutron stars
Can highlight in real-time the relevant regions of an image being described
Double legal trouble for Musk as he also faces civil lawsuit over renewed British pot-holer 'paedo' claims
Battery development could help boost performance of smartphones