Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-10-30
2002-08-27
Dam, Tuan Q. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C709S241000
Reexamination Certificate
active
06442749
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer software architectures, and more specifically, to a software architecture for applications composed of a plurality of software components which perform specific tasks. The inventive architecture facilitates execution of the software components in different sequences and the efficient transfer of data or documents between components. The invention also relates to computer hardware and a method for implementing a task oriented application in accordance with the inventive architecture.
2. Description of the Prior Art
The field of computer software engineering includes the development of design principles intended to guide the structured design and implementation of software applications. One such principle is that of a task oriented architecture for an application. In such an architecture, the functions performed by the application (e.g., data processing functions such as spell checking, transmission of data to a specified location, data conversion, etc.) are represented as separate tasks with each task performed by a dedicated component or module of the application program. The components or modules are typically invoked in a specified sequence without the need for inputs from a user. The invoked components perform a sequence of tasks which execute an overall function desired by the user.
In order to achieve greater efficiency in terms of increasing the uniformity with which applications execute a sequence of tasks, and in reducing the size of software programs, it is desirable that a component or module be capable of being shared between multiple applications. This permits a set of generic task performing components to be combined in a specific sequence to perform a desired set of functions. A component or module based software architecture facilitates this because each component can be designed to be substantially self-contained.
However, a problem encountered when attempting to utilize a component for a specific task in different sequences with other components or as part of multiple applications is that the task component interface may not be fully compatible with that of the calling component(s) in the application, or with that of the application component(s) called by the task component. This problem also limits the ability to rearrange components designed to implement various tasks into new applications.
While it is possible to design every software component of every application to have a common interface, this is an enormous task. This approach also does not address the issue of how to access existing software components (sometimes referred to as “legacy” software) which may have been written with incompatible interfaces.
One approach which permits software components with different interfaces to operate together is termed a “wrapper”. A wrapper is a software structure which is positioned above or outside of (in a hierarchical sense) a specific application or component. The wrapper functions as an intermediary between the “wrapped” application or component and an external application or component. The wrapper accepts an input instruction from the external (calling) application or component and, by having a common interface with the wrapped application or component, is able to cause that wrapped application or component to be executed to perform a desired task. This is typically accomplished by converting the character stream from the wrapped software into a procedural or object oriented application programming interface (API). The external software applications or components interact with the wrapped software through the API. The wrapper thus removes the necessity for a compatible interface between the calling and called applications or components. A wrapper may thus be viewed as performing a translation function between a universal interface and the proprietary interface of the wrapped component.
However, although use of a wrapper provides a solution to the problem of incompatible software application and/or component interfaces, conventional wrappers do have limitations. The primary disadvantage of conventional wrappers is that they are specifically tailored to the wrapped software. This means that the code in the wrapper is written in the same language as the wrapped component, or in the form of a procedural interface to C or COBOL or an object oriented interface to C++ or Smalltalk. As a result, a new wrapper must be written for each new wrapped application or component. In addition, a wrapper written in such languages cannot be modified by a user to accommodate changes in the wrapped component. This places a significant limitation on a user's ability to customize and extend the wrapper, and as a result, the flexibility of the software architecture itself
Another disadvantage of conventional task oriented architectures relates to the way in which data or documents are transferred between different components of an application, or between components in different applications. In conventional architectures, the actual data or document is transferred in a proprietary format between components. This limits the type of data or documents exchanged (since the types exchanged must conform to the proprietary format, which may not recognize data types which are not hard coded into the format), and does not permit a component to modify the attributes of the data which are exchanged. This can limit the ability of the components to perform tasks which may require different data attributes to operate than those defined by the format.
What is desired is a computer software architecture for task oriented applications which can be customized by a user to permit access to components or applications having different interfaces. Computer hardware and a method for implementing such a software architecture is also desired.
SUMMARY OF THE INVENTION
The present invention is directed to a software architecture for task oriented applications. The architecture utilizes a wrapper as an intermediate structure between an external calling application and a wrapped component or module. The wrapper is written in a script language and acts to provide a bridging interface between the external application and the wrapped component. Data is transferred among components through the intermediary of a table of contents (TOC) file which contains data attribute information and hyperlinks to the actual data. The invention is also directed to computer hardware and methods for implementing the inventive software architecture.
REFERENCES:
patent: 5430836 (1995-07-01), Wolf et al.
patent: 5457798 (1995-10-01), Alfredsson
patent: 5473777 (1995-12-01), Moeller et al.
patent: 5475845 (1995-12-01), Orton et al.
patent: 5680551 (1997-10-01), Martino, II
patent: 5761656 (1998-06-01), Ben-Shachar
patent: 5806079 (1998-09-01), Rivette et al.
patent: 5809318 (1998-09-01), Rivette et al.
patent: 5953534 (1999-09-01), Romer et al.
patent: 5960202 (1999-09-01), Granston et al.
patent: 5966707 (1999-10-01), Van Huben et al.
patent: 5974258 (1999-10-01), Ferri et al.
patent: 5978579 (1999-11-01), Buxton et al.
patent: 6009525 (1999-12-01), Horstmann
patent: 6044469 (2000-03-01), Horstmann
patent: 6163794 (2000-12-01), Lange et al.
patent: 6179489 (2001-01-01), So et al.
patent: 6237044 (2001-05-01), Jordan
Datamation May 15, 1995 “Legacy Code: Don't Bag It, Wrap it”.
Datamation May 15, 1995 “Bring Legacy Code into the Object Realm”.
Title: Chimera: hypertext for heterogeneous software environments, Author: Anderson et al, ACM, 1994.*
Title: Constructing application-specific heterogeneous embedded architectures from custom HW/SW applications, Author: Steven Vercauteren et al, ACM, 1996.*
Title: Reconciling environment integration and component independence, Author: Kevin Sullivan et al, ACM, 1990.
Araki Hirokatsu
Hirao Tsuyoshi
Matsumoto Hitoshi
Takahashi Tadashi
Wakitani Masaru
Coudert Brothers LLP
Dam Tuan Q.
Das Chameli C.
Fujitsu Limited
LandOfFree
Apparatus, method and architecture for task oriented... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus, method and architecture for task oriented..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus, method and architecture for task oriented... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2960244