The Internet presents numerous sources of useful information---telephone directories, product catalogs, stock quotes, weather forecasts, etc. Recently, many systems have been built that automatically gather and manipulate such information on a user's behalf. However, these resources are usually formatted for use by people (e.g., the relevant content is embedded in HTML pages), so extracting their content is difficult. Wrappers are often used for this purpose. A wrapper is a procedure for extracting a particular resource's content. Unfortunately, hand-coding wrappers is tedious. We introduce wrapper induction, a technique for automatically constructing wrappers. Our techniques can be described in terms of three main contributions. First, we pose the problem of wrapper construction as one of inductive learn...

This article describes several practical approaches to leveraging an organization's legacy investments so that it can evolve, rather than having to reinvent itself entirely.

By the early 1990s the need for reengineering legacy systems was already acute, but recently the demand has increased significantly with the shift toward web-based user interfaces. The demand by all business sectors to adapt their information systems to the Web has created a tremendous need for methods, tools, and infrastructures to evolve and exploit existing applications efficiently and cost-effectively. Reverse engineering has been heralded as one of the most promising technologies to combat this legacy systems problem. This paper

One approach to dealing with spiraling maintenance costs, manpower shortages and frequent breakdowns for legacy code is to "migrate" the code into a new platform and/or programming language. The objective of this paper is to explore the feasibility of semiautomating such a migration process in the presence of performance and other constraints for the migrant code. In particular, the paper reports on an experiment involving a medium-size software system written in PL/IX. Several modules of the system were migrated to C++, first by hand and then through a semiautomatic tool. After discovering that the migrant code was performing up to 50% slower than the original, a second migration effort was conducted which improved the performance of the migrant code substantially. The paper reports on the transformation techniques used by the transformation process and the effectiveness of the prototype tools that were developed. In addition, the paper presents preliminary results on the evaluation o...

s of a successful solution, with the contexts in which it works. Most work on systems reengineering so far has attempted to provide a methodology for reengineering. Examples include [4], [16], and Unisys' Refits. However, no reengineering methodology has yet had anything like the impact of the successful development methodologies. Possible problems (apart from immaturity of the field) are: Organisations and their reengineering projects differ very widely. One organisation's legacy system may be a small but vital and unmaintainable collection of spreadsheets, another's a system consisting of millions of lines of code. Reengineering problems arise at many different levels, from the architecture of huge systems to the detailed structure of small components. A methodology must either make (explicit or implicit) restrictions on its scope, or be huge, with most of the methodology being irrelevant to any given reengineering project. The potential user of the met

By detecting interoperability problems at the architectural style level, properties of an integrated system can be defined early in the design process. There are many integration strategies, but their definitions do not provide the developer with a foundation to select a strategy for its appropriateness in implementing a correct solution. In this paper, we discuss our preliminary findings from architectural style integration analysis. We form a partial integration taxonomy that shows the relationship between existing integration strategies and the integration elements defined at the architectural level.

Depending on the physical structuring of large distributed safety-critical real-time systems, one can distinguish federated and integrated system architectures. This paper investigates the communication services of an integrated system architecture, which combines the complexity management advantages of federated systems with the functional integration and hardware benefits of an integrated approach. A major challenge is the need to accommodate the communication services to the different types of integrated application subsystems that range from ultradependable control applications (e.g., an x-by-wire system) to non safety-critical applications such as multimedia or comfort systems. In particular, the encapsulation of the communication activities of different application subsystems is required not only to prevent error propagation from non safety-critical application subsystems to higher levels of criticality, but also to facilitate complexity management and permit independent development activities.

The problems posed by mission-critical legacy systems - e.g., brittleness, inflexibility, isolation, non-extensibility, lack of openness - are well known, but practical solutions have been slow to emerge. Generally, organisations attempt to keep their legacy systems operational, while developing mechanisms which allow the legacy systems to interoperate with new, modern systems which provide additional functionality. The most mature approach employs gateways to provide this interoperability. However, gateways introduce considerable complexity in their attempt to maintain consistency between the legacy and target systems. This paper presents an innovative gateway-free approach to migrating legacy information systems in a mission-critical environment : the Butterfly Methodology. The fundamental premise of this methodology is to question the need for the parallel operation of the legacy and target systems during migration. 1. Introduction Many organisations, although solvent and exhibiti...

In many enterprises the presence of heterogeneous legacy information systems is pervasive, nevertheless the d4fferent component organizations need to cooperate in order to oJ]kr new services. The Distributed Object Computing is a valid approach for the definition of a cooperative model among heterogeneous legacy information systems, but few methodologies and architectures explicitly address these issues. This paper describes a case study (or better, a set of case studies) in which these issues were addressed: it is the Cooperative Architecture over the Unitary, Network of the ltalian Public Administration. Then it proposes some methodological suggestions, steming from the case studies, for the development of cooperative systems based on distributed object middleware.

A common characteristic of today's information systems is the distribution of data among a number of autonomous and heterogeneous repositories. Increasingly, these repositories are database management systems (DBMS), but there is still a very large volume of data that is stored in le systems, spreadsheets and others. A fundamental challenge in building next generation information systems is to provide interoperability among these autonomous and potentially heterogeneous repositories. The commercial state-of-the-art in addressing the interoperability of DBMSs is to build gateways. This approach is quite restricted and provides only a partial solution. None of these systems properly deal with semantic or structural heterogeneity of the stored data. An alternative approach toachieving interoperability among DBMSs is the multidatabase approach[11]. Amultidatabase system resides unabtrusively on top of existing database systems and presents a single database illusion to its users. In particular, a multidatabase system maintains a single global database schema against which its users issue queries and updates. It is suggested that this is the approach that should be preferred over gateways [5]. One restriction of multidatabase systems has been that they cannot handle repositories which donothave DBMS capabilities. The introduction of object-oriented technology into data management [3] has lifted this restriction. Object-orientation, with its encapsulation and abstraction capabilities, enable the development of wrappers which encapsulate a particular repository and provide