Sie sind auf Seite 1von 15

Provisional Patent Application of

Lorenzo T Geraci

For

TITLE: METHOD AND SYSTEM TO BOND, OR INTEGRATE TIGHTLY,


SOFTWARE TO HARDWARE, SOFTWARE TO OTHER SOFTWARE,
HARDWARE TO OTHER HARDWARE, AND THE RESULT OF ANY
BONDED COMBINATIONS TO ADDITIONAL SOFTWARE OR
ADDITIONAL HARDWARE.

CROSS-REFERENCE TO RELATED APPLICATIONS: None.

FEDERALLY SPONSORED RESEARCH: None.

SEQUENCE LISTING: None.

ABSTRACT

A method and system to bond, or integrate tightly, software to hardware, software to


other software, and the result of any bonded combinations to additional software or
additional hardware. The bonded system or systems, which are created through the use
of a Framework (FIG. 1) consisting of Bus (200), Broker (300), Database (400), and
Engine (500).

The method and system enables faster deployment of software applications, greatly
reduces maintenance, enhances the operational capabilities of the hardware and of the
software including the operating system, increases the reliability of the systems
consisting of bonded hardware, operating system, and application.

Application Programming Interfaces or APIs (100) interface with layers such as the
hardware layer, the operating system layer and the software application layer (FIG. 1 and
FIG.2); monitoring the activities of these layers (130). Such activities are matched
against actions stored into the Database (400) and trigger reactions directed by the Broker
(300) and executed by the APIs (100).
2

Activities not present in the Database (400) are treated as extraordinary events and routed
to the Engine (500) in order to have new procedures developed for execution by the APIs
(100) and storage into the database (400).

TECHNICAL FIELD

This invention relates in general to the integration of computing devices and software,
including operating systems; as well as the management of ordinary and extraordinary
tasks within the resulting computing environment and from the outside world to the
resulting computing environment.

DISCLOSURE OF INVENTION

Presently the computing paradigm follows a three layers approach: the hardware layer,
the operating system layer and the application layer, the Legacy Paradigm (FIG. 1).

The present invention is a system and method for executing a tight integration called
Bonding among two or more of the following layers:
- Hardware Layer;
- Operating System Layer;
- Application Layer;
- The Bonded Layer resulting from the combination of two or more of the layers.

The logical components of the invention are as follows (FIG. 2):


- Multiple Application Programming Interfaces (APIs), one per each layer to be
bonded;
- The Broker, which manages the APIs;
- The Database, which stores and queries activities, events, notices and procedures;
- The Engine, which oversees the entire operation.

The API (Application Programming Interface) interfaces and interacts with its layer and
performs three sets of functionalities (FIG. 3):
a) It is capable of monitoring the activities of its layer (130 and 140): i) internal to
the layer, ii) calls generated by the layers to other layers, iii) calls received by
the layer generated outside the layer; querying the Database for the related
activity (141);
b) Executes instructions retrieved from the Database or in response to activity in its
layer or as instructed by the Broker or the Engine (151, 150; 151, 152, 160 and
165);
c) Simulates the functions of the layer (151).
3

The Bus (FIG. 4) scans its interfaces with the other logical components (250 and 210;
FIG. 1), reads the header (220) of each instruction (230 and 235) and of each notice (240
and 245) arriving to the Bus; then routes such instruction or notice to the appropriate
destination.

The Broker (FIG. 5) receives notices from the API(s) about activities within the layers
and between layers. The Broker queries the Database for the appropriate instruction(s)
associated with such activities (321 and 325) and manages the execution of the
response(s) associated with notices (326). Such responses can be:
- Instruct one or more APIs to execute one or more instructions;
- Send a notice to the Engine;
- Send a request for instruction to the Engine;
- Check on the status of one or more APIs then resubmit the query;
- A combination of two or more of the above;
- Do nothing.

If the query does not produce any response (325), the Broker flags the activity as
Extraordinary Event (330), and sends a Request to the Engine (335), then continues in its
routine (340).

When the Engine sends an instruction to the Broker (340 and 350), the Broker selects the
API that will execute the instruction and add the appropriate header to the instruction
(351) before sending it to the Bus (353).

