Reengineering windows software applications into reusable CORBA objects

Reengineering windows software applications into

reusable CORBA objects

Jim-Min Lina,*, Zen-Wei Honga, Guo-Ming Fanga, Hewijin C. Jiaub, William C. Chuc

aDepartment of Information Engineering, Feng Chia University, Taichung City 40724, Taiwan, ROCbDepartment of Electrical Engineering, National Cheng Kung University, Tainan City, Taiwan, ROC

cDepartment of Information Engineering and Computer Science, Tong Hai University, Taichung City, Taiwan, ROC

Received 29 September 2002; revised 2 July 2003; accepted 26 August 2003

Abstract

CORBA is becoming one of the most important middleware for supporting object-oriented and client/server paradigms in distributed

computing systems. However, application systems based on CORBA are still scarce to date. One reason is that only few CORBA object

services have been developed. To have a new CORBA application, a programmer must make the effort to design a program with a CORBA

interface. In our previous work [Proceedings of the Sixth IEEE Computer Society Workshop on Future Trends of Distributed Computing

Systems (1997) 2], a re-engineering approach was proposed to convert RPC-based programs into CORBA objects. This has successfully

increased the development of CORBA applications. However, the source code is required in this approach. In many cases, software designers

cannot acquire the source code. This prevents adapting existing PC software applications, particularly for Windows applications. Our study

addresses this problem. A graphic factory temperature monitor system, which integrates MS-Excel under MS-Windows, was implemented to

demonstrate the feasibility of our approach.

q 2003 Elsevier B.V. All rights reserved.

Keywords: Software reuse; Software integration; CORBA; Functional integration model

1. Introduction

The object-oriented, client/server programming para-

digm has been an important trend for distributed computing

software development. Common Object Request Broker

Architecture (CORBA) [1,2], which was proposed by

Object Management Group (OMG), is one of the most

important middleware programs used to support this

software development paradigm.

However, CORBA applications are still not widely used.

One main reason is that only few CORBA object services

have been developed for CORBA clients. A user that wants to

have a new CORBA application needs to design a program

with a CORBA interface. The speed of software development

is obviously limited. Therefore, it would be significant to

have a method to quickly build a CORBA object service.

Software reuse is a significant way to improve the

speed of software development. Thousands of application

software programs (APP) exist for Personal Computer (PC)

users. CORBA supports object services in heterogeneous

environments, including MS-Windows and UNIX. There-

fore, reusing existing PC APPs would be an efficient and

economic way to construct CORBA object services.

Microsoft COM/DCOM [3] and Active X [4] are

proposed for integrating binary-code APPs under an MS-

Windows environment. However, these techniques have

less interoperability support between Windows platform

software and software built on other platforms. There are

several advantages in reusing existing PC APPs as CORBA

objects:

1. Diverse tools/functions support. Because there are plenty

of existing PC APPs, CORBA users can have the benefits

of harnessing these APPs.

2. Saving time and money. By reusing existing software as a

module in a newly developed software system, coding

for this module is unnecessary. Additionally, many PC

APPs can be purchased at low prices, therefore, saving

both time and money.

0950-5849/$ - see front matter q 2003 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2003.08.003

Information and Software Technology 46 (2004) 403–413

www.elsevier.com/locate/infsof

* Corresponding author. Tel.: þ886-4-2451-7250x3754; fax: þ886-4-

2451-6101.

E-mail address: [email protected] (J.-M. Lin).

http://www.elsevier.com/locate/infsof

3. Ensuring software reliability. Most existing software has

been well designed by venders and well tested by

millions of customers. Reusing such software might have

the potential to increase the software reliability if COTS

software components are carefully and accurately

identified.

4. Evolving software easily. Although PC APPs may evolve

with different released versions, they usually have

compatible user interfaces. An old version of a PC

APP that was re-engineered into CORBA can easily be

upgraded in a plug-and-play manner using a newly

released version in our approach.

5. Decentralization. Most traditional PC APPs are designed

for a single user. Through porting a PC APP on CORBA,

this tool can provide services for multiple clients and

become decentralized software.

6. Revaluing existing software. Many PC APPs may be

retired because of limited functionality. Reusing these

PC APPs can revalue them.

In this paper, a CORBA Functional Integration Model

