Patent Application
20080175268
The present invention generally relates to the field of computer software, and particularly to a method to provide interoperability of different version protocols.
In a distributed system, processes communicate via a common protocol. As the protocol evolves, processes are upgraded to make use of a new protocol. However, upgrading a process is not always desirable because upgrading may cause inherent instabilities among processes. Further, upgrading of all processes in a distributed system may incur unnecessary cost. As a result, it is common that some processes are upgraded and some are not in a distributed system. When an upgraded process and an un-upgraded process communicate with each other, the upgraded process may need to tolerate the protocol used by the un-upgraded process.
Conventionally, a version number of protocol has been exchanged between two processes before they start communicating. As such, each process has prior knowledge of the protocol version being used by other processes. In order to maintain interoperability between upgraded and un-upgraded processes, protocol source codes are often changed. For example, the serialization/de-serialization code of the upgraded process may be changed in order to send and receive data in the old protocol format employed by the un-upgraded process. However, this approach assumes that there is ready access to the source code that performs serialization. This is not always true. For example, protocols that use the JAVA serialization may allow compatible changes in the in-memory representation of the data being transferred. In the JAVA environment, an extension mechanism may allow a user to write program codes to handle portions of the serialization/de-serialization. Sometimes, the changes are so incompatible as to violate the assumptions built into Java serialization, including the extension mechanism. In such a case, there is no easy means to preserve compatibility. One way to preserve compatibility may be to change the Java serialization itself in the upgrade process, which is usually not possible. Another way is to upgrade all processes, which may not be practical for reasons described earlier.
Therefore, it would be desirable to provide a method and system to preserve interoperability among processes with different version protocols. It would be also desirable to provide a method and system to provide interoperability among processes without access to protocol specific source code.
Accordingly, the present invention provides a method and system to preserve interoperability through transformation of in-memory representation of different versions of the same data without modifying the previous version protocol source code.
In a first aspect of the present invention, a method of preserving interoperability between a first process with a first protocol and a second process with a second protocol is provided. The second protocol is an upgraded version of the first protocol and the second process is capable of processing both an updated data format and an un-updated data format. When the second process receives data from the first process, the first protocol may be utilized to de-serialize the data. Then, the data may be converted into in-memory presentation of the un-updated data format. The converted data may be transformed into in-memory representation of the updated data format suitable for being understood by the second process. In this manner, the interoperability of the un-updated protocol can be preserved without requiring accessing a protocol source code.
In a further aspect of the present invention, a method of preserving interoperability between a first process and a second process when the second process sends data to the first process is provided. The second protocol is an upgraded version of the first protocol and the second process may be capable of processing both updated data format and un-updated data format. Further, the second process may be capable of transforming between in-memory representation of both an un-upgraded data format and an upgraded data format. The second process may transform in-memory representation of the data from the upgraded data format to the un-upgraded data format. The first protocol may be utilized to serialize the in-memory representation of the data. During serialization, the in-memory representation of the un-upgraded format data may be converted into a proper data structure for the first protocol. The converted data may be sent to the first process. As such, the interoperability of the first process may be preserved.
In an advantageous aspect of the present invention, all processes in a distributed system may not have to be upgraded in order to communicate with each other. Further, the upgraded process may not have to change its protocol source code to accommodate un-upgraded protocol.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed. The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate an embodiment of the invention and together with the general description, serve to explain the principles of the invention.
The numerous advantages of the present invention may be better understood by those skilled in the art by reference to the accompanying figures in which:
Reference will now be made in detail to the presently preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings.
The present invention is directed to a method and system to preserve interoperability among processes in a distributed system through transformation of in-memory representation of different versions of the same data. The present invention does not require modifying the previous version or the current version protocol source code. In the following description, numerous specific descriptions are set forth in order to provide a thorough understanding of the present invention. It should be appreciated by those skilled in the art that the present invention may be practiced without some or all of these specific details. In some instances, well known process operations have not been described in detail in order not to obscure the present invention.
Referring generally now to
Referring to
In Step 102, an upgraded process may receive data from un-upgraded process. It is to be noted that the upgraded process may have means to determine a version number of the protocol that the un-upgraded process currently utilizes. There are various ways to provide version information of protocol to other processes. For example, the version information may be sent in a header, service context, or the like. The version information may be sent separately from the actual data being sent. If the actual data is divided into logical chunks, such as object boundaries in an object oriented system, the version information may be associated with each logical chunk of the data. In a particular embodiment of the present invention, a default version number may be assumed, if no version information is provided from the un-upgraded process. In Step 104, the upgraded process may utilize an old version protocol (un-upgraded protocol) to de-serialize the received data. The old version protocol has been determined by the version information.
Generally, de-serialization/serialization of data involves restructuring of the data. Serialization involves taking a data structure or object and encoding it into a regular and usually architecture-independent form, suitable for archival to a file, piping to another application, or, by extension, transmission across a network. Usually, the encoding takes the form of a byte stream (a sequence of bytes). When receiving a serialized stream of data, the encoding process may be reversed to get a copy of the original data structure. This is a de-serialization process. It should be appreciated by those skilled in the art that architecture independence must be maintained for serialization and de-serialization. Serializing the data structure in an architecture independent format may resolve the problems of byte ordering, memory layout, or simply different ways of representing data structures in different programming languages.
In Step 106, the data may be converted into an in-memory representation of the old data format (un-upgraded protocol format). Typically, when data is exchanged between processes, the received data may be parsed so that the content of the data is available in some form (e.g. in-memory representation form) for a process to manipulate. For example, when an XML (eXtensible Markup Language) Editor application receives an XML document, a parsing step may be required before the XML document is able to be processed by the XML Editor application. In some instances, Document Object Model (DOM) interface may be utilized to parse the XML document. The DOM interface is a programming interface specification developed by the World Wide Web Consortium (W3C), which parses an entire XML document and constructs a complete in-memory representation of the document using the classes modeling. After the DOM of the XML document is generated, the XML Editor may be able to display XML pages on the user's computer monitor. It is also well known to the art that parsing an XML document (representation) into an equivalent data structure suitable for being manipulated by an application is often called de-serialization, or un-marshalling. Similarly, writing a data structure to an equivalent XML representation is often called serialization or marshalling.
It is to be noted that the upgraded process is capable of processing the in-memory representation of both the un-upgraded protocol format and the upgraded protocol format. For example, in JAVA, Step 106 may be done by loading old classes and new classes through different class loaders that are not associated with each other. The old and new classes may be incompatible but have the same package and class name. In a particular embodiment of the present invention, the old and new classes may co-exist in the upgraded process. Each of the classes may have different in-memory representation. In Step 108, the in-memory representation of the old format (un-upgraded protocol format) data may be transformed into in-memory representation of the new format (upgraded protocol format) data. It is to be noted that the upgraded process comprises a means to transform between the in-memory representation of the un-upgraded protocol and the in-memory representation of the upgraded protocol. For example, in the JAVA environment, Step 108 may be done by using reflection to call methods to convert between the old and the new classes. In such a case, a change the in-memory representation of either the un-upgraded protocol or upgraded protocol to preserve JAVA serialization compatibility is not necessary.
Referring to
Referring now to
Referring now to
In the exemplary embodiments, the methods disclosed may be implemented as sets of instructions or software readable by a device. Further, it is understood that the specific order or hierarchy of steps in the methods disclosed are examples of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the method can be rearranged while remaining within the scope and spirit of the present invention. The accompanying method claims present elements of the various steps in a sample order, and are not necessarily meant to be limited to the specific order or hierarchy presented.
It is believed that the method and system of the present invention and many of its attendant advantages will be understood by the forgoing description. It is also believed that it will be apparent that various changes may be made in the form, construction and arrangement of the components thereof without departing from the scope and spirit of the invention or without sacrificing all of its material advantages. The form herein before described being merely an explanatory embodiment thereof, it is the intention of the following claims to encompass and include such changes.
The present application is a continuation of U.S. application Ser. No. 11/002,698 filed Dec. 2, 2004. Said U.S. application Ser. No. 11/002,698 is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11002698 | Dec 2004 | US |
| Child | 12055128 | US |