The Broker loops back to monitoring the Bus for notices (310).

The Database (FIG. 6) receives requests from the API(s) (410 and 420). If a match to the
request exists in the Database, the corresponding instruction is sent to the Bus (423), if
there’s no match, a notice is sent to the Bus.

The Database receives notices from the Broker (430 and 440). If a match to the notice
exists in the Database, the corresponding instruction is returned to the Broker (443), if
there’s no match, a notice is returned to the Broker.

The Database receives notices from the Engine (450 and 460). If a match to the notice
exists in the Database, the corresponding instruction is sent to the Bus (463), if there’s no
match the Database gathers relevant data on the event (465). Examples of relevant data
are:
- Data on similar events;
- Similar notices;
- Status of API(s);
- Status of the layer related to the notice.
4

Then the data is sent to the Engine (466), and the procedure is flagged “Attempted,
Waiting for Feedback” (467).

The Database receives feedback from the Engine (470), related to non-standard
procedures attempted. Positive feedback will result in the insertion of the procedure into
the Database (472) therefore becoming part of the standard procedures. After storing the
new procedure, the flag on the related attempted procedure is cleared (473).

The Database loops back to monitoring the Bus.

The Engine (FIG. 7) monitors the Bus for notices of Extraordinary Events (510 and 520).
If the Broker can handle this event, the event is routed to the Broker (521 and 540). If the
Broker cannot handle it, the notice is compared to the standard procedures in the
Database (522), then a set of instructions is formulated (523). The Database determines
the logical units that will execute the instructions and the appropriate headers are added
to the instructions (524), passed to the Bus (525), and the attempted procedure is flagged
as “Waiting for Feedback” (526).
If the procedure returns errors, the process of determining the new procedure loops back
(522, 523, 524, 525, 526, and 527).
Once the new attempted procedure is executed with no errors, the new set of instructions
is compiled in finished form (530) and it is sent to the Database for insertion as a new
standard procedure (531), notifying the related API(s) of the existence of the new
standard procedure (532).

The Engine receives requests from the Broker (535 and 550). The Engine processes these
requests as if they were Extraordinary Events. The request is compared to the standard
procedures in the Database (522) and then a set of instructions is formulated (523). The
Database determines the logical units that will execute the instructions and the
appropriate headers are added to the instructions (524), passed to the Bus (525), and the
attempted procedure is flagged as “Waiting for Feedback” (526).
If the procedure returns errors, the process of determining the new procedure loops back
(522, 523, 524, 525, 526, and 527).
Once the new attempted procedure is executed with no errors, the new set of instruction
is compiled in finished form (530) and it is sent to the Database for insertion as a new
standard procedure (531), notifying the related API(s) of the existence of the new
standard procedure (532).

The Engine receives Error Flags (560). The Engine processes these Error Flags as if they
were Extraordinary Events. The Error is compared to the standard procedures in the
Database (522), then a set of instructions is formulated (523). The Database determines
the logical units that will execute the instructions and the appropriate headers are added
to the instructions (524), passed to the Bus (525), and the attempted procedure is flagged
as “Waiting for Feedback” (526).
If the procedure returns errors, the process of determining the new procedure loops back
(522, 523, 524, 525, 526, and 527).
5

Once the new attempted procedure is executed with no errors, the new set of instruction
is compiled in finished form (530) and it is sent to the Database for insertion as a new
standard procedure (531), notifying the related API(s) of the existence of the new
standard procedure (532).

The Engine loops back to monitoring the Bus.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high level representation of the common computing paradigm represented by


three logical layers:
- Hardware Layer;
- Operating System Layer;
- Application Layer.
For the purpose of describing the invention, this representation is referred to as the
Legacy Paradigm.

FIG. 2 is a high level representation of the integration of the invention with the Legacy
Paradigm, bonding multiple layers into one single logical layer that acquires different
properties such as:
- Increased reliability;
- Elimination of conflicts between the layers and between the bonded layers and
other systems or users, including those connected by networks or by other means;
- Self-healing properties.
The Invention is composed of five logical units:
- The Application Programming Interfaces (APIs); one API per logical layer (100);
- The Bus (200);
- The Broker (300);
- The Database (400);
- The Engine (500).

