 |
Description  |
|
|
FIELD OF THE INVENTION
The present invention relates to the field of software system architecture;
in particular, to object-oriented architectures constructed for the
development of complex software systems.
BACKGROUND OF THE INVENTION
As the software industry matures and the available computational power
increases, software developers are being challenged with problems of
inescapable complexity. This means that the problems which researchers are
attempting to confront in software are of such complexity that it is
difficult-if not impossible-for an individual developer to comprehend all
of the subtleties of a particular design. In some cases, the complexity of
such systems exceeds the human intellectual capacity.
Consider the requirements of a software system which must manage the
development and manufacturing process of a multi-engine commercial
aircraft; or the fabrication of a very large scale integrated (VLSI)
microprocessor circuit. These problems are typical of those encountered in
the management of work in a factory shop floor. As is appreciated by
practitioners in the art, the management of a factory floor environment is
one of the more imposing tasks facing computer scientists today. The
enormity of the requirements of a factory floor software system has
prompted researchers to search for alternative architectures aimed at
handling and controlling the vast complexity of the tasks involved.
In the past, factory floor software systems have comprised traditionally
centralized systems. The basic assumption of these prior art approaches is
that all of the functional programs run on one centralized mainframe
computer system. According to these architectures, the factory floor
machine functions were embodied in executable subroutines. However, the
main problem inherent with such architectures is that they ignore a basic
fact about the factory floor environment; that is, that the factory floor
is distributed in nature. Distributed in the sense that machines,
resources, labor, work instructions, etc., are all physically located in
different areas of the shop floor. Moreover, the task of manufacturing a
product requires complex coordination of all of the objects listed above.
Thus, the nature of the problem flies in the face of conventional
architectural solutions. Because of the distributed nature of the factory
floor environment, execution of software functions inherently created
conflicts in the control of the factory floor environment in prior art
systems.
As will be seen, the present invention provides an object-oriented process
architecture for factor floor management software which is capable of
tracking, monitoring and controlling all aspects of the factory
environment in not simply the work in progress. Importantly, the
architecture of the present invention is compatible with the distributed
nature of the factory floor since it is itself distributed in make-up. As
a result, the present invention produces a substantial savings in terms of
performance and in the development of a factory floor software system.
Furthermore, because the present invention is implemented in an
object-oriented manner, the architecture provides the ability to model
real world events and objects directly in software. Other advantages and
methods of the present invention will become apparent upon a reading of
the detailed discussion which follows.
SUMMARY OF THE INVENTION
An object-oriented architecture for a factory floor management software
system is described. According to the present invention, factory floor
entities are modelled as factory objects within a relational database.
This database includes a library which contains objects that model all
factory elements.
In one embodiment, the present invention comprises an interface server
means for facilitating user interaction with the software system via one
or more of the factor/floor entities. These entities include operators,
supervisors, or other users. Most often, the interface server means
comprises an X-terminal device or a work station computer running on an
X-server. In other instances, the interface server means may also include
a bar code device coupled to another work station computer which runs a
bar code device server.
The present invention further comprises Application Engine means for
processing user interaction of events and generating application service
requests as a result. Application service means are also included for
processing the application service requests and generating a database
service request in response. These database service requests are utilized
to retrieve, manipulate and update data stored within the relational
database. A database service means provides indirect access to the
relational database in response to an application service request. Each of
these means bring together information gathered from the factory floor in
the form of user input.
Finally, a Communication Manager means is employed for coordinating
interprocess communication between the Application Engine means, the
Application Server means, and the Database Server means.
Importantly, the architecture of the present invention allows for each of
the major components described above to be distributed among computer
resources that are networked across the factory floor and even among
multiple factory sites.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be understood more fully from the detailed
description given below and from the accompanying drawings of the
preferred embodiments of the invention, which, however should not be taken
to limit the invention to these specific embodiment but are for
explanation and understanding only.
FIG. 1 depicts a block diagram of a conventional approach to software
organization.
FIG. 2 is a diagram of an example of a hierarchy of selected objects
commonly found in a factory floor shop floor environment.
FIG. 3 illustrates the relationship between various factory objects in
accordance with the currently preferred embodiment of the present
invention.
FIG. 4 illustrates a simple routing example for the manufacture of a
product as a sequence of work-related operations.
FIG. 5 shows the hierarchy of factory floor objects in accordance with the
currently preferred embodiment of the present invention.
FIG. 6 illustrates the distributed nature of the architecture of the
currently preferred embodiment of the present invention.
FIG. 7 illustrates the architectural layers maintained by the present
invention
FIG. 8 is a diagram of the object-oriented process architecture of the
currently preferred embodiment.
FIG. 9 illustrates the levels of functionality incorporated into the
currently preferred embodiment of the present invention.
FIG. 10 shows how a group of application nodes are grouped together to form
a domain in accordance with the currently preferred embodiment of the
present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT(S)
An object-oriented architecture finding application in a factory floor
management software system is described. In the following description,
numerous specific details are set forth, such as specific object-types,
tasks, routines, etc., in order to provide a thorough understanding of the
preferred embodiment of the present invention. It will be obvious,
however, to one skilled in the art that the present invention may be
practiced without these specific details. In other instances, well-known
elements have not been shown in detail in order to avoid unnecessarily
obscuring the present invention.
In the course of describing the present invention, frequent reference will
be made to use of the invented architecture in conjunction with a factory
floor management software system. It is appreciated that this
implementation merely reflects the currently preferred embodiment of the
present invention, and should not be taken as a limitation on the scope of
the invented architecture. It should also be understood that the concepts
embodied in the present invention are applicable, or may be extended, to
encompass other implementations, software systems, applications, etc. That
is, the novel architecture described below is fundamental in nature,
having considerable application beyond the realm of the factory floor
environment.
A Brief Overview Of Object-Orientation
A basic assumption underlying prior architectural approaches is that all of
the software code runs on a single mainframe computer. This means that
instructions are executed in a serial manner on one central processing
machine, usually a very large centralized computer. These systems
typically assume a functional approach to the way that programs are
implemented. That is, the functional aspects of the program are identified
along with how the program can access the central database to obtain the
data it needs to perform that particular function. The architectural
diagram of FIG. 1 illustrates this prior art approach.
Suppose the user wants to represent a machine as an entity possessing
certain attributes. For instance, the machine may have an attribute called
"NAME" which represents the machine's identification. Other desirable
attributes might include "STATE", i.e., the state of the machine - whether
the machine is currently idle, in repair, busy, etc. All of the attributes
of the machine represent data. This data is shown being resident within
block 10 of FIG. 1.
Also associated with the machine is a set of functions, each denoted in
FIG. 1 by blocks 11-13. For example, function F.sub.1, represented by
block 11, might correspond to the function "START THE MACHINE". In other
words, the execution of function F.sub.1 transfers the state of the
machine from idle to busy. Likewise, function F.sub.2 might be defined as
the function "STOP THE MACHINE"; and function F.sub.N might correspond to
the function "BRING THE MACHINE DOWN FOR REPAIR".
Essentially, what each of the functions represented by blocks 11-13 does is
that, given a particular machine identity (i.e., NAME), the function
operates on the state of the machine (i.e., STATE). Thus, according to the
conventional software approaches, each of the functions F.sub.1 -F.sub.N
is embodied in a separate subroutine.
The main drawback of this approach, however, is that there exists a
potential for any number of these subroutines to be in conflict with one
another at any point in time. Moreover, running such a program on a
central computer ignores the fact that in reality many systems are
distributed in nature and therefore require an architecture capable of
assimilating that distributed characteristic.
Object-oriented software design is the construction of software systems as
structured collections of abstract data type implementations. Importantly,
object-oriented software construction allows an entity to be modeled as an
object having certain characteristics and certain behaviors. In accordance
with the present invention, machines utilized in a factory floor
environment are modeled by an associated set of characteristics and
functions which it may perform. In this sense, the machine's
characteristics (corresponding to the data aspects of software) and
behavior (corresponding to the functional aspects of software) are totally
encapsulated about a single concept called "object". One of the benefits
of object-orientation is that by encapsulating characteristics and
behavior into a concept called "object", a high level of correspondence
between the software model and reality is preserved. Object-orientation is
also ideally suited to a distributed system architecture which relies upon
a number of separate computers (e.g., nodes) all of which are connected
through a common network; and all of which run programs concurrently
(depending, of course, upon the specific functions requested by the user).
A second important concept in object-orientation is the concept of
inheritance. This is demonstrated by the example of FIG. 2. In FIG. 2, an
object called "EQUIPMENT" is represented by ellipse 15. This object
possesses certain characteristics such as weight, dimension, etc.
Subclassed from the parent object "EQUIPMENT" are objects 16 and 17
labelled "STATIONARY" and "MOBILE", respectively. Basically, the hierarchy
of FIG. 2 abstracts the common characteristics from the moving and
stationary classes into the higher, more generalized, class of object
class called "EQUIPMENT".
Note that the "MOBILE" subclass inherits the characteristics and behavior
of the superclass object, but each subclass object includes additional
characteristics which differentiate them from one another. In essence, the
hierarchy of FIG. 2 represents a sort of taxonomy of progressively higher
levels of differentiation from top to bottom, and progressively higher
levels of abstraction from bottom to top. For example, subclassed from the
object "MOBILE" are such objects as tools, fixtures, etc. Similarly a
subclass of "STATIONARY" equipment includes machine, sensor, or other
similar objects. Thus, it can be seen how the object-oriented nature of
the present invention helps to reuse some objects which were previously
defined as a superset. From a software development standpoint, this
approach produces substantial savings in performance and development time.
Observe that the object-oriented scheme represented by the example of FIG.
2 is vastly different from the functional approach typical of the prior
art. In a purely functional approach, each entity is broken into its data
in a set of corresponding functions or subroutines, ignoring the common
characteristics which could be reused in an efficient manner. One of the
other key attributes of the object-oriented approach of the present
invention, as applied to factory floor management software systems, is the
ability to dynamically link certain behavior. This means that is, because
common characteristics are subsumed by increasing levels of abstraction in
the object level hierarchy, behaviors that can be commonly applied to
various objects within that grouping can be dynamically linked. For
example, the user could define a behavior called "PRINT" on a parent
object. The parent object itself could be subclassed into different types
of printers, e.g., laser printer, line printer, etc. When a command
"PRINT" is issued to each device, the software has the ability to realize
that the print command is different for each of the different printer
objects, thereby invoking the appropriate methods and routines specific to
each.
This example points out one of the primary advantages of objects; that is,
their reusability. Combinations of objects and messages to the objects,
allow more general functionality to be constructed. Thus, the
object-oriented nature of the present invention encapsulates functionality
at the object library and Application Engine and Server levels, as will be
described in more detail shortly.
For a fuller discussion of object-oriented software construction, see
"Object-Oriented Design With Applications" by Grady Booch, Chapters 1-7,
1991, which is herein incorporated by reference. Other references which
discuss the object-oriented paradigm include: "The C++ Programming
Language" by Bjarne Stroustrup, 1986; and "Object-Oriented Software
Construction" by Bertrand Meyer, 1988.
The Factory Floor Environment
The present invention is currently embodied in factory floor management
software for discrete and batch manufacturing work. However, before
preceding with a more detailed discussion of this preferred embodiment, it
is helpful to briefly describe the organization of a typical factory floor
environment.
The vast majority of factories can be modeled using a small number of basic
concepts. The software that models these concepts must be capable of
tracking, monitoring and controlling all of the various activities of the
factory floor. The present invention, through its use of an
object-oriented software architecture, implements these concepts as
factory objects. From a standpoint of functionality, the system software
is defined by the behavior of these objects.
In the currently preferred embodiment, the reference model for the factory
floor consists of four different layers: the work place, which includes
work centers, work cells and work stations; inventory, which encompasses
both storage and work-in-progress inventory; physical resources, including
machines, labor and operators; and logical resources, which embodies work
instructions, test plans, and part programs. Each of these four layers are
linked with the assistance of bills-of-resources'(BOR) and
bills-of-material (BOM), which specify the non-consumable resources and
materials needed to perform a given operation. The layers are also linked
with the aid of routing which specifies the sequence of operations a
manufactured item must go through during the production process.
The complete relationship of these four layers is shown in FIG. 3. Observe
that work-in-progress (WIP) inventory consists of a manufactured item that
has routing and contains a number of operations. Each of the operations
uses one or more BOMs and/or BORs. The resources and materials are
combined at work stations which are grouped into work cells. Each of the
work cells may be further abstracted to work centers, which finally are
grouped to comprise the factory itself.
The software system used in conjunction with the present invention operates
as the centerpiece of factory floor management. That is, software programs
manage the three operational centers- the work center, work cell and work
stations. Altogether, the system interfaces all of the automated pieces of
equipment, cell controllers, and shop floor data collection devices to
provide seamless integration of all devices operating within the factory.
A work station is a stationary location where work is performed. An
assembly work bench, a milling station, and inspection station are
examples of work stations. Work generally implies the processing of
material, such as assembly, fabrication, test or packaging processes.
Preferably, the concept of work is broadened to denote any kind of work,
including machine repair, set-up and operator training. To perform work at
a work station, resources such as machines and labor are allocated to the
work station. Once the work is completed, the resources are deallocated
and the work order is moved to another work station.
A work cell is defined as a conveniently organized group of work stations.
The work cell is formed based on many factors, such as process flow and
shared storage. A synchronized or paced line, a test area, or a small
assembly line are each modeled as a work cell in conjunction with the
currently preferred embodiment of the present invention.
A work center is a conveniently organized group of work cells. A work
center is generally formed based on the assumption that one particular
item is going to be manufactured in one work center. In a work order
environment, the work order is released and closed within one work center.
When an item requires more than one work center, the routing of the item
goes from one work center to another in a sequential manner.
FIG. 4 illustrates an example of a routing path that may be employed in the
manufacture of a certain item. Each node (e.g., 28-34) in FIG. 4
represents a distinct processing point, also referred to as an operation.
Once an operation has been completed, a decision is made on the
disposition of the material. The disposition determines the next operation
to which the material will be transferred. If an operation has been
successful, the material will pass to the next operation in the routing
sequence. By way of example, the progression from operations A-B-C-D
represents a normal flow for an object manufactured according to FIG. 4.
If the disposition was to fail, for instance, at node 31, then rework may
be required. This is represented in the routing diagram by the rework path
from node 31 back to node 29 (i.e., from D to B). A choice of alternate
paths, such as manual versus automatic assembly, is illustrated in FIG. 4
by two separate paths: one directly from node 31 to node 34, and the other
from node 31 to node 34 via nodes 32 and 33.
Realize that the whole concept of shop floor control utilizing the
architecture of the present invention allows a user to keep track of the
entire manufacturing process. In other words, during the manufacture of
say 10,000 widgets, a record is maintained of what machine worked on the
widgets, at what point, what was the state of the environment during that
work, what were the work instructions followed, etc. The entire history of
events is recorded so that one may retrieve information pertinent to any
operation performed anytime during the manufacturing process.
This information is important for several reasons. Consider the situation
wherein a part fails during normal usage. It may be critical to understand
how and why that part failed and a manufacturing history becomes
invaluable. In other cases, the manufacturing process itself is unstable
and software control of the shop floor environment permits analysis of the
manufacturing process for the purpose of improving consistency and
efficiency. An example of this latter situation often occurs in the
fabrication of semiconductor integrated circuits wherein yields must be
improved through vigorous analysis of a multitude of processing
parameters.
Architectural Overview
The object-oriented process architecture of the currently preferred
embodiment is based on the factory floor application-dependent assumptions
discussed above. These assumptions are categorized as actions or
requirements of the factory floor, work centers, work stations, work
cells, tasks, and users.
Referring now to FIG. 5, a hierarchy of factory floor objects is shown. By
way of example, shop floor block 39 embodies the factory floor itself.
Located within shop floor 39 there are any number of work centers 40. Each
work center consists of a specialized, well-defined and focussed
manufacturing function performed in synchronization with other work
centers to meet the manufacturing goals of the factory. Work centers all
have the trait that they must communicate with each other and be capable
of accessing each others' database.
Each of the manufacturing functions within a work center are hierarchically
decomposed into tasks. The beginning of a task, the completion of a task,
and (if the task is decomposable) the start and completion of the
sub-tasks in between, are represented as events.
Every work center 40 consists of a plurality of work cells 41. Work cells
41 are made up of a group of tasks that are performed in a synchronized
and controlled manner. The individual tasks may be performed
asynchronously, but are typically within the control of a work cell
controller in an automated environment, or a group leader/operator in the
case of a manual environment. Work cells, are further broken down into
work stations 42 wherein individual tasks are physically performed within
the control of a work cell controller.
Note that in FIG. 5, the capital letter "N" indicates that there could be
one or more items at that particular level. For instance, a factory floor
is usually supported by ten or more work centers. (The dots to the sides
of each of the blocks 40 through 42 represent these "N" items which could
exist at a parallel level in the hierarchy.)
The work station is the physical representation of an interactive
environment that performs a manufacturing task. Typically, the interaction
is limited to factors of production: including materials,
operator/supervisor, tools, work station environment and manufacturing
task definitions and work instructions. Tasks are performed by, on, or
using any of these factors. For example, the task of building a product at
a manufacturing operation may require the use of specific piece parts, an
operator with a particular skill level, and machines with particular
set-ups involving various tools. Some manufacturing operations may be
sensitive to the work station environment where the operation is
performed. Factors of productions get allocated to work stations to
perform a task as defined in the bill-of-resources for the task.
The task definition includes the factors of production required to perform
the task and its decomposition into subtasks. The tasks to be done at a
work center need to be planned, scheduled, controlled and tracked.
Planning can be weekly, daily, or by shifts. Scheduling may have to be
done from one job to the next in real-time.
It is appreciated that the software system employed in conjunction with the
present invention monitors and controls each of the work stations involved
in the manufacturing process. In this way the architecture of the present
invention provides the end user with an integrated view of the factory
floor, which itself can be defined as or modeled as close to reality as
possible. The integration is not limited to the factors of production, but
crosses factory work center boundaries and allows for easy integration to
other software systems.
The architectural premise of the present invention is based on user
requirements. These requirements include ease of use, the ability for the
user to configure the system, object orientation, the ability to
distribute components and the ability to port the software to various
hardware platforms. In this way, the architecture of the present invention
ensures that the end user interface to the software system is simple,
elegant, and rich in application-dependent functionality relevant to the
factory floor.
Hardware/Software Architecture
According to the present invention, the complex environment of the factory
floor is partitioned into smaller pieces which are considered as factory
objects. One of the architectural goals of the present invention is to
identify a familiar set of factory objects and build software
functionality, data representation, and the user interface around the
creation, manipulation, control, data collection, analysis and management
of these objects. Factory objects can be any of the five factors of
production previously discussed, represented as work orders, lots, serial
IDs, components, machine/tools/operator types, etc. Factory objects can
also be such things as concepts, part definitions, BOM, specifications,
routing, or even data display objects, such as quality control charts,
etc.
Importantly, the architecture of the present invention allows for each of
its major components to be distributed among computer resources that are
networked across the factory floor and among multiple factory sites. The
primary motive for this approach is that the process of manufacturing a
product--as encapsulated within all the work centers on a factory
floor--demands a distributed environment. Since the architecture of the
present invention allows each major architectural component to be
processed on any appropriate computer resource that is available on a
network, the architecture is characterized as having a distributed
processing capability. By the same token, the architecture of the present
invention provides for a distributed database capability enabling the user
to collect and access data anywhere on the network. Moreover, this
distribution is largely transparent to the user.
Form, function, data and communication are four important aspects of any
software system. Form defines the "look and feel" of user interaction and
helps determine how data is represented and passed to an output mechanism.
The output mechanism usually comprises a bit-mapped work station, a
character cell terminal, or some form of data buffer resident in memory or
on disk.
The functional aspect of software refers to capabilities that are
application dependent. For instance, most of the shop floor control
application code employed in conjunction with the present invention is
concerned with the creation, manipulation, control, data collection,
analysis and management of factory objects. In other cases, the functional
aspect of software represents the actual application running against the
user interface.
Within the context of the present specification, data means the
representation and physical storage of data that is collected and used
during the creation, manipulation, analysis and management of factory
objects. In other words, data represents the ability to make persistent
entries into the software system.
Finally, the communication aspect of software establishes a dialog between
each of the form, function, and data aspects of the software.
Communication is embodied in the present invention through a message
passing architecture which allows messages to be sent across the network
from one program or application, to another program or application running
on a remote machine or node. In accordance with the currently preferred
embodiment, the communication component has the primary task of delivering
messages generated by one of the architectural components to another
receiving component.
A key feature of the present invention is the fact that each of the four
aspects of software described above are embodied in the architectural
diagram of FIG. 6, which illustrates the distributed architecture of the
currently preferred embodiment. As can be seen, a user, represented by
block 41, interacts with factory floor management software system via a
windowed interface in front of an X-terminal 50. The user may be entering
data, retrieving or manipulating data, or simply monitoring the
manufacturing process. A second user 56 is also shown interacting with a
different terminal-- however, in this case the data entry device is a bar
code reader device 57.
During a normal operating session, user 41 interacts with the display
window which is effectively backed-up by its own X-server program 51.
Program 51 runs on the front-end machine displaying window 50, which
preferably comprises one node in the network. The same is true of bar code
device 57. That is, there exists a bar code server 58 which runs on a
front-end computer or node. Both of the machines associated with servers
51 and 58 run software programs that execute a code to accept inputs from
either bar codes device 57 or from X-terminal window 50. These inputs are
passed across the network to various applications which embody the
function of the factory floor management software system. In this way, the
interface services implement the form aspect of software. One of the
primary functions of the interface services is to provide a means of
initiating service requests to the application services which, in turn,
can request services from the database services. It is appreciated that in
the embodiment of FIG. 6, all of the objects (including the Database
Servers) may be distributed across networked computer resources.
Within X-terminal window 50 there are various input means such as buttons,
a keyboard, typed commands, graphics, icons, etc., each of which is
preferably modeled as an object. By way of example, when the "RETURN"
button is depressed on the keyboard, this activity is treated as an object
effectively invoking a method which goes and changes a certain
characteristic. For example, the method may consist of first graying out
the display screen and then executing an application which runs in a
background environment.
It should be understood that each of the elements or objects illustrated in
FIG. 6 are distributed as separate processes running on various computer
nodes throughout the network. To insure proper system performance, it is
necessary to have a dedicated interface service and application service
component for each end user. To better understand the interaction of these
services, it is helpful to be introduced to the concept of Application
Engines (AE) which are part of the user interface.
The Application Engine maintains the context of the transaction in terms of
application service requests going to, and completed by, Application
Servers (AS) via the local Communication Manager (CM). An Application
Engine that requires an entry from an end user (via an X-window) is
commonly referred to as an X-Application Engine (XAE).
The application architecture of the present invention supports interactive
and non-interactive (computational) applications. A typical application
consists of an Application Engine and one or more Application Servers. The
primary distinction between an Application Engine and an Application
Server is that Application Engines do not interact directly with factory
objects. Instead, they leverage Application Servers to create or modify
factory objects. Application Engines form the primary interaction with the
end user. Application Servers never interact with users directly.
Each Application Engine comprises a separate process which contains, at a
minimum, an event handler and some application-specific code. The event
handler is a process which responds to event messages (i.e., requests)
delivered from the Communication Manager and to X-window event signals
delivered by the X-interface. Each Application Engine also contains
non-reusable application-specific code that maintains the application
context/state and creates application service requests. These requests are
passed to the Communication Manager, which routes the request to an
appropriate Application Servers.
Basically, Application Engines are the background processes that process
the user interaction further. As such, each Application Engine normally
resides on a separate node within the network. By way of example, in FIG.
6, Application Engine 52 is dedicated for X-term window 50, whereas bar
code Application Engine (BAE) 60 is dedicated for use with bar code device
57.
Interactive Application Engines are called X-based Application Engines
(XAEs). (Note, if an Application Engine does not have a user interface it
is simply referred to as an Application Engine). An X-Application Engine
contains X-user interface (XUI) code which provides the complete user
dialog and presentation components of the software system. Currently, this
code is based on the XUI tool kit from Digital Equipment Corporation,
which runs under the DEC windows environment.
The XUI code within an Application Engine creates the application window(s)
and populates it with "widgets"(the term "widgets" refers to user
interface abstractions, such as buttons, menus, text fields, graphics,
etc.) from the XUI toolkit. The XUI widgets interpret X-events coming in
from the users' X-server and make calls to the callback routines within
the Application Engine. Callback routines map user interactions from the
X-server (X-events) to specific Application Engine functionality. Thus,
Application Engines bridge the user interface widget library with the
factory services/factory object library (to be discussed further shortly).
The script Application Server shown in FIG. 6 by ellipse 54 is an example
of a specialized Application Server. With the script Application Server,
the user selects and runs a specific script code. The script Application
Server generates X-Application Engine requests and passes the requests to
the Communication Manager, such as Communication Manager 53 in FIG. 6. The
Communication Manager, in turn, invokes XAEs. Because other X-Application
Engines can be spawned, an application programmer can use script to
provide sequence control over the execution of a collection of
X-Application Engines. In order to invoke an X-Application Engine, the
user must provide an identifier (XID) for the display.
The first time an X-Application Engine "invocation" request is received by
a Communication Manager, the requested X-Application Engine is spawned and
the process ID is entered in an active process table. The requested XID
(the identifier for the display)is also stored in the active process
table. The X-Application Engine order request is then passed to the newly
spawned X-Application Engine process event handler. This event handler
opens an X-connection to the requested X-display and creates the
appropriate application windows.
Once the transaction has finished, the X-Application Engine process removes
the application windows from the X-display and returns to a dormant state.
When this state | | |
