Legacy Systems
 | |
Team-Fly  |
 | XML, Web Services, and the Data Revolution By Frank P. Coyle |
| Table of Contents | |
| Chapter 8. Back to the Future |
Legacy is an inevitable part of the technology curve: the new becomes old, and the software a company has relied on for years becomes cumbersome and difficult to integrate with newer systems. Beginning in the 1960s and 1970s, mainframes were the workhorses of computing. Built around processors that were weak in comparison to today's gigahertz servers, mainframes brought to the table two things that still make them players today: the ability to traffic in large volumes of data thanks to powerful, separate input/output processors and the ability to manage large volumes of transactions by running complex transaction processing software known as Transaction Monitors. During the 1980s, the increasing power of the microprocessor coupled with the emergence of local area networks gave rise to client-server computing and challenged the power of the mainframe. Amid assertions that "the mainframe was dead," client-server systems did make significant inroads into the mainframe market.
The attempt to connect legacy mainframe applications gave rise to Common Object Request Broker Architecture (CORBA), an effort to unify languages in a common object format. The 1990s gave us something totally different: the Web. Built out of constituent parts , the Web brought computing to everyone, not just workers attached to client-server networks. But the Web brought more than just a network; it brought with it a philosophy of open standards and collaborative interaction among both software components and the information workers who actively designed reusability into parts by limiting their scope. Connection Challenges
A decade ago the problem was how to connect mainframe applications ”which were typically written in COBOL, data intensive , and transaction-based ”to client-server systems. Today, the problem is how to make both mainframe applications and client-server systems work with the Web. Thanks to e-commerce, legacy data and applications have taken on a new importance. As the Web opens up to both wired and wireless devices and connections, the killer applications will be those that can get the data to the customers, employees , and partners anywhere , anytime . Both the year 2000 (Y2K) and the Web revolution have set the stage for an unprecedented shift in thinking about legacy. Ironically, although the threat of Y2K problems put most software development on hold, the intense code assessment and cleanup also culminated in an up-to-date inventory of systems and applications. As a result, many companies are in better shape than before Y2K to exploit the Web environment.
For mainframe-based legacy applications, the solution to the integration problem has been component technology ”CORBA, Enterprise JavaBeans, or Distributed Component Object Module ”to move data across the enterprise. The problem is that all variations of this technology are code-centric, meaning that the software must fit into a specific, often proprietary, program infrastructure before integration can take place. Suggestions for dealing with the legacy problem have included the "scrap and rewrite" approach and the suggestion to build bridges into multilanguage object systems such as CORBA, which define language-neutral bindings for passing data between procedures and object methods . With options such as these, it's no wonder pundits were proclaiming "the mainframe was dead" in the late 1980s and early 1990s. Legacy's New Position
Now, however, legacy finds itself in an interesting position. Long outsiders in the client-server realm, mainframe legacy applications and mainframes themselves are seeing a renewed interest because of changes in the shape of the Web. As Figure 8.4 shows, XML-based SOAP messaging and Web services connectivity based on .NET and J2EE have opened up new options for extending legacy systems. Figure 8.4. Three options for connecting mainframe applications: (1) direct legacy to Web services via SOAP, (2) connecting via .NET and its Common Language Runtime, and (3) connecting via J2EE's Connection Architecture One option is to offer services or use other Web services through direct SOAP connections to customers, partners, and suppliers. Another option is to use the .NET framework to integrate legacy code directly. For example, existing COBOL applications can be recompiled to operate as part of the .NET Common Language Runtime and be made to interoperate with any of the other .NET languages. On the J2EE side, the Java Connection Architecture driven by the Java Community Process defines a standard for connecting the J2EE platform to heterogeneous non-Java applications, including mainframe transaction processing, database systems, and legacy applications written in COBOL and other languages. |
| | |
| Team-Fly |
| Top |
EAN: 2147483647
Pages: 106