FIG. 3 is a flow chart illustrating the process within the API (100) logical component, by
which the invention interfaces and interacts with the various layers. The logical unit
representing this process is referred as the API. The API is common to the various types
of layers such as:
- Hardware Layers, meaning any computing platform or computing device;
- Software Layers, including Operating System’s Layers;
- Bonded Layers resulting from the combination of two or more of the following:
o Hardware Layers;
o Software Layers, including Operating System’s Layers;
o Bonded Layers.
6

The API (100) for each distinct software, hardware, or bonded layer abstracts the direct
interface differences required to access and interact with each layer in order to provide a
common, standardized interface for access and interaction with the Bus (200).

FIG. 4 is a flow chart illustrating the process within the Bus (200) logical component.
The Bus routes data within the system’s framework and among its logical units.

FIG. 5 is a flow chart illustrating the process within the Broker (300) logical component,
which manages the APIs (100), their requests, and the execution of the instructions
related to standard procedures stored in the Database (400), as well as routes special
events to the Engine (500) or to the Database (400).

FIG. 6 is a flow chart illustrating the process within the Database (400) logical
component, which stores standard procedures to be executed, the event that triggers these
procedures, and the logical units that will execute the procedures linked to their timing.
The Database (400) also gathers data regarding extraordinary events for which there is no
stored procedure, and receives and stores procedures related to these events, formulated
by the Engine (500).

FIG. 7 is a flow chart illustrating the process within the Engine (500) logical component,
which oversees the hierarchy of the logical units, controls the layers, and governs the
formulation of procedures to be stored in the Database (400) in response to new events.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG.1 illustrates a typical computing environment, composed of the hardware layer, the
operating system layer and the application layer; where a software application (the
application layer) delivers utility to the end user(s). For the purpose of describing the
invention, this is called the Legacy Paradigm. FIG. 2 illustrates the same paradigm
with the addition of the present invention, called the Framework, resulting in a tightly
integrated computing unit called Bonded Layers.

A preferred embodiment of the present invention executes on a computer system based


on an Intel X86 compatible processor such as the Intel Pentium processor (the hardware
layer); executing the Red Hat Linux (the operating system layer); with a software
application installed that requires the above combination of hardware and operating
system, such as Nagios (the application layer).

The present invention is typically stored in the storage device and executed by the
processor from memory, as it is typical for the application layer and the operating system
layer.
7

In the following discussion, the term “action” refers to the execution of a set of
instructions by the layers; the term “monitoring” refers to the observation of the APIs of
such actions; the term “notice” refers to information sent by a logical component of the
invention to another logical component of the invention; the term “instruction” refers to
the set of instructions to be executed by one or more logical components within the
invention, including a “do nothing” instruction.

Within each layer (hardware, operating system and application), is an API (100) that has
been designed to perform method steps of the present invention, geared toward
monitoring the layers, and to perform actions on such layers as instructed by the other
logical components of the invention.

The layers’ activities trigger responses from the API, dependent on the instructions
received from the other logical components of the invention.
Known activities are stored in the Database (400) along with the appropriate instruction.
Instructions in response to unknown activities (extraordinary events) are formulated and
tested by the Engine (500), before being executed by the APIs (100). New instructions
executed by the API under direct control from the Engine (500) are then stored in the
Database (400) and become part of the stored procedures repository.

An example of an action to be taken is when the software application may need to reboot
the hardware. The invention will call the proper procedure from the Database (400), shut
off the software application, shut off the operating system, note to restart the operating
system, note to restart the software application, put itself into a reboot mode, reboot the
hardware and upon the hardware coming back on line, launches the operating system,
then launches the application software returning the application software at the same
status prior to the reboot call.

Another example of an action to be taken is when the application software must perform
maintenance tasks, such as data compacting and file defragmentation. The entire
computing unit is shut-off, then the operating system is launched with the bare minimum
services necessary to operate the computing environment and launch the maintenance
application. Upon successful completion of the data compacting and file
defragmentation, the maintenance application is closed, the operating system is restarted
with the entire set of services, and the software application is launched returning it to the
same status prior to the maintenance call.

