Second Generation Legacy to Web Strategies Via XML

Transcription

1 Second Generation Legacy to Web Strategies Via XML Part 1 - Business Strategic Issues by Don Estes Table of Contents 1. BUSINESS STRATEGIC ISSUES 1.1 THE B2B IMPERATIVE 1.2 HOW TO B2B 1.3 MIDDLEWARE VERSUS NATIVE XML 1.4 XML EQUALS SQL EVERYWHERE 1.5 XML BOLT-ONS 1.6 XML SCHEMA AND DATA INTEGRITY 1.7 STANDARD XML DICTIONARIES 1.8 XML AND MAINFRAMES 1. Business Strategic Issues 1.1 The B2B Imperative Business-to-business (B2B) e-commerce via the Internet is a disruptive technology. It turns many classic rules of the old economy upside down, where yesterday's winners may be tomorrow's losers. In many markets, tomorrow's winners are now preparing to undercut the incumbent. Targeted companies will be those who are too inflexible in their business process and supporting IT systems to respond effectively in time, and they will go under or be absorbed. In particular, B2B promises that any intermediaries who do not add value or who have noncompetitive cost structures will be certain losers. Although some markets will narrow, creating several niches for nimble companies, there are also many markets where the "winner take all" effect will rule. This is the observation that certain goods and services, Microsoft Office and ebay being two well known examples, gain more in value as more people use them. Microsoft Word may be no better than WordPerfect, just as Excel may be no better than Lotus 1-2-3, but if you want to exchange files with others, you will pick the product which is ubiquitous rather than the one which is better. Similarly, you pick an auction site based on the largest number of members, not the best process or user interface. There are substantial financial benefits that will accrue to successful B2B initiatives. By 2003, Forrester Research estimates that B2B e-commerce will reach $3 trillion; Gartner Group estimates $4 trillion. The announcement of global part sourcing by the Big Three automakers show that they "got it", and estimates put the value at a 14% reduction in the cost of building a car. In fact, the cumulative effect of B2B is estimated by The Economist magazine 1, reviewing reductions in transaction costs of between 2% and 40% depending on the industry, to be a permanent increase of 5% in the output of goods and services in the first world economies. In the US alone, that would mean $400 billion per year, with 1/4% to 1/2% added to US annual GDP growth. 1.2 How To B2B Maintaining application-to-application (A2A) operational integration is a daily challenge within most enterprises. Extending A2A integration into B2B integration is being forced onto the IT agenda by the business case. Unfortunately, the unsatisfactory A2A solutions provided in the past will not provide successful strategies for the more difficult case of B2B integration. We need new strategies to provide the flexibility, responsiveness and robustness lacking in most A2A implementations. Once accomplished, a successful B2B integration strategy may be used to eliminate the operational headaches from old A2A solutions. IT management has 3 strategic options on how to get to the web: F Buy an off the shelf solution and interface it to your existing applications F Create a new application solution from scratch F Re-use your legacy applications There is no universal answer here. Each solution will be the best choice in different circumstances, sometimes under the same roof. A careful analysis is required to determine the pros and cons of each approach for each application. One must make the best choice, although it is unlikely that a single one will maximize cost, risk, quality, reliability,

