Logic, or functional, adapters encapsulate not only legacy data but also the business logic in the legacy system. Wrappers are a form of logic adapter that can be used to encapsulate legacy logic within a modern interface. The logic-wrapping techniques described in this section can access legacy data, if required, in addition to legacy logic. Object-Oriented WrappingThe conceptual model of object-oriented wrapping is deceptively simple: Individual applications, common services, and business data are all represented as objects. In reality, object-oriented wrapping goes beyond simply requiring analysis, decomposition, and OO abstraction. The encapsulation, reengineering, and coexistence of object with legacy (ERCOLE) project describes an exemplifying process to wrap legacy applications with OO systems [De Lucia 97]. Of the multiple difficulties involved in wrapping a legacy system, two are of special relevance: the definition of appropriate object-level interfaces and the need for integrated infrastructure services. Translating the monolithic and plain semantics of the legacy system to an object-oriented system can be a difficult task. A good knowledge of the domain can greatly help. For example, Stets describes an experience in which the Win32 API is translated into objects, using specific knowledge of the structure of the operating system [Stets 99]. Unfortunately, developers wrapping a system rarely have such deep domain knowledge. Some techniques have been developed to streamline the legacy-to-OO mapping. In one such method, every coarse-grained persistent item is mapped to an object, and services are assigned to objects with an algorithm that minimizes coupling [Cimitile 97]. Although these and other techniques are useful in extracting objects from legacy systems, the mapping problem is far from being solved . Component WrappingComponent wrapping is similar to OO wrapping, but components , unlike objects, must conform to a component model. Although there are several commercially viable component models, we focus here on developing logic wrappers using EJB, because this is the prevalent component model used in our case study (see Section 9.2 for more information on EJB). The first step in wrapping a legacy system using EJB is to separate the legacy system into logical units ”shown in Figure 13-3 as function 1 and function 2. The difficulty of dividing the legacy system into discrete functions depends on how the separation was defined in the legacy system interfaces and whether new interfaces must be built. Although a black-box approach is preferable, it still may be necessary to peer into the black box to truly understand the legacy system [Plakosh 99]. Figure 13-3. Wrapping legacy business logic using EJBs The next step in wrapping the legacy business logic is building a single point of contact to the legacy system. It is a good idea to centralize all the communication knowledge in a single software artifact. The communication method used will depend on the particular situation. Options include RMI-IIOP, sockets, or even MOM. This has the advantage of uncoupling the EJB server from the legacy system and allowing asynchronous communication. This single point of contact can be implemented internally as a bean ”the adapter in Figure 13-3 ”or externally as a service broker ” a software component outside the EJB server. The differences depend mainly on the communication method and security restrictions. For example, to create a new thread or to listen to a socket, the single point of contact must be outside the application server because the EJB specification prevents EJBs from being multithreaded or listening to sockets. The final step in wrapping the legacy business logic is implementing a wrapper bean for each module in the legacy system. In Figure 13-3, this wrapper is shown as Bean 2. These enterprise beans forward requests to the legacy system, using the single contact point, in a manner similar to object wrapping. This component approach has several advantages. First, the benefits of component-based systems can be supported with relatively limited effort. We can, for example, build new EJBs that use the wrapper beans in unanticipated ways, greatly improving system flexibility. Second, wrapper beans are bona fide enterprise beans and therefore can be fully integrated with all the management facilities and services included with the application server. Finally, wrapping legacy business logic provides a road map to substitute the old system incrementally. After wrapping the functionality of the legacy system, we can reimplement wrapper beans one at a time ”Bean 1 in Figure 13-3. The system and the clients will not notice any disruption, because the reimplemented bean will maintain the same interfaces provided by the wrapper bean. In time, it is possible to replace the old system completely. Wrapping legacy business logic with EJBs is not without risk. The EJB specification is porous, and portability problems can arise among vendors ' application servers [Comella-Dorda 00]. In addition, the Java programming language may be unsuitable for performance-critical or real-time applications. [2]
Another issue involves providing services for deployed components. A wrapper bean represents business logic in an external legacy system. A mechanism is needed to manage services across the legacy system and the EJB server. This mechanism, called a connector, represents a Java solution to the problem of providing connectivity between the many application servers and EISs already in existence [Sharma 02]. Many application servers, including BEA's WebLogic and IBM's WebSphere, support the J2EE Connector Architecture (JCA) adapters for enterprise connectivity. Using JCA to access an enterprise information system is akin to using JDBC to access a database. Connectors, shown in Figure 13-4, manage transactions, security, and resource pooling between the server and the legacy resource. This architecture allows the development of a standard connector to access a legacy data source or system. The connector can be plugged into any application server that supports the connector mechanism. It is, of course, still necessary to implement application-level communication. Figure 13-4. Integrating legacy business logic using connectors ComparisonTable 13-2 contrasts the two logic adaptation techniques described in this section. Table 13-2. Comparison of Logic Adaptation Techniques
|