Generic data exchange method using hierarchical routing

A process including retrieving a list of one or more candidate objects with which an origin object can communicate using a standard command language, wherein at least one of the one or more candidate objects uses a command language different than the standard command language. The process queries the schema of one or more target objects selected from among the one or more candidate objects and uses the standard command language to transmit to the one or more target objects commands and/or data consistent with the schemas of the target objects.

TECHNICAL FIELD

The present invention relates generally to data communication and in particular, but not exclusively, to a generic data exchange method using hierarchical routing.

BACKGROUND

Many modern systems, such as machine vision systems, consist of multiple different components coupled together in such a way that they can communicate and interact with each other. Coupling of the components is usually accomplished using a combination of hardware and software—the hardware provides the tangible physical link between components, while the software controls the hardware and can perform other functions.

While these systems offer many advantages, one disadvantage they have is that different components in the system may operate under different protocols and/or understand different command languages. As such, a user of the system who wants to communicate with a specific component must know both the communication protocol needed to reach the component and the commands understood by the component. In a system with many different components, that means that a user must know multiple different protocols and command languages or structures to be able to interact with all the different components in a system.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

Embodiments of a system and method for generic data exchange method using hierarchical routing are described. Numerous specific details are described to provide a thorough understanding of embodiments of the invention, but one skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In some instances, well-known structures, materials, or operations are not shown or described in detail but are nonetheless encompassed within the scope of the invention.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one described embodiment. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in this specification do not necessarily all refer to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

FIG. 1illustrates an embodiment of a machine vision system100. System100includes machine vision cameras A1-A3coupled in a daisy-chain configuration to computer A, such as a personal computer, and machine vision cameras B1-B3coupled in a bus configuration to computer B. Computer A is coupled to computer B by a communication link, such as an Ethernet, TCP, HTTP or other such connection. In different embodiments, the communication link between components in system100can be hard-wired, wireless, or some combination of the two.

Within machine vision system100, cameras A1-A3need not all be the same type of camera and, similarly, cameras B1-B3need not all be the same type of camera, nor do they need to be coupled by the same kind of communication link. If the cameras are different, it can happen that the cameras operate using different software, different command languages and different communication protocols. In such an arrangement, a user operating cameras A1-A3from computer A must know all the different command languages and communication protocols to be able to communicate with and operate the cameras. A user operating cameras B1-B3from computer B faces a similar predicament. An extra layer of complication is added when a user on computer B wants to operate cameras A1-A3through the network connection between computer B and computer A, as the network connection can add its own command language and protocol.

FIG. 2illustrates an embodiment of a framework200for generic data exchange among different components. Framework200includes two devices, device1and device2, communicatively coupled by a communication path201. In one embodiment devices1and2can be any two devices within a machine vision system such as system100. For example, device1can be a computer such as a PC A while device2can be a machine vision camera such as camera B2, but in other embodiments device1and device2can be other kinds of devices.

Device1can include hardware components such as a processor, memory, storage, hardware communication interfaces, and so forth. One or more processes such as process1can run on the processor. Within process1are instances of an origin object202and a local service object204. As used herein, the term “object” is intended to have the meaning associated with the term in object-oriented programming; that is, an object is a discrete software entity that can include both routines and data, that can call and be called by other objects, and that includes certain properties on its own or in relation to other classes of objects such as derivation, inheritance, and the like. In one embodiment origin object202can be a user interface, but in other embodiments origin object202can perform some other function.

Local service object204also runs in process1and can communicate with origin object202as well as with other objects that can be within process1or in other processes. In the illustrated embodiment, then, local service object204generally serves to transfer commands and data between objects inside and outside process1. In the embodiment shown, local service object204can transmit a request package received from origin object202out of process1and can receive a response package from outside process1and transmit it to origin object202. As further described below the request package and response package use a standard command language that is understood by local service object204.

Communication object206also runs on device1. In the illustrated embodiment an instance of communication object206runs in some other process outside process1, but in other embodiments it could run within process1. Communication object206functions to exchange information between device1and device2via communication path201. In one embodiment, communication object206can be a Windows Communication Foundation (WCF) object, but in other embodiments other types of communication objects can be used, depending on the nature of device1and what communication protocols need to be supported. Among other types of data it can exchange, in the illustrated embodiment communication object206can receive a request package from local service object204and transmit it outside device1, and similarly can receive a response package from outside device1and transmit it to local service object204.