2 and time to market simultaneously. We have a basic rule of thumb that we use: F If the legacy application no longer fits the business, buy or build new F If the legacy application does an adequate job, re-use it through modernization Although this and subsequent articles will focus on re-use of legacy applications, there are many times when a new solution would be preferable, and we are the first to recommend new when it makes business and technical sense. 1.3 Middleware Versus Native XML We consider middleware to be a first generation solution. If you have to get your legacy application up and running right now, there are several middleware solutions available. Many of these are quite popular, and do the job. However, middleware adds to the maintenance burden and fails to address underlying structural issues within the application itself. A significant part of the value of adopting XML derives from a comprehensive improvement in the robustness of module interfaces. Consider the classic screen scraper approach. The middleware intercepts the HTML message inbound from the workstation, translates it to a fixed format as expected by the target program, and passes it on to the host. On the way back, the middleware captures the screen image outbound to what the host program thinks is a character based terminal, translates it to HTML, and passes it on to the browser running on the workstation. However, whenever the underlying program has to be changed, the middleware must be modified at the same time, increasing the maintenance effort and complicating the deployment. A second-generation solution would perform these functions within the host program, so that there would be a single point of maintenance. When communicating with a character based terminal, the traditional logic would be executed, but when communicating with a browser, it would decode and encode a browser compatible document. This could be HTML, but XML provides a much more flexible exchange. An XML document provides the data to be displayed, and a companion stylesheet written in the extensible Stylesheet Language (XSL) provides the presentation information. An XML aware browser such as Internet Explorer 5.0 combines the XML and XSL and internally generates a temporary HTML for display purposes. A default XSL can be generated once from a utility, which reads, for example, CICS specifications and creates an XSL, which would display equivalently. However, once created, the XSL file can be edited and customized, and the support of presentation information separated from the host program. This will be particularly important where an application needs to be globalized, so that the XSL provides local language and display capabilities about which the host application needs to know nothing. First generation solutions are unlikely to provide these application-enhancing capabilities. The essence of the Internet is the use of open standards. Middleware is almost always a proprietary solution, and runs contrary to this open philosophy. A second-generation solution will bypass proprietary layers of software, and will focus on open source and open standards. For XML, this will mean maintaining the XML encoding and decoding logic directly into your programs, in the language in which they are written, or calling a universal encoding and decoding subroutine for which you control the source. 1.4 XML Equals SQL Everywhere XML is being touted as the most significant event in data exchange since SQL. XML provides a loosely coupled interchange of data that is very similar to SQL. However, XML is much more general than SQL, and it includes the ability to exchange data between application programs and browsers, between application programs and other application programs or subroutines, between application programs and post-processing utilities, and between application programs and databases. Consider the difference between traditional fixed record I/O formats and SQL databases. Whenever a file format changes, all programs using the file must be reviewed and recompiled, in some cases after maintenance modifications are made but also for programs which require no maintenance changes at all. Thus, fixed record I/O forces a tightly coupled data exchange. By contrast, SQL databases allow a unique definition of each data item for each program. Data items receiving SQL data need not have the same definition as the database column. When a database table changes, only programs whose logic is directly impacted by the change need to be reviewed, modified and recompiled. As a result, SQL provides a loosely coupled data exchange. Other than SQL databases, all current data exchange is tightly coupled. Data file formats are

