Flexibly deployable communication device facilitating interoperation between middleware
View Patent ↗A novel communication device (e.g., router or switch) facilitates interoperation between a plurality of middleware. The communication device has in-ports, out-ports, and a configurator. In-ports, IP 0 , . . . , IP m , are associated with a middleware from a plurality of middleware and out-ports, OP 0 , . . . , OP n , are associated with a middleware from the plurality of middleware. The configurator configures in-ports and out-ports based on a binding and transport of associated middleware and the novel communication device facilitates interoperation between middleware via a communication path between at least one configured in-port and at least one configured out-port, with the communication path allowing an incoming message to pass from said at least one configured in-port to said at least one configured out-port. Parameters ‘m’ and ‘n’ are chosen such that any of the following conditions are true: m=0 and n≧1, m≧1 and n=0, m=n, m=1 and n>1, m>1 and n=1, and m≠n.
1. An article of manufacture comprising a non-transitory computer storage medium having computer readable program code embodied therein implementing a communication device to facilitate interoperation between a plurality of middleware, said storage medium comprising:
(a) computer readable program code implementing one or more in-ports, IP 0 , . . . , IP m , each in-port associated with a middleware from said plurality of middleware, each of said in-ports defining a connection between a given middleware and an API handling a given operation call coming from said given middleware to a bus, said in-ports identifying an operation call from said middleware, and computer readable program code implementing one or more out-ports, OP 0 , . . . , OP n , each out-port associated with a middleware from said plurality of middleware, wherein ‘m’ and ‘n’ are chosen such that any of the following conditions are true: m=n, m=1 and n>1, m>1 and n=1, and m≠n, each of said out-ports defining a connection between another middleware and another API handling another operation call going from said bus to said another middleware, each of said in-port and out-port comprising a binding and a transport, said binding is at least associated with data formatting and said transport associated with at least a communications protocol or middleware;
(b) computer readable program code implementing a configurator, said configurator receiving inputs based on said identified operation call and, based on said inputs, dynamically configuring at least one in-port associated with a first middleware and at least one out-port corresponding to a second middleware,
wherein said computer readable program code facilitates interoperation between said first and second middleware via at least one communication path between at least one configured in-port and at least one configured out-port, said communication path allowing an incoming message to pass from said at least one configured in-port to said at least one configured out-port, and
wherein said API handles said operation call by dividing said operation call into a plurality of parts without transforming the data format of at least one of said parts into a canonical format.
2. The article of manufacture of claim 1 , wherein said communication device is any of the following: a router or a switch.
3. The article of manufacture of claim 1 , wherein said configurator works in conjunction with a database storing configuration data to identify which in-ports and out-ports are to be configured.
4. The article of manufacture of claim 3 , wherein said database additionally stores any of, or a combination of, the following: threading configuration information, implementation interceptors information, or bootstrap information.
5. The article of manufacture of claim 1 , wherein data moved over said path is represented in a plurality of different formats and an element in said path is able to request data in any of the said plurality of different formats.
6. The article of manufacture of claim 5 , wherein said unwanted formats of said moved data are discarded by said system.
7. The article of manufacture of claim 5 , wherein data is created in a previously unavailable format when said element in said path requests data in said previously unavailable format.
8. The article of manufacture of claim 1 , wherein said in-port identifies an operation corresponding to each received message, said identification based on any of the following: size of the received message, information in the message header, or parsing a part of the payload of received message.
9. The article of manufacture of claim 8 , wherein said identified operation is used to identify an optimal path among a plurality of paths or is used to decide the type of processing.
10. A server-side communication device implemented in an article of manufacture comprising a non-transitory computer storage medium having computer readable program code embodied therein facilitating interoperation between a server and a plurality of middleware, said server-side communication device, said computer storage medium comprising:
(a) computer readable program code implementing one or more in-ports, IP 0 , . . . , IP m , each in-port associated with a middleware from said plurality of middleware, each of said in-ports defining a connection between a given middleware and said server, each of said in-ports comprising a binding and a transport, said binding is at least associated with data formatting and said transport associated with at least a communications protocol or middleware, said in-ports identifying an operation call from said middleware;
(b) computer readable program code implementing a configurator receiving inputs based on said identified operation call and, based on said inputs, dynamically configuring at least one in-port associated with a given middleware,
said server-side communication device facilitating interoperation between said server and said at least one configured in-port associated with said given middleware via a communication path, said communication path allowing an incoming message to pass from said at least one configured in-port associated with said specific middleware to said server, and
wherein said server handles said operation call by dividing said operation call into a plurality of parts without transforming the data format of at least one of said parts into a canonical format.
11. A server-side communication device facilitating interoperation between a server and a plurality of middleware, as per claim 10 , wherein said server-side communication is implemented in-process with a server process.
12. A server-side communication device facilitating interoperation between a server and a plurality of middleware, as per claim 10 , wherein said configurator works in conjunction with a database storing configuration data to identify which in-ports are to be configured.
13. A server-side communication device facilitating interoperation between a server and a plurality of middleware, as per claim 12 , wherein said database additionally stores any of, or a combination of, the following: threading configuration information, implementation interceptors information, or bootstrap information.
14. A server-side communication device facilitating interoperation between a server and a plurality of middleware, as per claim 10 , wherein said in-port identifies an operation corresponding to each received message, said identification based on any of the following: size of the received message, information in the message header, or parsing a part of the payload of received message.
15. A server-side communication device facilitating interoperation between a server and a plurality of middleware, as per claim 14 , wherein said identified operation is used to identify an optimal path among a plurality of paths or is used to decide the type of processing.
16. An article of manufacture comprising a non-transitory computer storage medium having computer readable program code embodied therein implementing a dynamically configurable switch facilitating interoperation between a set of middleware, said storage medium comprising:
(a) computer readable program code implementing one or more in-port modules, IP 0 , . . . , IP m , configurable to implement one or more in-ports, each in-port associated with a middleware from said set of middleware, each of said in-ports defining a connection between a given middleware and an API handling a given operation call coming from said given middleware to a bus, said in-ports identifying an operation call from said middleware, and computer readable program code implementing one or more out-ports modules, OP 0 , . . . , OP n , configurable to implement one or more out-ports, each out-port associated with a middleware from said set of middleware, each of said out-ports defining a connection between another middleware and another API handling another operation call going from said bus to said another middleware, each of said in-port and out-port comprising a binding and a transport, said binding is at least associated with data formatting and said transport associated with at least a communications protocol or middleware;
(b) computer readable program code implementing a configurator dynamically configuring in-ports and out-ports for an identified subset of middleware among said set of middleware, said dynamically configuration of in-ports and out-ports being based on a binding and transport of a subset of said set of middleware, said configurator receiving inputs based on said identified operation call and, based on said inputs, dynamically configuring at least one in-port associated with a first middleware and at least one out-port corresponding to a second middleware, and
said switch facilitating interoperation between said first and second middleware via at least one communication path between at least one configured in-port and at least one configured out-port, said communication path allowing an incoming message to pass from said at least one configured in-port to said at least one configured out-port, and
wherein said API handles said operation call by dividing said operation call into a plurality of parts without transforming the data format of at least one of said parts into a canonical format.
17. The article of manufacture of claim 16 , wherein said configurator works in conjunction with a database storing configuration data to identify which in-port and out-port is to be configured.
18. The article of manufacture of claim 17 , wherein said database additionally stores any of, or a combination of, the following: threading configuration information, implementation interceptors information, or bootstrap information.
19. The article of manufacture of claim 16 , wherein data moved along said path is represented in a plurality of different formats and an element in said path is able to request data in any of said plurality of different formats.
20. The article of manufacture of claim 19 , wherein unwanted formats of said moved data are discarded by said dynamically configurable communication device.
21. The article of manufacture of claim 19 , wherein data is created in a previously unavailable format when said element in said path requests data in said previously unavailable format.
22. The article of manufacture of claim 16 , wherein said in-port identifies an operation corresponding to each received message, said identification based on any of the following: size of the received message, information in the message header, or parsing a part of the payload of received message.
23. The article of manufacture of claim 22 , wherein said identified operation is used to identify an optimal path among a plurality of paths or is used to decide the type of processing.