Communication path201provides a route through which data can be exchanged between device1and device2. In one embodiment, communication path201can be a hard-wired connection, but in other embodiments it can be a wireless connection, and in still other embodiments it can be a combination of hard-wired and wireless connections. Communication path201can use different communication protocols in different embodiments, usually depending on the protocols supported by communication objects206and208on either end of the communication path. Examples of communication protocols that can be used include Ethernet, TCP/IP, HTTP, HTTPS, a Web service interface such as SOAP, and so forth. In the illustrated embodiment, device2has an IP address of 10.20.1.17, indicating the TCP/IP is the communication protocol being used.

Device2, like device1, can include hardware components such as a processor, memory, storage, hardware interfaces, and so forth. One or more processes such as process2can run on the processor. Running within process2are instances of one or more target objects, such as target object212(named “xscape”) and target object214(named “vscape”), as well as an instance of a remote service object210that can communicate with the target objects and with communication object208. Although only two target objects are shown in the illustrated embodiment, device2will generally include one or more candidate objects running within one or more processes with which origin object202can communicate using the illustrated framework, and any of the candidate objects is an object that can be chosen as a target object. As further discussed below, by issuing the necessary commands (see, e.g.,FIGS. 5A-5B), origin object202can select one or more target objects with which it wants to communicate from among the candidate objects.

Remote service object210also runs in process2and can communicate with communication object208and with target objects212and214, as well as with other candidate objects that can be within process2or in other processes on device2. In the illustrated embodiment, then, remote service object204generally serves to transfer commands and data between objects inside and outside process2. In the embodiment shown, remote service object210can receive a request package from communication object208and can transmit a response package from target objects212and214to communication object208. The request package and response package use a standard command language that is understood by remote service object210.

Communication object208also runs on device2. In the illustrated embodiment an instance of communication object206runs outside process2, but in other embodiments it could run within process2. As with communication object206, communication object208functions to exchange information between device1and device2via communication path201. In one embodiment, communication object208can be of the same type as communication object206, such as a Windows Communication Foundation (WCF) object, but in other embodiments other types of communication object208can be used, provided that communication object208supports the protocol needed to communicate with communication object206. Among other types of data it can exchange, in the illustrated embodiment communication object208can receive a response package from remote service object210and transmit it outside device2and similarly can receive a request package from outside device2and transmit it to remote service object210.

Operation of framework200begins, in one embodiment, with origin object202. Initially, origin object202wants to communicate with objects on device2, but doesn't know which objects on device2are candidates for communication, so it assembles a first request package that includes commands in a standard command language. The standard command language can include route commands that will route the first request package to remote service object210, as well as commands that query the namespace of the remote service object to determine a list of candidate objects with which the remote service object, and hence origin object202, can communicate. The commands can also include commands to query the schema of each candidate object. The first request package is then routed to local service object204, which processes the request package, calls communication object206, and passes the request package to communication object206for transfer over communication path201. Communication path201transmits the request package to communication object208, which then transmits it to remote service object210. Remote service object210processes the namespace query and the schema queries and assembles the results into a first response package, and transmits the first response package to communication object208, which then transmits the first response package to origin object202via communication path201, communication object206, and local service object204.

Having received the first response package, origin object202(or, more accurately, a user of object202) can choose one or more target objects with which to communicate from among the candidate objects identified by the remote service object (i.e., the namespace of remote service object210) and, having queried the schemas of the candidate objects, can assemble a second request package with the correct routing information and with commands to be executed by the one or more target objects, as well as data consistent with the respective schemas of the target objects. The second request package is then routed to the target object or objects the same way the first request package was routed. In response to the second request package, remote service object210assembles a second response package based on responses from the target objects. The response package can include a header and a payload. The second response package is then routed back to the origin object the same way the first response package was routed.

In some cases, the payload of the second response package can include data in a format that cannot be handled by the communication protocol used by communication path201and communication objects206and208. In such cases, communication object208may need to encode the payload before transmission and communication object206may need to un-encode the payload before transmitting the second response package to origin object202. Of course, in other embodiments of the operation of framework200it is possible that the target objects and their schemas are known beforehand. In such cases, the user could simply use the second request package and the process described above for the first request package and first response package would be unnecessary. Further details of the operation of framework200are provided below with reference toFIGS. 4-11.

