WO2002087136A2 - Systeme de communication multiprotocole adaptatif - Google Patents

Systeme de communication multiprotocole adaptatif Download PDF

Info

Publication number
WO2002087136A2
WO2002087136A2 PCT/US2002/013182 US0213182W WO02087136A2 WO 2002087136 A2 WO2002087136 A2 WO 2002087136A2 US 0213182 W US0213182 W US 0213182W WO 02087136 A2 WO02087136 A2 WO 02087136A2
Authority
WO
WIPO (PCT)
Prior art keywords
interface card
finite state
state machine
application protocol
intermediate language
Prior art date
Application number
PCT/US2002/013182
Other languages
English (en)
Other versions
WO2002087136A9 (fr
WO2002087136B1 (fr
WO2002087136A3 (fr
Inventor
Avery Moon
Original Assignee
Infotone Communications Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infotone Communications Corporation filed Critical Infotone Communications Corporation
Priority to AU2002309605A priority Critical patent/AU2002309605A1/en
Priority to EP02736613A priority patent/EP1381962A2/fr
Priority to JP2002584522A priority patent/JP2005504455A/ja
Publication of WO2002087136A2 publication Critical patent/WO2002087136A2/fr
Publication of WO2002087136A3 publication Critical patent/WO2002087136A3/fr
Publication of WO2002087136A9 publication Critical patent/WO2002087136A9/fr
Publication of WO2002087136B1 publication Critical patent/WO2002087136B1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Definitions

  • 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.
  • 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.
  • Network protocols are concerned with defining the specifics about the organizational, representational, and identification semantics of the computer network.
  • the basic data unit, framing schemas, error recovery/retry mechanisms, and packet (dis)assembly are defined within network protocols.
  • 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.
  • 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.
  • ASICs application-specific integrated circuits
  • multi-protocol network routers pioneered integration of heterogeneous physical and network layer protocols. Specifically, the multiprotocol 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) .
  • IP Internet Protocol
  • 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.
  • 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.
  • the invention provides a modular system that allows a user to easily expand the system to accommodate additional application protocols.
  • 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.
  • 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.
  • a lookaside buffer is used by the finite state machine to properly create the multidimensional matrix using previous state values.
  • the lookaside buffer contains previous stream values that are placed into the lookaside buffer by the finite state machine.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Fig. 1 is a block schematic diagram of a prior art approach of converting application protocols using n 2 conversion routines according to the invention according to the invention;
  • 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
  • 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
  • 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;
  • 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
  • Fig. 6 is a block schematic diagram showing a preferred embodiment of the universal configuration functionality using declarative configuration according to the invention.
  • Fig. 7 is a block schematic diagram of a multi-computer system implementing the invention's application protocol conversions according to the invention.
  • Fig. 8 is a block schematic diagram of the major components of two types of single board computers according to the invention.
  • 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.
  • Fig. 10 is a block schematic diagram of the major components surrounding a CPU on a single board computer according to the invention
  • Fig. 11 is a block schematic diagram of a bit stream conversion to a multidimensional matrix representation according to the invention
  • Fig. 12 is a block schematic diagram of a three-stage conversion pipeline according to the invention according to the invention.
  • Fig. 13 is a block schematic diagram showing a two-stage multi-dimensional matrix conversion process using finite state machines according to the invention.
  • 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.
  • 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
  • Fig. 16 is a block schematic diagram of a prefix pipeline, infix pipeline, and suffix pipeline according to the invention.
  • 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
  • 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.
  • 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.
  • 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.
  • Fig. 21 is a block schematic diagram showing a preferred embodiment of the multi-dimensional matrix for the invention using slots, dimensions, and a multidimensional region according to the invention
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • Fig. 27 is a block schematic diagram showing a preferred embodiment of the finite state machine for the invention according to the invention.
  • 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.
  • Fig. 29 is a block schematic diagram showing a preferred embodiment of the finite state machine for the invention according to the invention.
  • 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.
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Fig. 39 is a block schematic diagram of the generative time-dynamic attribute of the pairspace abstract formulation according to the invention.
  • Fig. 40 is a block schematic diagram specifying the functional representation of non-disjointness for the pairspace abstract formulation according to the invention.
  • Fig. 41 is a time-dynamic comparison of state between temporal and persistent pairspace abstract formulations according to the invention.
  • Fig. 42 is a block schematic diagram of the major components of the TDGC abstract formulation according to the invention
  • Fig. 43 is a block schematic diagram illustrating the correspondence between a GIRC pair and a (name, value) pair according to the invention
  • 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.
  • 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.
  • 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.
  • 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.
  • Fig. 48 is a schema representation of the correspondence between AFO and (Name, Value) pair for the pairspace abstract formulation according to the invention.
  • 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
  • Fig. 50 is a block schematic diagram of a finite state machine diagram of prior art implementing proxy object invocation according to the invention.
  • 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
  • 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
  • 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
  • Fig. 54a is a block schematic diagram of a subset of the automated systems integration method according to the invention.
  • Fig. 54b is a block schematic diagram of a subset of the automated systems integration method according to the invention.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • the invention provides a modular system that allows a user to easily expand the system to accommodate additional application protocols.
  • an application protocol 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 synchro ni ⁇ ty semantics, and inter-application transaction processing semantics.
  • 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.
  • 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.
  • 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 orby anotherfinite state machine.
  • 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.
  • the source protocol is EDI
  • the destination protocol is XML.
  • the EDI and XML protocols in this example could be equiv alently substituted forany two application protocols.
  • 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.
  • 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.
  • 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.
  • the destination side's finite state machine 307 reads its copy of the virtual representation matrix 306.
  • 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.
  • a prefe ⁇ ed 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, forexample, to the finite state machine 402.
  • the finite state machine 402 maps from the initial EDI to the single intermediate virtual rep resentation matrix 403.
  • 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.
  • 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.
  • the invention combines a finite state machine 501 with a lookaside buffer 502 to create a schema matrix 505.
  • the finite state machine is created for a specific communication protocol.
  • the invention provides the user with a configuration table 503 and an exception table 504 to adjust the finite state machine's behavior.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • source and destination computer systems 602, 603 as illustrated in Fig. 2 as distinct entities could equivalent ⁇ 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PNC physical network connection
  • the attributes of the PNC such as whether it is connect-oriented or connection-less for example, are not a defining attribute of the invention.
  • 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 I/O capacity between two computer systems.
  • socket abstraction 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.
  • 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.
  • 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.
  • 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.
  • SBCs are programmatically independent. Equivalently, each SBC executes one independent stream of computer instructions per CPU and utilizes independent random access memory (RAM).
  • RAM independent random access memory
  • 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.
  • ALP application layer protocol
  • ALA ALP logical adapters
  • each CPU is a general-purpose processor.
  • SMP symmetric multi- computing and multi-processing machines
  • NUMA general-purpose processor
  • each CPU is predominantly interchangeable (although in some cases distinguishable) from the perspective of the operating system and application-layer software executing upon it.
  • 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.
  • the invention relies intimately upon how functionality is decomposed into parts and then implemented accordingly b y 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.
  • 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.
  • FIG. 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.
  • CompactPCI compact shared peripheral component interface
  • 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.
  • 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.
  • 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.
  • each SBC is inserted into backplane 800 via a PCI interface 801 , 802, which provides the electrical connectivity between each adapter and backplane 800.
  • 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.
  • 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.
  • 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 h 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.
  • 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.
  • PIA and ALA adapters share a common architecture: CPU-and network l/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.
  • 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.
  • each adapter also includes RAM 906 and persistent storage 905.
  • the persistent storage could be either a traditional hard-disk (based upon magneto-physical rotational properties) or a solid-state device such as flash memory.
  • persistent storage 805 is providing persistent storage for software code and data required by the invention.
  • the size, access speeds, and other operational parameters of the persistent storage are not directly relevant to the implementation of the invention.
  • Both PIA and ALA SBC adapter 803, 816, 817, 818, 819 are distinguished b y 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.
  • 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).
  • 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.
  • 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 ⁇ j), for all adapters (PIA and ALA) .
  • 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).
  • PBC PCI-to-PCI bridge chips
  • 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.
  • PBCs PCI-to-PCI bridge chip
  • the backplane which is specific to a preferred embodiment using a CompactPCI interconnect.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the CPU 807 and PBC 804 on each SBC coordinate to simulate a socket using device driver software.
  • device driver software is loaded into RAM 806 for use in the operating system kernel running on CPU 807 from persistent storage 805.
  • 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.
  • Data values are placed into RAM 806 via a collaboration between PBC 804, CPU 807, and direct memory access (DMA) 1103.
  • 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.
  • the inverse operation occurs for socket write onto backplane 800 via PCI interface 802.
  • Ethernet chip 907 is implementing a live network stack, where instead CPU 807, 815 simulate a functionally-identical network stack when PBCs are used.
  • 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.
  • 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.
  • 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) .
  • the PIA S BC 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 S BC 1202.
  • each PIA SBC 1202 is an entry-point where users 1204 of the system can request services from the system.
  • PNCs 1206 are established between the PIA SBC 1202 and each user 1204 requesting execution of an incoming user request (IUR) .
  • IUR incoming user request
  • 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 UlC-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.
  • HTTP Internet hypertext transfer protocol
  • each PIA SBC 1202 provides programmable system control from the perspective of requesting users 1204.
  • this system-wise programmability 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • DSSI dynamic service state information
  • 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.
  • Each ALA SBC 1207 implements functionality which is not only asymmetric, but is logically constrained to a fixed logical function set (FLFS).
  • FLFS logical function set
  • 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.
  • 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.
  • 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 h 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.
  • all of the ALA SBCs are connected via the interconnect 1305.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • each ALA SBC 1207 is 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 S BC 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.
  • 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.
  • 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 structured query language (such as SQL).
  • 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.
  • connectivity between the ALA SBCs and PNC SBCs is provided via the interconnect 1203.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • GFIP generalized functional integration process
  • a preferred embodiment of the GFIP referred to as procedural process flow (PPF)
  • PPF procedural process flow
  • declarative configuration A preferred embodiment of GFIP dependent upon PPF, referred to as declarative configuration.
  • a preferred embodiment of declarative configuration is provided.
  • the universal logical integration dataflow (ULID)
  • the ULID embodies operations which define how an intermediate virtual representation may be processed during exchange between interfaces.
  • the ULID can be embodied b y 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.
  • 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.
  • 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.
  • the generic functional integration process is a process common to all application protocols which facilitates a user to configure an integration process for a multi-protocol integration system.
  • 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.
  • 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.
  • a preferred embodiment of GFIP consists of the 13-step procedural process flow (PPF) process.
  • PPF procedural process flow
  • 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.
  • 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.
  • the 13-step procedural process flow is a request-reply cycle for a single user configuration request for integration with this invention.
  • 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.
  • the PPF process is as follows for a given IUR being executed by a given PIA SBC for a given UIP.
  • 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.
  • the term instantiation is defined to mean the procedural implementation of the steps required to complete a specific process.
  • IUR will correspond to one or more configuration instructions, the structure and organization of which are attributes of an embodiment.
  • 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.
  • 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.
  • 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.
  • the IUR is translated from the network encoding required for the PIAP into a intermediate integration representation (MR) using RAM located on the PIA SBC.
  • MR intermediate integration representation
  • (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 b y 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.
  • 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.
  • ASIUR application-specific IUR
  • 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.
  • C-DSSI dynamic service state information connection
  • n ASIUR which must be executed
  • 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.
  • 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.
  • 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.
  • ASIR application-specific integration representation
  • the ALA SBC receives the ASIUR via the C-DSSI, parses the sequence of bytes, or any equivalent computational form, into an intemal 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
  • 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.
  • 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.
  • ASIRPR ASIR parameter results
  • 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 bi-directional communication between the ALA SBC and the LRCS into RAM.
  • 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).
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • the PPF defines the 13 steps necessary to execute a single IUR configuration update for a single user.
  • 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 h its entirety.
  • 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.
  • 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.
  • at least one PIA SBC is required to provide the programmable interpretation required to fulfill a IUR.
  • at least one ALA SBC is required to access the LRCS and implement the ALP required therein.
  • PIA and ALA SBCs mutually share dynamic service state information (DSSI) as defined above.
  • DSSI dynamic service state information
  • 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.
  • 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.
  • LRCS LRCS implementing the ALP required for each ALA.
  • a user can operate a distinct software application on a LRCS, yet accessing the PIA SBC for configuration, without violating this constraint.
  • DSSI Physical connection established across the interconnect of the chassis.
  • This physical connection is termed the C-DSSI previously.
  • any mechanism for connection which supports this requirement would be sufficient.
  • 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.
  • 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 bi-directional data exchange capabilities between user 811 and S BC 803 using the socket network abstraction.
  • the PAIP for such PNC is defined via HTTP over TCP/IP and uses the common request-reply model to exchange data necessary for implementing the IUR.
  • the IUR from user 811 is assumed to specify functionality which requires at most one ALA SBC to implement. This simplifying assumption is made solely for clarification, and should not be considered an attribute of the invention. This same process can be implemented concurrently with other ALA SBC adapters using the same implementation as described herein. Further, the format and bytestream representation of the ASIUR can be represented by a variety of processes; this embodiment relies upon the simple textual representation of the IUR, as provided by user 811 based upon HTTP. As such, the IIR for this embodiment is the same as the IUR request, as is common in many embodiments. This intermediate representation of the IUR is stored h RAM 806 on PIA 803.
  • PIA 803 establishes a C-DSSI with ALA SBC, using socket abstraction.
  • C-DSSI connection establishment is implemented via backplane 800, PBC 804, 814, RAM 806, connection 901 , 910, and DMA 903 using the network socket simulation technique using the PCB bridging techniques described above and illustrated in Fig 10.
  • PIA 803 communicates the ASIUR to ALA SBC, using the simulated socket connection constructed in (4), above. Specifically, the IIR stored in RAM 806 on SBC 803 is transmitted over backplane 800 via PBC 804, 814, using connection 901 , 910, as the electrical connectivity across backplane 800. Upon receipt by PBC 814, CPU 815 and DMA 903 cooperate to store the ASIUR in RAM 806 via electrical connectivity 904 and 905. This results in the ASIUR being stored in RAM 806 and being available for interpretation by CPU 815 on ALA SBC,.
  • ALA SBC translates ASIUR into ASIR using CPU 815, in preparation for ASIR to be encoding into ALP for transmission to the LRCS 812, having received the ASIUR via the C-DSSI.
  • ASIR is identical to ASIUR.
  • the ALP expected by LRCS 812 is identical to what the LRCS 811 provided in the original IUR.
  • no intermediate transformation of the ASIUR is required by ALA SBC,.
  • the ASIR is stored in RAM 806 on ALA SBC,, awaiting transmission to LRCS 812.
  • ALA-LRCS communication if required by the semantics of the specific IUR, according to the manner defined previously in the abstract formulation, ALA SBC establishes a PNC to LRCS 812, in the manner defined above specific to ABA SBC adapters, and transmits the ASIR in the ALP format mutually agreed upon by ALA SBC, and LRCS 812.
  • CPU 815 requests that a PNC be constructed, ala the socket abstraction, using Ethernet chip 907 via electrical connection 908 and 909. Similar to other network connectivity, LRCS 812 accepts the network connection and establishes a bi-directional communication path between LRCS 812 and CPU 815.
  • RAM 806 As is common, intermediate representation of data being transmitted via Ethernet chip 907, is stored in RAM 806 on ALA SBC,.
  • ASIR is identical to ALP, in this embodiment, ALA SBC, simply communicates ASIR over PNC to LRCS 812.
  • LRCS 812 Upon receipt, LRCS 812 responds by communicating the ASIRPR of the request defined h ASIR back to ALA SBC,.
  • ALA SBC stores such parameter results in RAM 806.
  • PIA result receipt using the same bi-directional process defined in (5) the C- DSSI, but in the reverse direction, ALA SBC, communicates the parameter results received from LRCS 812 in (7) to SBC 803, in response to the respective ASIR request which corresponds to the IUR from the original user 811 which PIA 803 delegated ASIR to ALA SBC, in (4).
  • PIA SBC 803 stores the ASIRPR in RAM 806 for subsequent interpretation and communication back to user 811.
  • the PIAP is HTTP over TCP/IP, which results in the generation of a standardized HTTP response packet by CPU 807 and Ethernet chip 907 which encapsulates the composed ASIRPR response to the original IUR from user 811.
  • HTTP HTTP
  • the PNC initiated in (1) can be 0 used in this example for returning the reply, encoded appropriately for the PIAP, to the user.
  • IUR termination the PNC may optionally be closed by user 811 , depending upon the requirements being fulfilled by user 811.
  • the PIAP ALP, 5 HTTP in this embodiment includes a provision for either user 811 or PIA S BC 803 to optionally specify physical closure at this step. If user 811 opts to physically close the PNC, then Ethernet chip 907 is notified of the closure request via normal TCP/IP connection semantics. Ethernet chip 907 relays the closure request to CPU 807 which then disconnects the socket abstraction and 0 releases the computational resources in RAM 806 allocated for this process.
  • the PIAP ALP (HTTP) implements the optional PIAP- specific non-physical token closure mechanism via the backplane 200 OK result status code.
  • the backplane 200 result code indicates successful completion of the last request which was submitted via the PNC. 5
  • Declarative configuration 1403 serves to facilitate arbitrary configuration of integration processes by users 1401 without the user 1401 having to explicitly or implicitly specifying programmatic code.
  • programmatic code is defined to be any human-readable, machine-readable, or combination thereof which is source code, object code, executable code, or any equivalent intermediate form in-between written in a manner which uses or is logically equivalent to a programming language.
  • a preferred embodiment for declarative configuration will be described below.
  • Declarative configuration 1403 is one of three preferred embodiments described here for configuring the multi-protocol integration system for integration processes. Declarative configuration 1403 is particular to the invention, while the other two, common to prior systems, are: programmatic code and graphical. Thus, declarative configuration is an embodiment of an abstract formulation which could serve to interpret an IUR, as described above, within an embodiment of the GFIP such as PPF.
  • programmatic code configuration enables the user to instruct specific procedural instructions for the instantiation, via writing and compiling programming code (such as in Java), which adheres to a specific application programming interface (API).
  • API application programming interface
  • the compiled programmatic code must be installed or uploaded, at which time it will be available for use.
  • graphical configuration enables the user to instruct specific procedural instructions for the instantiation, via use of a graphical user interface (GUI) such as program written in HTML for use via a browser on the Internet or a custom program for Microsoft Windows.
  • GUI graphical user interface
  • the system implementing the GUI uses the configuration instructions provided by the user via the GUI to generate some instance of programmatic code, whether compiled, interpreted, or other alternative translation into a form executable on a computer system, or its functional equivalent.
  • declarative configuration 1403 provides a method in which users 1401 can provide configuration instructions to an instance of an embodiment 1402 of the multi-protocol integration system without writing any programmatic code or generating code with a graphical user interface, as common to prior systems.
  • the following are attributes of declarative configuration 1403, as illustrated in Fig. 14, which further demonstrate contrast with prior systems.
  • non- programmatic configuration is a capability of GFIP, rather than functionality which is independent or an extension, and thus an "add-on" or equivalent.
  • the instructions provided by the user 1401 to declarative configuration 1403 do not generate programmatic code which must subsequently be compiled, interpreted, loaded or otherwise managed similar to programmatic code by users.
  • neither the abstract formulation nor embodiments require the structure of declarative configuration 1401 to be defined, adherent to, or otherwise affected by an application programming interface (API) for programming code or equivalent.
  • API application programming interface
  • the method provided by declarative configuration 1403 is translating one or more configuration instructions (for example, as embodied by a UIR, as described above, or any logically equivalent) from a user 1401 to one or more configuration tables 1406 associated with one or more instances of the composite set 1405 of finite state machine 1407, bytestream 1409, and intermediate virtual representation 1408, as described above.
  • the declarative configuration 1403 relies upon communicability with each of the composite sets 1405 via a connection 1404.
  • An abstraction formulation for such connection 1404 is provided above, while a preferred embodiment for such connection 1404 is provided below.
  • the abstract functional role for configuration tables 1406, as they correspond with finite state machines 1407 and exception tables (not illustrated, for clarity; see below for a description), within the multiprotocol integration system is described in below.
  • Fig. 14 omits specific details about the composite set, which are described in greater detail above and below.
  • a preferred embodiment for declarative configuration particular to the multiprotocol integration system contrasting with prior systems would be the combination of two components.
  • a component capable of providing the user 1401 with a command line interface (CLI), supporting a network protocol over the connection 1410 such as RFC 854 (the embodiment of such may optionally include a terminal emulation, such as VT100).
  • CLI command line interface
  • RFC 854 the embodiment of such may optionally include a terminal emulation, such as VT100.
  • VT100 terminal emulation
  • VT100 terminal emulation
  • declarative configuration 1403 would provide an embodiment which provided a non-programmatic, human-readable display format which enabled a user 1401 to specify arbitrary configuration instructions for arbitrary integration processes.
  • MRTR multidimensional representation transformation and transaction representation
  • the intermediate virtual representation is illustrated by this embodiment via one or more logically-contiguous sequences 2102 of zero or more logical elements 2103.
  • Each individual element 2103 of a sequence 2102 is termed a slot.
  • Each logically-contiguous sequence of logical slots 2102 is termed a "dimension”.
  • Each instance of the intermediate representation corresponding to this embodiment, consisting of one or more dimensions 2102, is termed a region 2101.
  • the quantity of dimensions 2102 in Fig. 21 is an attribute of a specific region instance; equivalently, the number of dimensions in a region is not an attribute of this embodiment.
  • each slot 2103 should be interpreted as a "placeholder” or "logical unit”, rather than as an insertion point or similar interpretation arising from any specific physical interpretation (such as, for example, might be found on an embodiment of the hardware, as described previously).
  • slots may be opaque in the interpretation that their structure does not imply a particular instantiation (such as a one-to-one mapping between slots and bytes), although such a defined structure may be illustrated by an embodiment or a specific instance of an embodiment.
  • Slot opacity provides many benefits, for example enabling multiple concurrent data consumers to view the same dimensions logically inconsistent ways, as described below. Further, the mechanism in which slots 2103, dimensions 2102, and regions 2101 are computationally implemented are not defined by the invention.
  • a multidimensional region 2101 is composed of dimensions 2102, as in Fig. 21.
  • a contiguous range of slots 2201 , 2203, 2006 are contained within their respective dimension 2101 , where a range is defined to be one or more slots which are contiguous in the same dimension.
  • the dimensions within a region may have zero or more relationships, whether explicit or implicit.
  • An relationship is defined in this context as a logical correspondence which may materially affect one or more operations performed upon the region 2101.
  • One embodiment for operationalizing relationships within a MRTR is via annotations, as described below.
  • any criterion which can be computationally quantified can equivalently be expressed as a relationship among dimensions, whether applicable to all MRTR intermediate representations or only specific to one or group of protocols or formats.
  • an explicit annotation 2302 is a relationship which is denoted via specific corresponding values within one or more slots 2301 in the same dimension 2101.
  • An implicit annotation 2303 is a relationship which is not denoted via specific corresponding values within one or more slots in the same dimension. Instead, the corresponding annotation value for the implicit relationship is maintained externally from the dimension 2101 , and corresponding dimension, via any mechanism which can temporarily store the corresponding value. Thus, an annotation may be either explicit or implicit.
  • one or more types of annotation identifiers 2304 may be required to logically associate the annotation storing the corresponding value with the one or more slots 2301. Neither the number and types of relationships among regions nor their operational interpretation, given a plurality of such relationships are possible, is not considered an attribute of MRTR
  • a secondary function for annotations within MRTR is to provide attributes for individual slots 2402 or ranges of slots 2404 within a dimension.
  • An attribute could be type, as defined programming language theory, as illustrated in Fig. 24.
  • the blocks in Fig. 24 should be considered an attribute of implementing and interpreting a type attribute for a specific instance of a dimension, and thus not defining characteristics for MRTR annotations.
  • the dimension 2401 could maintain data being used in one or more concurrent integration process data operations 2403. Each data operation could view the data maintained by the slots with the type annotation in a type-incompatible manner.
  • a representative data operation 1 could view the slot data as type t1 2405, while data operations 2 and n interpret the slot data as type t2 2406 and t3 2407, where each type t1 , t2, t3 differs mutually.
  • the term view in this context is intended to be interpreted generally, to refer to any process of logical interpretation or similar.
  • the difference in type is illustrated in Fig. 24 by the differing visual patterns in slot views 2405, 2406, 2407.
  • the visual patterns are purely for display clarity and not a defining attribute of MRTR.
  • MRTR supports the definition, instantiation, and operationalization of arbitrary computational operations defined over any combination of slots, ranges, dimensions, and regions, just as such operations can be defined over any well-defined abstract formulation. Further, both basic and composite operations can be derived, as necessary to facilitate arbitrarily complex data exchange and translation algorithms as necessary by the invention.
  • One embodiment for an abstract formulation for computational operations 2501 upon MRTR is defining a functional relationship between a source region 2502 and a destination region 2503.
  • the functional input from the source region 2502 consists of one or more slots or ranges 2504.
  • the functional output into the destination region 2503 consist of one or more slots or ranges 2505.
  • the relationship between the input slot and ranges 2504 and the output slots or ranges 2505 is independent.
  • the functional operation may result in differing number, size, or shape of output slot or ranges 2505.
  • the functional operation may result in modifications to slots in different dimensions of the destination region 2503 than the source region 2502.
  • the functional operation may result in slots or ranges 2504 which are contiguous in the source region 2502 becoming discontiguous in the destination region 2503.
  • operations 2501 can also be composed recursively and also utilize conditional logic, facilitating implicit dependencies among and between operations.
  • a key advantage of this type of flexible computational operations is the ability to specify what otherwise would be complex, potentially composite, operations (e.g., require many individual programming code lines in a traditional programming Inaugage, such as Java) over slots, ranges, dimensions, or regions using a single logical operation.
  • arbitrary many-to-many computational operations can be defined via composition of discrete computational operations 2501. Referring to Fig. 26, 2501 , 2502, and 2503 are from Fig. 25 with detail excluded for clarification.
  • a derived operation 2601 is a computational operation, as defined above, which is invoked implicitly in response to invocation of computation operation 2501. MRTR capacity to invoke implicit operations, transparently from the perspective of the invocation of the operation 2501 , provides numerous benefits.
  • a common requirement for integration processes are to participate in local or distributed transactions. Therefore, one instance of a derived operation 2601 could invoke the begin transaction operation, while a subsequent derived operation could invoke the commit or rollback operation. Such a subsequent derived operation could be associated with the same operation 2501 , another functional operation, any arbitrary asynchronous functionality (such as expiration of a timer), or any equivalent.
  • the definition of the begin, commit, and rollback operations in this context is equivalent to their accepted definition within transaction processing theory.
  • a derived operation may or may not be opaque from the perspective of the logic invoking the operation, and may or may not require configuration.
  • a specific process provides one preferred embodiment of the finite state machine, as described initially in reference to Fig. 3, and provides significant computational advantage and contrasts with prior systems.
  • the defining components of the process are a bytestream 2702, whose attributes are defined below, and a suitably-defined resumable pull stream automata (RPSA) 2701 as described below.
  • RPSA 2701 is an embodiment of the finite state machine 303 from Fig. 3, and thus should not be considered a defining attribute of this invention.
  • RPSA 2701 is an embodiment of the finite state machine 303 from Fig. 3, and thus should not be considered a defining attribute of this invention.
  • RPSA resumable pull stream automata
  • V is not an attribute of this process, as V is only required for finite-length bytestreams.
  • the physical location where V is computationally storage is also not considered a defining attribute of this process, as it can be stored in the schema matrix, a lookaside buffer, or any other temporary storage mechanism within the invention.
  • the value of V is set to the numeric zero (0) upon entering the Begin state 2706.
  • R 2713 a specific logical function 2713, referred to as R 2713, can be defined over the bytestream with specific semantics.
  • R 2713 is not a state or transition in RPSA 2701 , but rather a function which may be invoked by RPSA 2701 to request data from the bytestream 2702.
  • the semantics of the R 2713 function is that upon request, the R function will either retum a positive amount of data from the bytestream or an indication that no data is currently available. The positive amount of data, if returned, is referred to as D.
  • the length of D, provided D is returned for an invocation of R 2713, is referred to as
  • Precisely how such a read function is implemented over the bytestream is an attribute of an embodiment of this process.
  • bytestream 2702 can equivalently be a bi-directional bytestream without materially altering the definition of this process.
  • this process is symmetric, and thus is applicable for both input and output processing, as the bytestream 2702 and schema matrix 2704 can be exchanged without materially altering the definition of this process.
  • the first condition is that the bytestream 2702 may stall zero or more times during a communication process.
  • the term shall is defined in this context to mean that there exists non-zero lengths of time during a communication operation (after the start and before the end) in which no data is available.
  • blocking the condition which arises in response to a stall is commonly referred to as "blocking". Specifically, the R returns _ when the bytestream 2702 stalls.
  • the sequence of data which is received on the bytestream 2702 in-between stalls, if such stalls occur, during a communication process is termed a chunk.
  • the second condition is that the bytestream 2702 may be readable by this process only once, in a strictly sequential (non-random access) order. In such cases, the bytestream 2702 can equivalently be referred to as a sequential bytestream.
  • the third condition is that the bytestream 2702 may have a finite (bounded) or infinite (unbounded) length; thus, the bytestream is not required to adhere to any boundedness constraints.
  • the schema matrix 2704 and lookaside buffer 2703 while defining attributes of this invention, are not required for this preferred embodiment of the finite state machine. If they are optionally used with this process, then the dashed lines connecting Process state 2708 and schema matrix 2704 and lookaside buffer 2703 represent the functions necessary to read and write values from the respective intermediate virtual representation or lookaside buffer. Their nonnecessity arises from the observation, recognizable by one skilled in the art, that either the schema matrix 2704 or the lookaside buffer 2703 can be replaced b y a null function which supports an equivalent set of read-write operations.
  • a null function is defined in this context to mean a function whose invocation performs no material computational action.
  • the RPSA consists of 5 states: Begin 2706, Pull, 2707, Process 2708, Halt 2710, and End 2712.
  • the automata state transitions are Begin_Pull, Pull_Process, PullJHalt, Pull_End, Halt_Pull, Process_Pull.
  • Actions which are invoked by logic external to the RPSA are represented by dotted lines: start action 2705, resume action 2711 , and continue action 2709.
  • a communication process which is processed by RPSA 2701 begins a communication process in state Begin 2706.
  • the RPSA remains in the Begin state until the start action 2705 is invoked, causing the Begin_Pull transition to occur.
  • control is not returned to the logic which invoked the RPSA until a subsequent State.
  • control refers to the single sequence of instructions being executed (for example, when a CPU is executing a steam of instructions and an arbitrary function f is invoked and the calling program must wait to continue until f completed execution, in one preferred embodiment)
  • the Pull state 2707 implements a composite operation: compare the value of V and N, if (V ⁇ N) then invoke R 2713 and incur a state transition based upon evaluation of the result. If (V > N), then the Pull state will invoke the Pull_End transition. The RPSA will remain in the End state until the start action 2705 is invoked on the Begin state 2706. If the result of the R 2713 invocation is D, then the Pull_Process transition occurs. If the result of the R 2713 invocation is _, then the Pull_Halt transition occurs.
  • a process operation is invoked. Every time the Process state 2708 is entered, V is incremented by one. Such process operation may result in reading or writing data from either or both of the schema matrix or lookaside buffer, as described above.
  • the RPSA Upon completing the Process operation (referred to as process-completion), the RPSA returns control to the logic which invoked the RPSA, yet the RPSA remains in the Process state 2708. Therefore, the automata states are independent from the states associated with any logic which invokes the RPSA. The ability for the RPSA to retum control to the logic which invokes the RPSA, while still maintaining in the Process state (and optionally retaining reference to the schema matrix 2704 and lookaside buffer
  • the logic invoking RPSA may subsequently request RPSA continue processing the communication at any time (as control was returned upon entering the Halt state 2701 or upon completing the Process operation in Process state 2708) via the respective continue action 2709 or resume action 2711.
  • the Halt_Pull transition occurs.
  • the Process_Pull transition occurs. Referring to Fig. 28, a simple illustrative example of using this process for implementing one instance of quality-of-service for the invention is described.
  • QoS quality-of-service
  • the QoS embodiment 2801 consists of any computational implementation which supports the capacity to execute a sequence of instructions and maintain temporal data (such as a CPU combined with RAM).
  • the QoS loop 2801 is executing a processing loop 2804, which is defined as a finite or infinite flow control loop over a fixed set of operations; for example, the "for" flow control statement found in many programming languages (e.g., Java) would suffice.
  • the processing loop 2804 is invoking operations defined over a plurality of RPSA 2803, with 3 RPSAs 2803 illustrated in Fig. 28. As described in the context of Fig. 27, each of the RPSA are feed data through a single bytestream 2802, according to the description above.
  • a simple QoS prioritization algorithm can be implemented by this processing loop 2804. Specifically, define the term iteration to mean the composite processing operation for the RPSA: either a continue action 271 1 or resume action 2709, as appropriate for the current state of the RPSA, as described above.
  • each iteration of the QoS logic 2804 provides each RPSA a "turn" for processing data.
  • freq(RPCS) to be the measure of how many discrete processing operations the QoS logic 2804 invokes, corresponding to each RPSA 2803. In this example, enumerate the different RPCS from 1 to n.
  • Fig. 29 illustrates the logical components associated with a dynamic finite state machine 2901. While visually similar to Fig. 11 , this figure differs as ft excludes detail, which was presented in previous figures, to ensure clarity in illustrating dynamic finite state machines.
  • the finite state machines described thus far are static: a fixed automata whose attributes depend on the attributes of its instantiation and optionally a configuration table, as described above.
  • the finite state machines illustrated in Fig. 29 are dynamic finite state machines 2901.
  • the definition of a dynamic state machine is that the set of states and transitions, along with all the corresponding computational instantiation implied therein, may change in response to specific, well-defined conditions. Note that whether an automata is static or dynamic is an attribute of an embodiment of this invention, and thus a defining attribute of the invention.
  • the dynamic finite state machine 2901 includes the same components as a finite state machine, as described previously. Of specific importance to this description are the bytestream 2904 and the intermediate virtual representation 2905. Just as with a static finite state machine, the dynamic state machine 2901 performs the state process as defined above of moving data from the bytestream into the intermediate virtual representation for input processing, and moving data from the intermediate virtual representation to the bytestream for output processing.
  • a dynamic finite state machine can be used for both input and output processing, due to the symmetry of its definition.
  • the dynamic finite state machine 2901 can be defined in terms of a set of states and transition rules Z1 2903 and Z2 2902.
  • state pair we define the term state pair as the pair ⁇ set of states, transition rules ⁇ , as necessary to define the dynamic finite state machine 2901.
  • transition rules ⁇ we define the term state pair as the pair ⁇ set of states, transition rules ⁇ , as necessary to define the dynamic finite state machine 2901.
  • Z1 2903 and Z1 2902 are state pair instances.
  • set of sales and transition rules are sufficient for uniquely defining a finite state machine when defined as above. For cases which such are not sufficient, as might be required in an embodiment which includes dependent functional invocation for example, the definition of Z1 2903 and Z2 2902 should be appropriately broadened, as necessary, to maintain such additional values.
  • What defines a dynamic finite state machine 2901 is the capacity for its state pair to change during its execution.
  • the timing, interval, frequency, and other specific temporal parameters about its changing are not considered defining attributes of a dynamic finite state machine 2901.
  • the illustration of two state pairs h Fig. 29 is an attribute of the Figure, not a defining attribute of a dynamic state machine.
  • the dynamic finite state machine 2901 may have a plurality of potential state set instances which the dynamic finite state machine 2901 may be defined by.
  • the term assignment is defined in this context to mean the process in which the state pair of the dynamic finite state machine 2901 is assigned to a specific instance value (such as Z1 2903 or Z2 2902).
  • the condition, timing, and other operational characteristics which causes assignment to occur for a dynamic finite state machine 2901 are not considered defining attributes of a dynamic finite state machine 2901.
  • Dynamic autogeneration is an assignment conditional which results in the generation of state pairs which reflect configuration parameters, commonly provided by the user. Specifically, a configuration update, as defined above, may be performed by a user which results in the dynamic creation of the appropriate corresponding state pair for one or more dynamic finite state machines.
  • Z2 2902 could represent a state pair which was generated in response to a configuration update performed by a user.
  • dynamic autogeneration is independent of the state set or transition rules for a specific dynamic finite state machine, and thus is universally applicable within this invention.
  • Dynamic stimuli is an assignment conditional which modifies state pair used b y the dynamic finite state machine 2901 based upon quantitative dynamic parameters, whether dependent or independent from specifics of the specific integration process occu ⁇ ing at that time. Dynamic stimuli may occur via, at least, two ways: self-reflectively or non-self-reflectively.
  • Self-reflective dynamic stimuli assignment is defined by an assignment conditional which is invoked by the dynamic state machine itself. Equivalently, the dynamic state machine invokes the necessary operation, however that may be implemented in an embodiment, to perform the assignment.
  • Non-self-reflective dynamic stimuli assignment is defined as any assignment of a state pair for a dynamic finite state machine which occurs in response to quantitative dynamic parameters, as defined above, performed by any logic other than the dynamic finite state machine whose state pair is being modified.
  • An operational complementary component for a multi-protocol integration system step is the definition of a process for logical dataflow of a multi-protocol integration system, referred to as the universal logical integration dataflow (ULID). More specifically, this definition expresses the essential intent and design of implementing a functional multi-protocol integration process using an embodiment of this invention. Further, the formulation of ULID further exemplifies that the invention delivers operations on a multi-protocol integration system by using an integration method which is independent of application protocol. ULID further demonstrates how the invention contrasts with previous systems, as well as general-purpose computers, as ULID specifically defines a formulation of dataflow which is not generally-programmable.
  • the ULID consists of numerous discrete components, each of which cooperate defining one embodiment for the logical dataflow of this invention. Discussion of ULID begins by elaborating on the dataflow for the interfaces, finite state machines, and virtual intermediate representation as described above conjunction with Figs. 2 and 3. This initial dataflow using these components is sufficient for fulfilling the requirements for this invention as a universal integration system. Sequential multi-stage conditional dataflow (SMCD) is described below, which is one preferred embodiment of ULID. Further, using techniques conceptually similar to the means described above in the preferred embodiment for PPF, a preferred embodiment for ULID can similarly be implemented using the hardware embodiment of this invention as described above.
  • SMCD sequential multi-stage conditional dataflow
  • SMCD sequential multi-stage conditional dataflow
  • Fig. 15 provides an enlarged view of Fig. 13 focusing on illustrating how additional dataflow and corresponding integration exchange and translation operations 1501 , may optionally be facilitated between intermediate virtual representation matrices 1303, 1304.
  • SMCD sequential multistage conditional dataflow
  • Fig. 16 provides an view of Fig. 13 overlaid with three pipelines 1601 , 1602, 1603.
  • the components in this figure represent attributes of the SMCD embodiment of the ULID, and thus should not be considered defining attributes for this invention.
  • the dataflow in the SMCD is broken into three pipelines, which all run concurrently: a prefix pipeline, an infix pipeline, and a suffix pipeline.
  • the pipelines run semi-independently, as their primary inter- dependency arises from the data which is sequentially passed between them. Further, there may be one or more instances of each pipeline running independently and concurrently, depending upon the specific integration processes which are being processed by the invention.
  • One or more instances of the interface, finite state machine, and intermediate representation as described above may be a component included in either or both the prefix pipeline 1601 or the suffix pipeline 1603.
  • attributes of either the prefix pipeline 1601 or suffix pipeline 1602 may imply certain functional requirements for the corresponding finite state machine.
  • the prefix pipeline 1601 and suffix pipelines 1603 are physical pipelines, as they are executed on specific (i.e. defined in advance) integration interfaces: the prefix pipeline executes on an input interface and the suffix pipeline executes on an output interface.
  • the infix pipeline 1602 may be a virtualized pipeline, and may exist for "conceptual convenience" and thus not reside on a specific integration card. Instead, the infix pipeline may be composed of composable transformation operations which can be distributed across input and output interfaces.
  • this 3-stage SMCD design could be equivalently formulated as a 2-stage design, as the infix pipeline may be virtualized.
  • the 3-stage design is presented here solely for clarity in description.
  • the SMCD 1700 is the aggregation of one or more prefix pipelines 1701 , zero or more infix pipelines 1702, and one or more suffix pipelines 1703.
  • Data for an individual integration process is received by a prefix pipeline 1704, optionally passed to an infix pipeline 1702, passed to a suffix pipeline 1706, and then sent to the destination system by the suffix pipeline 1706.
  • a single iteration of any pipeline is termed a cycle; the transfer of a logical piece of data through the entire process (i.e. through all iterations of the pipelines, as defined by the configurable transformation rules such as illustratively exemplified through 1704, 1705, 1706) is termed a completion.
  • a crossbar is defined as a logical interconnectivity which facilitates exchange, also referred to as representation switching, of intermediate virtual representations among one or more of the pipelines.
  • this design uses the infix crossbar 1708.
  • this design uses all three illustrated crossbars 1707, 1708, and 1709.
  • the minimal crossbar requires ⁇ -to- ⁇ interconnectivity.
  • Crossbar 1707 is the prefix crossbar, which provides connectivity between the ⁇ prefix pipelines and the ⁇ infix pipelines and the ⁇ suffix pipelines.
  • Crossbar 1708 is the infix crossbar which connects each of the ⁇ infix pipelines. Infix pipeline switching is described below.
  • crossbars 1707 and 1709 are equivalent.
  • the electrical interconnectivity, optical interconnectivity, and other operational attributes of the crossbar e.g., blocking, switched, wormhole
  • the crossbar is time-divisioned according to the cycle times of the pipelines is also not considered a defining attribute of the dataflow crossbar architecture, but rather an attribute of an embodiment.
  • a preferred embodiment of SMCD uses MRTR, as described above, as a standard intermediate representation which is used in common across all pipelines.
  • the use MRTR is deliberate: all data flowing through the system must be discretely packetizable into variable-length multidimensional regions.
  • MRTR serves a the conceptual equivalent to the "packet" in physical-layer devices.
  • the use of a homogeneous intermediate representation, such as MRTR enables all pipelines to utilize an identical cycle.
  • MRTR is independent of application protocol
  • MRTR can further be used as a common intermediate representation across all pipelines, irrespective of the application protocols being processed b y each pipeline.
  • Data sinks can be understood analogously as dead message queues (DMQs) within message queuing (MQ) or publish-and- subscribe (PS) architectures.
  • DMQs dead message queues
  • MQ message queuing
  • PS publish-and- subscribe
  • physical-layer devices such as routers or switches do not have any analogies of data sinks: packets are either dropped silently (as in contention or for unreachable UDP packets) or are never connected (as in TCP).
  • Data sinks are necessary in this dataflow architecture to support once-and-only-once delivery (03), transactional semantics, data validation, exception handling, state reconciliation, and state preservation.
  • juncture Each individual processing step, as exemplified below, within a pipeline is termed a juncture and the collection of all the junctures are termed the juncture set.
  • This dataflow architecture is termed contextually opaque, as pipelines, junctures, intermediate virtual representations, and all other components in the SMCD rely upon identifiers which are opaque.
  • An opaque identifier is defined as an identifier which does not define the physically context for which the data will be processed next. This differs fundamentally from all other types of middleware and prior systems, in which explicitly knowing the identity of the destination is a prerequisite.
  • the dataflow begins with the prefix pipeline 1801 and ends with the resulting intermediate representation 1805 being sent via 1804 to the either the infix pipeline or suffix pipeline, depending upon the optionality of infix processing for the specific data being processed.
  • the prefix pipeline 1801 starts by accepting the application protocol being connected by the integration system via an application protocol communicated via the bytestream 1803.
  • One or more processing steps are initially executed by a finite state machine 1802, which sequentially executes junctures 1808, 1809, 1810, 1811 , and 1813. Any exceptions which occur during processing in the prefix pipeline 1801 are reported to the exception table 1807 via 1816, using an operational mechanism which is an attribute of an embodiment.
  • the lookaside buffer 1806 is accessed via 1815, using a operational mechanism which is considered an attribute of an embodiment.
  • the Protocol Interpretation juncture 1808 serves to interpret the basic mechanics of the specific application protocol. For example, protocol interpretation would perform all the processing to decode, decrypt, reorder, error recovery, flow control, and other similar tasks which are independent from the schematic interpretation of the data. This juncture 1808 is conceptually equivalent, while functionally different, to framing and similar frame-oriented operations (e.g., OSI layer 2) in physical-layer devices.
  • the Format Parsing/Block Assembly juncture 1809 serves to interpret the data format which was prepared for interpretation by the Protocol Interpretation juncture 1808.
  • the primary objective of this juncture 1809 is to convert the data, whose input structure depends directly upon the application protocol, into a block structure regularized for the application protocol abstraction (e.g., MQ, RPC, etc).
  • format parsing would perform all the processing necessary to interpret the semantics of the data format including operations such as data validation and schema mapping.
  • the Filter/Sort juncture 1810 serves to performing arbitrarily complex filtering and sorting operations upon the blocks, based upon parameters defined in terms of the application protocol. Any operation which can logically be specified is supported by this juncture 1810.
  • the primary objective of this juncture 1810 is to enforce data selection, data validation, data shaping, and other conceptually similar rules which depend upon mutating the structure or order of the data.
  • the Transposition juncture 1811 serves to transform the blocks, which are the cycle for the junctures processing the application protocol, into the intermediate virtual representation 1812 (such as MRTR).
  • the intermediate virtual representation 1812 such as MRTR.
  • the Filter/Sort Representation juncture 1813 serves to perform arbitrarily complex filtering and sorting operations upon intermediate virtual representation instances 1812, based upon parameters defined in terms of the intermediate virtual representation.
  • the output from this juncture 1813 is the resulting intermediate virtual representation 1805 from the prefix pipeline 1801.
  • the difference between this juncture 1813 and juncture 1810, is that the filter/sort operations are defined over the application protocol in juncture 1810 while they are defined over an intermediate virtual representation in juncture 1813.
  • the cycle for the prefix pipeline 1801 finite state machine is a block, which is an increment of data.
  • the definition of the term increment depends upon the application protocol, but abstract represents an aggregation of data which is organized into a logical group.
  • an application protocol which implements queuing abstraction such as Java Message Service
  • an application protocol which implements a (object) remote procedural call (such as CORBA, RMI, or SOAP) defines a block in increments of functional invocations.
  • the finite state machine outputs an intermediate virtual representation 1812.
  • Such intermediate virtual representation 1812 is processed by zero or more junctures external to the finite state machine (such as juncture 1813) and the resulting intermediate representation 1805 is sent to either the infix or suffix pipeline, according to the conditions defined above.
  • the functionality or execution operation of the finite state machine 1802 as well as juncture 1813 may be specialized by parameters provided by the configuration table 1814.
  • Configuration tables, their role in GFIP, and their role in providing declarative configuration are described above.
  • a preferred embodiment of SMCD uses dynamic finite state machines to facilitate dynamic configuration.
  • junctures may be omitted.
  • execution of the Filter/Sort Blocks juncture 1810 would not commonly be required for integration processes which do not define a logical filter operation.
  • functionality in pipelines can be implemented by junctures in either or both the finite state machine 1802 or logic external to the finite state machine 1802, such as the Filter/Sort Representation juncture 1813.
  • the suffix pipeline 1901 is a symmetric reflection of the prefix pipeline. Therefore, the input to the dataflow for the suffix pipeline is a sequence of intermediate virtual representations 1903, while the output is a bytestream 1904 processed by a finite state machine 1902 which communicates with the connected system according to the mutually-agreed upon application protocol.
  • the operation of the suffix junctures are respectively sequentially- symmetric equivalent to those defined for the prefix junctures.
  • the infix pipeline 2001 is optionally executed after execution of the prefix pipeline 2005 and prior to execution of the suffix pipeline 2016.
  • the infix pipeline accepts as input an intermediate virtual representation 2006 from the prefix pipeline.
  • the infix pipeline outputs an intermediate virtual representation 2015 which is sent to the suffix pipeline.
  • the infix pipeline includes zero or more configuration tables 2002, which are accessed by each of the junctures via 2019. Exceptions which may occur during processing in the infix pipeline 2001 may be reported to zero or more exception tables 2004 accessed by junctures via 2018, using an operational mechanism which is an attribute of an embodiment.
  • Zero or more lookaside buffers 2003 may be accessed by junctures via 2017, using an operational mechanism which is considered an attribute of an embodiment.
  • the sequential juncture processing of the infix pipeline 2001 is as follows.
  • the Classify, Assemble, Fragment 2007 juncture performs arbitrary assembly and fragmentation operations, based upon arbitrary classification algorithms, which enable n-to-m intermediate representation transformations. If m ⁇ n, then an assembly operation was performed; otherwise, a fragment operation was performed.
  • the Filter/Sort Representation 2008 juncture performs filtering and sorting of intermediate representations, based upon arbitrary filtering and sorting algorithms.
  • the Filter/Sort Representation 2013 and Classify, Assemble, Fragment 2014 junctures are sequential-symmetric equivalent to the respective junctures 2008 and 2007.
  • the output from the Classify, Assemble, and Fragment 2014 is the intermediate virtual representation 2015 which is outputted to the suffix pipeline 2016.
  • the prefix transform 2009, universal virtual representation 2010, and suffix transport 2012 form the core of the dataflow universality defined by the invention.
  • the prefix transform 2009 transforms the intermediate representation incoming from the prefix pipeline into a universal virtual representation 2010.
  • the suffix transform 2012 performs the inverse transformation, converting the universal virtual representation 2010 into an intermediate representation.
  • the dataflow architecture does not define any specific attributes for this universal virtual representation 2010, other than stipulate that the representation of the universal virtual representation 2010 is independent from both the prefix intermediate representation 2006 and suffix intermediate representation 2015.
  • Preferred embodiments for operations which can provide such a universal virtual representation include the following, which were discussed above: value- mapping, schema-mapping, and first-order-logic.
  • the infix crossbar 2011 provides infix pipeline switching, as described above, which facilitates switching of intermediate virtual representations between infix pipelines. As switching intermediate representations among infix pipelines is not a required attribute for minimal functionality the dataflow design, the existence or non-existence of the infix crossbar 2011 is considered an attribute of an embodiment.
  • POMSQ partially-sequential opaque multi-stage queuing
  • POMSQ is defined by the following condition: one or more of the junctures in this invention are implemented by a queue data structure, with the interface between either side of the juncture defined exclusively through standard enqueue and dequeue operations defined over the queue (thus excluding data exchange between either side that does not adhere to the semantics defined by the queue).
  • POMSQ is multi-stage, as this invention combines numerous junctures into a well-defined structure.
  • POMSQ is sequential, as this invention defines a predefined relationship among each of its junctures. POMSQ is only partially-sequential because although each of the junctures has a predefined relationship, these relationships do not constrain discrete data flowing through this invention to visit each sequential juncture. Specifically, discrete data can be given a variable path through the junctures this invention depending upon its data processing requirements.
  • queues for junctures are particular to this invention, as it provides an alternative abstraction than found in the prior art. Specifically, when considering network communication within this invention, the use of queues for network communication differs from prior art which relies upon remote procedure calls, sockets, streams, or distributed objects. In contrast, this embodiment would abstract network communication as a queue data structure.
  • the primary role for providing a queue abstraction for junctures within this invention is to facilitate decoupling between data processing stages.
  • Decoupling provides the ability for discrete stages to provide well-defined functionality without being aware of the location of the data input or data output locations. This decoupling can be made more effective by using MRTR, which ensures that even the structure and dependent operations invoked over the data input and data output are decoupled from the stage.
  • One embodiment of this invention could use opaque identifiers, such as human- readable strings, to distinguish individual juncture queues. Therefore, all data processing operations are defined over opaque identifiers which are explicitly decoupled from any distinguishing attributes of the computers which this invention is communicating. In contrast, prior art relies upon non-opaque identifiers h computation (such as an IP address for network communication).
  • the boundedness of a POMSQ queue is an equally-important attribute for implementing advanced functionality within this invention. For example, implementing quality-of-service and resource allocation is made significantly easier if the queue is inherently bounded, and thus can perform meta-queue operations; for example: measure queue "fullness”, notify stages upon queue overflow, and statistically compute average queue "fullness”.
  • Pairspace The Pairspace part of the invention pertains to a specific method and system to implement a loosely-coupled isometric distributed system, built upon an associative set of name-value pairs which are logically shared among all nodes.
  • a distributed system has numerous unique attributes, which are enumerated below, which make it ideally suited for solving specific computational problems within a broad class of problem domains.
  • Fig. 30 - 53 correspond to the following description of the Pairspace pair of the invention.
  • Pairspace part of the invention are defined in the same order as the vertical schema for a distributed system described above; such an ordering is optimal as it enables the clear exposition of each component, while equally highlighting the interdependencies between the plurality of components in the system.
  • the Pairspace part of the invention is built on a single concept: a single mutually shared set of pairs, denoted symbolically as (name, value), which are accessible from all nodes within the system.
  • This set of pairs which is logically shared among all nodes, is termed a pairspace.
  • the pairspace is the communication abstraction.
  • This mutually shared set of pairs is isometric, as each node within the system perceives of the pairspace identically.
  • prior art relies upon non-isometric systems; for example, in client- server systems, there is a clear distinction between nodes providing "server” functionality versus those playing "client” roles.
  • the pairspace is anonymous, as nodes communicating via a pairspace do not have unique identifiers and no "direct" communication between individual nodes is defined.
  • Anonymity also differs from prior art, in which the role of identity is critically important.
  • data sockets are connected between nodes by the source node specifying the identity of the destination node; thus, by definition, sockets depend upon the notion of identity to operate and thus are non-anonymous.
  • the communication abstraction is a collection of associative (name, value) pairs which are isometrically accessible from every node.
  • socket and data stream abstractions which are so pervasive in the prior art, have no role in the communication abstraction defined by the Pairspace part of the invention as the pairspace defines an abstraction which is simultaneously more expressive yet simpler.
  • the defining characteristic of a pairspace is that the set of pairs are organized associatively: nodes access (or read) values within the space exclusively through a global pairwise associative function p(name) -value.
  • p(name) -value a global pairwise associative function
  • the symbol 'name' is constrained to a sequence of textual letters, composed from any written natural language (e.g., English, French, Japanese ⁇ hus, each pair within the space is uniquely identified by its name, which is associatively bound to a single value.
  • the symbol 'value' refers to an arbitrary object which can be composed in a programming language; such an object can include constructs from any language, spanning procedural to object-oriented, such as: a byte, a sequence of numbers, a hashtable, an accounting ledger, or any other operationalized concept from prior art.
  • primitive operations are those operations which are defined on the pairspace which can not be decomposed into suboperations; this contrasts with composite operations, which are defined as compositions of primitive operations.
  • the six primitive operations are defined as follows.
  • the write operation consists of binding a new pairwise association into the space, such that this new association is subsequently accessible via p; this operation requires the name- value pair being inserted into the space as the argument.
  • the read operation consists of retrieving a pairwise association which was previously bound into the space, via application of p on a given name and retrieving a value composed of exactly one from the set ⁇ _, value ⁇ , where value is an arbitrary non-null object from the set of objects defined above; this operation requires a single name as the argument and returns a value.
  • the symbol "_" is defined to mean that no value is bound to 'name 1 .
  • the remove operation consists of removing a previously bound pairwise association, such that the removed pair is no longer subsequently accessible from the space via p; this operation requires the name from the name-value pair being removed as the argument.
  • the notify operation consists of specifying a notification trigger, which signals the node which invoked the notify operation when an association is bound in the space which textually matches the name provided as an argument; this operation requires the name from the name-value pair which will be waited upon for subsequent binding i 1 : 1 to the space.
  • the testAndSet operation consists of an atomic operation which merges read and write: the pairwise association of a given name is read from the space; if the name does not map to a valid value via p (i.e. the space lacks a mapping for such name), then a name-value pair is atomically written into the space; this operation requires the name-value pair and returns a boolean: true if value was written, false otherwise.
  • the fetchAndAdd operation consists of an atomic operation which merges read, write, and numeric addition: the value of a (nameNalue) pair is read, a non- zero quantity is added to the numeric quantity of the value, the newly added value is written into the space, and the pre- added value is returned; the value of the pair is assumed to be of a numeric type, while this operation requires a name, a nonzero addition quantity, and returns a numeric.
  • pairspaces are a generative communication abstraction: each (name, value) pair inserted into the pairspace is uncoupled from the node which inserted it; no interdependency exists between the lifecycle of any pair in the pairspace and the participation of any node (esp. the node which inserted such pair) in the system.
  • node n writes pair (nameNalue), (nameNalue) will continue to remain accessible within the space irrespective of whether n continues participation in the distributed system.
  • the primitive operations RWR ⁇ T are defined atomically over the space; specifically, the pairspace is defined such that there does not exist any time, with respect to the nodes accessing the pairspace, during which any pair is disjoint; this context, disjointness is defined as the existence of one or both of two conditions: (1) a name exists within the space, but does not validly map to a value; or (2) a value exists within the space, but is not mapped to by a valid name. Atomiticity also guarantees validity of the notify operation, as such notification triggers are guaranteed to occur provided binding occurs on a non- disjoint pair.
  • a pairspace differs significantly from a tuplespace; a tuplespace defines a pattern matching function over a collection of tuples using a template tuple (commonly referred to as a pattern) composed of formal and actual fields.
  • a tuple is an instance of a collection class whose elements are "name and value" pairs.
  • Such a tuplespace pattern matching function considers both value and type identifiers, as well as instance type equality.
  • a pairspace and tuplespace may be considered conceptually akin, but their inherent properties and preferred embodiments differ significantly.
  • the communication abstraction for the distributed system which the Pairspace part of the invention defines is simply an associative pairspace with five primitive operations; contrast this with prior art which defines bi-directional point- to-point data sockets as the primitive communication abstraction, whether stated explicitly or implied.
  • Pairspaces can be dichotomized into two distinct categories: temporal and persistent; specifically, an inherent attribute of each pairspace is whether the name-value pairs are stored temporally or persistently.
  • Temporal pairspaces are a communication abstraction which are "memory-less” : all the values within the space are lost when the space is closed (space closure is defined as any set of steps which leads the space to no longer be accessible to nodes, whether explicitly closed via the nodes or implicitly closed due to power loss to the distributed system).
  • Persistent pairspaces are a communication abstraction which has "memory”: all values written into the space remain accessible until explicitly removed by a node, irrespective of intermediate space closures.
  • temporality as an attribute of a communication abstraction differs markedly from prior art.
  • Prior art assumes such a time-dynamic feature is defined by independent components which overlay functionality upon the communication abstraction; for example, persistence is not even a consideration in the method and system of bi-directional data sockets, as persistence falls outside the scope of reading and writing bytes.
  • the pairspace as a communication abstraction is notable as its attributes are self-descriptive of a fully- expressive data protocol: set of (name, value) pairs, six primitive operations, operation atomicity, and set temporality; all operations are based upon a equality comparison of a sequence of textual characters (respecting the character equality rules of the natural language; e.g., some natural languages perform textual comparison different for certain letter combinations, such as 'ch' in Spanish).
  • the pairspace does not require that nodes define a data protocol to facilitate structured communication.
  • communication abstractions defined in prior art require that nodes define such data protocols to facilitate any type of structured communication. For example, data sockets require nodes to specify a byte-oriented encoding and formatting for exchanging objects; tuplespaces require nodes to specify instance type and value operations ⁇ at minimum, equality ⁇ upon every object which is well- defined within the system.
  • the Pairspace part of the invention defines several additional logical constructs which are built upon the pairspace communication abstraction: transparent distributed garbage collection, adaptive delegation-based object invocation, and support for heterogeneous distributed object systems via transparent generic adaptive delegation. These logical constructs composed with the definition of the pairspace result in a well- defined distributed system. Further, such additional logical constructs are important for contrasts the Pairspace part of the invention with salient aspects of prior art.
  • the Pairspace part of the invention defines a reference-counting distributed garbage collection algorithm over the pairspace, which when combined with a system for nodes which supports scope-based garbage collection, results in a transparent distributed garbage collection ⁇ TDGC) resource management method and system for the Pairspace part of the invention.
  • TDGC transparent distributed garbage collection
  • Transparent distributed garbage collection is defined over a pairspace by abstracting the notion of reference counting( which is a technique well- established in the prior art; specif ically( a global isometric reference count ⁇ GIRC) can be defined for each pair, which is bound to be a non- negative value.
  • This reference count is isometric because it is not bound to any individual node, but rather is itself a ⁇ name, value) pair within the space.
  • a second "GC pair" exists (x g , 11) where x s represents the reference count identifier for pair (x,y) and ⁇ is a non-negative integer representing the present numeric GIRC.
  • Two composite operations defined over the pairspace are the basis for TDGC: lock and unlock.
  • the lock operation increments the GIRC of a pair, while the unlock operation decrements the GIRC of a pair.
  • Both operations are implemented by using the fetchAndAdd primitive on the GIRC associated with the pair being locked, specified in psuedocode as:
  • the pairspace DGC algorithm can be stated concisely as: remove pair (x,y) iff GC pair is (x- Q , 0)
  • This concise formulation is notable, as GC algorithms in prior art are significantly more complicated. To ensure atomiticity, the pairspace must implement this algorithm eagerly (as opposed to lazily), to ensure that at no time does there exist a pair (a,b) such that (a- s ,0), with respect to the nodes communicating via the space. Implementation of this algorithm over all pairs in the space is defined by the Pairspace part of the invention to be an attribute of the pairspace communication abstraction.
  • Transparency of the distributed garbage collection arises when GIRC and pairspace DBC algorithm are combined with nodes which implement transparent localized garbage collection (LGC), such as scope-based "reachability" algorithms which are common in prior art.
  • LGC transparent localized garbage collection
  • the exact mechanics how LGC are implemented by each node is not relevant, provided that it does exist.
  • Transparency is implemented by invoking an unlock operation (by the LGC, or related systems) every time a pair, which was previously retrieved via a read operation, becomes unreachable on a node.
  • the LGC provides a means for eliminating the need for programmers to explicitly track GIRCs, as the scoping reachability rules for the LGC implicitly invoke the unlock operation when necessary.
  • this TDGC algorithm implements a pairspace-wide GC policy which ensures that pairs remain accessible (i.e. are not unbound from the pairspace) at all times during which any node within the distributed system retains an reachable reference to such pair, without having explicitly decremented the GIRC to zero for such pair.
  • AdaptiveDelegation-based Object Invocation Having identified the defining characteristics of a pairspace, along with a transparent resource management policy for such communication abstraction, the next immediate concern when considering the vertical schema is facilitating implementation of computer program logic. This is important as a communication abstraction without a means of implementing program logic is not generally considered useful.
  • Pairspace part of the invention must further define the well-defined programmatic interface and specify the broad set of contextual semantics for the distributed system, as introduced above in the vertical schema.
  • AFO adaptive functional object
  • ADPM adaptive delegation-based prototype mechanism
  • fn' is serving as the delegate prototype.
  • the AFO is strongly-typed (as it has defined method signatures), yet it is generic: invoking a method on a particular object is implemented by routing the invocation via the delegation prototype.
  • method invocation over the AFO occurs dynamically via delegation: parameters of the method being invoked are transformed into method invocation argument parameters (the name of the method is not relevant, as the name is x n the pair (x, fn) , and thus implied in fn.
  • AFO defines a single generic invocation method named 'call' (referred to symbolically here as call()) which accepts an ordered sequence of arguments; in an object-oriented language, the argument would be an array of objects; in a procedural language, the argument would be an array of values or pointer references) .
  • binding methods on adaptive functional objects results all methods being invoked on a 'value' from a unique (nameNalue) pair.
  • this conditions ensures the only functionality which is defined over the pairspace are the six primitive operations.
  • methods invoked over the pairspace must be specific to an individual AFO (such as fv in this case), and such AFO must be a value in an associative pair bound in the pairspace.
  • AFOs maintain all the attributes of pairspaces: generativity, anonymity, and loose-coupling. Further, the fact that AFOs maintain such attributes further distinguish them from prior art.
  • AFOs are generative, in that their existence is unbound from the node which defined them. Equivalently, a node may insert a pair into the pairspace and then stops participating; generativity ensures that such pair will continue to exist in the pairspace, even after the node stops participating.
  • the pairspace makes this possible by ensuring that nodes using the AFO have no means of ascertaining whether the originating nodes are presently participating or not.
  • the originating node for a AFO is defined as the node which inserted the AFO into the pairspace.
  • AFOs also retain anonymity of the pairspace, as AFO objects do not provide any information which identifies the originating node. This contrasts with systems defined in prior art, in which the identity of a particular node is critical; for example, client-server systems such as the Internet (which uses domain names via D ⁇ S) would not be possible without the use of identities.
  • AFOs are loosely-coupled because the only communication between the originating node and the invoking nodes is implemention of the adaptive delegation invocation semantics. Equivalently, there is no facility for node f to communicate with node g in any manner excepting that provided by the mutually shared set of pairs in the pairspace.
  • AFOs do not require the generation of proxies for either the "server” (defined as the node where the object being invoked is hosted) or the "client” (defined as the node which is remotely invoking the functionality on the hosted object).
  • each proxy defines, for its respective node, a set of strongly-typed method signatures (whether encapsulated in an object, as in RMI, or procedurally).
  • Each node relies upon this proxy to manage invocation semantics, parameter marshalling, return value processing, and other semantics specific to the distributed system.
  • ADPM relies upon a single generic AFO which has a method interface which is strongly-typed; thus, making the AFO compatible with strongly-typed languages, such as Java.
  • pairspaces do not require the use of proxies is critically important for practical and theoretical reasons. Specifically, systems defined in prior art exemplify that proxies must be generated for every object used within the distributed system. Thus, the use of proxies requires that users define h advance all the potential objects which are used within the system. In contrast, a pairspace provides no boundary upon the AFO objects which can be inserted into the space and further does not require any a priori knowledge about such AFO objects. As such, the use of proxies with a pairspaces would violate its inherent definition -hence, why they can not theoretically be used together.
  • the Pairspace part of the invention uses delegation-based object invocation to eliminate the need to implement object-specific strong type checking across the pairspace; this is necessary because proxies implement strong type checking, yet proxies are not usable with a pairspace.
  • using delegation-based object invocation enables functionality to be defined over the pairspace using a single well-defined AFO, via call(), which transforms strongly- typed method invocations into weakly-typed remote delegation.
  • the strongly-typed method invocation is foo()
  • the weakly-typed remote delegation is through call() with 'args'.
  • pairspaces support arbitrary objects as values in (name, value) pairs, and assume no a priori knowledge about the objects, their types, or their method signatures; and (3) pairspaces are isometric and dynamic, eliminating the possibility of supporting statically compiled interface definitions (via IDL) or non-isometric proxies (e.g., stubs and skeletons) .
  • Transparent Generic Adaptive Delegation Transparent generic adaptive delegation (TGAD) is the generalization of adaptive object invocation, defined above, to support invocation of functionality from objects implemented by any existing distributed object protocol (e.g., CORBA, COM, RMI). Specifically, the usage scenario is when a node desires to invoke functionality from an object in the pairspace defined in a distributed object protocol other than AFO. Of course, this type of heterogeneous adaptation is critical for providing interoperability and compatibility with existing systems.
  • CORBA CORBA, COM, RMI
  • TGAD is necessary when 'obj' is an object accessible via another distributed protocol (e.g., COBRA) and 'foo' is remotely invoked via 'obj'.
  • COBRA distributed protocol
  • the Pairspace part of the invention implements TGAD via one unique AFO adaptive bridge per distributed protocol.
  • the adaptive bridge defines the proxies or IDL required to export the AFO into the distributed protocol, and properly marshall arguments and retum values between the pairspace and the other distributed protocol transparently.
  • the bridge defines the protocol- specific parameters for call and makes the other distributed protocols aware of the local AFO object and supports bi-directionally invocation: (1) invoked by nodes in the pairspace, to invoke functionality from objects throughout the other distributed protocol networks; or (2) objects through the distributed protocol networks can invoke functionality from AFOs in the pairspace.
  • RMI as an example of a distributed protocol within this context.
  • a single unique AFO bridge must be defined. Specifically, this bridge must define a RMI proxy stub which exports the delegation-based callO method, so it is accessible to the RMI network. In doing so, RMI objects will be accessible to nodes within the pairspace via the bridge, and vice-versa.
  • Unified Data Basis Transformations part of the invention is to define a single common abstraction through which data exchange, transformation, and process rules can be defined over. More specifically, a method and system which defines an abstract mapping between source and destination computer systems. Although all middleware systems share the same abstract formula for implementing communication between independent computer systems, the exact semantics of the map, its structure, and its implementation technique depends intimately upon the specific embodiment.
  • the present Unified Data Basis Transformations part of the invention defines an alternative technique for viewing such middleware processing, based upon a technique for representing data using a universal abstraction which is independent from the semantics of existing middleware; without loss of generality, a representative sample of such semantics of existing middleware include byte ordering, data representation, protocol encoding, and security parameters.
  • the present Unified Data Basis Transformations part of the invention defines set of basis transformations which bi- directionally transform data from any specific middleware abstraction into a representation compatible with the present Unified Data Basis Transformations part of the invention.
  • Such basis transformations are necessary to define the interfaces between existing systems and the universal data basis, as the present Unified Data Basis Transformations part of the invention defines a representation which is explicitly incompatible (without transformation) with existing middleware abstraction.
  • Fig. 51 provides a linear algebraic block diagram of a UDB, along with the source and destination transformations (defined below) .
  • a universal data basis is a novel abstraction which facilitates representation and transformation of data from any middleware communication abstraction, along with defining a set of primitive operations.
  • One or more synchronization primitives are also defined over the UDB to provide asynchronous notification of process boundaries.
  • the novelty for a UDB arises from the fact that any data and process logic, irrespective of their originating middleware abstraction, can be expressed uniquely using a single means of representation.
  • UDB differ from prior art in that a pair of source and destination transformations are necessary to bi-directionally convert data to and from existing middleware systems, to make the data available for processing within the UDB.
  • Fig. 43 diagrams the abstract block diagram for a UDB .
  • a UDB is composed of three components. First, one or more equivalent means of representing the data within the UDB, Second, a set of primitive operations which define the mechanisms for how transformations on the data within the UDB are specified by software logic. Third, a set of synchronization primitives which specify how to signal asynchronous and synchronous process events over the UDB. As such, all three components are inherent qualities of the present Unified Data Basis Transformations part of the invention, yet the specific characteristics of both are instantiations of a preferred embodiment.
  • One or more operational primitives are required to facilitate how data is read, written, and transformed while represented in the UDB.
  • the operational primitives define the techniques for such read/write operations which are compatible with the way data is represented in the UDB.
  • the precise semantics of the operation primitives are specific to an embodiment, as the present Unified Data Basis Transformations part of the invention does not define specific operations on the data represented in the UDB.
  • One or more synchronization primitives are required to facilitate signaling between the basis transformations. Depending upon the synchronization primitives, such synchronization could facilitate either a synchronous or asynchronous relationship between each of the transformations. Without loss of generality, using a block synchronization algorithm would facilitate a synchronous implementation of the UDB, while using a non-blocking synchronization algorithm would facilitate a asynchronous implementation of the UDB. Without loss of generality, Fig. 46 illustrates a synchronous implementation of a UDB, while Fig. 47 illustrates an asynchronous implementation of a UDB.
  • BT basis transformations
  • SBT source basis transformation
  • DBT destination basis transformation
  • basis transformations are the minimum required transformations for making data contained in alternative formats compatible with the UDB.
  • Both the source basis transformation and destination basis transformation consist of two discrete phases: format transformation and protocol transformation.
  • Format transformation is the phase which converts the data to or from the UBT to the logical data format of the data source or destination.
  • Protocol transformation is the phase which converts acquires or transmits the formatted data via the protocol appropriate for the middleware abstraction.
  • SBT perform protocol transformation then format transformation.
  • DBT perform format transformation then protocol transformation.
  • Fig. 45 defines a flow diagram for a sample instantiation of a unicast, unidirectional UDB process.
  • the source abstraction is XML data received via RMI.
  • XML is the data format and RMI is the protocol (with RPC being the middleware abstraction);
  • RMI defines an encoding, a character set interpretation, and a semantic interpretation (via an implicit or explicit schema);
  • RMI defines a wire-line protocol and RPC-equivalent conventions.
  • the SBT in this case would consist of the following two sequential phases. First, the XML data must be received and unwrapped from the RMI protocol-layer. Second, the XML data (which, in this case, would be represented by a stream of bytes in the RMI data payload) must be transformed into the format appropriate for the UDB.
  • the destination abstraction is XML data sent via RMI.
  • XML is the data format
  • RMI is the protocol (with object-oriented RPC being the middleware abstraction) .
  • the DBT in this case would consist of the following two sequential phases. First, data in the UDB format must be transformed into XML data. Second, the XML data must be wrapped into the RMI protocol-layer and sent to the destination.
  • a set of intermediate transformations can be defined.
  • Such intermediate transformations define a set of such ITs using the single set of common primitive operations defined over the UDB.
  • This ability to concisely and elegantly express transformational logic contrasts with traditional middleware, where oftentimes such transformations are difficult to codify today. The reasons for such complexity today could arise from incompatible abstractions, incompatible data formats, incompatible APIs, or requirement for complicated adapters/interfaces.
  • Fig. 48 provides a block diagram for an intermediate transformation.
  • the UDB provides a common representation along with a common set of operational and synchronization primitives, which facilitates data and process logic from a plurality of middleware systems to be represented and acted upon via intermediate transformation logic in a homogeneous manner.
  • a shared set of common operation primitives enable arbitrarily complex intermediate transformations to be specified once, irrespective of what type of middleware system the UDB is communicating with.
  • transformation logic can be written once and applied to a plurality of systems, instead of requiring a unique codification for each middleware abstraction.
  • the three common characteristics of the UDB enable greater expressiveness of intermediate transformation logic, as data from multiple abstractions can be acted upon by a single IT transparently.
  • a UDB provides the ability to mask partition boundaries between discrete middleware systems, providing the virtualization of a unified data representation with shared common primitives for operations and synchronization.
  • the UDB provides the ability to define intermediate transformation logic that spans what are today a plurality of incompatible middleware abstractions.
  • Such reuse is not possible with prior art, for two reasons: (1) no such capability exists to define IT across multiple incompatible middleware abstractions; and (2) the lack of such capability prevents IT defined once to be reused across other abstractions.
  • a defining operational attribute of a UDB is that the SBT and DBT are transparent with respect to the intermediate transformations.
  • transformational logic can be expressed using the common set of shared primitives, ignoring the semantics of how the data arrives and is transformed from the source and is send and transformed to the destination.
  • the transformation logic is written to assume that data exists in a single representation, that of the UDB, and transformations should be defined over precisely that representation.
  • transformations defined over a UDB can only access data, attributes, and process logic from the data source and destination as it is exposed by the SBT and DBT.
  • intermediate transformation logic can not access, or be dependent upon, characteristics of the source or destination data formats, representations, or middleware abstractions. Thus, there is no way to "cheat" and access the "raw" underlying source and destination data streams. This transparency contrasts markedly from prior art, where the semantics of source and destination transformation is precisely what the middleware is defining.
  • the source basis transformations and destination basis transformations may be composed of one or more independent steps which are composed together.
  • a DBT may transparently multiplex data contained in the UDB across multiple data destinations. Without loss of generality, a representative motivation for such multiplex semantics would be to distribute data which was represented contiguously in the UDB to multiple independent data destinations, which may utilize one or more heterogeneous middleware abstractions.
  • a SBT may transparently demultiplex data contained in multiple data sources into the UDB. A representative motivation for such demultiplex semantics would be aggregate data from multiple independent data sources, which may utilize one or more heterogeneous middleware abstractions, contiguously in the UDB.
  • contiguity is specific to the embodiment.
  • contiguity would be defined as a continuous set of bytes in a stream or a contiguous range of bytes in a ring buffer.
  • a universal data basis has several attributes which define it distinctly from alternative formulations in prior art.
  • UDB universal transformation compatibility: an embodiment of a UDB must possess the capacity to support SBT and DBT for all middleware abstractions. Specifically, the UDB embodiment must be sufficiently generalized to theoretically support transformations which are feasible and well-defined. A embodiment is not required to actually define all such transformations; rather, the UDB must be theoretically capable of having such transformations defined subsequently.
  • the operational definition of a UDB requires that an embodiment of a UDB not be the composition of two or more existing middleware abstractions. Specifically, the representation and transformation semantics of a UDB embodiment must transformation-compatible with other middleware abstractions but be defined using an alternative abstraction.
  • message map transformations are implemented by numerous types of middleware, with message brokers being a representative example of such. See Fig. 44 for a schematic flow representation.
  • MMT are instructions for converting data directly between a source data representation and one or more target data destinations.
  • Representative examples of such MMT are schema conversions, data conversion, and protocol conversion.
  • the advantage of such message map transformations is that they attempt to mask complexity by hiding the underlying data representation format (such as EDI or XML), while still being defined over a single middleware abstraction (message brokering, in this case).
  • MMT are one or more intermediate transformations which define how data coming from the source is transformed such that it is compatible with the destination.
  • the message transformation layer is the group of functionality which collects incoming data from the source, applies the MMT, and distributed the outdoing data to the destination.
  • a UDB defines a minimum of three distinct categories of transformations; of those three! at most one category of transformation can be an identity transformation set.
  • one or more source basis transformations define the rules for transforming data from the originating source format into the UDB.
  • one or more destination basis transformations define the rules for transforming data from the UDB into the outgoing destination format.
  • a set of intermediate transformations define the rules for how data in the UDB is manipulated to achieve the desired intermediation logic.
  • the first and second categories can not be identity transformations, by definition, as the source and destination formats are not trivially compatible with the UDB.
  • the third category can be an identity transformation, under the null case that data is being sent between source and destination without any transformation.
  • One embodiment of the present Unified Data Basis Transformations part of the invention implements a UDB by transforming heterogeneous data streams into the basis via an extensible, asynchronous event-driven model. Such embodiment exposes boundaries between the UDB and the individual heterogeneous streams via either, at the discretion of the user, an unbounded bytestream or a ring buffer.
  • discussion is limited to formulation of the present embodiment via a ring buffer.
  • a bytestream can be composed by maintaining a read and write pointer in the ring buffer, and reading from the ring buffer sequentially while respecting circularity between the read and write pointers.
  • This is a well-established and commonplace transformation.
  • a SBT and DBT is required for each specific middleware abstraction.
  • a SBT for this embodiment would accept data transmitted over a physical network interface, using the format and protocol appropriate for the middleware, and convert it into a ring buffer.
  • the data and process logic communicated by the middleware system is transformed into a contiguous array of bytes over a fixed-length ring buffer.
  • Fig. 9 diagrams the SBT transformation.
  • a DBT for this embodiment would accept data stored in a fixed-length ring buffer with contiguous array of bytes into the format and protocol appropriate for the destination middleware system.
  • Fig. 46 diagrams the DBT transformation.
  • the Unified Data Basis Transformations part of the invention defines two primitive operations, which when composed recursively, are sufficient for defining arbitrarily complex intermediate transformation logic. Specifically, this embodiment defines a read operation and write operation. These primitive read and write operations are equivalent to the standard LOAD and STORE operations on the random access memory of standard microprocessors. As detailed extensively in prior art, a LOAD operation accepts a memory address, commonly within the virtual memory space 'of the process which is running the UDB, and returns the value stored in the random access memory at that address. A STORE operation accepts a memory address, commonly within the virtual memory space of the process which is running the UDB, and a value, then writes the value into the memory address in the random access memory.
  • Both the LOAD and STORE operations commonly exchange data between random access memory, or some intermediate cache, and physical registers within the microprocessor.
  • the three categories of transformations signal transition boundaries via a conditional synchronization variable. Without loss of generality, such transition boundaries consist of completing a basis transformation: source, intermediate, and destination. Specifically, intermediate transformations wait for notification asynchronously from a SBT, indicating completion of the source transformation and requesting intermediate transformation; DBT wait for notification asynchronously from a IT, indicating completion of the intermediate transformation and requesting destination transformation.
  • a conditional variable as the synchronization primitive provides optimal performance in practical implementations, as conditional variables define a highly-efficient non-polling technique for asynchronous waiting.
  • conditional variables are generally considered by prior art to be the optimal mechanism for minimizing the consumption of computational processor capacity due to waiting.
  • Conditional variables eliminate what prior art commonly refers to as "busy waiting".
  • the Unified Data Basis Transformations part of the invention encapsulates the novelty and programmatic value of a UDB by providing a natural and intuitive means to specify intermediate transformation logic: using solely read and write operations on a contiguous range of bytes in memory.
  • the UDB uses the SBT and DBT to transform data from the source and destination middleware systems into a contiguous region of bytes.
  • Such a representation enables complex transformation logic, which previously had to be specified procedurally using traditional middleware programming techniques, to be specified as simplify reads and writes of memory.
  • Fig. 47 diagrams the flow process which intermediate transformations can define over this embodiment of the UDB. Not accidentally, this embodiment of the UDB provides a perspective on middleware data and process logic which is conceptually equivalent to that of a stand- alone computer.
  • the UDB eliminates the traditional complexity of middleware transformations by masking the physical and logical boundaries which currently partition discrete middleware systems. Moreover, this embodiment of the UDB provides a homogeneous and transparent instantiation of the present Unified Data Basis Transformations part of the invention, as a range of bytes h memory are transformed using the same techniques (read and writes) irrespective of where the data originates from or is being transmitted to.
  • the process of communicating byte streams of information between two or more independent computers is the basis for all computer system internetworking.
  • the functionality of all network and server-based software programs depend upon such an ability. Further, the performance and usability of such programs is generally considered better as the speed of such network communication increases.
  • critical goals of computer networking include: continually increase the throughput (commonly measured as bytes/second) and decrease latency (commonly measured in millisecond delay in transmission) of physical interconnection (e.g., the speed at which packets of information are distributed between physical network interface cards), continually decrease the latency time spent processing network communication in the application, and continually decrease the latency time spend processing the network communication in the operating system kernel/libraries.
  • Zero copy is simply a technique which copies bytes participating in a unidirectional network communication exactly once, commonly into a memory region which is shared between the user-level application and either the kernel or a memory-mapped buffer on the network interface card.
  • Zero copy is considered ideal, as it eliminates all excessive copying between disparate memory regions. Elimination of such excessive copying is critical, as such copying requires many computer processor and memory bus cycles.
  • the foregoing problems and shortcomings of the prior art are addressed by the present Zero-Copy Transparent Network Communication part of the invention, h which a method and system are provided for implementing zero-copy communication between independent computer systems while eliminating the need for explicit primitive network operations.
  • the Zero-Copy Transparent Network Communication part of the invention is particularly, though not exclusively, suited for use as the communication technique for exchanging data between multiple independent computers organized together via multi- computing or a loosely-coupled cluster.
  • This method assumes the existence of a system which physically implements reflective memory between all of the computer systems (defined as "nodes" herein) participating in the network communication. Any system providing such reflective memory is suitable for use in the present Zero-Copy Transparent Network Communication part of the invention. Examples of such systems from prior art include implementations for multiprocessors, multicomputers with a shared backplane, and loosely-coupled internetworked clusters of computers.
  • the present Zero-Copy Transparent Network Communication part of the invention is defined as the composition of two algorithms along with ⁇ novel method for their interdependency: a "Zero-Copy Transparent Java Network Delivery” algorithm, for the source machine participating the network interconnectivity, and a "Zero-Copy Transparent Java Network Receipt” algorithm, for the one or more destination machines participating in the network interconnectivity.
  • the present Zero-Copy Transparent Network Communication part of the invention do not differentiate, intentionally, between the two cases - as there is no difference in their implementation (as guaranteed by the defining characteristic of the underlying reflective memory), beyond the potential for reflective memory-specific configuration details.
  • the performance difference between unicast and multicast in many embodiments will be negligibly small, due to performance characteristics of many practice reflective memory implementations.
  • Each algorithm includes components whose embodiment implementation must be partitioned into two programming languages: (1) Java code which defines the class, interfaces, and implementation for the zero-copy transparent network interconnect; and (2) operating system-specific code, commonly referred to as "native code" in the prior art (when used in conjunction with Java code), providing a runtime interface between the reflective memory system and the Java code (1).
  • Java code which defines the class, interfaces, and implementation for the zero-copy transparent network interconnect
  • operating system-specific code commonly referred to as "native code” in the prior art (when used in conjunction with Java code)
  • embodiments may choose a variety of implementation techniques (such as implementation via numerous discrete submethod calls, using dynamic type reflection, using delegation, or any other semantically- identical method) which anyone experienced in the prior art would consider equivalent as implementing the characteristics of such algorithms. Equivalently, numerous steps in the following algorithms can have their order permuted, while still retaining the same semantic interpretation; anyone experienced in the prior art would also consider such reordering equivalent as implementing the characteristics of such algorithms.
  • the Zero-Copy Transparent Java Network Delivery algorithm is defined by the following steps:
  • step (1) assign the value of jBuf to be equal to the returned Java memory array from Salloc(), as executed in steps (2)-(3);
  • Sfree() requests that Buf be demapped from shared memory and deallocated; for reflective memory systems, this step implicitly causes any subsequent reflection between computer systems participating in the network interconnect to cease.
  • Sfree() returns boolean value indicating success of the operation defined in (8), back to the software caller who invoked Sfree() in (7); the value of this boolean retum value is defined to be equal to the success or failure of the reflective memory system to cease subsequent implicit reflection; if no such boolean value is provided by the reflective memory system, then a true retum value is assumed; as one skilled in the art will readily appreciate, this step could also be implemented without a retum value (a "null" return value in prior art) with equivalent intent
  • step (5) using Java are implicitly changing the shared reflective memory underlying the Java byte array jBuf, as defined by the pairwise mapping in (3) .By the definition of reflective memory, such changes are automatically propagating to a corresponding shared reflective memory buffer on each of the computer systems implementing the Zero-Copy Transparent Java
  • Network Receipt algorithm without loss of generality, such propagation will require coordination with kernel shared memory and virtual memory mechanisms along with traffic over the shared medium connecting each of the computers participating in the interconnectivity (e.g., a shared backplane, a common bus, or a loosely-coupled cluster of computer systems internetworked by traditional wire networks such as Ethernet).
  • kernel shared memory and virtual memory mechanisms along with traffic over the shared medium connecting each of the computers participating in the interconnectivity (e.g., a shared backplane, a common bus, or a loosely-coupled cluster of computer systems internetworked by traditional wire networks such as Ethernet).
  • the Zero-Copy Transparent Java Network Receipt algorithm is defined by the following steps:
  • Step (2) allocate a memory buffer, termed "Buf” herein, using operation system- specific code, compatible with the reflexive memory system in use, which is shared (reflected) and made accessible in the virtual or physical memory space among all the nodes implementing Receipt algorithms as defined by the present Zero-Copy Transparent Network Communication part of the invention; this step is defined as stage one of a function, termed "Salloc()", which is implemented using native code and is invoked from Java via a "native method call" (as termed in the prior art), which is a method in a Java interface or class which is defined with a native method int-rface (e.g., Java method with a "native" method access qualifier)
  • step (1) assign the value of jBuf to be equal to the returned Java memory array from Salloc(), as executed in steps (2)-(3); one skilled in the art will readily recognize that this step and step (1) can be, for convenience, combined in a single definition and assignment statement in Java while retaining the same intent
  • Sfree() Java native method termed "Sfree()" (using the same definition of "native method” as defined above) is invoked to request that jBuf be deallocated and its reflective memory mapping be eliminated.
  • Sfree() requests that Buf be demapped from shared memory and deallocated; for reflective memory systems, this step implicitly causes any subsequent reflection between computer systems participating in the network interconnect to cease.
  • Sfree() returns boolean value indicating success of the operation defined (8), back to the software caller who invoked Sfree() in (7); the value of this boolean return value is defined to be equal to the success or failure of the reflective memory system to cease subsequent implicit reflection; if no such boolean value is provided by the reflective memory system, then a true return value is assumed; as one skilled in the art will readily appreciate, this step could also be implemented without a retum value (a "null" retum value in prior art) with equivalent intent.
  • the present Zero-Copy Transparent Network Communication part of the invention is defined as reflective memory (as opposed to shared memory): bytes written to the shared reflective buffer are automatically propagated to all computer systems participating in the network interconnectivity, without any required intrinsic synchronization support (although using such a network communication technique requires such to provide completion signaling).
  • reflective memory as opposed to shared memory
  • intrinsic synchronization support although using such a network communication technique requires such to provide completion signaling.
  • Communication part of the invention as desired by the user is to define fully reflective memory between each of the participating systems and use such as a network communication abstraction.
  • the present Zero-Copy Transparent Network Communication part of the invention uses a "zero-copy" communication technique: the bytes of the byte array jBuf are not transferred to .a secondary buffer before or-during network communication. This differs from network communication methods from prior art, such as sockets or streams, which require that jBuf be transferred to such an intermediate buffer (usually to a kernel communication buffer or a network buffer interface card) to implement the logical and/or physical transmission.
  • the present Zero-Copy Transparent Network Communication part of the invention relies upon a "transparent" network communication technique. No input/output or socket methods are invoked to signal or implement data transmission between computers participating in the network interconnectivity. Instead, data transmission is implicitly signaled and occurs upon writing values into the byte array jBuf.
  • This transparency attribute is critical, as it defines the means to achieve the remarkably low-latency and high-performance characteristics of the present Zero-Copy Transparent Network Communication part of the invention. In terminology defined in prior art, this attribute of the present Zero-Copy Transparent Network Communication part of the invention is commonly termed "transparent".
  • reflective memory used in this manner provides a flexible programming model which can implement techniques pioneered in symmetric multiprocessing (SMP) computer systems: message passing and shared memory.
  • SMP symmetric multiprocessing
  • Reflective memory in Java provides these benefits specially for computers that are organized using multi-computing and loosely-coupled clustering.
  • transparent network communication is also superior than existing network as it eliminates the traditional latency and computational performance cost associated with network protocol stacks, such as TCP/IP.
  • reflective memory using a transparent zero-copy mechanism is not processed by the operating system networking infrastructure; instead, it is mapped directly into memory, without loss of generality, through direct memory access (DMA) and user-kernel memory mapping.
  • DMA direct memory access
  • SI Systems integration
  • Fig. 54a, 54b, and 55 - 60 correspond to the following description of the Automated Systems Integration pair of the invention.
  • Data exchange is the general practice of moving bytes of information between independent computers via communication networks. Such exchange can occur between computers that are owned by a single entity, or between multiple entities.
  • the bytes of data in any such exchange are often formatted ii heterogeneous types; this lack of common format arises because the data being exchanged originates from the plurality of different computer programs using a plurality of different data format standards (e.g., ASCII text files, structured query language (SQL), or extensible markup language (XML) ).
  • ASCII text files e.g., ASCII text files, structured query language (SQL), or extensible markup language (XML)
  • SQL structured query language
  • XML extensible markup language
  • Process state is the computer representation of the "roadmakers” for the logical process flow which the data exchange is implementing. Specifically, all computer programs have a defined process flow which the instructions of the software and hardware program execute for such exchange. For programs which move data between multiple computers, the logical "roadmarkers” for this process are distributed across each of the computer participating in the process. Process state manifests as bytes stored in random access memory (RAM) and persistent storage (such as a hard drive) of each of the computers participating h the process; the software programs controlling the data exchange define the "rules" (or set of logical conditions and constraints) for how and when such process state is defined and saved into RAM or persistent storage. Thus, maintaining process state is a cooperative activity between the software, providing the algorithms and software logic for the process, and the hardware, storing the state data arising from execution of the process.
  • RAM random access memory
  • persistent storage such as a hard drive
  • an "integration solution” is defined as implementation of a group of interdependent hardware and software to solve the requirements for a particular integration process requiring data exchange and process state maintenance.
  • customer 1 is defined as the one or more entities seeking such integration solutions.
  • Service-driven systems integration is a human-intensive process driven by a group of interdisciplinary individuals, each with complementary domain- specific areas of expertise, coordinating to implement an integration solution.
  • a solution delivered to the customer is composed of a set of technology components, such as computer servers and software, which have been combined together intelligently to meet the specific integration problem.
  • the real value provided b y service-driven SI is the expertise and knowledge contributed by the individual human members of the SI group - not the individual technology components.
  • B y definition, service-driven systems integration assumes the existence of an interdisciplinary group of domain experts, along with a group of enabling technology which they customize to develop customer solutions.
  • other services may be provided by the SI group, such as user training, such non- technology-driven services are considered outside the scope of the systems integration practice.
  • service-driven systems integration is, with few exceptions, structured around performing discrete projects for specifically identified customers; the scope of work of a particular "project” is defined as the process of solving that single customer's problem.
  • the economic justification for service-driven systems integration lies in charging higher rates per project than the cost of implementing the project in terms of human labor and physical technology.
  • IP tangible intellectual property
  • SI groups rely upon a trusted group of independent technology firms who provide computer hardware and/or software, upon which the systems integration solutions are built by the SI group. Oftentimes, a significant fraction of the value provided by SI group to customers is encapsulated in the training and technical expertise which the group possesses in using their selected set of technology components to solve a specific business problem.
  • the key characteristic about this attribute is that the service-driven SI group is independent from the technology partners firms providing hardware and . software.
  • service-driven SI groups use whatever set of technology tools are necessary to solve the problem defined by the customer; specifically, the SI group rarely maintains specific allegiance to a particular piece of hardware or software from project-to-project. Equivalently, the service-driven SI is customer- and solution-oriented, rather than product-oriented.
  • Service-driven systems integration begins with problem identification, which is the communication-, time-, and human-intensive process of working to carefully identify the problem being proposed by the customer; this phase is termed the "exploratory phase” herein.
  • the process continues by the SI group analyzing the type of technology products installed in the customer's facilities and the specifics of how the customer uses such technology in the business processes.
  • a critical component of these first two steps is in-depth communication between the SI group and employees, of various skills and positions.
  • the output of this phase is usually some form of tangible documentation which defines, quantifies, and qualifies the problem being considered for resolution via an SI project.
  • the installation phase includes multiple steps: physical installation is required to make the hardware or software available the customer facilities; validation is required to verify the solution meets the customer requirements which were identified during exploratory phase; and testing is required to verify the solution is technically compatible with the other hardware and software used by the customer.
  • the installation phase there usually is some fixed duration of time during which the customer remains in communication with the service-driven SI group, to note any anomalies or deviations from the specified requirements with the installed solution.
  • Product-driven systems integration is the codification into software of solutions to specific problems pertaining to the integration of data or program state within computer systems.
  • the essence of product- driven SI is identifying integration problems faced by a group of customers, then developing and commercializing software which solves such problems.
  • the limiting factor of product-driven systems integration is how quickly integration problems can be identified and solutions for them codified into software. While such integration problems are often identified in conjunction with customers, the goal of product- driven systems integration is to solve customer integration challenges for many through use of a single, standardized, fixed, well-defined set of features.
  • Product- driven systems integration assumes the existence of group of experts with expertise in their appropriate domain and software development.
  • product-driven systems integration is iterative: the features of the software are fixed at non-arbitrary intervals in time and a distinct product with such features is given, an identifying mark (such as a version or year) and commercialized as a discrete entity.
  • product-driven integration contrasts markedly with service- driven integration, as product-driven integration is based upon fixed release dates with defined feature sets, rather than being project-driven.
  • service-driven SI product-driven SI develops their products outside the scope of a particular customer during the development phase.
  • product-driven SI is not concerned necessarily with meeting every conceivable requirement of a particular customer, but rather defining a generalized piece of software which can conceivably meet most requirements of a group of customers.
  • the economic justification for product-driven integration follows from the belief that the integration product should cost a fraction of the total cost of development, while revenue is instead generated by selling the product to the broadest group of customers.
  • products derived from product-driven SI may be customizable to a limited degree, through only within a narrowly-defined parameter space through such techniques as macro languages, graphical configuration, or other product-specific features. Although this constitutes a degree of customization, each software package is constrained within the design, architecture, and integration perspective which the software embodies. Specifically, the type of customization is fixed at the time of feature stabilization and commercialization.
  • product-driven SI does not produce a complete solution; rather, product- driven SI provides the software which some trained domain-expert must purchase, install, configure, deploy, and manage. Specifically, product-driven SI predominantly lacks any people-driven processes. This contrasts with service- driven SI which delivers highly-specialized solutions to specific customers.
  • product-driven SI is predominantly subject to the well-documented economic effects of software: relentless addition of new features until few competitors remain or the market demand disappears.
  • product-driven SI develops monolithic software which gradually adds new features over time.
  • the features of such products can rarely be segmented or subsetted intelligently, preventing individual customers from choosing exclusively those features which are needed. Instead, in the name of maximizing the potential base of customers, such products often assimilate nearly every conceivable feature which could possibly be required by a customer.
  • customers bias towards buying more features than are immediately needed with the belief that at some future time the features unused today will be needed.
  • product development cycle within the industry; this process consists of the following steps: domain selection, problem definition, paradigm selection, requirements specification, trade-off analysis, feature selection, technical specification, architectural design, implementation, validation, intemal testing, and external customer testing.
  • product development cycle consists of the following steps: domain selection, problem definition, paradigm selection, requirements specification, trade-off analysis, feature selection, technical specification, architectural design, implementation, validation, intemal testing, and external customer testing.
  • the duration of this iterative cycle commonly extends a year or more.
  • product development cycles require extensive time commitments from an interdisciplinary team of domain exports; certainly such products are not developed hastily or without extensive planning and documentation.
  • Product-driven systems integration can be considered as a specific instance of software development, as implied by the preceding discussion.
  • Product-driven systems integration is concerned with designing a piece of software which solves a specific problem requiring data exchange or maintenance of process state.
  • One skilled in the art will readily appreciate that a broad group of published literature exists on software development models, as elaborated in the references, and as such a discussion on such is abbreviated to include what is defined above.
  • anyone familiar with the art will recognize that specific firms usually vary these procedural steps modestly, to accentuate their particular mix of knowledge, expertise, and financial resources.
  • product-driven and service-driven systems integration represent two extremes in their prototypical and practical forms.
  • SDSI represents absolute individual customization while PDSI represents mass production.
  • cost SDSI depends upon charging customers above the production cost, while PDSI amortizes development cost over the broadest group of customers possible.
  • features SDSI seeks to precisely meet the customer needs, while FDSI seeks to maximize relevant features.
  • structure SDSI is "one-off" project- oriented while, FDSI is product-oriented and iterative.
  • SDSI develops little reusable IP, while PDSI is built around the sale of software which is legally protected against unauthorized redistribution via copyright law.
  • SDSI and FDSI share three common aspects: complexity, time requirements, and supply cost.
  • SDSI and PDSI are human-centric processes which are not amendable to optimization or automation via computers.
  • the result of this complexity is that systems integration require extensive time and cost to implement effectively.
  • the cost of both is driven by the high salary costs of domain experts, working either for a single customer (SDSI) or towards a common group of customers (PDSI) ; the time requirement for both arises from the inherent complexity of the problem and the relatively small set of technology tools used by either technique to increase the productivity of individual group members.
  • the invention pertains to a method and system for automating the identification, design, and implementation of systems integration solution for delivery to customers as implemented by a SI group using a novel business process which relies upon five technology components designed for this purpose; the method and technique defined by the present invention is termed "automated systems integration", as it defines a process which is highly- automated by use of such technology components.
  • configurable hardware specialized type of computer hardware which is suitable for rapid, flexible customization while explicitly compatible with the other components.
  • GUI graphical user interfaces
  • common technical standards a set of common technical standards which describe the characteristics of data, software program structure, hardware interfaces, data boundaries, security mechanisms, error handling, and other semantic attributes of the data exchange and process state.
  • integration coupling a set of highly specialized computer compilers, runtime environments, application servers, transformation languages, data interfaces, and asynchronous process state maintenance mechanisms which interpret and implement the systems integration using the automation common standards, reusable systems logic, and reusable graphical interface definitions.
  • ASI automation components can conceptually be thought of as a highly-specialized and novel type of "integration toolbox", or set of interdependent technical tools which collectively facilitate automated systems integration.
  • the present invention defines a method and system for automating system integration via such components (provided they meet the defining attributes enumerated herein).
  • Automated systems integration is a cyclic and iterative set of well-defined procedural steps, defined below, implemented by an automated SI group.
  • ASI is cyclic as the process is performed on an on-going basis, and multiple such instantiations of this process may be optionally performed concurrently. Further, the ASI group executes such procedural steps iteratively in the order which they are presented below.
  • ASI depends intimately upon the existence of the preceding technology components and strict adherence to the following process. Specifically, a systems integration practice would not be in the spirit of the method and system defined by the present invention if either of these conditions is not meet. This contrasts with PDSI and SDSI which, by their definition, rely exclusively upon the SI group and not any specific structured set of technology. Second, ASI explicitly supports performing the following process concurrently, while PDSI and SDSI are sequential processes.
  • the PDSI group may develop multiple products independent, but each individual product is only capable of defining a fixed set of features; thus, product development by the PDSI group on each single product can only, by definition, proceed along one path.
  • each individual SI group member only has a fixed amount of hourly time available to contribute to systems integration projects; once such time is fully allocated to active projects, there is, by definition, no capacity for that individual to contribute to additional projects.
  • the primarily resources for both SDSI and PDSI are inherently allocable in non-concurrent practice.
  • Automated systems integration consists of seven phases, summarized for convenience (but not a strict definition) : (1) problem definition; (2) translation of problem definition into set of requirements; (3) distillation of technical implementation specification from requirements; (4) identification of set of technical features not presently available from standardized automation components; (5) implementation of the presently unavailable features identified previously; (6) merging of newly developed capabilities into standardized automation component's; (7) offering of solution to customers based upon aggregation of features from automation components.
  • phases are defined in detail below.
  • the ASI group identifies and defines a specific systems integration problem, with well-defined attributes, based upon professional experience or communication with one or more potential customers.
  • An essential attribute of such a problem is that the ASI group believes that the problem affects more than a single potential customer.
  • the definition of an ASI problem differs from SDSI in that problem identification and definition exists outside the scope of a specific systems integration project for a individual customer.
  • the ASI group takes the problem definition and translates it into a set of specific requirements which fall into the following well-defined set of "requirement domains"; anyone familiar in the prior art would recognize this step as a highly- specialized type of formal requirements analysis:
  • GUI graphical user interface
  • event handling the synchronous and asynchronous software algorithms and program logic appropriate to handle event-driven procedures, such as triggers, time-based timers, and automated polling.
  • transaction boundaries use of atomic/consistent isolated/durable (ACID) properties to define divisible boundaries between discrete computations (commonly referred to as transactions, in the prior art) in the data exchange and state maintenance processes to provide appropriate fault-tolerance, exception recovery, rollback, and retry semantics and via software algorithms.
  • privilege enforcement set of security conditions, event auditing, privilege states, secure-insecure transition boundaries, and logical roles which must be adhered to by the solution to meet customer requirements for security and privacy.
  • error handling procedures detection, handling, human notification, automated escalation, persistent record, graphical display, and reporting policies for how deviations occurring at runtime are handled by the solution via software algorithms and program logic.
  • business rules set of overarching technically.-definable conditions (commonly known as "meta-rules" in prior art) which govern the implementation and semantics of the solution processing of each component via software algorithms and program logic.
  • the ASI group transforms these requirements onto the technical specifications which the AST is standardized upon.
  • This step results in the development of technical implementation guidelines for how to construct a solution, using the ASI automation components, which meets the functional requirements previously identified. While this present invention defines the general mechanism for such, anyone familiar in the prior art appreciates that the specific practice of this transformation depends upon each standardized automation component; specifically, each preferred embodiment of the present invention may define a particular means for performing such transformation for each standardized ASI automation component.
  • this step is composed of the logical composition of each of the transformations into technical automation components from functional requirements.
  • each functional requirement may result implementation requirements in one or more standardized ASI automation component.
  • the key novel characteristic of this relationship is that it remains consistent during each iteration of the cyclic process (as opposed to varying based upon the semantics of the specific project as in SDSI, or varying based upon the formulation of the discrete product as in PDSI). As such, this relationship and the transformation process joining the two is considered to be a static attribute of ASI.
  • the ASI group proceeds to identify which technical specifications cannot be implemented with the existing functionality provided by the ASI automation components.
  • the set of new functionality, defined in the requirement domains for the present iteration yet not satisfied with existing automation components, is termed the "delta set".
  • the delta set is the composition of all of the individual differential set of features required in each standardized automation component.
  • GUI graphical user interface
  • event handling algorithms and program logic necessary to support specialized types of asynchronous or synchronous event handling which have not been previously defined by ASI iterations.
  • transaction boundaries define the boundaries of data exchange and program state which require use of ACID properties to ensure proper fault-tolerance, exception recovery, rollback, and retry semantics for the data and process state involved in the specific integration solution.
  • privilege enforcement definition of the security states, transition boundaries, privilege states, and logical roles which are unique to specific integration solution and have not been defined by previous ASI iterations; and the appropriate software algorithms and program logic necessary therein.
  • error handling procedures definition of the error detection, escalation patterns, persistent record keeping, graphical display, and reporting necessary for the specific integration solution; and the appropriate software algorithms and program logic necessary therein.
  • the ASI group proceeds to implement the functionality required in the five automation components necessary as identified in the delta set. This implementation occurs in a well-defined and methodical manner, with the precise semantics depending upon the automation component defined by preferred embodiments.
  • This development phase has two explicit intents, one independent and one dependent.
  • the independent intent is to implement and standardize the technical functionality which does not yet exist in the automation components, from the delta set.
  • This primary independent intent is critical to understanding the objective of ASI integration: although the delta set arises from the ASI iteration for a specific integration problem, the first and foremost intent of this development phase is to facilitate augmentation and standardization of the new functionality provided in the automation components. Equivalently, the real goal of the cyclic ASI iterations is to rapidly implement and standardize systems integration functionality.
  • the secondary, and dependent, intent of this phase is to then utilize the standardized automation components to solve the specific integration problem considered b y the ASI iteration, after the delta set has been implemented and standardized.
  • ASI is a key characteristic of ASI which differentiates it from SDSI and PDSI: multiple instances of this process can be performed at the same time, using the same set of ASI automation components.
  • ASI is a cyclic process which is repeated as necessary to meet disparate customer requirements.
  • ASI implementations can have durations lasting from weeks to months.
  • each iteration of ASI may not necessarily meet all the known requirements of any single customer. Thus, multiple iterations may be necessarily to develop independent ASI solutions which can be subsequently joined to provide comprehensive solutions to the defined problems of a given customer.
  • ASI differs non-trivially from SDSI, as the explicit intent of SDSI is to implement a solution which satisfies the perceived requirements of the customer.
  • the ASI group may decide to implement systems integration using the ASI technique, but do so poorly based upon a set of systemic or idiosyncratic characteristics about their individual members, customers, or other influences.
  • a poor implementation defined as having the intention to adhere to each phase but not being able to effectively operationalize such adherence, would be considered an instance of the method and system defined by the present invention.
  • Automated systems integration is a technology-centric process, which relies upon a set of highly-customizable and standardized automation components.
  • the automation in this method and system arises from leveraging highly-customizable hardware, firmware, software, and graphical layout components combined with a well-defined process for iteratively identifying systems integration problems, implementing their solutions, and delivering the resulting integration systems to a plurality of customers.
  • This entire process revolves around specially-designed systems integration customization tools, which automate and standardize the majority of this process.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Abstract

La présente invention concerne un système de communication multiprotocole adaptatif. Ledit système comprend une pluralité de cartes réseau uniques connectées à un fond de panier ou une interconnexion communs. Chaque carte réseau envoie et reçoit des trains de bits d'un protocole d'application spécifique, échangeant des données entre des protocoles d'application qui peuvent être différents. La carte réseau fournit le train binaire entrant dans une machine à états finis spécialisée dans la conversion d'un train de bits de protocole d'application spécifique en une représentation matricielle multidimensionnelle pour un protocole de communications particulier, par exemple, EDI, XML, ou pour la représentation de translation intermédiaire selon l'invention. L'invention fait appel à des machines à états finis pour convertir le train de bits de protocole de communication initial en représentation intermédiaire selon l'invention. Une machine à états finis située sur une carte réseau réceptrice est utilisée pour convertir le train de bits entrant en une matrice multidimensionnelle de langage intermédiaire et fait passer la matrice vers une carte réseau destinataire qui possède une machine à états finis utilisée pour convertir la matrice multidimensionnelle de langage intermédiaire en un train de bits de protocole d'application. Le train de bits de protocole d'application est ensuite envoyé à un système informatique récepteur.
PCT/US2002/013182 2001-04-25 2002-04-25 Systeme de communication multiprotocole adaptatif WO2002087136A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2002309605A AU2002309605A1 (en) 2001-04-25 2002-04-25 Adaptive multi-protocol communications system
EP02736613A EP1381962A2 (fr) 2001-04-25 2002-04-25 Systeme de communication multiprotocole adaptatif
JP2002584522A JP2005504455A (ja) 2001-04-25 2002-04-25 適応マルチプロトコル通信システム

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US28659501P 2001-04-25 2001-04-25
US60/286,595 2001-04-25
US29835501P 2001-06-14 2001-06-14
US60/298,355 2001-06-14
US30828001P 2001-07-26 2001-07-26
US30827501P 2001-07-26 2001-07-26
US60/308,280 2001-07-26
US60/308,275 2001-07-26
US10/128,941 2002-04-24
US10/128,941 US20020161907A1 (en) 2001-04-25 2002-04-24 Adaptive multi-protocol communications system

Publications (4)

Publication Number Publication Date
WO2002087136A2 true WO2002087136A2 (fr) 2002-10-31
WO2002087136A3 WO2002087136A3 (fr) 2003-02-13
WO2002087136A9 WO2002087136A9 (fr) 2003-04-10
WO2002087136B1 WO2002087136B1 (fr) 2003-11-13

Family

ID=27537817

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/013182 WO2002087136A2 (fr) 2001-04-25 2002-04-25 Systeme de communication multiprotocole adaptatif

Country Status (6)

Country Link
US (1) US20020161907A1 (fr)
EP (1) EP1381962A2 (fr)
JP (1) JP2005504455A (fr)
CN (1) CN1516840A (fr)
AU (1) AU2002309605A1 (fr)
WO (1) WO2002087136A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100334821C (zh) * 2004-04-19 2007-08-29 中兴通讯股份有限公司 一种通信系统有限状态机的测试方法
CN1764213B (zh) * 2004-10-21 2011-05-25 株式会社电装 蓝牙通信装置和方法以及短程无线通信装置和方法
US8712974B2 (en) 2008-12-22 2014-04-29 Google Inc. Asynchronous distributed de-duplication for replicated content addressable storage clusters
US9081841B2 (en) 2008-12-22 2015-07-14 Google Inc. Asynchronous distributed garbage collection for replicated storage clusters

Families Citing this family (187)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10137574B4 (de) * 2001-07-31 2006-01-19 Infineon Technologies Ag Verfahren, Computerprogramm und Datenverarbeitungsanlage zur Verarbeitung von Netzwerktopologien
US20030055644A1 (en) * 2001-08-17 2003-03-20 At&T Corp. Systems and methods for aggregating related inputs using finite-state devices and extracting meaning from multimodal inputs using aggregation
JP2003076620A (ja) * 2001-09-04 2003-03-14 Fujitsu Ltd 動的プロトコル交換システムおよび方法
US7437731B2 (en) * 2002-05-30 2008-10-14 Oracle International Corporation Coordinated collaboration system in an integration platform
US7277963B2 (en) * 2002-06-26 2007-10-02 Sandvine Incorporated TCP proxy providing application layer modifications
WO2004014065A2 (fr) * 2002-08-05 2004-02-12 John Campbell Systeme de machines etat fini
AU2002335729A1 (en) * 2002-09-09 2004-03-29 Atitania Ltd. Method and apparatus for converting data between two dissimilar systems
US7257575B1 (en) 2002-10-24 2007-08-14 At&T Corp. Systems and methods for generating markup-language based expressions from multi-modal and unimodal inputs
US7512531B1 (en) * 2002-12-30 2009-03-31 Daniel Shia Method and apparatus for specifying reactive systems
US6985910B2 (en) * 2003-02-06 2006-01-10 International Business Machines Corporation Tilting tree spinning cones method and system for mapping XML to n-dimensional data structure using a single dimensional mapping array
US7860916B2 (en) * 2003-03-18 2010-12-28 Microsoft Corporation Systems and methods for transforming data in buffer memory without unnecessarily copying data to additional memory locations
US7953891B2 (en) 2003-03-18 2011-05-31 Microsoft Corporation Systems and methods for scheduling data flow execution based on an arbitrary graph describing the desired data flow
US7131077B1 (en) * 2003-03-28 2006-10-31 Xilinx, Inc Using an embedded processor to implement a finite state machine
US20040199622A1 (en) * 2003-04-07 2004-10-07 Huscher Anthony Alan eRoom operations console
US7702729B2 (en) * 2003-04-08 2010-04-20 Johanson Bradley E Event heap: a coordination infrastructure for dynamic heterogeneous application interactions in ubiquitous computing environments
JP4136857B2 (ja) * 2003-09-11 2008-08-20 キヤノン株式会社 機器検索方法およびプログラム
WO2005052703A1 (fr) * 2003-11-17 2005-06-09 Siemens Aktiengesellschaft Systeme d'automatisation redondant destine a la commande d'une installation technique et procede d'utilisation d'un tel systeme d'automatisation
US7372946B2 (en) * 2003-12-11 2008-05-13 Agilent Technologies, Inc. Measurement deferral and aggregation for extensible test configuration
US7519719B2 (en) * 2004-04-15 2009-04-14 Agilent Technologies, Inc. Automatic creation of protocol dependent control path for instrument application
US7810103B2 (en) * 2004-04-30 2010-10-05 Microsoft Corporation System and method for validating communication specification conformance between a device driver and a hardware device
US8249953B2 (en) * 2004-05-13 2012-08-21 Cisco Technology, Inc. Methods and apparatus for determining the status of a device
US7789308B2 (en) * 2004-05-13 2010-09-07 Cisco Technology, Inc. Locating and provisioning devices in a network
US8113418B2 (en) * 2004-05-13 2012-02-14 Cisco Technology, Inc. Virtual readers for scalable RFID infrastructures
US7325734B2 (en) * 2004-05-13 2008-02-05 Cisco Technology, Inc. Methods and devices for assigning RFID device personality
US7336175B2 (en) * 2004-05-13 2008-02-26 Cisco Technology, Inc. Methods and devices for locating and uniquely provisioning RFID devices
US7322523B2 (en) * 2004-05-13 2008-01-29 Cisco Technology, Inc. Methods and devices for uniquely provisioning RFID devices
US7422152B2 (en) * 2004-05-13 2008-09-09 Cisco Technology, Inc. Methods and devices for providing scalable RFID networks
US7930432B2 (en) * 2004-05-24 2011-04-19 Microsoft Corporation Systems and methods for distributing a workplan for data flow execution based on an arbitrary graph describing the desired data flow
US8655756B2 (en) 2004-06-04 2014-02-18 Sap Ag Consistent set of interfaces derived from a business object model
US8604910B2 (en) * 2004-07-13 2013-12-10 Cisco Technology, Inc. Using syslog and SNMP for scalable monitoring of networked devices
US7509431B2 (en) * 2004-11-17 2009-03-24 Cisco Technology, Inc. Performing message and transformation adapter functions in a network element on behalf of an application
US7664879B2 (en) 2004-11-23 2010-02-16 Cisco Technology, Inc. Caching content and state data at a network element
US7987272B2 (en) 2004-12-06 2011-07-26 Cisco Technology, Inc. Performing message payload processing functions in a network element on behalf of an application
CN100358302C (zh) * 2004-12-06 2007-12-26 华为技术有限公司 一种使用状态机测试网元接口的方法
US7496750B2 (en) * 2004-12-07 2009-02-24 Cisco Technology, Inc. Performing security functions on a message payload in a network element
US7725934B2 (en) 2004-12-07 2010-05-25 Cisco Technology, Inc. Network and application attack protection based on application layer message inspection
US8082304B2 (en) 2004-12-10 2011-12-20 Cisco Technology, Inc. Guaranteed delivery of application layer messages by a network element
US7606267B2 (en) 2004-12-10 2009-10-20 Cisco Technology, Inc. Reducing the sizes of application layer messages in a network element
US8059539B2 (en) * 2004-12-29 2011-11-15 Hewlett-Packard Development Company, L.P. Link throughput enhancer
US7551567B2 (en) * 2005-01-05 2009-06-23 Cisco Technology, Inc. Interpreting an application message at a network element using sampling and heuristics
US7721005B2 (en) * 2005-01-19 2010-05-18 Iona Technologies Limited Data bus between middleware layers
US7904587B2 (en) * 2005-01-19 2011-03-08 Iona Technologies Limited Flexibly deployable communication device facilitating interoperation between middleware
US7836202B2 (en) * 2005-01-19 2010-11-16 Iona Technologies Limited Communication system integrating a plurality of middleware and implementing sophisticated paths for data flow
US20060161718A1 (en) * 2005-01-20 2006-07-20 Berke Stuart A System and method for a non-uniform crossbar switch plane topology
US7698416B2 (en) * 2005-01-25 2010-04-13 Cisco Technology, Inc. Application layer message-based server failover management by a network element
US8205046B2 (en) 2005-01-31 2012-06-19 Hewlett-Packard Development Company, L.P. System and method for snooping cache information using a directory crossbar
US7584296B2 (en) * 2005-03-05 2009-09-01 Intel Corporation Asynchronous network stack operation in an operating system independent environment
US7414975B2 (en) * 2005-03-24 2008-08-19 Ixia Protocol stack
US8121148B2 (en) * 2005-03-24 2012-02-21 Ixia Protocol stack using shared memory
US9363481B2 (en) * 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US20060271698A1 (en) * 2005-05-16 2006-11-30 Shrader Anthony G Boa back office integration protocol
US7953826B2 (en) 2005-07-14 2011-05-31 Cisco Technology, Inc. Provisioning and redundancy for RFID middleware servers
US7345585B2 (en) 2005-08-01 2008-03-18 Cisco Technology, Inc. Network based device for providing RFID middleware functionality
US20070030816A1 (en) * 2005-08-08 2007-02-08 Honeywell International Inc. Data compression and abnormal situation detection in a wireless sensor network
CA2556143A1 (fr) * 2005-08-15 2007-02-15 Thales Canada Inc. Architecture d'acquisition et de simulation de donnees
US8189599B2 (en) * 2005-08-23 2012-05-29 Rpx Corporation Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks
US7782873B2 (en) * 2005-08-23 2010-08-24 Slt Logic, Llc Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks
US8698603B2 (en) 2005-11-15 2014-04-15 Cisco Technology, Inc. Methods and systems for automatic device provisioning in an RFID network using IP multicast
US7447707B2 (en) * 2005-12-16 2008-11-04 Microsoft Corporation Automatic schema discovery for electronic data interchange (EDI) at runtime
US8316344B2 (en) 2005-12-30 2012-11-20 Sap Ag Software model deployment units
US8370794B2 (en) 2005-12-30 2013-02-05 Sap Ag Software model process component
US8321831B2 (en) 2005-12-30 2012-11-27 Sap Ag Architectural design for internal projects application software
US8326703B2 (en) 2005-12-30 2012-12-04 Sap Ag Architectural design for product catalog management application software
US8327319B2 (en) 2005-12-30 2012-12-04 Sap Ag Software model process interaction
US8676617B2 (en) 2005-12-30 2014-03-18 Sap Ag Architectural design for self-service procurement application software
US8448137B2 (en) 2005-12-30 2013-05-21 Sap Ag Software model integration scenarios
US8522194B2 (en) 2005-12-30 2013-08-27 Sap Ag Software modeling
US8380553B2 (en) 2005-12-30 2013-02-19 Sap Ag Architectural design for plan-driven procurement application software
US8407664B2 (en) 2005-12-30 2013-03-26 Sap Ag Software model business objects
US8402426B2 (en) 2005-12-30 2013-03-19 Sap Ag Architectural design for make to stock application software
US8396731B2 (en) 2005-12-30 2013-03-12 Sap Ag Architectural design for service procurement application software
US8660904B2 (en) 2005-12-30 2014-02-25 Sap Ag Architectural design for service request and order management application software
US8396761B2 (en) 2006-03-30 2013-03-12 Sap Ag Providing product catalog software application as enterprise services
US8396749B2 (en) 2006-03-30 2013-03-12 Sap Ag Providing customer relationship management application as enterprise services
US20070233539A1 (en) * 2006-03-30 2007-10-04 Philipp Suenderhauf Providing human capital management software application as enterprise services
US8442850B2 (en) 2006-03-30 2013-05-14 Sap Ag Providing accounting software application as enterprise services
US8538864B2 (en) 2006-03-30 2013-09-17 Sap Ag Providing payment software application as enterprise services
US8326702B2 (en) 2006-03-30 2012-12-04 Sap Ag Providing supplier relationship management software application as enterprise services
US8438119B2 (en) 2006-03-30 2013-05-07 Sap Ag Foundation layer for services based enterprise software architecture
US8321832B2 (en) 2006-03-31 2012-11-27 Sap Ag Composite application modeling
US8312416B2 (en) 2006-04-13 2012-11-13 Sap Ag Software model business process variant types
KR100783679B1 (ko) * 2006-05-11 2007-12-07 한국과학기술원 데이터 스트림에 기반하는 서비스의 개발, 배치, 제공을용이하게 하는 미들웨어 시스템
US7738456B2 (en) * 2006-08-07 2010-06-15 Cisco Technology, Inc. Techniques to map switch and router ports to physical locations
US20080071887A1 (en) * 2006-09-19 2008-03-20 Microsoft Corporation Intelligent translation of electronic data interchange documents to extensible markup language representations
US8161078B2 (en) 2006-09-20 2012-04-17 Microsoft Corporation Electronic data interchange (EDI) data dictionary management and versioning system
US8108767B2 (en) 2006-09-20 2012-01-31 Microsoft Corporation Electronic data interchange transaction set definition based instance editing
US8745486B2 (en) * 2007-01-25 2014-06-03 Microsoft Corporation Streamable interactive rendering-independent page layout
WO2008127474A1 (fr) * 2007-04-17 2008-10-23 Edward Frederick Publication, importation et formatage de modules de page internet
US7925783B2 (en) * 2007-05-23 2011-04-12 Microsoft Corporation Transparent envelope for XML messages
US7552405B1 (en) 2007-07-24 2009-06-23 Xilinx, Inc. Methods of implementing embedded processor systems including state machines
US8103785B2 (en) * 2007-12-03 2012-01-24 Seafire Micros, Inc. Network acceleration techniques
US8315900B2 (en) 2007-12-31 2012-11-20 Sap Ag Architectural design for self-service procurement application software
US8671034B2 (en) 2007-12-31 2014-03-11 Sap Ag Providing human capital management software application as enterprise services
US8447657B2 (en) 2007-12-31 2013-05-21 Sap Ag Architectural design for service procurement application software
US8510143B2 (en) 2007-12-31 2013-08-13 Sap Ag Architectural design for ad-hoc goods movement software
US8671033B2 (en) 2007-12-31 2014-03-11 Sap Ag Architectural design for personnel events application software
US8401936B2 (en) 2007-12-31 2013-03-19 Sap Ag Architectural design for expense reimbursement application software
US8671032B2 (en) 2007-12-31 2014-03-11 Sap Ag Providing payment software application as enterprise services
US8266686B1 (en) * 2008-01-11 2012-09-11 Sprint Communications Company L.P. System and method for VoIP firewall security
EP2139193B1 (fr) * 2008-06-26 2012-10-17 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Procédé pour effectuer une médiation de données, et produit de programme informatique associé, dispositif de médiation de données, et système d'informations
US8453126B1 (en) * 2008-07-30 2013-05-28 Dulles Research LLC System and method for converting base SAS runtime macro language scripts to JAVA target language
US8868532B2 (en) 2008-08-08 2014-10-21 Microsoft Corporation Message exchange pattern rendezvous abstraction
US8380549B2 (en) 2008-09-18 2013-02-19 Sap Ag Architectural design for embedded support application software
US8321250B2 (en) 2008-09-18 2012-11-27 Sap Ag Architectural design for sell from stock application software
US8315926B2 (en) 2008-09-18 2012-11-20 Sap Ag Architectural design for tax declaration application software
US8818884B2 (en) 2008-09-18 2014-08-26 Sap Ag Architectural design for customer returns handling application software
US8386325B2 (en) 2008-09-18 2013-02-26 Sap Ag Architectural design for plan-driven procurement application software
US8374896B2 (en) 2008-09-18 2013-02-12 Sap Ag Architectural design for opportunity management application software
US8352338B2 (en) 2008-09-18 2013-01-08 Sap Ag Architectural design for time recording application software
US8595077B2 (en) 2008-09-18 2013-11-26 Sap Ag Architectural design for service request and order management application software
US8401928B2 (en) 2008-09-18 2013-03-19 Sap Ag Providing supplier relationship management software application as enterprise services
US8326706B2 (en) 2008-09-18 2012-12-04 Sap Ag Providing logistics execution application as enterprise services
US8359218B2 (en) 2008-09-18 2013-01-22 Sap Ag Computer readable medium for implementing supply chain control using service-oriented methodology
CN101409673B (zh) * 2008-11-12 2013-07-03 北京恒光创新科技股份有限公司 一种网络适配器数据传输方法、网络适配器及系统
US8321308B2 (en) 2008-12-03 2012-11-27 Sap Ag Architectural design for manual invoicing application software
US8401908B2 (en) 2008-12-03 2013-03-19 Sap Ag Architectural design for make-to-specification application software
US8311904B2 (en) 2008-12-03 2012-11-13 Sap Ag Architectural design for intra-company stock transfer application software
US8321306B2 (en) 2008-12-03 2012-11-27 Sap Ag Architectural design for selling project-based services application software
US8738476B2 (en) 2008-12-03 2014-05-27 Sap Ag Architectural design for selling standardized services application software
US8671035B2 (en) 2008-12-11 2014-03-11 Sap Ag Providing payroll software application as enterprise services
WO2010103341A1 (fr) * 2009-03-10 2010-09-16 Telefonaktiebolaget L M Ericsson (Publ) Système et procédés pour un redémarrage de serveur d'application géré
WO2011133644A2 (fr) * 2010-04-22 2011-10-27 Bae Systems Information And Electronic Systems Integration Inc. Distribution de messages dans de multiples formats dans des réseaux de communication tactique
US20110264880A1 (en) * 2010-04-23 2011-10-27 Tatu Ylonen Oy Ltd Object copying with re-copying concurrently written objects
US8566480B2 (en) 2010-06-23 2013-10-22 International Business Machines Corporation Load instruction for communicating with adapters
US8572635B2 (en) 2010-06-23 2013-10-29 International Business Machines Corporation Converting a message signaled interruption into an I/O adapter event notification
US9213661B2 (en) 2010-06-23 2015-12-15 International Business Machines Corporation Enable/disable adapters of a computing environment
US8375045B2 (en) * 2010-06-23 2013-02-12 Raytheon Company Translating a binary data stream using binary markup language (BML) schema
US8650337B2 (en) * 2010-06-23 2014-02-11 International Business Machines Corporation Runtime determination of translation formats for adapter functions
US8626970B2 (en) 2010-06-23 2014-01-07 International Business Machines Corporation Controlling access by a configuration to an adapter function
US9195623B2 (en) 2010-06-23 2015-11-24 International Business Machines Corporation Multiple address spaces per adapter with address translation
US8650335B2 (en) 2010-06-23 2014-02-11 International Business Machines Corporation Measurement facility for adapter functions
US8639858B2 (en) 2010-06-23 2014-01-28 International Business Machines Corporation Resizing address spaces concurrent to accessing the address spaces
US8468284B2 (en) 2010-06-23 2013-06-18 International Business Machines Corporation Converting a message signaled interruption into an I/O adapter event notification to a guest operating system
US8615645B2 (en) 2010-06-23 2013-12-24 International Business Machines Corporation Controlling the selectively setting of operational parameters for an adapter
US8621112B2 (en) 2010-06-23 2013-12-31 International Business Machines Corporation Discovery by operating system of information relating to adapter functions accessible to the operating system
US9342352B2 (en) 2010-06-23 2016-05-17 International Business Machines Corporation Guest access to address spaces of adapter
US8635430B2 (en) 2010-06-23 2014-01-21 International Business Machines Corporation Translation of input/output addresses to memory addresses
US8549182B2 (en) 2010-06-23 2013-10-01 International Business Machines Corporation Store/store block instructions for communicating with adapters
CN101964798A (zh) * 2010-10-15 2011-02-02 德讯科技股份有限公司 基于远程桌面协议的多图形协议统一代理系统
US8819286B2 (en) * 2010-10-19 2014-08-26 Hewlett-Packard Development Company, L.P. Methods, systems, and apparatus for processing messaging data sets using structured data sets
CN102255802B (zh) * 2011-06-27 2014-01-01 中国建设银行股份有限公司 一种sna主机报文解析的方法及系统
CN103095661A (zh) * 2011-11-01 2013-05-08 镇江华扬信息科技有限公司 一种基于Javascript虫洞技术的SSO实现方式
CN103685041B (zh) * 2012-09-04 2017-04-19 清华大学 一种基于比特粒度可编程的路由器及路由方法
US8996061B2 (en) * 2012-09-21 2015-03-31 Bae Systems Information And Electronic Systems Integration Inc. Bridging communications between tactical SDR and cellular telephone networks
US9189441B2 (en) * 2012-10-19 2015-11-17 Intel Corporation Dual casting PCIE inbound writes to memory and peer devices
WO2014169227A1 (fr) * 2013-04-12 2014-10-16 Northeastern University Reconfiguration de forme d'onde fondée sur l'ontologie
CN103269285B (zh) * 2013-05-24 2016-08-17 杭州华三通信技术有限公司 网络通信集群装置和用于实现网络通信集群的方法
CN104243512B (zh) * 2013-06-07 2018-05-04 上海联影医疗科技有限公司 一种医疗服务的集成方法
US9304849B2 (en) 2013-06-12 2016-04-05 International Business Machines Corporation Implementing enhanced error handling of a shared adapter in a virtualized system
US9400704B2 (en) 2013-06-12 2016-07-26 Globalfoundries Inc. Implementing distributed debug data collection and analysis for a shared adapter in a virtualized system
US9111046B2 (en) 2013-06-12 2015-08-18 International Business Machines Corporation Implementing capacity and user-based resource allocation for a shared adapter in a virtualized system
US9720775B2 (en) 2013-06-12 2017-08-01 International Business Machines Corporation Implementing concurrent adapter firmware update for an SRIOV adapter in a virtualized system
US9323620B2 (en) 2013-06-12 2016-04-26 International Business Machines Corporation Implementing shared adapter configuration updates concurrent with maintenance actions in a virtualized system
US9317317B2 (en) 2013-06-12 2016-04-19 International Business Machines Corporation Implementing concurrent device driver maintenance and recovery for an SRIOV adapter in a virtualized system
US10543706B2 (en) * 2013-08-09 2020-01-28 MeccoPartners, LLC EIP protocol converter system for laser for dot peen marking systems
CN104392192A (zh) * 2014-10-11 2015-03-04 昆腾微电子股份有限公司 在非接触卡中实现通信协议复用的装置和方法
US10069928B1 (en) * 2015-01-21 2018-09-04 Amazon Technologies, Inc. Translating requests/responses between communication channels having different protocols
JP6356909B2 (ja) * 2015-04-23 2018-07-11 株式会社東芝 クライアントシステム、クライアントシステムの管理方法、システムコントローラ
US10255336B2 (en) 2015-05-07 2019-04-09 Datometry, Inc. Method and system for transparent interoperability between applications and data management systems
CN106357706A (zh) * 2015-07-13 2017-01-25 青岛海尔滚筒洗衣机有限公司 电器设备控制方法、电器设备控制装置及其电器设备
US10594779B2 (en) 2015-08-27 2020-03-17 Datometry, Inc. Method and system for workload management for data management systems
SG10201507051WA (en) * 2015-09-03 2017-04-27 Certis Cisco Security Pte Ltd System and method for high frequency heuristic data acquisition and analytics of information security events
EP3139548B1 (fr) * 2015-09-04 2018-04-11 Airbus Operations Passerelle de sécurité d'assurance élevée interconnectant différents domaines
CN105516158A (zh) * 2015-12-18 2016-04-20 山东海量信息技术研究院 一种可配置协议转换状态机电路结构及协议配置方法
CN105812368A (zh) * 2016-03-15 2016-07-27 山东超越数控电子有限公司 一种多种通讯协议通用编程方法
KR102421791B1 (ko) 2016-05-26 2022-07-15 삼성전자주식회사 Mmt 네트워크 시스템에서 미디어 시간 정보를 전송 하는 방법 및 장치
CN108076110B (zh) * 2016-11-14 2021-02-26 北京京东尚科信息技术有限公司 电子数据交换系统和包含电子数据交换系统的装置
US10783287B2 (en) * 2017-06-14 2020-09-22 International Business Machines Corporation Employing natural language processing to facilitate geospatial analysis
CN108595731B (zh) * 2018-01-23 2022-02-08 苏州盛科通信股份有限公司 一种以太网芯片中动态表项的设计方法及装置
US10402380B1 (en) * 2018-05-09 2019-09-03 Carecloud Corporation Interactive user interface for schema transformation
US10944850B2 (en) * 2018-10-29 2021-03-09 Wandisco, Inc. Methods, devices and systems for non-disruptive upgrades to a distributed coordination engine in a distributed computing environment
US11294869B1 (en) 2018-12-19 2022-04-05 Datometry, Inc. Expressing complexity of migration to a database candidate
US11436213B1 (en) 2018-12-19 2022-09-06 Datometry, Inc. Analysis of database query logs
US11468043B1 (en) 2018-12-20 2022-10-11 Datometry, Inc. Batching database queries for migration to a different database
US11178113B2 (en) * 2019-07-30 2021-11-16 Ppip, Llc Protocol isolation for security
CN111343196B (zh) * 2020-03-19 2020-12-08 广州市城建开发集团名特网络发展有限公司 一种兼容多种通讯协议的通信系统与通信方法
CN111414266B (zh) * 2020-03-23 2024-04-05 浪潮通用软件有限公司 一种分布式事务的同步异步通信方法和装置
CN111625224B (zh) * 2020-05-28 2023-11-24 北京百度网讯科技有限公司 代码生成方法、装置、设备及存储介质
US11442703B2 (en) 2020-09-22 2022-09-13 Cisco Technology, Inc. Domain-specific language for serverless network functions
US11126415B1 (en) * 2020-09-22 2021-09-21 Cisco Technology, Inc. Combining domain-specific language with general-purpose language for serverless network functions
US11625230B2 (en) 2020-09-22 2023-04-11 Cisco Technology, Inc. Identifying execution environments for deploying network functions
CN113300893B (zh) * 2021-05-25 2022-03-08 西北工业大学 一种基于硬件的反射内存网络系统
US20230004573A1 (en) * 2021-06-30 2023-01-05 Optx Solutions, Llc Systems and methods for ingesting data in disparate formats
CN113836060B (zh) * 2021-09-24 2024-05-28 北京机电工程研究所 一种适用于仿真模型及流程模型的分布式实时仿真平台
CN114679502B (zh) * 2022-03-15 2023-11-21 珠海格力电器股份有限公司 用于数控系统的通信方法和系统
CN114697131A (zh) * 2022-04-27 2022-07-01 京东科技控股股份有限公司 数据调用方法及装置、存储介质及电子设备
CN116846863B (zh) * 2023-08-30 2023-11-10 东方空间技术(山东)有限公司 一种光纤反射内存网内存映射方法、装置及计算设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5555415A (en) * 1994-01-10 1996-09-10 Metasphere, Inc. Object oriented event message dispatching subsystem and method utilizing a disposition matrix
US5680552A (en) * 1994-09-20 1997-10-21 Lucent Technologies Inc. Gateway system for interconnecting different data communication networks
US5826030A (en) * 1995-11-30 1998-10-20 Excel Switching Corporation Telecommunication switch having a universal API with a single call processing message including user-definable data and response message each having a generic format
US6111893A (en) * 1997-07-31 2000-08-29 Cisco Technology, Inc. Universal protocol conversion

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410675A (en) * 1989-08-21 1995-04-25 Lisa M. Shreve Method of conforming input data to an output data structure and engine for accomplishing same
US5574919A (en) * 1991-08-29 1996-11-12 Lucent Technologies Inc. Method for thinning a protocol
US5826017A (en) * 1992-02-10 1998-10-20 Lucent Technologies Apparatus and method for communicating data between elements of a distributed system using a general protocol
US6134598A (en) * 1997-05-23 2000-10-17 Adobe Systems Incorporated Data stream processing on networked computer system lacking format-specific data processing resources
US6785730B1 (en) * 1999-02-16 2004-08-31 Rebecca S. Taylor Generic communications protocol translator
US6401132B1 (en) * 1999-08-03 2002-06-04 International Business Machines Corporation Subchaining transcoders in a transcoding framework
KR100476895B1 (ko) * 2002-05-21 2005-03-18 삼성전자주식회사 가변 가능한 데이터 전송 모드를 갖는 인터페이스 장치 및그것의 동작 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5555415A (en) * 1994-01-10 1996-09-10 Metasphere, Inc. Object oriented event message dispatching subsystem and method utilizing a disposition matrix
US5680552A (en) * 1994-09-20 1997-10-21 Lucent Technologies Inc. Gateway system for interconnecting different data communication networks
US5826030A (en) * 1995-11-30 1998-10-20 Excel Switching Corporation Telecommunication switch having a universal API with a single call processing message including user-definable data and response message each having a generic format
US6111893A (en) * 1997-07-31 2000-08-29 Cisco Technology, Inc. Universal protocol conversion

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100334821C (zh) * 2004-04-19 2007-08-29 中兴通讯股份有限公司 一种通信系统有限状态机的测试方法
CN1764213B (zh) * 2004-10-21 2011-05-25 株式会社电装 蓝牙通信装置和方法以及短程无线通信装置和方法
US8712974B2 (en) 2008-12-22 2014-04-29 Google Inc. Asynchronous distributed de-duplication for replicated content addressable storage clusters
US9081841B2 (en) 2008-12-22 2015-07-14 Google Inc. Asynchronous distributed garbage collection for replicated storage clusters
US10291699B2 (en) 2008-12-22 2019-05-14 Google Llc Asynchronous distributed de-duplication for replicated content addressable storage clusters
US11943290B2 (en) 2008-12-22 2024-03-26 Google Llc Asynchronous distributed de-duplication for replicated content addressable storage clusters

Also Published As

Publication number Publication date
CN1516840A (zh) 2004-07-28
EP1381962A2 (fr) 2004-01-21
JP2005504455A (ja) 2005-02-10
WO2002087136A9 (fr) 2003-04-10
WO2002087136B1 (fr) 2003-11-13
AU2002309605A1 (en) 2002-11-05
WO2002087136A3 (fr) 2003-02-13
US20020161907A1 (en) 2002-10-31

Similar Documents

Publication Publication Date Title
US20020161907A1 (en) Adaptive multi-protocol communications system
Schmidt et al. C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks
Hayden The ensemble system
Henning et al. Advanced CORBA® programming with C++
Schmidt et al. Pattern-oriented software architecture, patterns for concurrent and networked objects
Pyarali et al. Design and Performance of an Object-Oriented Framework for High-Performance Electronic Medical Imaging.
US20030135850A1 (en) System of reusable software parts and methods of use
US20020038336A1 (en) IMS transaction messages metamodel
US20020078010A1 (en) High level assembler metamodel
Myerson The complete book of middleware
Tari et al. Fundamentals of distributed object systems: the CORBA perspective
Bever et al. Distributed systems, OSF DCE, and beyond
Dineen et al. The Network Computing Architecture and System: An Environment for Developing Distributed Applications.
Giese Contract-based component system design
Aleksy et al. Implementing distributed systems with Java and CORBA
Voth et al. Distributed application development for three-tier architectures: Microsoft on Windows DNA
Chiang The use of adapters to support interoperability of components for reusability
Singhai QuarterWare: A middleware toolkit of software RISC components
Pryce Component interaction in distributed systems
Bacon et al. Distributed computing with RPC: The Cambridge approach
Mitchell Implementations of Process Synchronisation and their Analysis
Bhandarkar CHARISMA: a component architecture for parallel programming
Gailliard et al. Mapping semantics of CORBA IDL and GIOP to open core protocol for portability and interoperability of SDR waveform components
Sheu et al. A New Architecture for Integration of CORBA and OODB
Seizovic The Architecture and Programming of a Fine-Grain Multicomputer

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/62-62/62, DRAWINGS, REPLACED BY NEW PAGES 1/42-42/42; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002584522

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2002736613

Country of ref document: EP

B Later publication of amended claims

Free format text: 20021217

WWE Wipo information: entry into national phase

Ref document number: 028119584

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2002736613

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642