3 fixed and must agree exactly for all users of that file. Data exchange between a fixed screen format and interpretive middleware is similarly tightly coupled. Data exchange between application programs, either through a CALL interface or through message passing, is almost always through a fixed format that must agree exactly. Users of EDI as well as tightly coupled architectures such as DCOM and CORBA are all familiar with the limitations and burdens imposed by the fixed structure. Adopting a loosely coupled data exchange architecture based on XML not only removes the need for middleware with its attendant maintenance burden, but it reduces the maintenance burden across all programs, which must share data. XML addresses this maintenance burden in three ways: decreased cost of maintenance, increased reliability of software, and decreased time to implement changes (i.e., time to market). With the responsiveness required for the new competitive environment being expressed in Internet time, perhaps the greatest benefit of XML will be the decrease in the time required for reliably changing software. 1.5 XML Bolt-Ons There is also another factor driving XML implementations: imposed standards. Recently, the U.S. Depository Trust Company (DTC), which handles securities trading settlement in the USA, and SWIFT, the international financial transaction network, announced that next year they will begin accepting data exchanges via XML documents. Although the legacy, fixed format data exchange will continue to be supported for the foreseeable future, it is clear that not moving to XML based exchange will impose a steadily increasing burden for users of their services in the next few years. This is a shot across the bow for companies that don't have plans for XML data exchange. Companies that don't embrace XML either for its benefits or to avoid being left behind technologically may be forced into it by their data exchange partners. However, in this case, it makes sense to consider a simple XML bolt-on solution. The few file or message interface formats required for external communication with an application that speaks XML certainly do not mandate the wholesale retrofitting of the legacy application for XML. In this case, one could simply use an XML generation utility or write the code into the affected program or programs to create an XML document in place of the old fixed record format. Deciding for wholesale use of XML versus a simple bolt-on is a management decision, not a technical decision. It is similar to the decision to replace VSAM, for example, with a SQL database in order to capture the larger benefits of the relational database environment: data integrity at the logical and context levels, and a loosely coupled interface between program and data. Why replace a perfectly good file system or old database with SQL? If you have a good reason to answer yes to SQL, then you have a good reason to answer yes to the wholesale use of XML, and perhaps a few additional ones as well. As a practical matter, at first most sites will use XML only at the interfaces with external applications. However, as the power of the XML interface becomes clear and supporting tools become available, XML data exchange will begin to be used for A2A integration, and eventually within applications as well. In fact, we see this beginning to happen with some of our customers. 1.6 XML Schema and Data Integrity B2B e-commerce is the ultimate challenge in program-to-program data sharing. Implementing XML as the data exchange mechanism addresses a critical part of the problem with its loosely coupled architecture, but another critical part remains: data integrity. Successful general-purpose data exchange requires absolute data integrity. Data integrity must be considered at 4 levels: F Physical layer - hardware F Logical layer - basic data attributes F Context layer - where and how used F Semantic layer - the meaning of the data The physical layer is usually taken for granted, ensuring that parity errors and other failures at the hardware level cannot contaminate our data. The logical layer requires programmers and database analysts to coordinate each data item definition with regard to its basic attributes, such as type (numeric, alpha, date, etc.), size, format, scale, valid values, and etc. Getting the logical layer right has been an on-going challenge since the advent of computers, but diligence combined with solid tools and procedures generally makes a failure at this layer an unusual event at most sites. The context layer is the focus of data integrity issues at most sites. This involves referential integrity among data files and database tables, data flow between modules, and where and how the data items are used. Given that the logical layer is under control, this is the layer where most data related failures will occur. The semantic layer is seldom the focus of data integrity concerns, but this will change with a