Framework200offers multiple advantages. Among other things, framework200is very light weight, meaning that it implements a very minimal schema that is easily overlaid on other existing schemas, for example as shown inFIG. 12, and otherwise uses minimal support code, such as the parser that can be found in embodiments of local service object204. This combination of a minimal schema and minimal support code allows framework200to be substantially self-contained, meaning that it requires few or no links to other existing communication frameworks, object frameworks or extensive external libraries. The minimal, substantially self-contained nature of framework200allows existing implementations of services, objects, etc, to be adapted to function within the framework with minimal code changes, and also allows the framework to be easily adapted to any kind of processing hardware, operating system, etc., without adversely affecting operation.

FIGS. 3A-3Cillustrate alternative embodiments configurations that can communicate using a framework such as framework200. Framework200illustrates an embodiment of communication framework applied to multiple devices, but in other embodiments other communications are possible.FIG. 3Aillustrates an embodiment in which the communication is among instances of origin and target objects running within the same process on the same device. In this embodiment, the communication path is established by a direct call from one object to the other, and instances of intermediary objects such as the local and remote service objects and the communications objects are not necessary.FIG. 3Billustrates an embodiment in which two processes run on the same device and communication is among an origin object in one process and a target object in the other process. In this embodiment, the communication path could be established using named pipes or, in an embodiment where the different processes are running on different (asymmetrical) CPU cores, using shared memory.FIG. 3Cillustrates an extension ofFIG. 2in which communication between the origin object and a target object can involve multiple hops, such as when the origin object can communicate with target object2via intermediary device2.

FIG. 4illustrates an embodiment of a process400for an origin object such as origin object202(seeFIG. 2). The process starts at block402. At block404, the process checks whether the origin object knows the target object with which it wants to communicate. If the origin object does not, then the process proceeds to block406, where the origin object assembles a request package that includes commands in a standard command language. The commands can include routing commands to direct the request package to the correct remote service object and query commands to determine the namespace of the particular remote service object—that is, the list of objects with which the remote service object can communicate, and hence a list of candidate objects with which the origin object can communication. In one embodiment the request package can also include schema query commands to determine the schema of each candidate object.

Once the request package is ready, at block408the origin object transmits the request package to the remote service object, for example as shown inFIG. 2. At block410, the process receives a response package from the remote service object. The response package includes a header and a payload; in this case the payload can include the namespace of the remote service object, which will be a list of candidate objects with which the origin object can communicate. The process then returns to block404, where it checks whether the one or more target objects with which the origin object wants to communicate are known after return of the response package. If the target object is known, then the process moves to block412.

At block412, the process checks whether the namespace and schema of the target objects are known. If they are not, then the process proceeds to block414, where the origin object assembles a request package that includes commands in a standard command language. The commands can include routing commands to direct the request package to the correct target objects, query commands to determine the namespace of the particular target object, and schema query commands to determine the schema of each target object. Once the request package is ready, at block416the origin object transmits the request package to the target objects. At block418, the process receives a response package from the target objects. The response package can include the namespace of the targets object, as well as the schemas of the target objects if the schema query was used. The process then returns to block412, where it checks whether the namespace and/or schema of the target objects are known after return of the response package.

If at block412the namespace and schema of the target object are known, then the process moves to block420, where the origin object assembles a request package that includes commands for the one or more target objects in the standard command language. The commands can include routing commands to direct the request package to the correct target objects, and commands that cause the target object to take some action, such as returning data. Once the request package is ready, at block422the origin object transmits the request package to the target objects. At block424, the process receives a response package from the target objects. The payload of the response package from the target objects can include confirmation from the target objects that the commands were carried out or can include data requested from the target objects (see, e.g.,FIGS. 11B-11C).

Of course, in different embodiments it can be possible to bypass or omit one or more blocks from process400. For example, if the location, namespace and schema of all the desired target objects are known in advance, process400can be started at block420instead of block402.