(CFIM) [5] is proposed for integrating APPs in binary code

mode into CORBA. This paper focuses on how to reuse MS-

Windows software as a CORBA object using the wrapper

technique [6]. In general, there are two main differences

between this system and previous work on wrappers:

1. Most of the traditional wrappers aim to translate

information from various data sources into a uniform,

accessible data representation. In our work, data sources

can be encapsulated and various functionality sources,

such as computation tools, picture drawing tools, data

management tools, and even communication tools, can

be wrapped as reusable units. This contributes additional

functionality’s to the integrated software system.

2. The success of traditional wrappers relies on the

existence of a well-defined programmatic interface,

such as database API, HTTP commands, and so on,

for the encapsulated data sources. Our wrappers are

able to simulate human user operations, such as typing

keyboard keys and clicking a mouse key, rather than

invoking the tool’s services through the tool’s API. A

Coordinator program acts like a human to integrate

applications. It receives an output data stream from

one application, filters the output data stream and then

translates the filtered data into an input data stream in

the format for the application’s input commands.

Therefore, no common integrated software data format

or source code is required in this approach.

A factory temperature monitoring/analyzing system, that

integrates MS-Excel under MS-Windows has been

implemented to demonstrate the feasibility of our approach.

This paper is organized as follows: related software

integration works are introduced in Section 2. The CFIM for

binary-code level software integration and the wrapper

design for Windows tools are addressed in Section 3. An

example, a wrapper for Excel, is given to illustrate Windows

wrapper design in Section 4. A brief conclusion is made in

Section 5.

2. Related works

Various approaches to migrating non-object-oriented

legacy systems to object-oriented platforms have been

proposed in the literature. Some of them have also

successfully migrated a legacy system into distributed

object environments. Wrapper (i.e. encapsulation) is the

most important technique widely used in these approaches.

However, most of the proposed approaches were based on

the assumption that the source code of a legacy system is

available. Conversely, the source code for MS-Windows

applications is seldom available. Therefore, our wrapping

technique is proposed to cope with the difficulty of source

code unavailability. In the following paragraphs, we will

focus on the wrapping technique comparison among the

related works.

Neighbors’ approach [7] was to find the locations of

loosely coupled code regions in a system rather than

individually extracting the software components. His study

was based on a structure-based approach to analyze the

existing program’s architecture and interconnection data

graph. However, he did not encapsulate the extracted

software components into object-orientated modes. De

Lucia, et al. [8,9] proposed a six-step process to migrate

the existing source code into object-orientated format.

During object identification, the legacy program codes

could be decomposed into individual program parts

according to an abstract object model. The legacy system

could then be reengineered by encapsulating the decompo-

sition into object wrappers. De Lucia migrated a legacy

COBOL system into a client/server paradigm [10,11]. Other

researches, such as Serrano et al. [12,13], encompassed data

mining and evolutionary migration techniques into reengi-

neering a legacy program. They also proposed a feasible

reengineering methodology to migrate non-object-oriented

systems into the CORBA platform [14].

Our approach to wrapping MS-Windows applications

into software objects occurs at the non-source-code level.

For commercial-off-the-shelf (COTS) software tools,

especially the MS-Windows applications, source code is

seldom available. The issues in incorporating COTS

software products into a new software development system

have been discussed by the Software Engineering Institute

of Carnegie Mellon University [15,16]. David Carney

regarded COTS software as a ‘turnkey’ system, including

MS-Windows office or desktop computing environment

[17]. He stated that COTS software systems provided

valuable and reliable capabilities. If COTS tools are

correctly and carefully assembled together a COTS software

J.-M. Lin et al. / Information and Software Technology 46 (2004) 403–413404

integrated system could provide many benefits for large-

scale system [18–20].

More software vendors provide various programmable

interfaces for integrating COTS software into their

modern software application systems. Recent 3-tier

architectures, such as CORBA and Java Connector

Architecture, provide standards for developing interfaces.

For example, most database systems support Open

DataBase Connectivity (ODBC), which is an open driver

provided by Microsoft. For example, Active Server Pages

(ASP) is a technique for developing a client/server

system under Microsoft platforms. A programmer could

write an Active X component to access the dataset in a

database system via ODBC. Microsoft Distributed

Common Object Model (DCOM) and .NET share the