4 vengeance as B2B data exchange becomes common. When all data is exchanged internally, there may be differences in the meaning of a given data item's definition, but it is readily resolvable when issues arise because both sides of the exchange are entirely under one roof. This will not be so with B2B data exchange. When data must be exchanged among partners and competitors, among dissimilar cultures and languages, and among differing hardware and software platforms, we are facing a digital version of the Biblical Tower of Babel. XML provides the mechanism to address this issue through the concept of data tags. Regardless of what the data name or names by which a data items is identified in different contexts, it is assigned a universal data tag which uniquely identifies the semantic meaning of that data item whenever it is used. For example, our recent Y2000 experience could be characterized as a data tagging exercise, in which we had to identify dates wherever they appeared, ensure that their format was correct, and that their use was correct. Now, we need to do the same thing for all data items that are candidates for data exchange in B2B e-commerce. However, Y2000 was comparatively simple, because there was little problem agreeing on what MMDDYY or YYYYMMDD meant. Consider a simple tag such as "name". Does this mean "first name + space + last name", or "last name + comma + space + first name", or what? And that's a USA-centric view of the problem. How do SELLER ACCT-ID length 4, numeric STREET-ADDRESS CITY length 20 alphanumeric STATE-CODE length 2, alphanumeric ZIP-CODE length 9, numeric DESCRIPTION you include the fact that Spanish names have two family names? What an American would consider to be the family name would not be the last name in Spanish and elsewhere. In many Asian countries the family name is the first name. Then there are cultures where some people have only one name. Globalization with its complementary problem of localization of display and usage is beginning to expose this sort of problem even before B2B e-commerce issues are considered. 1.7 Standard XML Dictionaries Through the use of XML schema definitions, consistent dictionaries of agreed semantics can be published. Large sites and particularly large companies with multiple sites and dissimilar implementations can serve as a proving ground for the infrastructure needed for data tagging even before addressing e-commerce issues. However, how do we get everyone with whom we have to exchange data to agree on a common dictionary? There are several industry specific initiatives in progress at this time. For example: F FRXML - general accounting reporting, from AICPA F FIXML - XML definitions of the FIX transaction protocol, from FIX organization F FinXML - data interchange for capital markets, from Integral Corporation F FpML - derivatives and FX processing, from JP Morgan and PricewaterhouseCoopers F NTM - risk management and derivatives, from Infinity F XML/EDI - general electronic data interchange, from XML/EDI Group Ideally, we should just adopt the agreed standard and retrofit all our legacy applications with the BUYER ACCOUNT-CODE length 7, numeric ADDRESS-LINE-1 length 30, alphanumeric ADDRESS-LINE-2 length 30, alphanumeric CITY length 25, alphanumeric STATE-NAME length 20, alphanumeric ZIP-CODE length 5, numeric DESCRIPTION Fig. 1 - Disjointed Data Definitions relevant standard. Two problems immediately surface: the standards are still in flux, and our applications may fit the standards like a square peg in a round hole. XML comes to the rescue with the extensible Stylesheet Language Transformation (XSLT) process. Consider this disjointed set of data definitions ("dialects") between two data exchange partners (see Fig. 1 left). It is pretty straightforward to define an XSLT to transform the seller's XML dialect into the buyer's XML dialect. This provides a 2-tier translation scheme that will work nicely for two parties, as well as for in-house data exchanges between different systems. However, when other parties come into the exchange, this solution starts to break down. As participants increase in number, the number of 2- tier translations required goes up much faster than the number of participants. As a practical matter, it becomes necessary to move to a 3-tier translation scheme. One party transforms their unique dialect into the current draft of the proposed industry standard, all exchange is done in the standard dialect, and then a second transformation is

5 F O done into the other party's dialect. Only a relatively small number of transformations are required, R E C R O S S C O R P O R A T I O N regardless of the number of data exchange partners. These are the ultimate promises of XML: industry wide data exchange standards, and a loosely coupled data exchange architecture that is flexible enough to grow and to allow quick response to threats and opportunities. The rule in IT services has always been that if you can get the data right, then the processing logic is easy. However, data problems have been so intractable that solution providers have focused on the logic and just allowed disjoint data definitions to propagate. Now, XML comes forth with a practical solution to data issues which fit all significant issues. W H I T E P A P E R 1.8 XML and Mainframes Most of the current discussion and development related to XML involves off-mainframe platforms and solutions that do not directly address the realities of mainframes and large IT shop operations. Perhaps more importantly, the credibility of the technology has not been established in the minds of the key people who have to get the work out every day. Yet, it is precisely those shops that have the greatest need for the A2A and B2B integration capabilities provided by XML technology. In future articles, we will seek to bridge the gap between the XML developers and the mainframers. We will explore practical strategies to embrace XML, even for shops that continue to support older technologies but would benefit from selective modernization. We will discuss XML technical details from a mainframe point of view, including XML schema development recommendations to mirror mainframe databases. And, we will discuss how to implement second generation, native XML implementations, including integration into COBOL programs and direct interface between workstation browsers and mainframe programs. Author Bio: Don Estes is Director of Product Architecture for Forecross Corporation, a legacy to web and XML implementation solutions company. He is responsible for second-generation legacy to web products and services, including automated testing of transformed programs. Send your comments to Don_Estes@Forecross.com. Earlier versions of this paper appeared in the May, 2000 issue of the Cutter IT Journal, and the September - October, 2000 issues of eaj Journal. Permission is granted for reproduction and distribution of this document provided it is complete, unmodified, and retains all identification including this statement, and provided that notification of recipient is sent to the above address. All other reproduction and distribution is expressly forbidden. 1 April 1, 2000, Second Generation Legacy to Web Strategies Via XML - Business Strategic Issues