FIGS. 5A-5Billustrate embodiments of a request package.FIG. 5Ashows, with reference to framework200, a request package that includes nested tags, in extensible markup language (XML) format, to get the tree (a listing of steps and datums) from target object214, whose name is “vscape.” The request package start with a route tag that specifies the route the request package should take to get to the target object. In this case, the route is specified by providing the IP address of device2, which is 10.20.1.17, and by providing the name of the remote service object, which in the illustrated embodiment is “mixl.” The next command in the hierarchy is another route tag, which specifies how the package should be routed after it arrives at the remote service object; in this case, the second route tag specifies that the request package should be routed to target object “vscape.” The final nested tag is a command tag, which is routed to object “vscape” so that the commands in the tag can be executed.FIG. 5Bshows an alternative embodiment of a request package that contains commands for multiple target objects at once.FIG. 5Billustrates a request package that provides commands to both objects “vscape” and “xscape.” Other embodiments of a request package can include other tags beyond those shown inFIGS. 5A-5B. A non-exhaustive list of tags that can be used includes:<route>—if the destination name is understood, resolve it into an Object reference. Then for each of the child nodes in the object call the object's virtual method.<cmd>—do the action specified in the “act” attribute. The command in the act attribute is specific to the target object.<queryschema>—return detailed datatype information by using standard <schema> tags as defined by w3.org. An object can represent an arbitrarily complex datatype. Each item that can be individually read or written is called a field.<get> & <set>—get or set a field value from a target object that has previously been queried for its schema. Multiple fields can be handled at once.<subscribe> & <unsubscribe>—an object would like to have data “pushed” to it whenever there's an update.<response>—the response to a request. This can be directly returned in a synchronous request, or returned later if asynchronous.

FIG. 6illustrates an embodiment of a process600that can be carried out by a local service object such as object204(seeFIG. 2). The process starts at block602. At block604the local service object receives a request package from the origin object, and at block606it proceeds to parse the command language—that is, the tags—in the request package. In one embodiment, the tags can be parsed into a Document Object Model (DOM) tree, but other types of parsing are possible in other embodiments.

At block608, the local service object calls a communication object and at block610it transmits the request package to the communication object. After block610, the local service object is finished with processing the request package, so at block612it waits to receive a response package that responds to the commands in the request package. The local service object does not necessarily enter a wait state where it can do nothing else until it receives a response; it can be possible for the local service object to be able to process other request packages while waiting for responses to previous request packages. At block614, the local service object checks whether a response has been received. If no response has been received it returns to block614, but if a response has been received it proceeds to block616where it transmits the response to the origin object.

FIG. 7illustrates an embodiment of a process700for a communication object such as communication object206(seeFIG. 2). The process starts at block702. At block704the communication object receives the request package from the local service object, at block706it reads the first route tag in the command hierarchy and at block708it strips the first route tag from the request, so that the next route tag in the hierarchy will be the first tag seen by the object specified in the previous route tag. At block710, the communication object transmits the request package to the destination specified in the first route tag.

After block710, the communication object is finished with processing the current request package, so at block712it waits to receive a response package that responds to the commands in the request package. The communication object does not necessarily enter a wait state where it can do nothing else until it receives a response; it can be possible for the communication object to be able to process other request packages while waiting for responses to previous request packages. At block714, the local service object checks whether a response has been received. If no response has been received it returns to block712.

If at block714a response has been received, the process goes to block716where it checks whether the response package requires any decoding. In embodiments where the communication protocol supported by the communication objects and communication path cannot transfer the response package's payload in its native format, it can be necessary to encode the payload before transmission and decode it after reception. For example, if the response package payload includes binary data and the communication path and communications objects do not support binary, it can be necessary to encode the binary into a form that the communication elements can support. In one embodiment, binary data can be encoded and decoded using uuencode, but in other embodiments other methods can be used.

If at block716the response package does not required decoding, then the process goes to block720, where it transmits the response package to the local service object. Otherwise, if the response package payload was encoded for transmission and now requires decoding, it proceeds to block718, where it decodes the payload, and then proceeds to block720where it transmits the decoded response package to the local service object.

FIG. 8illustrates an embodiment of a process for a communication object such as communication object208(seeFIG. 2). The process starts at block802. At block804the communication object receives the request package from the transmitting communication object, at block806it reads the first route tag in the command hierarchy and at block808it strips the first route tag from the request, so that the next route tag in the hierarchy will be the first tag seen by the object specified in the previous route tag. At block810, the communication object transmits the request package to the destination specified in the first route tag, usually the remote service object.

After block810, the communication object is finished with processing the current request package, so at block812it waits to receive a response package that responds to the commands in the request package. The communication object does not necessarily enter a wait state where it can do nothing else until it receives a response; it is entirely possible for the communication object to be able to process other request packages while waiting for responses to previous request packages. At block814, the local service object checks whether a response has been received. If no response has been received it returns to block812.