same properties with ASP. Java Connector Architecture

(JCA) is another example that provides a Common Client

Interface (CCI) for the software integrator. CCI defines

several APIs for connecting an application server and

enterprise information systems (such as database systems

and transaction systems). JCA thinks that enterprise

system vendors have responsibility to provide relevant

interfaces written with CCI for software integrator.

However, we still have numerous COTS software

products that do not provide programmable interfaces.

MS-Windows applications exemplify this situation.

In the last decade, our previous projects [5,21,22]

proposed an approach to migrate COTS applications under

MS-DOS into CORBA platform to speed up CORBA server

object construction. However, we focused only on software

integration on virtual 8086 machines with single-tasking

operating systems in our previous researches. Potentially,

COTS applications under various platforms, like MS-

Windows and Linux, could be reengineered into the target

object models using the same approach.

3. CORBA function integration model

The UNIX pipe [23] is an inter-process communication

(IPC) mechanism that connects the standard output channel

of the writer process to the standard input channel of the

reader process in a UNIX system. Virtual Machine Pipe

(VMP) [24,25] has a similar idea with UNIX pipe in

performing software integration. Our previous work pro-

posed a VMP based functional integration model, FIM

[24 – 26], for non-CORBA software integration. An

extended FIM, called CORBA FIM (CFIM) [5,6], is

proposed to integrate PC APPs into a CORBA distributed

system.

The architecture for CFIM is shown in Fig. 1. There exists

a coordinator, several servers running DOS, Windows,

CORBA based applications and some clients. Each Windows

APP is encapsulated with a wrapper program. The wrapper

program serves as an interface between a non-CORBA based

application and other CORBA services. A wrapper is an I/O

interceptor with a CORBA interface protocol in CFIM.

Based on VMP technology, the CFIM provides a solution for

data and platform independent software integration. Under-

standing the external operations, input command format and

integrated software output results are all required. Knowing

the internal details of the program source codes is not

required. CFIM provides a framework that supports the

following mechanisms: (1) multitasking, (2) tools I/O

Fig. 1. System overview of CORBA based software integration.

J.-M. Lin et al. / Information and Software Technology 46 (2004) 403–413 405

interception/redirection and IPC, (3) tools coordination, and

(4) a functional integration interface specification mechan-

ism. VMP technology provides the primitive operations to

support multitasking, tools IPC and tools coordination.

CFIM enhances the VMP technology by offering a high level

integration interface specification language, that is used to

specify the integration protocol, and a generator, that

generates the low level interface to each integrated PC APP

according to the specified protocol.

3.1. Functional integration interface specification

mechanism

Because a functionally integrated approach might involve

labor intensive low level integration, such as I/O interception

and redirection, a high level CORBA Functional Integration

Interface Specification Language (CFIISL) is desired to

assist the integration process in a cost effective way. An

integration specification specified by CFIISL defines how

software systems will be integrated. CFIISL includes the

software-IC and software-circuit definitions and specifica-

tions. A CORBA Functional Integration Interface Library

(CFIIL) is actually the repository for storing reusable VMP

codes. A CORBA Functional Integration Interface Generator

(CFIIG) is used to generate the corresponding low level

VMPs for integrated tools.

A software-IC definition describes the integration-related

features of an integrated functional unit (tool). It contains

the following information: (1) Software-IC name, e.g.

Excel, (2) Software-IC type, or name of the operating

system upon which the tool is running, e.g. ‘MS-Windows’,

(3) Software-IC filename, or full path name of the executable

tool file, and (4) Software-IC pins. A software-IC may have

one or more software-pins. Each software-pin is an input (or

output) operation interface for a tool with certain charac-

teristics. The software-pin characteristics are specified by:

(a) Pin ID, i.e. name of a pin; it is usually the name of an I/O

device name, e.g. ‘KEYBOARD’. (b) Pin type, i.e. the

direction of the command/data stream that goes through

the pin, either ‘INPUT’ or ‘OUTPUT’. (c) Pin data type, i.e.

the data type of I/O stream, e.g. ‘ASCII_STRING’,

‘INTEGER16’, ‘INTEGER32’, ‘COORDINATE’,…etc.

and (d) Pin entry i.e. I/O redirector vector or signal type.