A third example of an action to be taken is when the available disk space decreases below
a threshold, within a series of progressive thresholds, the invention can send an alert
message via the API, using features present in one or more the layers, such as visual or
acoustic signals in the hardware, messaging capabilities in the operating system or in the
software application.
8

The present invention preferably contains many different stored procedures (possible
actions with related instruction set), with additional stored procedures to be created,
tested, executed and stored for future reference and use.

CLAIMS

1. A method for bonding, or integrating tightly, software to hardware. By software it is


intended any instruction set, including, but not limited to, operating systems. By
hardware it is intended any computing platform capable of running software, including,
but not limited to, operating systems and software applications.

2. A method for bonding, or integrating tightly, software to software. By software it is


intended any instruction set, including, but not limited to, operating systems.

3. A method for bonding or integrating tightly, hardware to hardware. By hardware it is


intended any computing platform capable of running software, including, but not limited
to, operating systems and software applications.

4. A method for bonding or integrating tightly, multiple pieces of software to hardware.


By software it is intended any instruction set, including, but not limited to, operating
systems. By hardware it is intended any computing platform capable of running
software, including, but not limited to, operating systems and software applications.

5. A method for bonding or integrating tightly, software to multiple pieces of hardware.


By software it is intended any instruction set, including, but not limited to, operating
systems. By hardware it is intended any computing platform capable of running
software, including, but not limited to, operating systems and software applications.

6. A method for bonding or integrating tightly, multiple pieces of software to multiple


pieces of hardware. By software it is intended any instruction set, including, but not
limited to, operating systems. By hardware it is intended any computing platform
capable of running software, including, but not limited to, operating systems and software
applications.

7. A method for bonding or integrating tightly, the result of any bonded combination in
claims 1 to 7 to additional software or additional hardware. By software it is intended
any instruction set, including, but not limited to, operating systems. By hardware it is
intended any computing platform capable of running software, including, but not limited
to, operating systems and software applications.

8. Any of the methods in claims 1 to 7, where one of the software is a piece of software
sending and receiving information to a network.

9. Any of the methods in claims 1 to 7, where all, or a portion of, the invention is tightly
9

integrated into another piece of software. By software it is intended any instruction set,
including, but not limited to, operating systems.

10. Any of the methods in claims 1 to 9, where the resulting tool is a single computing
unit, used for single or multiple purposes.

11. Any of the methods in claims 1 to 10, where one of the software is a piece of software
that integrates multiple computing units within a population of units, into overlapping
subsets of the population, that can be managed and operated individually, as the whole
population, as the whole subsets, or multiple units within a subset.
* * * * *
10

LEGACY PARADIGM

APPLICATION LAYER

OPERATING SYSTEM LAYER

HARDWARE LAYER

FIGURE 1

BONDED LAYERS

FRAMEWORK LEGACY PARADIGM

BROKER (300) API


APPLICATION LAYER
(100)
B U S (200)

ENGINE
DATABASE API
OPERATING SYSTEM LAYER
(500) (400) (100)

API
HARDWARE LAYER
(100)

FIGURE 2
11

APPLICATION PROGRAMMING INTERFACE - API (100)

MONITOR BUS FOR API


INSTRUCTION
(110)

INSTRUCTION
YES EXECUTE INSTRUCTION SEND NOTICE TO BUS BUS
PRESENT?
(121) (122) (200)
(120)

NO

MONITOR LAYER
ACTIVITY
(130)

ACTIVITY COMPARE ACTIVITY


YES BUS
PRESENT? AGAINST DATABASE
(200)
(140) (141)

NO

ACTIVITY IN
YES EXECUTE RESPONSE
DATEBASE?
(151)
(150)

NO
SEND NOTICE TO THE
BUS
FLAG ACTIVITY AS BUS
(200)
EXTRAORDINARY EVENT (152)
(160)

SEND NOTICE TO THE


BUS
BUS
(200)
(165)

FIGURE 3
12

B U S (200)

WAIT FOR ACTIVITY


(210)

READ HEADER API