If at block814a response has been received, the process goes to block816where it checks whether the response package's payload requires any decoding. In embodiments where the communication protocol supported by the communication object and communication path cannot transfer the payload in its native format, it can be necessary to encode the payload before transmission and decode it after reception. For example, if the response package payload includes binary data and the communication path and communications objects do not support binary, it can be necessary to encode the binary into a form that the communication elements can support. In one embodiment, binary data can be encoded and decoded using uuencode, but in other embodiments other methods can be used.

If at block816the response package does not required decoding, then the process goes to block820, where it transmits the response package to the local service object. Otherwise, if the response package payload does require encoding for transmission, it proceeds to block818, where it encodes the payload, and then proceeds to block820where it transmits the encoded response package to the communication object with which it is coupled by a communication path.

FIG. 9illustrates an embodiment of a process for a remote service object such as object210(seeFIG. 2). The process starts at block902. At block904, the request package is received from a communication object such as object208. At block906, the remote service object reads the first tag in the request package and at block908it determines whether the tag refers to a target object that is in its namespace (i.e., with which it can communicate). If the target object is not in its namespace, then at block910it returns an error, but if the target object is in its namespace then the process proceeds to block912, where the remote service object transmits the command to the target object.

After block912, the remote service object is finished with processing the first command, so at block914it waits to receive a response to the first command. The remote service object does not necessarily enter a wait state where it can do nothing else until it receives a response; it is entirely possible for the remote service object to be able to process responses from other target objects packages while waiting for responses to previous commands. At block916, the local service object checks whether a response has been received. If no response has been received it returns to block914, but if a response has been received it proceeds to block918where it writes the response from the target object into a response package.

At block920, the process checks whether the request package has any further tags for the same target object or for another target object. If the request package has more tags, the process returns to block908and goes through the process again with the next tag. If the request package has no further tags, then the response package is closed at block922and at block924the response package is transmitted to the communication object.

FIG. 10illustrate an embodiment of a process1000for a target object such as target objects212and/or214(seeFIG. 2). The process starts at block1002. At block1004, the target object receives a tag from the remote service object and at block1006it reads the command in the tag. At step1008the target object executes the command and at block1010is sends the result to the remote service object so that it can be included in the response package. At block1012the process checks whether there are any more tags with commands to be executed. If there is not, then the process ends at block1018. If there are more tags with commands to be executed, then at block1014the next command is read and at block1016it is executed, and at block1010the result is sent to the remote service object.

FIGS. 11A-11Cillustrate different embodiments of response packages that can be produced by target object, in this case a target object named “vscape” (see, e.g.,FIG. 2).FIG. 11Aillustrates a response package that responds to a “gettree” command received from an origin object. The response package includes a header, in this case the “mixl” and “response” tags, along with a payload that displays the tree—that is, the steps and datums within object vscape. In this response package, both the header and the payload are in XML format, so this response package would require no encoding or decoding for transmission.

FIG. 11Billustrates an embodiment of a response package with a payload that includes binary data. Binary data can be written to a response package without uuencoding using the BinaryTag helper class of objects. The assumption here is that a <get> had been done on a binary field named “mybin.” This is very similar to the logic to handle a normal <get>, but a BinaryTag was used instead of Tag. The second parameter to the BinaryTag constructor should be a GUID (Globally Unique Identifier) to ensure an unambiguous interpretation of the binary information.

FIG. 11Cillustrates an embodiment of a response package that includes graphics in the payload. Graphics can be represented by tags conforming to SVG, which is a language for describing two-dimensional graphics and graphical applications in XML. The specification is maintained by w3.org at http://www.w3.org/Graphics/SVG.

FIG. 12illustrates an embodiment of an object1200. In cases where an object does not used the standard command language used in the request package as its native language, it can be necessary to modify the object. Object1200illustrates an object1202that has been “wrapped” in additional code1204to make its command structure compatible with the standard command language. Additional code1204can be added to object1202by incorporating a header in at the beginning of the code of object1202. In effect, additional code1204makes object1202derive from a base class of objects that understand the standard command language and can “translate” between the standard command language and the native command language of object1202. In one embodiment, additional code1204can be a lightweight schema that wraps the existing schema of object1202, but in other embodiments additional code1204can perform other or additional functions. In operation, then, object1200receive a tag from a request package and object1202and additional code1204work together to process the tag and provide a response. In cases where object1202already understands the standard command language, object1202need not be wrapped with additional code1204.

The above description of illustrated embodiments of the invention, including what is described in the abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description.