The pin entry is the signal type. For example, the keyboard

message interception is achieved by sub-classing the

function GetMessage in the Windows system.

A software circuit consists of several channels that connect

software-pins among software-ICs. Each channel has basi-

cally one-way communications and defined by the communi-

cation and coordination characteristics, including (1) Channel

ID, i.e. name of channel, (2) Channel source, i.e. a pair of

Software-IC ID and Software-pin ID, and (3) Channel

destination(s), i.e. one or more pairs of Software-IC and

Software-pin ID. Fig. 2 shows an example of CFIISL. A more

detailed description of CFIISL can be found in Ref. [21].

3.2. CORBA functional integration interface generator

(CFIIG)

Based on the specifications in CFIISL, a CFIIG generates

the stubs that serve as the interface between software-ICs.

Fig. 3 shows the CFIIG process. CFIIG is responsible for

generating stubs for tools according to the software-IC pin

definition. For Windows APPs, CFIIG will generate a piece

Fig. 2. An example of FIISL.


of code that will intercept the system message queue for the

software-IC pin input and the output data through the

Graphic Device Interface (GDI) and System Development

tool Kit (SDK) Application Programmer’s Interface (API)

for output software-IC pins. CFIIG also generates the

message interface for the coordinator program and syn-

chronizes the operations between the coordinator and tools.

3.3. Wrapper for windows AP

To integrate a Windows APP into a CORBA platform,

the Windows APP should be encapsulated with a wrapper

program, which serves as an interface between the Windows

APP and CORBA clients. In other words, the wrapper hides

the operation details of the Windows APP and represents it

as a CORBA object to its clients.

Therefore, a wrapper takes two responsibilities. The first

is to accept requests from clients and reply with results to

the clients using the CORBA communication protocol. The

second is to convert the requests from clients into the

corresponding input command stream for the encapsulated

Windows APP and redirect the output data from the

encapsulated APP to its clients.

A wrapper is composed of two parts: a communication

interface to CORBA and an I/O interceptor/redirector

module to a Windows APP (see Fig. 4). To illustrate

wrapper operations, an operation scenario in which requests

are processed from CORBA clients is shown in Fig. 5. There

are six steps in this scenario:

Step 1

A CORBA client sends a request message to a CORBA

server through the CORBA interface module.

Step 2

The CORBA interface module then translates the request

into corresponding event messages and command strings for

the wrapped Windows tool.

Step 3

The wrapper sends the event messages and command strings

into the Windows tool.

Step 4

After a command execution in the Windows tool, the

wrapper acquires the data results from the Windows tool.

Step 5

The intercepted data is acquired from the Windows tool.

This data are filtered and reproduced into data that can be

passed into the CORBA interface module.

Step 6

The CORBA interface module prepares the result message

and replies to the corresponding CORBA client.

4. An experimental system

MS-Excel is a popular and useful software application.

There are many powerful and useful functions in it, such as

data calculation and a convenient statistical graphics

functions. In this section, Excel will be integrated into an

experimental Graphical Temperature Monitoring System

(GTMS) for an industry factory. This is achieved by

wrapping an Excel task as a CORBA object. Three parts

must be implemented in the Wrapper: input redirection,

output redirection, and CORBA interface.

4.1. Input redirection in windows

Because most Windows applications are driven by event

messages and receive input from mouse and keyboard

devices, the windows task input channel can be redirected

Fig. 3. CORBA functional integration interface generation.

Fig. 4. Structure of a wrapper.

Fig. 5. The scenario of processing request.


using an event message simulation for mouse and keyboard

devices.

Fig. 6 shows the input redirection by the wrapper. There is

a system message queue in MS-Windows to store external

events such as mouse or keyboard events. Once the mouse

clicks on a window, this window becomes active and receives

the program focus. A thread will receive event messages in

system message queue only as this thread receives focus.

Four steps are performed in the wrapper program to intercept

the input events from a target window task:

Fig. 6. Input channel redirection by the wrapper.

Fig. 7. Program codes for generating keyboard events.


Step 1

The focus is set the wrapped application using the wrapper.

Step 2

The Wrapper generates the necessary control messages and

sends them to the system message queue.

Step 3

The wrapped application will consequently receive the

control messages as if they were generated by a keyboard or

mouse.

Step 4

