Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20020161907
Kind Code
A1
Moon, Avery
October 31, 2002
Adaptive multi-protocol communications system
Abstract
An adaptive multi-protocol communications system provides a plurality of single computer interface cards connected to a common backplane or interconnect. Each interface card sends and receives bit streams of a specific application protocol, exchanging data between possibly differing application protocols. The interface card feeds the incoming binary stream into a finite state machine dedicated to converting a specific application protocol bit stream into a multi-dimensional matrix representation for a particular communication protocol, e.g., EDI, XML, or the invention's intermediate translation representation. The invention uses finite state machines to convert from the initial communication protocol bit stream to the invention's intermediate representation. A finite state machine on a receiving interface card is used to convert the incoming bit stream into an intermediate language multi-dimensional matrix and passes the matrix to a destination interface card which has a finite state machine used to convert the intermediate language multi-dimensional matrix to an application protocol bit stream. The application protocol bit stream is then sent to a receiving computer system.
Inventors:
Moon; Avery
(San Lorenzo, CA)
Correspondence Name and Address:
3475 EDISON WAY SUITE L
GLENN PATENT GROUP
MENLO PARK
CA
94025
US
Series Code:
128941
Filed:
April 24, 2002
U.S. Current Class:
709/230;
709/246
U.S. Class at Publication:
709/230;
709/246
Intern'l Class:
G06F 015/16
Claims
1. A process for an integration system that exchanges data between application protocols, comprising the steps of: providing at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol; wherein each interface card is communicably connected to a computer system; wherein said interface cards are connected to a common interconnect; wherein a first interface card converts a received first application protocol bit stream into a multi-dimensional matrix representation of said first application protocol; wherein a first interface card converts said first application protocol multi-dimensional matrix into a multi-dimensional matrix representation of an intermediate language; wherein said first interface card sends said intermediate language multi-dimensional matrix to a second interface card; wherein said second interface card converts said intermediate language multi-dimensional matrix into a multi-dimensional matrix representation of a second application protocol; wherein said second interface card converts said second application protocol multi-dimensional matrix into a second application protocol bit stream; and wherein said second interface card sends said second application protocol bit stream to a computer system.
2. The process of claim 1, wherein said first interface card performs said conversions on a frame basis.
3. The process of claim 1, wherein said first interface card uses a first finite state machine to perform said first application protocol bit stream conversion, and said first interface card uses a second finite state machine to perform said first application protocol multi-dimensional matrix conversion.
4. The process of claim 3, wherein said finite state machines use a lookaside buffer to retain previous states.
5. The process of claim 3, wherein said finite state machines use configuration tables and exception tables to adjust the finite state machine's conversion behavior.
6. The process of claim 5, wherein said configuration tables and said exception tables are user configurable.
7. The process of claim 1, wherein said second interface card uses a first finite state machine to perform said intermediate language multi-dimensional matrix conversion, and said first interface card uses a second finite state machine to perform said second application protocol multi-dimensional matrix conversion.
8. The process of claim 7, wherein said finite state machines use a lookaside buffer to retain previous states.
9. The process of claim 7, wherein said finite state machines use configuration tables and exception tables to adjust the finite state machine's conversion behavior.
10. The process of claim 9, wherein said configuration tables and said exception tables are user configurable.
11. An apparatus for an integration system that exchanges data between application protocols, comprising: at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol; wherein each interface card is communicably connected to a computer system; wherein said interface cards are connected to a common interconnect; wherein a first interface card converts a received first application protocol bit stream into a multi-dimensional matrix representation of said first application protocol; wherein a first interface card converts said first application protocol multi-dimensional matrix into a multi-dimensional matrix representation of an intermediate language; wherein said first interface card sends said intermediate language multi-dimensional matrix to a second interface card; wherein said second interface card converts said intermediate language multi-dimensional matrix into a multi-dimensional matrix representation of a second application protocol; wherein said second interface card converts said second application protocol multi-dimensional matrix into a second application protocol bit stream; and wherein said second interface card sends said second application protocol bit stream to a computer system.
12. The apparatus of claim 11, wherein said first interface card performs said conversions on a frame basis.
13. The apparatus of claim 11, wherein said first interface card uses a first finite state machine to perform said first application protocol bit stream conversion, and said first interface card uses a second finite state machine to perform said first application protocol multi-dimensional matrix conversion.
14. The apparatus of claim 13, wherein said finite state machines use a lookaside buffer to retain previous states.
15. The apparatus of claim 13, wherein said finite state machines use configuration tables and exception tables to adjust the finite state machine's conversion behavior.
16. The apparatus of claim 15, wherein said configuration tables and said exception tables are user configurable.
17. The apparatus of claim 11, wherein said second interface card uses a first finite state machine to perform said intermediate language multidimensional matrix conversion, and said first interface card uses a second finite state machine to perform said second application protocol multidimensional matrix conversion.
18. The apparatus of claim 17, wherein said finite state machines use a lookaside buffer to retain previous states.
19. The apparatus of claim 17, wherein said finite state machines use configuration tables and exception tables to adjust the finite state machine's conversion behavior.
20. The apparatus of claim 19, wherein said configuration tables and said exception tables are user configurable.
21. A process for an integration system that exchanges data between application protocols, comprising the steps of: providing at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol; wherein each interface card is communicably connected to a computer system; wherein said interface cards are communicably connected with each other; wherein a first interface card converts a received first application protocol bit stream into a multi-dimensional matrix representation of an intermediate language; wherein said first interface card sends said intermediate language multi-dimensional matrix to a second interface card; wherein said second interface card converts said intermediate language multi-dimensional matrix into a second application protocol bit stream; and wherein said second interface card sends said second application protocol bit stream to a computer system.
22. The process of claim 21, wherein said first interface card performs said conversions on a frame basis.
23. The process of claim 21, wherein said first interface card uses a finite state machine to perform said first application protocol bit stream conversion.
24. The process of claim 23, wherein said finite state machine uses a lookaside buffer to retain previous states.
25. The process of claim 23, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
26. The process of claim 25, wherein said configuration tables and said exception tables are user configurable.
27. The process of claim 21, wherein said second interface card uses a finite state machine to perform said intermediate language multi-dimensional matrix conversion.
28. The process of claim 27, wherein said finite state machine uses a lookaside buffer to retain previous states.
29. The process of claim 27, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
30. The process of claim 29, wherein said configuration tables and said exception tables are user configurable.
31. An apparatus for an integration system that exchanges data between application protocols, comprising: at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol; wherein each interface card is communicably connected to a computer system; wherein said interface cards are communicably connected with each other; wherein a first interface card converts a received first application protocol bit stream into a multi-dimensional matrix representation of an intermediate language; wherein said first interface card sends said intermediate language multi-dimensional matrix to a second interface card; wherein said second interface card converts said intermediate language multi-dimensional matrix into a second application protocol bit stream; and wherein said second interface card sends said second application protocol bit stream to a computer system.
32. The apparatus of claim 31, wherein said first interface card performs said conversions on a frame basis.
33. The apparatus of claim 31, wherein said first interface card uses a finite state machine to perform said first application protocol bit stream conversion.
34. The apparatus of claim 33, wherein said finite state machine uses a lookaside buffer to retain previous states.
35. The apparatus of claim 33, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
36. The apparatus of claim 35, wherein said configuration tables and said exception tables are user configurable.
37. The apparatus of claim 31, wherein said second interface card uses a finite state machine to perform said intermediate language multi-dimensional matrix conversion.
38. The apparatus of claim 37, wherein said finite state machine uses a lookaside buffer to retain previous states.
39. The apparatus of claim 37, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
40. The apparatus of claim 39, wherein said configuration tables and said exception tables are user configurable.
41. A process for an application protocol integration system, comprising the steps of: providing at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol with an external computer system; wherein said interface cards are communicably connected to each other; providing application protocol conversion means on said interface cards for converting said specific application protocols into an intermediate language representation; wherein an interface card sends said intermediate language representation to another interface card; wherein an interface card, upon receipt of said intermediate language representation, converts said intermediate language representation into a specific application protocol bit stream; and wherein said receiving interface card sends said specific application protocol bit stream to a computer system.
42. The process of claim 41, wherein said application protocol conversion means uses a dedicated finite state machine to perform said conversion.
43. The process of claim 41, wherein said receiving interface card uses a dedicated finite state machine to perform said intermediate language conversion.
44. The process of claim 41, wherein said interface cards are communicably connected across a interconnect.
45. An application protocol integration system, comprising: at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol with an external computer system; wherein said interface cards are communicably connected to each other; application protocol conversion means on said interface cards for converting said specific application protocols into an intermediate language representation; wherein an interface card sends said intermediate language representation to another interface card; wherein an interface card, upon receipt of said intermediate language representation, converts said intermediate language representation into a specific application protocol bit stream; and wherein said receiving interface card sends said specific application protocol bit stream to a computer system.
46. The apparatus of claim 45, wherein said application protocol conversion means uses a dedicated finite state machine to perform said conversion.
47. The apparatus of claim 45, wherein said receiving interface card uses a dedicated finite state machine to perform said intermediate language conversion.
48. The apparatus of claim 45, wherein said interface cards are communicably connected across a interconnect.
49. A process for an integration system that exchanges data between application protocols, comprising the steps of: providing at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol; wherein each interface card is communicably connected to a computer system; wherein said interface cards are communicably connected to each other; wherein a first interface card converts a received first application protocol bit stream into an intermediate language representation; wherein said first interface card sends said intermediate language representation to a second interface card; wherein said second interface card converts said intermediate language representation into a second application protocol bit stream; and wherein said second interface card sends said second application protocol bit stream to a computer system.
50. The process of claim 49, wherein said first interface card performs said conversions on a frame basis.
51. The process of claim 49, wherein said first interface card uses a finite state machine to perform said first application protocol bit stream conversion.
52. The process of claim 51, wherein said finite state machine uses a lookaside buffer to retain previous states.
53. The process of claim 51, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
54. The process of claim 53, wherein said configuration tables and said exception tables are user configurable.
55. The process of claim 49, wherein said second interface card uses a finite state machine to perform said intermediate language conversion.
56. The process of claim 55, wherein said finite state machine uses a lookaside buffer to retain previous states.
57. The process of claim 55, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
58. The process of claim 57, wherein said configuration tables and said exception tables are user configurable.
59. An apparatus for an integration system that exchanges data between application protocols, comprising the steps of: at least two interface cards; wherein each interface card is configured to send and receive a specific application protocol; wherein each interface card is communicably connected to a computer system; wherein said interface cards are communicably connected to each other; wherein a first interface card converts a received first application protocol bit stream into an intermediate language representation; wherein said first interface card sends said intermediate language representation to a second interface card; wherein said second interface card converts said intermediate language representation into a second application protocol bit stream; and wherein said second interface card sends said second application protocol bit stream to a computer system.
60. The apparatus of claim 59, wherein said first interface card performs said conversions on a frame basis.
61. The apparatus of claim 59, wherein said first interface card uses a finite state machine to perform said first application protocol bit stream conversion.
62. The apparatus of claim 61, wherein said finite state machine uses a lookaside buffer to retain previous states.
63. The apparatus of claim 61, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
64. The apparatus of claim 63, wherein said configuration tables and said exception tables are user configurable.
65. The apparatus of claim 59, wherein said second interface card uses a finite state machine to perform said intermediate language conversion.
66. The apparatus of claim 65, wherein said finite state machine uses a lookaside buffer to retain previous states.
67. The apparatus of claim 65, wherein said finite state machine uses configuration tables and exception tables to adjust the finite state machine's conversion behavior.
68. The apparatus of claim 67, wherein said configuration tables and said exception tables are user configurable.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims benefit of U.S. Provisional Patent Application Serial No. 60/286,595, filed on Apr. 25, 2001, U.S. Provisional Patent Application Serial No. 60/298,355, filed on Jun. 14, 2001, U.S. Provisional Patent Application Serial No. 60/308,280, filed on Jul. 26, 2001, and U.S. Provisional Patent Application Serial No. 60/308,275 filed on Jul. 26, 2001.
BACKGROUND OF THE INVENTION
[0002] 1. Technical Field
[0003] The invention relates to data communication across computer networks. More particularly, the invention relates to translating between different communication protocols and transmitting data across differing computer networks.
[0004] 2. Description of the Prior Art
[0005] Over the past five decades, thousands of computer programs have been written for businesses to implement a wide variety of functions. As businesses accumulate more computer systems with different functionality, they accumulate more of these discrete computer programs. As technology evolves, businesses upgrade existing systems and procure new systems at idiosyncratic intervals. As a result of business needs and industry-wide technologic innovation, businesses accumulate over time a disparate set of computer systems running a heterogeneous set of computer programs.
[0006] Over the past 20 years, the majority of businesses have interconnected all their computer systems together using a mix of hardware and software. Networking hardware such as: switches and routers, networking software, web servers, and firewalls, have become a cornerstone of how business computer systems are built and used today. Many capabilities offered by computer software today require that each computer be connected to a common shared network. At a macro level, the Internet is simply a worldwide amalgamation of computer networks from businesses, educational institutions, and governmental agencies.
[0007] The shift to requiring each computer to be connected to a network has greatly affected computer software. Specifically, many types of computer software now require the ability to communicate with other software, via the mutually shared network, to implement their capabilities. Electronic mail, web pages, and file servers all exemplify this dependence upon a shared network for transmission of information between computer software.
[0008] To facilitate the sharing of information between computer software, running over a shared network, a wide variety of computer protocols have been created which define the semantics for this sharing. Further, numerous discrete but interdependent layers of computer protocols have been defined over the past 30 years. For example, the OSI network stack model is one formulation of these protocols and their mutual relationship.
[0009] Within this context, three general layers of computer protocols can be identified: physical, network, and application. Physical network protocols are concerned with defining the specifics about the physical properties of the wires and hardware used to implement computer networking. For example, the electrical signaling and the number of bits in a byte are defined within physical protocols.
[0010] Network protocols are concerned with defining the specifics about the organizational, representational, and identification semantics of the computer network. For example, the basic data unit, framing schemas, error recovery/retry mechanisms, and packet (dis)assembly are defined within network protocols.
[0011] Application protocols are concerned with session negotiation, line parameters (compression, encryption, etc), data translation, data presentation format, data schemas, transactional semantics, and request-reply semantics. This protocol decomposition follows from conceptually aggregating layers from the OSI stack, based upon how they are implemented by computer systems today. Application protocols are implemented in computer software, within the specific software programs which require access to data using such protocols.
[0012] A wide variety of hardware computer systems and computer software programs have been devised to implement the physical and network protocol layers. Specially-designed hardware is required to implement the physical network protocols, as specific wiring and electrical signaling behavior must be implemented in silicon and be connectable via a physical network plug. The network protocol layers were initially (before 1990) implemented by software running on general purpose computers. More recently, network protocols have been implemented using custom application-specific integrated circuits (ASICs) or programmable network processors. These individual components, implementing physical and network layer protocol processing, are packaged into products including routers and switches.
[0013] Application protocols have not been implemented in hardware due to a variety of factors. First, connecting application logic with the hardware integration system is not considered feasible for performance and programmability reasons. Second, the perceived financial value for such a hardware integration system was not sufficient to warrant its development and commercialization. Third, rapid technologic change in the technology industry and long hardware design cycles for hardware questioned the financial motivation. Fourth, many historical protocols were proprietary to specific companies and hardware implementation may result in intellectual property infringement. Fifth, many software engineers did not perceive a need for a hardware-based integration system. Sixth, implementing integration systems in hardware was not considered an engineering best practice for either software or hardware engineers. Seventh, the lack of universally agreed upon protocol standards demanded the infeasible requirement that hundreds of application protocols be supported by the hardware integration system. Eighth, software engineering lacks best practices and historical precedent on how to implement complex computer software using a hardware approach.
[0014] As many computer protocols exist for each layer, there has always been a need for solutions which facilitate communication among systems using different protocols to exchange data. All these solutions implement functionality which enables multiple systems to exchange data by understanding and bridging the protocol interfaces which each discrete system exposes via its network connectivity; for this document, all solutions which implement capabilities which fit into this functional description are abstractly termed integration systems.
[0015] Beginning in the mid-1980s, multi-protocol network routers pioneered integration of heterogeneous physical and network layer protocols. Specifically, the multi-protocol network router implemented the functionality necessary to exchange data between networks running different types of physical and network layer protocols. The prototypical example of this class of innovation was the development of routing hardware which could exchange data between the proprietary IBM SNA protocol and the Internet Protocol (IP).
[0016] Bringing this analogy to the application layer, where application layer protocols are at the exchange level, the exchange of data between computers having heterogeneous application level protocols at the software level is complicated at best. Referring to FIG. 1, prior approaches required a large amount of software conversions for when for example, n application protocols are exchanged between two computer systems 101, 102. Since each conversion is unique, prior approaches required n.sup.2 conversion mapping routines 103, where n is the number of discrete instances of application protocols being exchanged, to completely cover the conversion combinations. Supporting n.sup.2
conversion routines is not feasible as n grows large. Due to this n.sup.2
complexity, prior approaches have resulted in high cost and long development cycles.
[0017] Prior approaches also commonly require many discrete software components for each application protocol used in exchange. Therefore, facilitating exchange among multiple systems is onerous for users because they must continually adapt their software and systems to use these disparate components. Further, the design for each data exchange component differs based upon many different factors such as programming language, protocol type, and operating system. Thus, prior approaches not only are technically complex, but they also are difficult to use because they lack a common design or implementation.
[0018] It would be advantageous to provide an adaptive multi-protocol communications system that provides a hardware integration system that communicates between multiple application protocols and dramatically reduces the number of conversion processes required. It would further be advantageous to provide an adaptive multi-protocol communications system that allows a user to easily expand the system to accommodate additional application protocols.
SUMMARY OF THE INVENTION
[0019] The invention provides an adaptive multi-protocol communications system. The system provides a hardware integration system that communicates between multiple application protocols and reduces the number of conversion processes required to n. In addition, the invention provides a modular system that allows a user to easily expand the system to accommodate additional application protocols.
[0020] The invention provides a plurality of single computer interface cards connected to a common backplane or interconnect. Inter-card communication is accomplished via a memory-mapped schema. Each interface card sends and receives bit streams of a specific application protocol. The interface cards exchange data between possibly differing application protocols.
[0021] The interface card feeds the incoming binary stream into a finite state machine. Each finite state machine is dedicated to converting a specific application protocol bit stream into a multi-dimensional matrix representation. The finite state machine operates on the bit stream and creates a multi-dimensional schema matrix for a particular communication protocol, e.g., EDI, XML, or the invention's intermediate translation representation.
[0022] A lookaside buffer is used by the finite state machine to properly create the multi-dimensional matrix using previous state values. The lookaside buffer contains previous stream values that are placed into the lookaside buffer by the finite state machine.
[0023] The user can adjust the finite state machine's behavior with a set of configuration tables and an exception table. The configuration tables allow the user to define how the finite state machine operates on the incoming byte stream to achieve a correct syntax for the schema matrix. The exception table is a set of constraints over the multi-dimensional regions of the matrix.
[0024] A preferred embodiment of the invention uses a two-stage approach to converting bit streams. A first finite state machine on a receiving interface card is used to convert the incoming bit stream into a multi-dimensional matrix representation of the bit stream's application protocol. A second finite state machine is used to convert the application protocol multi-dimensional matrix to an intermediate representation multi-dimensional matrix.
[0025] The intermediate representation multi-dimensional matrix is passed to a destination interface card. The destination interface card has a first finite state machine used to convert the intermediate representation multi-dimensional matrix to an application protocol multi-dimensional matrix. A second finite state machine is used to convert the application protocol multi-dimensional matrix to an application protocol bit stream. The application protocol bit stream is then sent to a computer system.
[0026] Another preferred embodiment of the invention uses composite finite state machines. Composite finite state machines convert from the initial communication protocol directly to the invention's intermediate representation. A finite state machine on a receiving interface card is used to convert the incoming bit stream into an intermediate representation multi-dimensional matrix.
[0027] The intermediate representation multi-dimensional matrix is passed to a destination interface card. The destination interface card has a finite state machine used to convert the intermediate representation multi-dimensional matrix to an application protocol bit stream. The application protocol bit stream is then sent to a computer system.
[0028] Other aspects and advantages of the invention will become apparent from the following detailed description in combination with the accompanying drawings, illustrating, by way of example, the principles of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0029] FIG. 1 is a block schematic diagram of a prior art approach of converting application protocols using n.sup.2 conversion routines according to the invention according to the invention;
[0030] FIG. 2 is a block schematic diagram showing an illustrative example of a representative plurality of systems connecting to the invention via a plurality of interfaces according to the invention;
[0031] FIG. 3 is a block schematic diagram of a preferred embodiment of the invention using a multi-computing architecture to provide application protocol conversions according to the invention;
[0032] FIG. 4 is a block schematic diagram showing an illustrative example of a configuration operation involving a user, the invention, and a plurality of interconnected systems according to the invention;
[0033] FIG. 5 is a block schematic diagram showing an illustrative example of an integration operation involving the invention and a plurality of interconnected systems according to the invention;
[0034] FIG. 6 is a block schematic diagram showing a preferred embodiment of the universal configuration functionality using declarative configuration according to the invention;
[0035] FIG. 7 is a block schematic diagram of a multi-computer system implementing the invention's application protocol conversions according to the invention;
[0036] FIG. 8 is a block schematic diagram of the major components of two types of single board computers according to the invention;
[0037] FIG. 9 is a block schematic diagram of a high level view of PCI-to-PCI bridges on single board computers according to the invention;
[0038] FIG. 10 is a block schematic diagram of the major components surrounding a CPU on a single board computer according to the invention;
[0039] FIG. 11 is a block schematic diagram of a bit stream conversion to a multi-dimensional matrix representation according to the invention;
[0040] FIG. 12 is a block schematic diagram of a three-stage conversion pipeline according to the invention according to the invention;
[0041] FIG. 13 is a block schematic diagram showing a two-stage multi-dimensional matrix conversion process using finite state machines according to the invention;
[0042] FIG. 14 is a block schematic diagram showing a one-stage multi-dimensional matrix conversion process using composite finite state machines according to the invention;
[0043] FIG. 15 is a block schematic diagram of a source multi-dimensional matrix representation, target multi-dimensional matrix representation, and sequential multi-stage conditional dataflow according to the invention;
[0044] FIG. 16 is a block schematic diagram of a prefix pipeline, infix pipeline, and suffix pipeline according to the invention;
[0045] FIG. 17 is a block schematic diagram showing an illustrative example of a plurality of prefix pipelines, infix pipelines, suffix pipelines, and pipeline crossbars according to the invention;
[0046] FIG. 18 is a block schematic diagram showing a preferred embodiment of the sequential multi-stage conditional dataflow for the prefix pipeline according to the invention;
[0047] FIG. 19 is a block schematic diagram showing a preferred embodiment of the sequential multi-stage conditional dataflow for the suffix pipeline according to the invention;
[0048] FIG. 20 is a block schematic diagram showing a preferred embodiment of the sequential multi-stage conditional dataflow for the infix pipeline according to the invention;
[0049] FIG. 21 is a block schematic diagram showing a preferred embodiment of the multi-dimensional matrix for the invention using slots, dimensions, and a multi-dimensional region according to the invention;
[0050] FIG. 22 is a block schematic diagram showing the relationship among slots across dimensions for a preferred embodiment of the multi-dimensional matrix for the invention according to the invention;
[0051] FIG. 23 is a block schematic diagram showing slot annotation for a preferred embodiment of the multi-dimensional matrix for the invention according to the invention;
[0052] FIG. 24 is a block schematic diagram showing an illustrative example of slot annotations for a preferred embodiment of the multi-dimensional matrix for the invention according to the invention;
[0053] FIG. 25 is a block schematic diagram showing a preferred embodiment of an abstract functional operation defined over two multi-dimensional matrices according to the invention;
[0054] FIG. 26 is a block schematic diagram showing a preferred embodiment of an operation derived from an abstract functional operation defined over two multi-dimensional matrices according to the invention;
[0055] FIG. 27 is a block schematic diagram showing a preferred embodiment of the finite state machine for the invention according to the invention;
[0056] FIG. 28 is a block schematic diagram showing an illustrative example using a preferred embodiment of the finite state machine for the invention according to the invention;
[0057] FIG. 29 is a block schematic diagram showing a preferred embodiment of the finite state machine for the invention according to the invention;
[0058] FIG. 30 is a block schematic diagram of a pairspace with a plurality of nodes associated with the pairspace abstract formulation according to the invention;
[0059] FIG. 31 is a block schematic diagram of the functional components of the p function associated with the pairspace abstract formulation according to the invention;
[0060] FIG. 32 is a block schematic diagram of the finite state machine for the read primitive operation associated with the pairspace abstract formulation according to the invention;
[0061] FIG. 33 is a block schematic diagram of the finite state machine for the write primitive operation associated with the pairspace abstract formulation according to the invention;
[0062] FIG. 34 is a block schematic diagram of the finite state machine for the remove primitive operation associated with the pairspace abstract formulation according to the invention;
[0063] FIG. 35 is a block schematic diagram of the finite state machine for the notify primitive operation associated with the pairspace abstract formulation according to the invention;
[0064] FIG. 36 is a block schematic diagram of the finite state machine for the white-lambda process associated with the pairspace abstract formulation according to the invention;
[0065] FIG. 37 is a block schematic diagram of the finite state machine for the testAndSet primitive operation associated with the pairspace abstract formulation according to the invention;
[0066] FIG. 38 is a block schematic diagram of the finite state machine for the fetchAndAdd primitive operation associated with the pairspace abstract formulation according to the invention;
[0067] FIG. 39 is a block schematic diagram of the generative time-dynamic attribute of the pairspace abstract formulation according to the invention;
[0068] FIG. 40 is a block schematic diagram specifying the functional representation of non-disjointness for the pairspace abstract formulation according to the invention;
[0069] FIG. 41 is a time-dynamic comparison of state between temporal and persistent pairspace abstract formulations according to the invention;
[0070] FIG. 42 is a block schematic diagram of the major components of the TDGC abstract formulation according to the invention;
[0071] FIG. 43 is a block schematic diagram illustrating the correspondence between a GIRC pair and a (name, value) pair according to the invention;
[0072] FIG. 44 is a block schematic diagram of the finite state machine for the lock primitive operation associated with the pairspace abstract formulation according to the invention;
[0073] FIG. 45 is a block schematic diagram of the finite state machine for the composite unlock primitive operation associated with the pairspace abstract formulation according to the invention;
[0074] FIG. 46 is a block schematic diagram of a preferred embodiment for a distributed garbage collection algorithm for the pairspace abstract formulation according to the invention;
[0075] FIG. 47 is a block schematic diagram of an illustrative example of node reachable for a preferred embodiment of a distributed garbage collection algorithm for the pairspace abstract formulation according to the invention;
[0076] FIG. 48 is a schema representation of the correspondence between AFO and (Name, Value) pair for the pairspace abstract formulation according to the invention;
[0077] FIG. 49 is a block schematic diagram of a finite state machine of a preferred embodiment implementing object invocation in ADPM for the pairspace abstract formulation according to the invention;
[0078] FIG. 50 is a block schematic diagram of a finite state machine diagram of prior art implementing proxy object invocation according to the invention;
[0079] FIG. 51 is a block schematic diagram of a finite state machine of a preferred embodiment for adaptive delegation for strong-typing object invocation for the pairspace abstract formulation according to the invention;
[0080] FIG. 52 is a block schematic diagram illustrating the logical correspondence between TGAD and a bridge for the pairspace abstract formulation according to the invention;
[0081] FIG. 53 is a block schematic diagram of a finite state machine of a preferred embodiment for implementing TGAD through a bridge with distributed systems utilizing a plurality of application protocols for the pairspace abstract formulation according to the invention;
[0082] FIG. 54a is a block schematic diagram of a subset of the automated systems integration method according to the invention;
[0083] FIG. 54b is a block schematic diagram of a subset of the automated systems integration method according to the invention;
[0084] FIG. 55 is a block schematic diagram illustrating the correspondence between a plurality of sequential iterations of the automated systems integration method according to the invention;
[0085] FIG. 56 is a block flow diagram for multiple instances of an embodiments of the automated systems integration method with non-overlapping delta sets according to the invention;
[0086] FIG. 57 is a block flow diagram for multiple instances of an embodiments of the automated systems integration method with overlapping delta sets according to the invention;
[0087] FIG. 58 is a block flow diagram for illustrating the monotonic sequential time reduction for multiple instances of an embodiment of the automated systems integration method according to the invention;
[0088] FIG. 59 is a block schematic diagram of the primary components for a single iteration of an embodiment of the automated systems integration method according to the invention; and
[0089] FIG. 60 is a block flow diagram of time-dynamic component evolution and composition of an embodiment apparatus of the automated systems integration method according to the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0090] The invention is embodied in an adaptive multi-protocol communications system. A system according to the invention provides a hardware integration system that communicates between multiple application protocols and reduces the number of conversion processes required to n. In addition, the invention provides a modular system that allows a user to easily expand the system to accommodate additional application protocols.
[0091] Just as a multi-protocol network router can accommodate hardware components which communicate with any physical and network protocol, the invention provides an integration system which accommodates hardware components which communicate with any application protocol. An application protocol according to the invention includes all the distinct interrelated concepts which are implied by the common interpretation of the term protocol when considered at the application layer, such as data protocol, data format, data schema, request-reply semantics, inter-application synchronicity semantics, and inter-application transaction processing semantics.
[0092] With respect to FIG. 2, the invention comprises a plurality of interfaces. Each interface is composed of single computer interface cards, accepting one or more network streams 201. The network streams are fed into the finite state machine 202. The finite state machine 202
operates on the network stream 201 to create the intermediate virtual representation 204. An operation of a finite state machine 202 is elaborated below. An intermediate virtual representation 204 may be specific to either a particular application protocol, e.g., EDI, XML, or the invention's intermediate virtual translation representation.
[0093] The lookaside buffer 203 may be used by the finite state machine 202 to properly create the intermediate virtual representation 204. For some data exchange operations, a finite state machine 202 must be able to look back into the previous stream values to place the correct values into a intermediate representation 204. The lookaside buffer 203 contains previous stream values, or composite values derived from one or more previous stream values, that are placed into and may be subsequently read from the lookaside buffer 203 by the finite state machine 202. Either the lookaside buffer 203 or the intermediate representation 204 may be shared among multiple finite state machines 202, provided they are collectively located on the same interface.
[0094] The finite state machine 202 is specifically created for a particular application protocol, in order to create a proper intermediate virtual representation 204. The intermediate virtual representation 204
is subsequently used by either another interface or by another finite state machine, as will be described below. Further, the invention may implement a plurality of well-defined operations upon an intermediate virtual representation 204 prior to its subsequent use by either another interface or by another finite state machine.
[0095] Referring to FIG. 3, a sequence of binary digits come off of the network interface card (NIC) 301 located on an interface. The binary digits are mapped onto a multi-dimensional schema matrix 303 by the finite state machine 302. In this example, the source protocol is EDI and the destination protocol is XML. One skilled in the art will immediately recognize that the EDI and XML protocols in this example could be equivalently substituted for any two application protocols.
[0096] The multi-dimensional schema matrix represents the structural characteristics for both an application protocol, commonly referred to as the schema, and data, commonly referred to as the values, whose structure adheres to such an application protocol. A preferred embodiment for the schema matrix is described below.
[0097] The EDI matrix 303 is passed to a finite state machine 304. This finite state machine 304 translates the EDI matrix 303 into the invention's intermediate translation virtual representation matrix 305. The virtual representation matrix 305 is transferred to the destination side's interface card via the interconnect, using a memory mapping scheme for example.
[0098] The virtual representation allows any computer interface card to transfer data to any other computer interface card without the card having to know the destination protocol. Computer interface cards may be communicably connected to other computer interface cards and freely exchange virtual representation matrices to transfer data.
[0099] The destination side's finite state machine 307 reads its copy of the virtual representation matrix 306. As will be described below, an interconnect may provide a means for the finite state machine 307 to directly use the intermediate virtual representation matrix 305 without copying, using a zero-copy communication scheme for example. The finite state machine 307 translates the matrix 306 into an XML multi-dimensional matrix 308. The XML multi-dimensional matrix 308 is passed to the finite state machine 309. The finite state machine 309 converts the XML matrix 308 into an XML bytestream and streams the XML stream to the NIC 310.
[0100] With respect to FIG. 4, a preferred embodiment of the invention uses composite finite state machines. Composite finite state machines convert directly between the communication protocol and the invention's intermediate virtual representation. The NIC 401 sends an EDI stream, for example, to the finite state machine 402. The finite state machine 402
maps from the initial EDI to the single intermediate virtual representation matrix 403.
[0101] The destination side's finite state machine 405 reads its copy of the virtual representation matrix 404. The finite state machine 405 then translates the virtual representation matrix 404 into an XML stream and streams the XML to the NIC 406.
[0102] The one or more specific intermediate-to-intermediate translation methods used to translate from the intermediate virtual representation matrix 403 to the intermediate virtual representation matrix 404 are not considered attributes of this invention.
[0103] Referring to FIG. 5, the invention combines a finite state machine 501 with a lookaside buffer 502 to create a schema matrix 505. As noted above, the finite state machine is created for a specific communication protocol. When a user requires modifications and customizations to the finite state machine's exchange or translation process, the invention provides the user with a configuration table 503 and an exception table 504 to adjust the finite state machine's behavior.
[0104] Each finite state machine 501 may be modified or customized arbitrarily based upon requirements directly or indirectly specified by the user, or based upon characteristics of operations being processed by a finite state machine 501. The configuration table 503 allows a user to define how the finite state machine 501 operates on the incoming byte stream 506. One skilled in the art will recognize that the process for how a user provides such instructions for modification or customization is not an attribute of the invention.
[0105] The exception table 504 is a set of constraints over the multi-dimensional regions of the matrix 505, along with an optional set of corresponding actions to take when such constraints are violated. As an illustrative example of an exception table 504, the constraints can be used as rules by a finite state machine 501 to enforce an incoming byte stream uses a correct syntax which is compatible for a schema matrix 505.
[0106] The preceding constitutes the defining attributes for the invention. Preferred embodiments of the invention are now described.
[0107] Referring to FIG. 6, a preferred embodiment of the invention could be embodied by an adaptive multi-protocol communications system in many different ways. As one example, the system 601 provides a multi-processor system that adapts to computer systems using differing application protocols 606, 607. The invention connects to one or more source computer systems 602, while connecting to one or more destination computer systems 603. Each source computer system 602 uses one or more application protocol(s) 606, while each destination computer system 603 uses one or more application protocol(s) 607. As is customary to reduce unnecessary detail, many components and electrical connections implicit in this and subsequent block diagrams are not drawn.
[0108] Each source and destination computer system 602, 603 connects to system 601 via an interface 604. Each interface 604 is composed of many discrete parts, as described below. The plurality of interfaces 604 are able to intercommunicate directly via an internal interconnect 605. The manner in which the interfaces 604 intercommunicate via the interconnect 605, along with the manner in which each interface 604 communicates with the source and destination computer systems 602, 603 is not a defining attribute of the system. One skilled in the art will recognize that the interconnect 605 serves to facilitate electrical connectivity among each interface 604, and thus the interconnect 605 may consist of any discrete or composite set of components which facilitate such electrical connectivity.
[0109] Although source and destination computer systems 602, 603 as illustrated in FIG. 2 as distinct entities, a preferred embodiment of the invention could equivalently support a single computer system serving as both a source and destination computer system 602, 603. One or more source computer systems 602 or destination computer systems 603
connecting to the system 601 could simultaneously connect using two or more application protocols. One or more source computer systems 602 or one or more destination computer systems 603 could simultaneously perform two or more exchanges using the same application protocol. Each application protocol 606, 607 connecting a source or destination computer systems 602, 603 and an interface 604 can either be uni-directional or bi-directional, as well as unicast or multicast.
[0110] The exact number and physical block specification of application protocols 606, 607, interfaces 604, and source and destination systems 602, 603 should be considered an attribute of a preferred embodiment of the invention, and not a defining attribute of the invention.
[0111] Referring to FIG. 7, an enlarged view of FIG. 6 focusing on the invention is illustrated, focused on the perspective of the one or more finite state machines 703 implemented on each interfaces 704. Each interface in the invention efficiently produces an intermediate virtual representation of the data being exchanged using finite state machines 703, which is communicated between interfaces across the interconnect using a common intermediate virtual representation 304. An intermediate virtual representation is used to exchange data between the computer systems using differing application protocols 301, 302.
[0112] FIG. 6 and FIG. 7 illustrate why only n conversion processes are required for data exchange implemented by this invention. Specifically, the maximum bound of n processes for exchange arises for two reasons. First, any application protocol 606, 607 can be converted into the intermediate virtual representation 704 via an appropriate finite state machine 703. Second, the finite state machine 703 and corresponding intermediate virtual representation 704 for a given application protocol are equivalent for both input to the invention (application protocol 701, 702 to intermediate virtual representation 704) and output from the invention (intermediate virtual representation 704 to application protocol 701, 702).
[0113] The invention is informally called a universal integration platform (UIP), as the invention defines an extensible hardware architecture which provides support for exchange among all application-layer protocols 606, 607 which are accessible by the invention via a shared network. The invention implements data exchange processes among any number of arbitrary computer systems (such as source and target computer systems 602, 603), each internetworked with the invention via a network connection. Further, the invention supports these capabilities for arbitrary computer systems, whether located on a private intranet or on the public Internet, provided they are internetworked via a common shared network. The invention apparatus can be connected to any computer systems via any network which provides connectivity logically equivalent to that provided by direct network connectivity, over switched/routed networks or the Internet for example. The application protocol 606, 607, 701, and 702
are carried over these network connections between the invention apparatus and the arbitrary computer systems.
[0114] In doing so, the invention provides the hardware implementation for a programmable computing system which facilitates the execution of arbitrary computational operations, either internally within the invention or externally on any arbitrary computer systems via remotely invoking functionality via an established application protocol. Thus, the invention further differs from computer hardware implementing physical and network layer protocols, as the invention can be dynamically configured to implement arbitrary logical transformations over the exchanged data. One skilled in the art will thus recognize that the invention can support any transformation which can be specified using a general-purpose programming language. An embodiment of these generalized logical transformations is provided below. This generality and extensibility contrasts with network routers and switches, whose primary functionality is not generally programmable.
[0115] Using the OSI network model discussed above as a reference, the invention is concerned with capabilities which implement integration processes affecting data and computational logic at the session-layer (layer 5) and above, supporting multiple application-layer protocols. Further, the invention makes only a single assumption about the interrelationship between itself and external computing systems for OSI layers 1-4: a physical network connection (PNC) is necessary to be established between the invention and a plurality of computing systems. One skilled in the art will recognize that the attributes of the PNC, such as whether it is connect-oriented or connectionless for example, are not a defining attribute of the invention.
[0116] As such, the semantics and implementation details of how such PNC, and the protocol stack manipulation for OSI layers 1-4 inherent therein, is established and maintained to the plurality of external computing systems is not considered relevant to the invention. Equivalently, such apparatus is physically connected to the external computer systems via a physical network cable. Provided such connection exists, precisely how it is implemented is not relevant to the invention.
[0117] From the perspective of the invention apparatus, each PNC is modeled programmatically as an abstract network connectivity endpoint via a bi-directional network communication abstraction. A preferred embodiment for this network communication abstraction are network sockets. The socket is a prevalent abstraction used in network programming for modeling a bi-directional capacity between two computer systems. Using such a network communication abstraction, embodied by the socket abstraction, ensures the invention remains independent from, or equivalently has no dependencies upon, the specific attributes of the PNC protocol type or the implementation mechanism. Thus, the invention is independent from the processing of physical and network protocols, as implemented by systems such as routers and switches.
[0118] One preferred embodiment of the invention implements data exchange among a plurality of application protocols via a closely-coupled asymmetric multi-computing, multi-processing apparatus. Such an apparatus is defined as closed-coupled because all components are physically contained within a single enclosure. It is defined as multi-computing, as such an enclosure supports the insertion of multiple physically-independent single board computers (SBC). It is further defined as multi-processing, as each SBC can include multiple central processing units (CPUs). Each CPU need not be a general-purpose CPU, as such may be an application-specific processor such as an ASIC, FPGA, or network processor. Each interface 604 from FIG. 6 is embodied on an SBC. One skilled in the art will recognize that the correspondence between interface and SBC is not a defining attribute of the invention.
[0119] Each of the SBCs are interconnected via a dedicated, high-speed interconnect. This dedicated interconnect serves the role of the interconnect 205 from FIG. 2. One skilled in the art will recognize that this dedicated interconnect could be embodied by any physical component which facilitates electrical connectivity between SBCs (commonly referred to as a backplane or bus). Representative examples include a shared bus, switched bus, integrated switch, switched fabric, or one or more specialized bridge chips.
[0120] A key defining characteristic of this apparatus is that the SBCs are programmatically independent. Equivalently, each SBC executes one independent stream of computer instructions per CPU and utilizes independent random access memory (RAM). The adaptability and extensibility of the invention partially arises from this SBC independence, which enables functionality of the invention to be determined by the individual SBCs inserted into the invention. For example, CPU n of SBC m cannot access via direct processor addressing, RAM of any other SBC than SBC m. Various enclosures are available to contain such SBCs and provide interconnect, each of which can contain a varying number of these computing units.
[0121] Many attributes of the invention, such as performance viability and concurrent multi-processing, rely upon the design factor that each data exchange operation for each application layer protocol (ALP) is processed by a single dedicated SBC. Due to the coupling between SBC and application protocol, SBCs are equivalently referred to in this document as ALP logical adapters (ALA).
[0122] Equivalently, the benefits of the invention depend upon such an asymmetric architecture and would not be achievable using systems that lack such asymmetry. Thus, this apparatus differs markedly from generic symmetric multi-computing and multi-processing machines (commonly referred to as SMP, NUMA, or equivalent), in which each CPU is a general-purpose processor. In such contrasting designs, each CPU is predominantly interchangeable (although in some cases distinguishable) from the perspective of the operating system and application-layer software executing upon it. Thus, each CPU has a positive probabilistic chance of being scheduled to implement any data exchange functionality or in which the allocation of programmatic tasks to specific CPUs and SBCs is specified by the user of the machine via process scheduling or other application-layer software programming.
[0123] Beyond just a specific hardware architecture, the invention relies intimately upon how functionality is decomposed into parts and then implemented accordingly by SBCs within such apparatus. Each SBC in the apparatus implements a single specific and well-defined set of capabilities. The UIP includes two distinct categorical types of such SBCs, which are generically termed adapters: (1) programmable interpretation adapters and (2) ALP logic adapters. The design and intent of the PIA and ALA SBCs within this extensible multi-protocol integration system are as flexible function-specific component building blocks.
[0124] With respect to FIGS. 8, 9, 10, and 11, exemplary illustrations of a component level diagram of the invention with multiple adapters (SBCs) 803, 816, 817, 818, 819 are shown. The SBC 803, 816, 817, 818, 819 are interconnected internally via a compact shared peripheral component interface (CompactPCI) bus backplane 800. As described above, the CompactPCI bus backplane of this preferred embodiment could equivalently be substituted for hardware components which provide equivalent electrical capabilities, such as: a shared bus, switched bus, integrated switch, switched fabric, or one or more specialized bridge chips.
[0125] Each individual adapter is connected externally 809 to either a network fabric 813 supporting connectivity by user 811 via an arbitrary network cable 810, or connected externally to a single LRCS 812, 826, 827, 828; each adapter externally connected to an LRCS via an independent and discrete network fabric 833, 829, 830, 831, providing concurrent connectivity between the adapter and the LRCS. The term network fabric is defined hear to mean any electrical connectivity provided via a network cable with optional intermediate bridging system such as a switch or router.
[0126] Adapter 803 is a programmable interpretation adapter (PIA SBC), as distinguished by 803 connecting to user 811. SBCs 816, 817, 818, 819 are ALP logical adapters, as distinguished by each connecting to their respective LRCS 812, 826, 827, and 828. Note that detail on adapters 817, 818, 819 is omitted for clarity, as their onboard components are substantively similar to that of adapter 816.
[0127] In a preferred embodiment, each SBC is inserted into backplane 800
via a PCI interface 801, 802, which provides the electrical connectivity between each adapter and backplane 800. Equivalently, the mechanism which provides electrical connectivity between each SBC will depend upon the attributes of the interconnect. For example, some interconnect types may not rely upon insertion for electrical connectivity, but rather use network cables. PCI interface 801 is an empty PCI interface, having no SBCs presently inserted into it. PCI interface 802 is a non-empty PCI interface, which results from the insertion of adapter 803 into backplane 800. The lack of SBCs in PCI interface 801, with the opportunity for insertion of additional SBCs at a future time, is the basis of extensibility for the invention. At any future time, an additional SBC (not shown, but which matches the electrical requirements of the PCI interface bus) can be inserted into PCI interface 801 to provide additional capacity or capabilities.
[0128] PCI buses can support a broad quantity of adapters ranging from one to several dozen, or more. Further, a broad range of computing devices exist which are compatible with the PCI bus architecture, such as Intel Pentium and Sun Sparc SBCs, which implement the functionality necessary to qualify as an adapter in this context. As such, the exact number and physical block specification of such adapters should be considered an attribute of an embodiment of the invention, and not a defining attribute of the invention. However, the breadth of types of adapters compatible with the PCI bus exemplifies the inherent flexibility of the adaptivity and extensibility provided by this invention.
[0129] The SBCs 803, 816, 817, 818, 819 can be constructed from any common combination of CPU 807, RAM 806, persistent storage 805, and other implied board-level components for use in a CompactPCI architecture. Further, the number of processors on each SBC is solely an embodiment detail, as any small number of CPUs 807 (typically four or fewer) could be accommodated on a single SBC without substantively modifying the block diagram as illustrated in FIG. 8. For this embodiment, each SBC is a single CPU. The size and type of the RAM 806 and persistent storage 805, are also embodiment details, as their exact size, type, and timings is not relevant to the implementation of the invention.
[0130] Both distinct types of SBC adapters defined by the invention, PIA and ALA, are illustrated in FIG. 8. SBC 803 is a PIA adapter, distinguished by the network connection 810 to a RCS 811. SBCs 816, 817, 818, 819 are ALA adapters, distinguished by network connections 832, 820, 822, 824 to LRCS 812, 826, 827, 828, respectively.
[0131] Several commonalties in embodiment exist between the PIA 803 and ALA 816, 817, 818, 819 adapters. Specifically, PIA and ALA adapters share a common architecture: CPU-and network I/O-oriented SBCs, which combine high-performance CPU 907, 915 with high-performance network I/O (Ethernet, in this example) 907. CPUs 907 and 915 are explicitly differentiated to clearly exemplify that the type, speed, and other implementation attributes of the CPU may differ substantively between the SBCs without affecting the functionality of the invention. In this example, the CPUs 907, 915 are qualitatively similar: based upon the same architecture, only with differing speeds based upon the complexity of the ALP being processed by the SBC. Further, the network I/O 907 could differ for each SBC, for the same reasons; however, in this embodiment, all network I/O 907 are composed of Ethernet components and 10/100BaseT network adapters 809 for simplicity of illustration. As is requisite for a computational SBC, each adapter also includes RAM 906 and persistent storage 905. For the same reasons, one skilled in the art will readily appreciate that the persistent storage could be either a traditional hard-disk (based upon magnetophysical rotational properties) or a solid-state device such as flash memory. In either case, persistent storage 805 is providing persistent storage for software code and data required by the invention. Further, one skilled in the art will recognize that the size, access speeds, and other operational parameters of the persistent storage are not directly relevant to the implementation of the invention.
[0132] Both PIA and ALA SBC adapter 803, 816, 817, 818, 819 are distinguished by their network connectivity with a plurality of LRCS's 811, 812, 826, 827, 828, according to the constraints upon connectivity for each as defined above, which have the intent of invoking the capabilities offered by the invention. Considering the connectivity of a single SBC as representative, SBC 803 connects to such user 811 via a network connection 810, which is commonly physically inserted into SBC 803 via the insertion plug 809. Network connection 810 is connected to user 811 via an arbitrary set of switched or bridged network connections (collectively termed the network fabric 813).
[0133] The invention minimally requires n-way connectivity for the PIA SBC and two-way connectivity for each ALA SBC adapter. The PIA SBC must be able to bi-directionally communicate with each ALA adapter, while the ALA adapters are not minimally required to intercommunicate amongst each other. However, this embodiment generalizes this minimum requirement to support n-way connectivity, or the ability for any SBC i to communicate with any SBC j (where i.noteq.j), for all adapters (PIA and ALA). In a preferred embodiment, this generalization arises from the incorporation of PCI-to-PCI bridge chips (PBC), located either on each SBC or integrated into the interconnect (CompactPCI backplane in this example).
[0134] FIG. 10 illustrates a subset of FIGS. 8 and 9 relevant to the PCI-to-PCI bridge chip (PBCs) and the backplane, which is specific to a preferred embodiment using a CompactPCI interconnect. As the following are attributes of a preferred embodiment, they should not be considered defining attributes of the invention. For example, an isometric switched fabric such as Infiniband does not rely upon traditional PBCs nor differentiates between "master" and "slave", as defined below. PBC 804 is a non-transparent PBC, located on the PIA SBC 803, and electrically connected to the PCI interface 802 on the backplane 800 via 1001. PBC 914
are transparent PBC, one per ALA SBC, electrically connected to the PCI interface 802 via 910.
[0135] In a preferred embodiment, the PIA SBC could serve electrically as the bus mastering device (termed the "master" or "system" SBC, within the chassis of a CompactPCI preferred embodiment), and thus controls enumeration of the attached PCI external peripherals, it uses a non-transparent PCI-to-PCI bridge. The ALA SBCs use transparent PCI-to-PCI bridges to prevent bus interference, as they execute the "slave" or "peripheral" role in PCI signaling. The PIA and ALA SBC PBCs are implementing the standard behavior for the PCI bus architecture.
[0136] As described above, the invention relies upon an abstract network connectivity and communication abstraction which provides bi-directional network communication between endpoints. A preferred embodiment of this abstraction is the network socket abstraction, for specifying the programmatic idiom for communication between each of the SBC adapters. An alternate preferred embodiment would be distributed shared memory, which provides a comparable abstraction by emulating network connectivity and communication abstraction over a logically-flat memory space composed of the physical memory from one or more SBCs in the UIP.
[0137] PBCs 904 and 914 define functionality in bus timings, signaling, and other electrical bus-oriented operations. As such, the PBC/backplane implementation is not suitable for providing the required socket abstraction--as that abstraction relies upon a bi-directional communication path that does not include any functional bus-oriented operations.
[0138] FIG. 11 illustrates the primary components involved in the simulation process. As is customary to reduce unnecessary detail, many components and electrical connections implicit in the block diagrams are not drawn. To achieve such abstraction, the CPU 807 and PBC 804 on each SBC coordinate to simulate a socket using device driver software. Such device driver software, is loaded into RAM 806 for use in the operating system kernel running on CPU 807 from persistent storage 805. As is common with device drivers, the driver is loaded into the kernel during the boot-up sequence of the OS on CPU 807. The network simulation is implemented by the device driver on CPU 807 translating socket requests into PCI bus operations on backplane 800 via PCI interface 802, and vice-versa.
[0139] Data values are placed into RAM 806 via a collaboration between PBC 804, CPU 807, and direct memory access (DMA) 1103. When data is read off backplane 800 via PCI interface 802, PBC 804, and device driver on CPU 807 coordinate to translate the bus signal into a socket read operation, moving the result of the read operation into RAM 806 via DMA 1103. Similarly, the inverse operation occurs for socket write onto backplane 800 via PCI interface 802.
[0140] One skilled in the art will readily appreciate that several other techniques for SBC connectivity are common. For example, the same functional embodiment is possible by connecting each SBC to an Ethernet switch, via an external Ethernet adapter. Thus, n-way electrical connectivity exists between each of the cards; with the Ethernet switch (not shown) and SBC Ethernet chip 907 providing the same functional role as the PBCs 804, 814 and the backplane 800. In this example, Ethernet chip 907 is implementing a live network stack, where instead CPU 807, 815
simulate a functionally-identical network stack when PBCs are used. As another example, the interconnect could autonomously perform the simulated network communication operations, implemented as direct coping from the source RAM 806 and into one or more RAM 806 on different SBCs, without involvement of or coordination with DMA 1103 or CPU 807.
[0141] Note that the embedded computer software (firmware), which runs on the invention, programmatically implements the abstract PPF model described below using this extensible asymmetric multi-computing device. The invention relies upon an abstract programming system which meets specific requirements for availability of programmatic constructs, such as the socket network abstraction; as such, any programming language commonly in use, which meets these conditions, can implement the minimal required functionality defined herein. One skilled in the art will also immediately recognize that the following abstract PPF model described below could be equivalently implemented by one or a set of ASIC, FPGA, or functionally-similar silicon components within the invention. Thus, whether the abstract PPF is implemented as firmware, silicon components, or a combination thereof is an attribute of an embodiment, rather than a defining attribute of the invention.
[0142] Having described the hardware components for a preferred embodiment of an apparatus embodying a multi-protocol integration system, observations about the structure and interdependencies of such can be identified. One skilled in the art will recognize that an individual SBC in the apparatus could combine the functionality of both a programmable interpretation adapter and an ALP logic adapter, without materially affecting the following description. Such a combined adapter would provide the combination of the functionality of both types of adapters. Within a specific instance of an apparatus for this invention, any number of programmable interpretation adapters or ALP logic adapters may be included. Thus, the quantity and mix of adapters in the invention should be considered an attribute of an embodiment of the invention, and not a defining attribute of the invention. The details and interpretation of multiple such adapters are defined as follows.
[0143] With respect to FIG. 12, an exemplary illustration of an adapter-level diagram of the invention with multiple adapters (SBCs) 1202, 1207 are shown. Each programmable interpretation adapter (PIA SBC) 1202 in the apparatus implements functionality which controls the execution of functionality within the UIC. Each PIA SBC can provide management, administration, configuration, or any similar functionality as required by a user of the apparatus. The embodiment of a PIA SBC for purposes of configuration are described below.
[0144] In contrast to existing systems, each PIA SBC 1202 does not execute software instructions which are specific to any ALP (with the potential exclusion of the application protocol which the user 1204 requires to access the PIA SBC 1202, such as RFC 854 or RFC 2068 as described below). Hence, the PIA SBC 1202 is executing the requisite management or brokering functionality, as defined above, required to implement the characteristics necessary for such universal integration platform. Users 1204 of the apparatus request and receive functionality from the UIC 1201
by establishing a PNC 1206 with the PIA SBC 1202.
[0145] Within the context of the multi-protocol integration system, each PIA SBC 1202 is an entry-point where users 1204 of the system can request services from the system. To implement such a service request, PNCs 1206
are established between the PIA SBC 1202 and each user 1204 requesting execution of an incoming user request (IUR). Each PIA SBC 1202 within the UIC 1201 offers an entry-point to users via a well-defined ALP 1205
specific to the UIC. This UIC-specific ALP 1205 is termed the PIAP. Any agreed upon ALP would suffice for a PIAP; a preferred embodiment of the invention uses the open, standardized Internet hypertext transfer protocol (HTTP), as defined in RFC 2068, as the PIAP.
[0146] Beyond serving as an entry-point, each PIA SBC 1202 provides programmable system control from the perspective of requesting users 1204. As described above, this system-wise programmability (whether for management, administration, configuration, or similar functionality) is a defining characteristic which differentiates the invention from devices which execute physical or network layer protocols. The user 1204
controlling such apparatus customizes the functionalities of the UIP via two broad uses of the PIA SBC. First, the user 1204 can load software instructions into the PIA SBC 1201, the semantics of which are not determinant from the invention. As such, any programming language which supports the socket abstraction could be used within this context. Second, the user 1204 can use specific configuration capabilities, as defined below, provided by the PIA SBC 1202 to configure the apparatus 1201 without use of programmatic code or software instructions.
[0147] For a variety of operational reasons (such as increased bandwidth, decrease latency, increased redundancy, providing fault-tolerance, or expanding user connection capacity), the apparatus can be configured with one or more PIA SBCs 1202 within a single UIC enclosure 1201. Each PIA SBC 1202 within the UIC 1201 acts autonomously with respect to all other PIA SBCs within the chassis, as each SBC is executing an independent instruction stream and utilizes independent RAM. Equivalently, each PIA SBC 1202 provides a concurrent implementation mechanism which can accept and process incoming requests from users 1204, without sharing any dynamic information (termed dynamic service state information, or DSSI) relevant to the handling of incoming requests being handled by all other PIA SBCs 1202 within the UIC 1201.
[0148] Continuing to refer to FIG. 12, ALP logical adapters (ALA SBC) 1207
implement exactly one application-layer protocol. Although capable of supporting at most one application protocol, each ALA SBC may support numerous different versions, subversions, revisions, or other similar refinements of that application protocol. The one-to-one relationship between each ALA SBC 1207 and the ALP which it is implementing is a unique attribute of the invention. Specifically, the recognition that each ALP should be implemented by a dedicated SBC is unique to the invention. Integration solutions built using common practice today do not use such an approach.
[0149] Each ALA SBC 1207 implements functionality which is not only asymmetric, but is logically constrained to a fixed logical function set (FLFS). This FLFS is defined in advance based upon the functional requirements of the specific type of computing system which the ALA SBC 1207 will connect with and the attributes of the ALP implemented by the ALA SBC 1207. Herein lies the contrast between an ALA SBC and any other computer hardware or software systems which implements application layer protocols: each ALA SBC is dedicated specifically and solely to implementing computer instructions which relate to the single ALP supported by the ALA SBC 1207. Equivalently, the ALA SBC 1207 will not execute any instructions that do not have bearing to the single ALP; the ALA SBC 1207 is not executing arbitrary general purpose computer instructions.
[0150] With respect to FIG. 13, a second exemplary illustration of an adapter-level diagram of the invention with multiple adapters (SBCs) 1302, 1303, 1304 are shown. The figure illustrates a representative data exchange and translation operation among 3 LRCS 1306, 1307 by the ALA SBAs 1302, 1303, 1304 in the apparatus 1301. Two source LRCS 1306 are connected to ALA SBCs 1302, 1303 in the apparatus 1301 via corresponding PNC 1308 using application protocols 1309 and 1310. One destination LRCS 1307 is connected to ALA SBC 1304 in the apparatus 1301 via a PNC 1308
using application protocol 1311. As described above, all of the ALA SBCs are connected via the interconnect 1305. Within this embodiment, the data exchange and translation occurs by translating data originating from source LRCS 1306 and exchanging it to destination LRCS 1307. This figure assumes that the configuration necessary for this data exchange and translation was previously established using a PIA SBC, compliant with the description above. As elaborated previously, the number and type of the ALA SBCs involved in FIG. 13 should be considered an attribute of an embodiment of the invention, and not a defining attribute of the invention.
[0151] Further, the number of logical remote computing systems (LRCS) 1209
which each ALA SBC 1207 supports concurrent connectivity contrasts with prior art. Specifically, each ALA SBC 1207 may enforce a bounded limit on the number of LRCS which can connect to each ALA SBC 1207 concurrently. The bounded limit on the number of LRCS may be specified by a user or may be a property of the ALA SBC 1207. Thus, the invention further contrasts with other such solutions which are designed to connect to any number of LRCS, performing any number of simultaneous connections with each.
[0152] Further, all ALA SBCs 1207 may not accept incoming IURs from users, nor do they implement general purpose logic associated with such user IURs. In the context defined above, each LRCS 1209 may be implemented by one or more physically independent computing systems, depending upon various operational requirements for the logical computing system. For example, computing systems which must be resilient to run-time failures, software programming errors, or for performance reasons are commonly aggregated together into clusters or fail-over pairs.
[0153] The invention is unique in that the capabilities of each ALA SBC 1207 are accessible by users for the functionality described above solely through PIA SBCs 1202 within the UIP 1201. Equivalently, each ALA SBC 1207 implements capabilities which are only accessible to users by invoking capabilities in the PIA SBC 1202, which are then delegated by the PIA SBC 1202 to the ALA SBC 1207 specific for such ALP. This contrasts with alternative systems which lack such asymmetry, facilitating users to access ALP capabilities via any general purpose CPU in the system.
[0154] Further considered unique to the invention, the LRCS 1209 is required to offer a single type of functionality via the specific PNC 1210 per ALA SBC 1207 which interconnects the UIP 1201 to the LRCS 1209. This constraint follows immediately from the requirement that each ALA SBC 1207 execute logic associated with a single ALP. This function-specific LRCS 1209 is referred to as a FS-LRCS, to emphasize the constraint that the LRCS 1209 is exclusively limited to offering capabilities from that specific logical functionality via a fixed function set. For example, the LRCS 1209 via the PNC 1210 could be implementing a specific type of computer database connectivity to access data stored in an arbitrary format, such as rectangularity in tabular format as required in structured query language (such as SQL).
[0155] The invention further depends upon specific implications of this one-to-one relationship between ALA SBC 1207 and ALP, as such relationship defines the relationship between the UIR, the PIA SBC 1202
handling the UIR, and the one or more ALA SBC 1207 executing the ALP requested in the UIR. As described above, connectivity between the ALA SBCs and PNC SBCs is provided via the interconnect 1203. As each SBC-to-FS-LRCS PNC 1210 is based upon exchange of a well-defined set of features, each SBC uses a ALP specific to the network encoding of such feature set. Thus, the PNC 1210 connecting the UIP 1201 and the FS-LRCS 1209 can be referred to as a FS-PNC, as the PNC 1210 is logically constrained to implement the single ALP which is appropriate for the function being provided by the FS-LRCS. Thus, each SBC not only includes a fixed and well-defined set of functionality, it also interconnects with LRCS exclusively via fixed and well-defined ALP. While the functionality of the SBC is bounded within a specific functional set, functions within the set defined by the ALP can be recursively composed to build arbitrarily complex operations. For example, the ALP for the FS-NIC with the database connectivity example would be a network encoding sufficient to represent the functional requirements of the SQL language.
[0156] Similar to how multiple PIA SBCs 1202 are supported within a single UIP, multiple ALA SBCs 1207 implementing the same ALP may exist in a single UIP, for a variety of operational reasons. While only a single ALA SBC 1207 is strictly required for supporting each ALP requested by the user 1204, multiple ALA SBCs 1207 may be included to improve operational performance (such as increased bandwidth, decreased latency, increased redundancy, providing fault-tolerance, or expanding user connection capacity). Similar to PIA SBCs 1202, each ALA SBC 1207 within the UIC 1201 acts autonomously with respect to all other PIA SBCs 1202 within the chassis. Equivalently, each ALA SBC 1207 provides a concurrent implementation mechanism which can simultaneously accept and process ALPs from any number of LRCS 1209, without sharing any DSSI relevant to the handling of incoming requests being handled by all other ALA SBCs within the UIC.
Complementary Components
[0157] The preceding described a preferred embodiment of the invention via an apparatus which embodies a multi-protocol integration system, as defined above. What follows are descriptions of additional complementary components of a multi-protocol integration system whose capabilities would be advantageous in an apparatus. As such, one skilled in the art will immediately recognize that the following components are neither defining attributes of the invention, nor defining attributes of a preferred embodiment, nor defining attributes of the invention apparatus. Such complementary components are respectively methods or processes, as will be described below.
[0158] The components described below may equivalently be defined independently from the invention, any specific preferred embodiment, or the invention apparatus. The following components are described below within the context of a multi-protocol integration system to demonstrate their advantage and improve discussion clarity.
[0159] The discussion of complementary components is dichotomized into two groups: configuration and operation. This dichotomization scheme is deliberate, as the scheme embraces the difference between methods and processes driven by a user (configuration) from the pre-configured integration processes implemented by the multi-protocol integration system. In fundamental contrast to prior systems, the complementary components distinctly segment these two groups.
[0160] The configuration complementary components described below consist of the generalized functional integration process (GFIP), which is an abstract formulation for configuration independent of application protocol, and embodiments thereof. As will be described below, the capacity for users to specify configuration instructions to a multi-protocol integration system independently from the application protocol differs fundamentally from prior systems. A preferred embodiment of the GFIP, referred to as procedural process flow (PPF), will be described below. A preferred embodiment of GFIP dependent upon PPF, referred to as declarative configuration, will be described below. A preferred embodiment of declarative configuration is provided. Within the context of these characterizations, the specific hardware components which could compose such a system in an embodiment, and their interrelationship within the multi-processing/multi-computing apparatus are described and typified.
[0161] Subsequent to discussion of the configuration complementary components, a plurality of operation complementary components will be described below. Specifically, a method for logical dataflow within a multi-protocol integration system is described as the universal logical integration dataflow (ULID), with corresponding data processing algorithms therein. Within the context of the previous description, the ULID embodies operations which define how an intermediate virtual representation may be processed during exchange between interfaces. One skilled in the art will recognize that the ULID can be embodied by any system which provides a specific set of prerequisites, as described below. Therefore, embodying the ULID within an apparatus for a multi-protocol integration system is appropriately considered a preferred embodiment for the ULID.
Generic Functional Integration Process
[0162] Using the above discussion of the complexity in facilitating exchange of data between computers having heterogeneous application level protocols using prior systems as a reference, configuration for a multi-protocol integration system using GFIP can be contrasted with prior systems. GFIP facilitates a integration process to be configured for a multi-protocol integration system using a common process which is independent from the application protocol. Within the invention apparatus, GFIP facilitates configuration of the configuration table in the invention for each ALA SBC. This fundamentally contrasts with prior systems which lack such configuration universality, as their configuration is dependent upon one or more application protocols involved in the integration process being configured.
[0163] The generic functional integration process (GFIP) is a process common to all application protocols which facilitates a user to configure an integration process for a multi-protocol integration system. As will be described below in the context of a preferred embodiment, configuration universality arises from the well-defined programmatic interaction between the various SBC adapters, each of which fulfills a specific well-defined part within the larger service process of fulfilling each UIR, as defined by GFIP.
[0164] The GFIP consists of the following steps: (1) accept an IUR from a user via a PNC; (2) interpret the IUR and identify the specific integration process being configured and ALPs required to implement such a process; (3) identify each ALA SBC which implements each corresponding ALP; (4) bi-directionally communicate with each ALA, to handle the respective request and reply processing for configuration of each ALP; (5) aggregate the results from all the ALA SBCs communicated within the previous step; and (6) return the result of the integration configuration back to the user which requested the original IUR. This process is the abstract formulation of the functional semantics necessary to implementing such an universal integration platform.
[0165] A preferred embodiment of GFIP consists of the 13-step procedural process flow (PPF) process. Within the context of the invention apparatus described above, the PPF formalizes the interaction between PIA and ALA SBCs as necessary for facilitating configuration of a multi-protocol integration system. The relationship between GFIP, PPF, and PIA SBCs is as follows: the PPF is a preferred embodiment of GFIP and each PIA SBC implements an embodiment of the PPF.
[0166] GFIP and PPF combine to express the essential intent and design for a preferred embodiment which facilitates configuration of the invention for an integration process. Further, this exemplifies that the invention delivers configuration which is independent of application protocol, for a universal integration system by using a specific configuration of hardware combined with a specific integration method.
[0167] The 13-step procedural process flow is a request-reply cycle for a single user configuration request for integration with this invention. In operational terms, the PPF describes how a user communicates with the UIP to execute each task which requires integration of multiple application-layer protocols. The specific implementation semantics of each step within this PPF, as implemented within this apparatus, can be instantiated via any control mechanism which meets the functional requirements for this abstract computing system; no specific software embodiment is required, as many such embodiments can be programmed to meet such requirements.
[0168] The PPF process is as follows for a given IUR being executed by a given PIA SBC for a given UIP. As described in detail above, the essential defining characteristic of PPF is that it is independent from application protocol, and thus is universally usable for configuring arbitrary integration processes which use a plurality of arbitrary application protocols in the invention. In this context, the term instantiation is defined to mean the procedural implementation of the steps required to complete a specific process.
[0169] In this context a IUR will correspond to one or more configuration instructions, the structure and organization of which are attributes of an embodiment. Finally, in this context the term configuration updates corresponds to instructions which update one or more parameters of a multi-protocol integration system, such as finite state machines, logic paths, junctures, stored values.
[0170] The steps of this PPF are as follows
[0171] (1) IUR commencement: a user requests functionality from the UIP via establishing a PNC between the user's logical remote computing system LRCS and the PIA SBC (which is listening for such a PNC establishment request), then submitting an IUR using the format and semantics defined by the agreed upon PIAP; specifically, the user writes a sequence of bytes, or any equivalent computational form, adherent to the constraints defined by the PIAP, representing the IUR to the UIP via the PIA SBC-to-LRCS PNC.
[0172] (2) request receipt: the PIA SBC receives the IUR, via the PIA SBC-to-LRCS PNC established in (1), and parses the sequence of bytes, or any equivalent computational form, representing the IUR (adhering to the PIAP constraints) into a representation which is usable by the UIP. The representation of the IUR will depend both upon the PIAP and the computational representation of the specific embodiment of configuration updates. Specifically, the IUR is translated from the network encoding required for the PIAP into a intermediate integration representation (IIR) using RAM located on the PIA SBC. The IIR is unrelated to the intermediate virtual representation defined previously, yet may be embodied by such.
[0173] (3) request interpretation: the PIA SBC interprets the IIR, as received in (2), to implement the one or more user configuration requests encapsulated in the IUR. In doing so, interpretation of the IIR indicates the ALA SBCs (and thus, LRCS and ALPs) of which functionality must be requested from. The IIR is interpreted as, or translated into, a set of machine code instructions which are executed by the one or more CPUs on the PIA SBC. As described above, the precise semantics of interpretation will depend upon the embodiment of the configuration updates. Irrespective of the embodiment, the interpretation process by the PIA SBC CPU uniquely identifies which ALA SBCs should be requested by enumerating the distinct functional sets required to implement the IUR, which may optionally require evaluation of one or more parameters for integration processes which are configured or partially-configured in the UIP via previous PPF instantiations or functionally equivalent. The subset of the IUR, which may be mutually-exclusive among ALA SBCs, which must be executed by each specific ALA SBC is termed the application-specific IUR (ASIUR) respective to that ALA SBC.
[0174] (4) IUR delegation: for each ALA SBC which is required to implement configuration updates corresponding to the ASIUR in (3), the PIA SBC establishes a dynamic service state information connection (C-DSSI) with the appropriate ALA SBC. For each ALA SBC, there is a one-to-one relationship with the PIA SBC handling the user request defined in (1). Thus, if there are n ASIUR which must be executed, then n C-DSSI are established with n ALA SBCs; the PIA SBC physically requests connection of the C-DSSI from the interconnect using the appropriate connectivity signaling mechanism.
[0175] (5) ALA connection: for each ALA SBC which established a C-DSSI with the PIA SBC in (4), the PIA SBC transmits the ASIUR specific to that ALA via the C-DSSI; the PIA SBC transmits a sequence of bytes, or any equivalent computational form, which encodes the ASIUR in a form appropriate for communication over the C-DSSI to the respective ALA SBC.
[0176] (6) ALA interpretation: for each ALA SBC which receives a ASIUR from the PIA SBC in (5), the ALA interprets the ASIUR and translates the ASIUR request into a sequence of configuration update instructions, possibly specific to that ALA SBC, which can be executed by the ALA SBC to fulfill the ASIUR. As with IUR interpretation, ALA SBC interpretation of the ASIUR may depend upon the specific embodiment for how configuration updates are computationally represented by the IUR and PIAP. This ALA-specific sequence of instructions is termed the application-specific integration representation (ASIR). Specifically, the ALA SBC receives the ASIUR via the C-DSSI, parses the sequence of bytes, or any equivalent computational form, into an internal functional representation stored in RAM. This internal representation is appropriately structured for execution on the ALA, as necessary to implement the configuration update requested by the IUR, usually defined as a sequence of instructions appropriate for the ALP which the ALA uses to communicate with the LRCS to fulfill the ASIUR
[0177] (7) ALA-LRCS communication: an IUR may require the ALA SBC to propagate configuration parameter changes to the one or more LRCS corresponding to that specific ALA SBC as defined by the IUR. In such cases, for each ALA SBC which defines an ASIR to execute the ASIUR in (6), the ALA SBC establishes a PNC with the respective LRCS and bi-directionally communicates the appropriate translation of the subset of the ASIR appropriate for that LRCS via the ALP which is mutually shared by the originating ALA SBC and the LRCS. This bi-directional communication over the PNC results in implementation of the ALP-specific formatting and logic necessary to convey the semantics of the LRCS-specific translated subset of the IUR to the LRCS using the ALP which the LRCS uses. The implementation of the ALP-specific logic by the ALA SBC results in the ALA SBC generating a set of ASIR parameter results (ASIRPR), based upon results which the LRCS returned in response to specific results from the ALA SBC embedded in the ALP over the PNC. Specifically, the ALA SBC establishes one or more physical PNC with the LRCS, as necessary; the ALA SBC conveys the ALP representation of the LRCS-specific translated subset of the ASIR to the LRCS over such PNC; the ALA SBC stores the intermediate results of the bidirectional communication between the ALA SBC and the LRCS into RAM.
[0178] (8) PIA result receipt: for each ALA SBC which generates ASIRPR in (7), the ALA SBC communicates such ASIRPR to the originating PIA SBC in (6) via the C-DSSI; specifically, each ALA SBC translates the ASIR parameter results from the corresponding LRCS into a sequence of bytes, or any equivalent computation form, which is then physically transmitted between the PIA and ALA SBCs via the C-DSSI established in (4).
[0179] (9) result interpretation: upon receipt of each ASIRPR by the PIA, for each respective ALA defined in (3), the PIA interprets the encoding of the ASIRPR and stores the results for completing interpretation of the IIR; the PIA receives the ASIRPR via the C-DSSI, interprets the sequence of bytes, or any equivalent computational form, which the ALA SBC encoded the ASIRPR for transmission over the C-DSSI, and then stores the interpreted result in RAM on the PIA SBC.
[0180] (10) intermediate IUR termination: for each ALA SBC a C-DSSI was established in (3), the PNC for the C-DSSI may be optionally disconnected, reflecting completion of the ASIUR after receipt by the PIA SBC of all the parameters from the ALA SBC required to implement the subset of the IUR corresponding to the specific ALA SBC; the PIA optionally physically requests the C-DSSI be disconnected from the interconnect using the appropriate connectivity signaling mechanism.
[0181] (11) result composition: the PIA SBC aggregates all the ASIRPRs as conveyed to the PIA SBC in (8) by each of the ALA SBCs, completes any requisite interpretation of the IIR built from the UIR, and then formats the set of parameter results appropriately using constrains required by the PIAP; the set of ASIRPRs results, stored in the RAM of the PIA SBC, are functionally transformed appropriately together based upon the functional requirements specified in the IUR; after functional transformation, the results are encoded into an outgoing byte sequence which matches the formatting requirements for the PIAP. The precise interpretation and transformation operations required of the IUR may depend upon the specific computational representation of the embodiment of the configuration updates.
[0182] (12) result delivery: the outgoing byte sequence defined in (10) and (11) may be delivered to the user via the PNC established between the PIA SBC and the user in (1). Or, the outgoing byte sequence defined in (10) and (11) may be delivered to the user via a second PNC which is established between the PIA SBC and the user, equivalent to the method specified in (1), as initiated by either the PIA SBC (asynchronously) or the user (synchronously). The sequence of bytes, or any equivalent computational form, encapsulating the result of the functional transformation defined by the UIR are physically written to the PNC established in (1).
[0183] (13) IUR termination: optionally based upon the appropriate conventions of the PIAP, the C-DSSI between the PIA and RCS established in (1) is logically closed, indicating completion of the IUR; if the C-DSSI is not logically closed, then some PIAP-specific mechanism is used to signal the completion of the request-reply cycle for a IUR. The PIA SBC physically requests disconnection of the C-DSSI from the interconnect using the appropriate connectivity signaling mechanism, breaking the communication path between the pair. If the PNC is not physically closed, then alternatively a PIAP-specific token is sent from the PIA SBC to the LRCS via the PNC (without disconnection) indicating that the IUR is complete; this signal implicitly indicates that another IUR can subsequently be submitted by the RCS to the PIA for processing within the UIC.
[0184] The PPF defines the 13 steps necessary to execute a single IUR configuration update for a single user. At any given time, a PIA may be concurrently processing an arbitrary number of independent IUR requests. For each independent IUR being interpreted by the PIA SBC, this process is executed in its entirety. One skilled in the art will recognize that logical optimizations performed on behalf of multiple concurrent IUR requests, such as reusing C-DSSI connections between PIA SBC and ALA SBCs, are attributes of an embodiment of the PPF and thus neither defining attributes of GFIP nor defining attributes of the invention.
[0185] Having identified the process steps for PPF, several abstractions about requirements for individual hardware components within a composite apparatus, are observable. These abstractions further exemplify how the invention relies upon how the specific computer hardware components are combined (rather than inherent physical or design characteristics of the components themselves), then used to implement a well-defined integration method.
[0186] First, at least one PIA SBC and one ALA SBC are required to implement non-degenerate configuration update functionality as required by a IUR. Non-degenerate functionality is defined as any functionality which requires access to one or more LRCS to access one or more data or invoke one or more remote application software capabilities. For non-degenerate functionality, at least one PIA SBC is required to provide the programmable interpretation required to fulfill a IUR. For non-degenerate functionality, at least one ALA SBC is required to access the LRCS and implement the ALP required therein.
[0187] Second, PIA and ALA SBCs mutually share dynamic service state information (DSSI) as defined above. Implementation of an IUR is dependent upon sharing state information dynamically in real-time between the PIA SBC, which is driving interpretation of the IUR, and the ALA, which is implementing the logic necessary for the application-specific task requested by the user via the IUR. An ALA SBC may share DSSI, corresponding to a single IUR, with exactly one PIA SBC. A PIA SBC may share DSSI, corresponding to a single IUR, with any number of ALA SBCs. The number of ALA SBCs which share DSSI with the PIA SBC is based upon the number of LRCS connections required to implement the functionality defined in the IUR.
[0188] Third, PIA and ALA SBCs establish PNCs with a mutually distinct set of LRCS, as lURs originate from users of computing systems which are independent from the LRCS implementing the ALP required for each ALA. One skilled in the art will recognize that a user can operate a distinct software application on a LRCS, yet accessing the PIA SBC for configuration, without violating this constraint.
[0189] Precisely how the PIA and ALA physically share such DSSI can be implemented via any method which supports electrical connectivity between the two SBCs. In a preferred embodiment of the invention, the SBCs ideally share DSSI via a physical connection established across the interconnect of the chassis. This physical connection is termed the C-DSSI previously. However, any mechanism for connection which supports this requirement would be sufficient. For example, an illustrative means for connectivity would be an external Ethernet connection between the two SBCs, whether directly connected or bridged via a switch or router.
[0190] The following is a sample embodiment implementation of the 13 step PPF model, using the hardware embodiment of a multi-protocol integration system described above. This flow model abstracts the physical component detail, instead relying upon a block flow diagram to clearly elucidate how this procedural process maps to the physical embodiment. FIGS. 8 and 9 can be decomposed into three discrete regions, those corresponding to: (1) the PCI backplane 800; (2) a PBI SBC adapter, the left branch line bounded by blocks 811 and 802; and (3) a representative ALA SBC adapter, the right branch line bounded by blocks 812 and 802.
[0191] The following 13-step process describes an embodiment of the PPF. An embodiment of the configuration updates, which provide an alternate preferred embodiment for the IUR request and operational semantics of IUR as experienced by the user, is described subsequently to this embodiment. The following maps the functional specification to the specific physical components implementing such process:
[0192] (1) IUR commencement: User 811 opens a PNC to SBC 803 (907
implements the requisite Ethernet protocol stack on SBC 803) to signal the IUR, via fabric 813 and physically connects to SBC 803 via network connection 810. The PNC 810 requests a common TCP/IP connection with Ethernet chip 907, providing bidirectional data exchange capabilities between user 811 and SBC 803 using the socket network abstraction. For this example, the PAIP for such PNC is defined via HTTP over TCP/IP and uses the common request-reply model to exchange data necessary for