(220) (100)

INSTRUCTION? YES ROUTE TO API


(230) (235)

NO

NOTICE? YES ROUTE TO BROKER BROKER


(240) (245) (300)

NO

ROUTE TO ENGINE ENGINE


(250) (500)

FIGURE 4
13

BROKER (300)

MONITOR BUS FOR


NOTICES
(310)

NOTICE YES COMPARE NOTICE


DATABASE
PRESENT? AGAINST DATABASE
(400)
(320) (321)

NO

MONITOR ENGINE NOTICE IN


YES EXECUTE RESPONSE
INTERFACE FOR DATEBASE?
(326)
INSTRUCTIONS (325)
(340)
NO

FLAG ACTIVITY AS
NO INSTRUCTION EXTRAORDINARY EVENT
PRESENT? (330)
(350)

YES
SEND REQUEST TO THE
ENGINE
ENGINE
ADD HEADER TO (500)
(335)
INSTRUCTION
(351)

SEND INSTRUCTION TO
BUS
THE BUS
(200)
(353)

FIGURE 5
14

DATABASE (400)

MONITOR BUS FOR API


REQUESTS
(410)

MATCH REQUEST
REQUEST YES YES SEND INSTRUCTION TO
AGAINST STORED MATCH FOUND?
PRESENT? THE BUS
PROCEDURES (422)
(420) (423)
(421)
NO NO

MONITOR BROKER
SEND NOTICE TO THE
INTERFACE FOR BUS
BUS
NOTICES (200)
(425)
(430)

MATCH REQUEST
NOTICE YES YES RETURN INSTRUCTION
AGAINST STORED MATCH FOUND?
PRESENT? TO THE BROKER
PROCEDURES (442)
(440) (443)
(441)
NO NO

MONITOR ENGINE
RETURN NOTICE TO THE
INTERFACE FOR BROKER
BROKER
NOTICES (300)
(445)
(450)

MATCH REQUEST
NOTICE YES YES SEND INSTRUCTION TO
AGAINST STORED MATCH FOUND?
PRESENT? THE BUS
PROCEDURES (462)
(460) (463)
(461)
NO NO

GATHER DATA ON
SIMILAR EVENTS, BUS
MATCH FEEDBACK WITH
FEEDBACK YES SIMILAR NOTICES, (200)
ATTEMPTED
PRESENT? STATUS OF API(s) AND
PROCEDURE
(470) RELATED LAYERS
(471)
(465)
NO

STORE NEW
PROCEDURE INTO SEND DATA TO ENGINE ENGINE
DATABASE (466) (500)
(472)

FLAG PROCEDURE AS
CLEAR FLAG FROM ATTEMPTED, WAITING
ATTEMPTED FOR FEEDBACK
PROCEDURE TABLE (467)
(473)

FIGURE 6
15

ENGINE (500)

MONITOR BUS FOR


NOTICES OF
EXTRAORDINARY
EVENTS
(510)

DATABASE
(400)

CAN IT BE
NOTICE YES NO COMPARE NOTICE
HANDLED BY THE
PRESENT? AGAINST DATABASE
BROKER?
(520) (522)
(521)

NO YES
FORMULATE
INSTRUCTION
(523)
PASS NOTICE TO
BROKER
BROKER
(300)
(540)
ADD HEADER TO
INSTRUCTION
MONITOR INTERFACE (524)
WITH BROKER FOR
REQUESTS
(535)
PASS INSTRUCTION TO
THE BUS
(525)

REQUEST YES
PRESENT?
AWAIT FEEDBACK
(550)
(526)

NO

NO ERROR YES
PRESENT?
(527)
WAS IT A
YES BROKER
REQUEST? NO
(535)
COMPILE NEW
INSTRUCTION FOR
BROKER
(530)

SEND NEW
INSTRUCTION SET TO DATABASE
NO WAS IT AN
THE DATABASE (400)
ERROR?
(531)
(536)

YES
NOTIFY API OF NEW
API
STANDARD EVENT
(100)
(532)

NO ANY ERROR YES


FLAGS?
(560)

FIGURE 7

Das könnte Ihnen auch gefallen