The wrapped application will react and perform the

corresponding operations to acquire the desired results

according to the control messages.

In addition to the above approach, Windows API-

SendMessage or OLE techniques can also be applied.

However, there are many problems using those techniques.

For example, when using SendMessage API, lots of time is

spent getting the windows handle needed to send input

events. In using OLE, not all applications support the OLE

protocol such that the applicability is limited. Therefore,

those methods were not adopted in this research.

The program code segment listed in Fig. 7 is used to

illustrate how keyboard and mouse events are generated in a

wrapper for a popular Windows application-MS-Excel.

The wrapper is programmed in Visual Cþþ with MS-

Platform SDK APIs. The same wrapper program can be

applied to other MS-Windows platforms, like Windows 98,

2000, ME and XP. The function of this program segment is

to send a keyboard event to Excel. This program is

explained as follows.

First the wrapper gets the Excel Handle window using

FindWindow () function:

ExcelHWND ¼ < FindWindow(‘XLMAIN’, NULL)

Second, GetWindowThreadProcessId() is used to get

the Excel thread identifier.

TheirId ¼ <

GetWindowThreadProcessId(ExcelHWND,NULL);

Because the wrapper will focus on Excel, it must attach

the Excel input to itself. AttachThreadInput() function

is used to attach the wrapper thread ID to the Excel

thread ID.

< AttachThreadInput(OurId, TheirId, TRUE);

The SetFocus() function is called to set the focus on

Excel. The keyboard event is then generated using the

keybd_event() function.

Fig. 8. Program codes for generating mouse events.

Fig. 9. Output redirection of a windows application.


< SetFocus(ExcelHWND);

< keybd_event(ScanCode, Ch,KEYEVENTF_EXTEN-

DEDKEY,0);

In the same way, mouse events are generated using

the MS-Windows USER module function as shown in

Fig. 8.

4.2. Output redirection of windows application

Fig. 9 shows the conceptual structure of the output

redirection in the wrapper. The Windows Clipboard

mechanism is used to redirect/intercept the output data

from the wrapped application. First, the Wrapper triggers

the wrapped application to save the output data in the

clipboard space using the output redirection mechanism.

The wrapper then acquires the needed data from the

Clipboard space.

The program segment codes listed in Fig. 10 are used to

illustrate how the needed data is acquired from the

Clipboard space. This is achieved through the following

operations with corresponding MS Platform SDK APIs:

Step 1

Generate ‘mark’ and ‘copy’ keyboard events. These events

will cause the wrapped application to save the needed output

data into the Clipboard space.

Step 2

Open the Clipboard by calling the OpenClipboard function.

Step 3

Select a proper Clipboard data format.

Step 4

Retrieve the data in the Clipboard space by calling the

GetClipboardData function.

Step 5

Close the Clipboard by calling the CloseClipboard

function.

Some problems could be incurred using this method. The

first problem is the data output ending perception sent to the

Clipboard space. In other words, there is a process

coordination problem between the wrapper and the wrapped

application. To synchronize the wrapper and the wrapped

application, a hook function is installed in the wrapper to

monitor messages in the wrapped application (see Fig. 11).

The second problem is retrieving the information contained

in the data in bit-map format. Wrapping image-processing

software to retrieve/interpret bit-map images might be a

possible approach for solving this problem.

4.3. CORBA interface

To execute a program in CORBA convention, it is

necessary to define a CORBA interface for the program.

Fig. 12 shows a scenario in which a CORBA application is

generated. First, the CORBA interface is defined in an

interface definition file (of file type .idl) using CORBA

Interface Definition Language (IDL). This file is then

compiled using an IDL compiler and a header file (of file

type .h) is generated for both the client and server sites. The

programs for both counterparts are compiled into executable

images with the above header file.

Fig. 10. Program codes for getting data from clipboard.

Fig. 11. Program codes for monitoring the message queue.


4.4. Graphical factory temperature monitoring system

A factory temperature monitoring/analyzing system in

which MS-Excel is reused as a chart-display unit is

implemented using the proposed method. In the simulated

factory the temperature of numerous locations must be

properly monitored and controlled. A Graphical Factory

Temperature Monitoring System (GFTMS) that collects

temperature data and graphically shows the temperature

analysis chart is used (see Fig. 13). In our implementation,

