The present invention provides multiple advances in network performance by integrating network, database and middleware technologies. Broadly, the present invention incorporates a variety of middleware solutions into adaptable hardware, such as a Field Programmable Gate Array (FPGA), that provides superior performance in embedded systems. The use of hardware such as FPGA to implement middleware solutions, permits parallel processing of data, allowing real-time performance for middleware elements. Multiple embedded middleware strategies are realized in FPGA's to allow for data interoperability between distributed applications running on multiple platforms. Examples of middleware solutions that can be incorporated into the FPGA of the present invention include Common Object Request Broker Architecture (CORBA), Remote Method Invocation (RMI), Simple Object Access Protocol (SOAP), and Data Distribution Service (DDS), by way of example.
Java Virtual Machines (JVM) are also implemented in the FPGA of the present invention in order to provide operating system independence, allowing applications to run on various operating systems. By integrating multiple embedded middleware strategies into the hardware solution of the present invention, applications take advantage of simultaneous middleware solutions without having to rework old application framework to accommodate new middleware solutions. Platforms utilizing the hardware of the present invention will experience reduced software processing overhead, while gaining a variety of capabilities, such as dynamic platform perimeter security, network security, pluggable embedded middleware, QoS and enhanced data exploitation. Using the FPGA hardware of the present invention, data can be read at a platform virtually at data line speed, thereby maximizing system throughput.
As will be discussed below in more detail, the system of the present invention integrates security policies in hardware form so that when data is captured and analyzed at a platform, it can be discarded if it does not conform to the security policies, before it is passed to the application or have an opportunity to run malicious software. By embedding security in the hardware, it is possible to authenticate other systems in the network to which the platform is connected.
Middleware is generally defined as software that functions as a conversion or translation layer, although it may also perform consolidation and integration functions. Middleware solutions have typically functioned to enable one application to communicate with another that ether runs on a different platform or is provided by a different vender, or both. Middleware is most often used to support complex, distributed applications, and in a distributed computing system, middleware comprises the software layer that lies between the operating system and the applications on each platform in the system.
In addition to increasing throughput and providing security at the platform-network interface, the hardware solution of the present invention reduces latency and increases a platform's ability to exploit data. Thus, by integrating middleware solutions into hardware at each platform, the platform may extract particular information of interest to it that is traveling through the network, and the platform can be assured that critical data intended only for its receipt is not shared with other platforms in the network.
The integration of middleware solutions into the hardware of the present invention improves QoS, particularly in mobile communication environments, because hardware-embedded security policies shared by each platform in the network provides a means of detecting the loss of a node, and overcoming this loss by relying on the embedded security at other nodes. When a node is lost, it can reconfigure itself by communicating with other nodes that share the same security policies, and retrieve these policies from other authorized network entities during the reconfiguration process.
Attention is now directed to
Referring also now to
The control/status plane 42 and data plane 43 interface with the middleware 40 and roughly comprise the network layer 54 and the datalink layer 56. The application software 38 and middleware 40 also interface with the media access control 44 (MAC), and the physical components 46 (PHY), which roughly correspond to the datalink layer 56 and the physical layer 58 of the OSI reference model.
Referring now to
Pluggable security protocols 74 are connected to the ESM 72 and comprise pluggable IP cores forming a circuit used for security purposes. The routing tables 68 may be stored in content addressable memory (CAM) such as a flash memory, and comprise any of multiple routing protocols used in corresponding, differing networks. A routing table is a set of rules, often viewed in table format, that is used to determine where data will be directed. The pluggable protocol engine 70 may comprise, for example, routing protocols such as OSPF, RIP, etc, or routed protocols such as IP, TCP, etc. Generally, routing protocols are formulas, or protocols, used by a router to determine the appropriate path over which data is transmitted. The routing protocol also specifies how routers in a network share information with each other and report changes. The routing protocol enables a network to make dynamic adjustments to its conditions, so that routing decisions do not have to be predetermined and static. In the illustrated embodiment, the pluggable security protocols 74 comprise a list of protocols governing data access control, which are embedded in a circuit forming part of the FPGA.
The resource manager 76 comprises an overall chain resource manager for the FPGA, and functions to detect problems that may occur in the middleware 40 or with routing protocols. If such problems are detected, the resource manager 76 automatically signals to the user, application or a mission computer, that it has detected a problem so that trouble shooting routines can be run, or data can be recorded to enable later analysis and solution of the problem. In other words, the resource manager 76 monitors the overall health of the FPGA and provides data back to higher level maintenance programs running outside of the FPGA.
Referring now simultaneously to
The QoS is specified in the form of network statements that are appended to data from remote locations and interpreted by the QoS manager 66 as a request to prioritize the incoming data so as to provide the specified level of class of data service. An arbiter 81 scans the QoS bits in the frame of the incoming data packet, and prioritizes the data according to the individual classes 79. Accordingly, data identified by the arbiter 81 as being “Class A” 79 is passed through first, and data identified as “Class D” 79 is passed through last. In the event that a QoS is not specified in a frame, then the incoming data is transmitted through a general path 83 directly to the ESM 72 for processing. Software applications 60 that are registered for a particular class of data service 79 will have priority in receiving or servicing data. It should be noted here that while the QoS manager 66 contributes significantly to the benefits of the present invention, it need not be employed in the simplest form of the invention.
The ESM 72 is updated from the local platform 10 and performs functions related to authentication, authorization and accounting. The ESM 72 authenticates data entering the platform from the network and authorizes the authenticated data to enter the system. The ESM 72 also maintains a record of unauthorized attempts to gain access to the system platform. “Accounting” refers to the ability of the ESM 72 to keep track of incoming data, and particularly unauthorized attempts to gain access to the system. In effect, the ESM 72 determines whether a security policy has been specified, and if so, whether it is enforced. The security policies may be contained in the software applications 60 or stored in a circuit containing the ESM 72. The ESM 72 functions to verify that the incoming data conforms to the specified security policies, and only that data that satisfies the security policies is allowed to enter the platform. If the incoming data does not conform to the specified security policies, the data is simply dropped and is not allowed to reach the applications 60. Thus, it can be appreciated that incoming data that is not authorized or does not conform with specified security policies need not be evaluated by the applications 60, thus reducing the data processing overhead on the applications 60. In effect, the ESM 72 acts as a client to corresponding embedded security managers at platforms in other nodes in the network.
Assuming that the security policy has been satisfied by the data, the data is passed through the ESM 72 to the IDL engine 80 which carries out functions normally allocated to middleware such as changing the form of the presentation of the data and marshalling/demarshalling services, or ORB (Object Request Broker) services for CORBA and DDS. In some cases, the software applications 60 may not require middleware, in which case the data will pass directly to the applications 60 or to the data exploitation manager 82. The IDL engine 80 provides computer language or simple syntax for describing the interface of a software component. It is essentially a common language for writing a “manual” on how to use a piece of software from another piece of software, in much the same way that a user manual describes how to use a piece of software to the user. IDLs are used in situations where the software on either side may not share common “call semantics”, referring to the way the computer language “talks” to the routines. For instance, “C” and Pascal languages have different ways of calling routines, and in general cannot call code written in the other language. IDLs are a subset of both, a general language to which both can conform to enable language-independent code. In the illustrated embodiment, the IDL engine 80 can dynamically update interfaces for messages that are expected on the interface; or that additional interfaces can be managed for multiple messages as they are identified in the data stream. The IDL engine 80 can handle multiple marshallers/demarshallers and can be flashed on the fly to account for enforced data policies on the platform 10, or if the IDL contract is flawed, then it can be updated on the fly
After processing by the IDL engine 80, the data is delivered to the data exploitation manager 82 which functions to detect predetermined types of data that are expected to be received in the incoming data stream, and passes this detected data directly to the applications 60. The data exploitation manager 82 cooperates with a pluggable database extension 84. The pluggable database extension 84 stores pre-selected elements from other databases in the network, so that these database elements can be extracted, as desired, to populate databases controlled by the database applications 62.
A real time XML parser and data content scanner 86 is provided which operates in concert with the pluggable database extension 84 and the data exploitation manager 82. The XML parser and data content scanner 86 provides, in embedded hardware form, a means of reading XML files and making the information from those files available to applications and programming languages. Thus, XML parsing is performed at the hardware level, rather than at the software level, in order to reduce latency of the system.
It should be noted here that the incoming data stream from the QoS manager 66 may pass through and be processed by any of the processing elements 72, 82 or 84, depending upon selected protocols, options and application requirements, however any of this data may pass directly from elements 72, 82, 84 to the applications 60 through an API/channel manager 88. Thus, elements 72, 80, 82, 84 and 86 are depicted in
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, aspects of the invention described in the context of particular embodiments may be combined or eliminated in other embodiments. Further, while advantages associated with certain embodiments of the invention have been described in the context of those embodiments, other embodiments may also exhibit such advantages, and no embodiment need necessarily exhibit such advantages to fall within the scope of the invention. Accordingly, the invention is not limited, except as by the appended claims.