the Excel program was selected and wrapped as a server

that collects and analyzes temperature data. In each of the

client sites, a random number generator is used to

simulate a temperature sensor and generate the tempera-

ture data. Through the Orbix (a product of CORBA),

clients send temperature data to the server at regular time

periods. Upon receiving this temperature data, the wrapper

filters the data and converts it into proper data format and

the corresponding Windows events for Excel. This

converted data and events will then be sent to Excel.

Excel will be Periodically triggered to draw the

temperature analysis chart.

Fig. 12. Generation of a CORBA application.

Fig. 13. GFTMS structure.


The following program slice is the definition of an IDL

file for the ExcelWrapper

//wrapper.idl

//define the interface of Wrapper

interface ExcelWrapper

{

short InputData(in short NoteID,in short Temperature);

};

In the interface, only the InputData() function with a

short data type is defined. It will be periodically called to

send the temperature data to the server. The experimental

GFTMS was successfully implemented for two man

(undergraduates) months. The GFTMS outlook is shown

in Fig. 14. It is apparent that the proposed approach is a

quick and economic way to build new software compared

with design from scratch.

5. Conclusions

Software reuse through software integration is probably a

fast way to construct new software applications. A CFIM

was proposed to achieve software integration under

heterogeneous systems, such as the CORBA environment.

This paper proposed a method to construct a CORBA object

by reusing/wrapping an existing Windows tool. There are

many advantages in this scheme, such as: (1) increasing the

software productivity of CORBA applications; (2) revaluing

existing Windows tools; (3) migrating a traditional

centralized tool, such as a Windows tool, into distributed

software. We implemented an experimental graphic factory

temperature monitoring system that integrates the popular

Windows tool, MS-Excel, under the Orbix environment.

Two-man-months (undergraduate students) were used to

accomplish this integration. This shows a promising result.

With the same goal, wrappers for other centralized tools,

such as MS-DOS and UNIX tools could also be developed.

In our approach, CORBA is not the only specified

architecture. With the use of this wrapping approach, we

can migrate the wrappers to other architectures [23,27], such

us RMI or Web Service, without significantly modifying the

wrapper. This research could be enhanced in numerous ways

in the future. For example, PIN data type I/O stream could be

implemented using XML/DTD; to compare implementations

using various 3-tier architectures; and so on.

Acknowledgements

The authors thank the anonymous referees for their

insightful suggestions on this paper. This research was

supported by National Science Council, Taiwan under Grant

NSC90-2213-E035-003.

References

[1] Object Management Group, CORBA: Common Object Request

Broker Architecture and Specification Revision 2.0, July 1995.

[2] OMG, CORBA 2 Interoperability Draft, OMG Document Number 95-

3-10, March 1995.

[3] A. Ewald, M. Roy, Choosing Between CORBA and DCOM, Object

Magazine October (1996).

[4] D. Chappell, Understanding Active X and OLE, Microsoft Press,

Redmond, WA, 1996.

[5] J.-M. Lin, W. Chu, W. Lo, H. Yang, C.-W. Lu, Building CORBA

objects with DOS software applications, Proceedings of the 22nd

International Computer Software and Applications Conference,

COMPSAC ’98 August (1998) 252–257.

[6] Y.-C. Pan, J.-M. Lin, W.-T. Lo, Wrapping existing software tools as

CORBA objects, Proceedings of Eighth Workshop on Object-

Oriented Technology and Applications, Chungli, Taiwan August

(1997) 187–193.

Fig. 14. Out looks of GFTMS user interface.


[7] J.M. Neighbors, Finding reusable software components in large

systems, Proceedings of the Third IEEE Working Conference on

Reverse Engineering November (1996) 2–10.

[8] A. De Lucia, G.A. Di Lucca, A.R. Fasolino, P. Guerra, S. Petruzzelli,

Migrating legacy systems towards object-oriented platforms,

Proceedings of IEEE International Conference on Software Mainten-

ance October (1997) 122–129.

[9] A. Cimitile, U. De Carlini, A. De Lucia, Incremental migration

strategies: data flow analysis for wrapping, Proceedings of the

Fifth IEEE Working Conference on Reverse Engineering October

(1998) 59–68.

[10] G. Canfora, A. Cimitile, A. De Lucia, G.A. Di Lucca, Decomposing

legacy programs: a first step towards migrating to client–server

platforms, Proceedings of the Sixth International Workshop on

Program Comprehension June (1998) 136–144.

[11] L. Aversano, G. Canfora, A. Cimitile, A. De Lucia, Migrating legacy

systems to the Web: an experience report, Proceedings of the Fifth

European Conference on Software Maintenance and Reengineering

March (2001) 148–157.

[12] M. Serrano, C. Montes De Oca, D. Carver, Evolutionary migration of

legacy systems to an object-based distributed environment, Proceed-

ings of the IEEE International Conference on Software Maintenance

August–September (1999) 86–95.

[13] M. Serrano, D. Carver, C. Montes De Oca, Mapping object-oriented

systems to distributed environment, Proceedings of 13th International

Conference on Industrial and Engineering Applications of Artificial

Intelligence and Expert Systems June (2000) 79–84.

[14] M. Serrano, D. Carver, C. Montes De Oca, Reengineering legacy

systems for distributed environments, The Journal of Systems and

Software (2002) 37–55.

[15] Carnegie Mellon University Software Engineering Institute (SEI)

COTS-Based System (CBS) Monograph Series, http://www.sei.cmu.

edu/cbs/monographs.html.

[16] C. Albert, L. Brownsword, Evolutionary Process for Integrating

COTS-Based Systems, Technical Report CMU/SEI-2002-TR-005

http://www.sei.cmu.edu/publications/documents/02.reports/02tr005.

html.

[17] D. Carney, Assembling large systems from COTS components:

opportunities, cautions, and complexities, SEI Monographs on the

Use of Commercial Software in Government Systems June

(1997).

[18] K. Ballurio, B. Scalzo, L. Rose, Risk reduction in COTS software

selection with BASIS, Proceedings of International Conference on

COTS-Based Software Systems (ICCBSS), February, Springer, 2002,

pp. 31–43.

[19] X. Burgues, C. Estay, X. Franch, J.A. Pastor, C. Quer, Combined

selection of COTS components, Proceedings of International Con-

ference on COTS-Based Software Systems (ICCBSS), February,

Springer, 2002, pp. 54–64.

[20] N.A.M. Maiden, H. Kim, C. Ncube, Rethinking process guidance for

selecting software components, Proceedings of International Con-

ference on COTS-Based Software Systems (ICCBSS), February,

Springer, 2002, pp. 151–154.

[21] J.-M. Lin, Cross-platform software reuse by functional integration

approach, Proceedings of the 21st International Computer Software

and Applications Conference, COMPSAC ’97 August (1997)

402–408.

[22] S.-C. Lee, J.-M. Lin, H.C. Jiau, Constructing COTS-based software

components with reusing COTS products, Proceedings of Inter-

national Symposium on Multimedia Software Engineering December

(2000) 289–296.

[23] D.M. Ritchie, K. Thompson, The UNIX Time-Sharing System, Bell

System Tech. Journal, 57(6), pt.2 July–August 1978.

[24] J.-M. Lin, S.R. Tsai, L.-M. Tseng, Integrating existing software

packages using the virtual machine technique, Journal of Systems

Software 18 (3) (1992) 207–218.

[25] J.-M. Lin, S.R. Tsai, Distributed software integration using a remote

virtual machine pipe mechanism, Proceedings of 1992 International

Computer Symposium December (1992) 13–15.

[26] J.-T. Wu, G.-M. Fang, Z.-W. Hong, J.-M. Lin, Reengineering

COTS-based products as web service applications, Conference

on Integrated Design and Process Technique (IDPT) (2003)

in press.

Further Reading

K. Liang, W.C. Chu, S.-M. Yuan, W. Lo, From legacy RPC services to

distributed objects, Proceedings of the Sixth IEEE Computer Society

Workshop on Future Trends of Distributed Computing Systems

October (1997) 2–7.


http://www.sei.cmu.edu/cbs/monographs.html

http://www.sei.cmu.edu/cbs/monographs.html

http://www.sei.cmu.edu/publications/documents/02.reports/02tr005.html

http://www.sei.cmu.edu/publications/documents/02.reports/02tr005.html

Documents

Reengineering windows software applications into reusable CORBA objects