US20090064126A1 - Versioning compatibility - Google Patents

Versioning compatibility Download PDF

Info

Publication number
US20090064126A1
US20090064126A1 US11/897,632 US89763207A US2009064126A1 US 20090064126 A1 US20090064126 A1 US 20090064126A1 US 89763207 A US89763207 A US 89763207A US 2009064126 A1 US2009064126 A1 US 2009064126A1
Authority
US
United States
Prior art keywords
client
server
remoting
remote access
access application
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
US11/897,632
Other versions
US10120733B2 (en
Inventor
Thomas Mitchell Elord
Ron Sigal
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Red Hat Inc
Original Assignee
Red Hat Inc
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 Red Hat Inc filed Critical Red Hat Inc
Priority to US11/897,632 priority Critical patent/US10120733B2/en
Assigned to RED HAT, INC. reassignment RED HAT, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ELROD, THOMAS MITCHELL, SIGAL, RON
Publication of US20090064126A1 publication Critical patent/US20090064126A1/en
Application granted granted Critical
Publication of US10120733B2 publication Critical patent/US10120733B2/en
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/541Interprogram communication via adapters, e.g. between incompatible applications

Abstract

A remoting client and a remoting server are described. In one embodiment, the remoting client has a client remote access application, a client invoker, a marshaller, and an unmarhaller. The client remote access application provides a version indicator of the client remote access application and receives a version indicator of a server remote access application. The client invoker generates an invocation request including the version indicator of the client remote access application. The client remote access application determines a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.

Description

    TECHNICAL FIELD
  • Embodiments of the present invention relate to network communication, and more specifically to network based invocations.
  • BACKGROUND
  • Remote procedure calls (RPC) allow a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. That is, the programmer would write essentially the same code whether the subroutine is local to the executing program, or remote. When the software is written using object-oriented principles, RPC may also be referred to as remote invocation or remote method invocation.
  • Current Remote or Remoting method invocations include, for example, RMI, EJB, and web services. The Java Remote Method Invocation API, or Java RMI, is a Java application programming interface for performing the object equivalent of remote procedure calls.
  • There are two common implementations of the API. The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another. The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP). In order to support code running in a non-JVM context, a CORBA version was later developed. RMI may refer to the programming interface or may signify both the API and JRMP, whereas the term RMI-IIOP, read RMI over IIOP, denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation.
  • The original RMI API was generalized somewhat to support different implementations, such as an HTTP transport. Additionally, work was done to CORBA, adding a pass by value capability, to support the RMI interface. Still, the RMI-IIOP and JRMP implementations are not fully identical in their interfaces.
  • However, a client-side agent may have difficulty communicating using an application version different from the application version of the server-side agent. A need therefore exists for an apparatus and a method to assure versioning compatibility between the remoting client and the remoting server.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:
  • FIG. 1 illustrates a network architecture in which embodiments of the present invention may be implemented.
  • FIG. 2 illustrates a block diagram of one embodiment of a remoting client.
  • FIG. 3 illustrates a block diagram of one embodiment of a remoting server.
  • FIG. 4 illustrates a block diagram of another embodiment of a network architecture.
  • FIG. 5 illustrates a block diagram of an exemplary computer system.
  • FIG. 6 illustrates a flow diagram of one embodiment of a method for providing compatibility between a remoting client and a remoting server.
  • FIG. 7 illustrates a flow diagram of another embodiment of a method for providing compatibility between a remoting client and a remoting server.
  • DETAILED DESCRIPTION
  • Described herein is a method and apparatus for providing version compatibility of remoting applications between a remoting client and a remoting server. The remoting client and the remoting server exchange information containing an indicator of the version of their respective remote access application. A compatible version may be determined based on the exchanged information.
  • General Architecture
  • FIG. 1 illustrates an exemplary architecture 100 composed of a remoting client 102 coupled to a remoting server 104 via a network 106. A remoting framework with a single, simple application programming interface (API) for making network based invocations, remoting calls, and other network related services is described. An example of a remoting framework is described in JBoss Remoting. The purpose of JBoss Remoting is to provide a single API for most network based invocations and related service that uses pluggable transports and data marshallers. The JBoss Remoting API provides the ability for making synchronous and asynchronous remote calls, push and pull callbacks, and automatic discovery of remoting servers. The intention is to allow for the use of different transports to fit different needs, yet still maintain the same API for making the remote invocations and only requiring configuration changes, not code changes.
  • One important component of the JBoss Remoting architecture is how servers are identified. This is done via an InvokerLocator, which can be represented by a simple String with a URL based format (e.g., socket://myhost:5400). This is all that is required to either create a remoting server or to make a call on a remoting server. The remoting framework will then take the information embedded within the InvokerLocator and construct the underlying remoting components needed and build the full stack required for either making or receiving remote invocations.
  • Some exemplary features of JBoss Remoting include server identification, pluggable transports, pluggable data marshallers, automatic discovery, server grouping, callbacks, asynchronous calls, local invocation, remote classloading, and sending of streams. In server identification, a simple string identifier allows for remoting servers to be identified and called upon. In pluggable transports, different protocol transports can be used such as socket, rmi, http, etc., via the same remoting API. In pluggable data marshallers, different data marshallers and unmarshallers can be used to convert the invocation payloads into desired data format for wire transfer. In automatic detection, remoting servers can be detected as they come on and off line. Server grouping gives the ability to group servers by logical domains, so that servers can only communicate within specified domains. Server callbacks can be received via push and pull models. Pull model allows for persistent stores and memory management. Asynchronous or one way calls can be made to the server. If an invocation on a remoting server that is within the same process space, remoting will automatically make this call by reference, to improve performance. Remote classloading allows for classes, such as custom marshallers, that do not exist within client to be loaded from the server. Sending of streams allows for clients to send input streams to the server, which can be read on demand on the server.
  • There are several layers to this framework that mirror each other on the client and server side. The outermost layer is the one which the user interacts with—e.g. the remote access application. On the client side, this is the Client API 108 class upon which the user will make its calls. In other words, this can be the external API access point for client code. On the server side, this is the InvocationHandler 110, which is implemented by the user and is the ultimate receiver of invocation requests. Next is the transport, which is controlled by the invoker layers 112, 114. Finally, at the lowest layer are the Marshallers 116, 118 that convert data format to wire format and the UnMarshallers 120, 122 that convert wire format to data format.
  • When a user calls on the Client API 108 to make an invocation, it will pass this invocation request to the appropriate Client Invoker 112, based on the transport specified by the locator url. Client Invoker 112 will then use Marshaller 116 to convert the invocation request object to the proper data format to send over network 106 to Remoting Server 104.
  • On the server side, UnMarshaller 122 receives this data from the network 106, converts it back into a standard invocation request object, and sends it on to the Server Invoker 114. The Server Invoker 114 then passes this invocation request on to the user's implementation of the Invocation Handler 110. The response from Invocation Handler 110 passes back through Server Invoker 114 and on to Marshaller 118, which will then convert the invocation response object to the proper data format and send back to Remoting Client 102. UnMarshaller 120 on Remoting Client 102 converts the invocation response from wire data format into standard invocation response object, which will be passed back up through Client Invoker 112 and Client API 108 to the original caller.
  • Remoting Client
  • FIG. 2 illustrates a block diagram of one embodiment of a remoting client 200. For determining which client invoker to use, the Client API 202 will pass the InvokerRegistry 210 the locator for the target server it wishes to make invocations on. The InvokerRegistry 210 will return the appropriate client invoker instance based on information contained within the locator, such as transport type. The client invoker 204 will then call upon the MarshalFactory 212 to get the appropriate Marshaller 206 and UnMarshaller 208 for converting the invocation objects to the proper data format for wire transfer. All invokers have a default data type that can be used to get the proper marshal instances, but can be overridden within the locator specified.
  • Remoting Server
  • FIG. 3 illustrates a block diagram of one embodiment of a remoting server 300. On the server side, it is the Connector class 302 that is used as the external point for configuration and control of the remoting server 300. The Connector class 302 will call on the InvokerRegistry 304 with its locator to create a Server Invoker 306. Once the server invoker 306 is returned, Connector 302 then registers the invocation handlers 314 on it. Server Invoker 306 uses the MarshalFactory 308 to obtain the proper marshal instances, Marshaller 310, and UnMarshaller 312 as is done on the client side.
  • Detection
  • FIG. 4 illustrates a block diagram of another embodiment of a network architecture 400. To add automatic detection, a remoting Detector 402, 404 will need to be added on both the remoting client 410 and the remoting server 412. A Network Registry 406 is added to the remoting client 410. An Invoker Registry 408 is added to the remoting server 412.
  • When Detector 404 on the server side is created and started, it will periodically pull from the Invoker Registry 408 all the server invokers that it has created. The detector 404 will then use the information to publish a detection message containing the locator and subsystems supported by each server invoker. The publishing of this detection message may be either via a multicast broadcast or a binding into a JNDI server. On the client side, Detector 402 will either receive the multicast broadcast message or poll the JNDI server for detection messages. If Detector 402 determines a detection message is for a remoting server 412 that just came online, it will register it in the Network Registry 406. Network Registry 406 houses the detection information for all the discovered remoting servers. Network Registry 406 may also emit a JMX notification upon any change to this registry of remoting servers. The change to the Network Registry 406 can also be for when Detector 402 has discovered that a remoting server is no longer available and removes it from the registry.
  • Server Architecture
  • FIG. 5 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 500 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
  • The exemplary computer system 500 includes a processing device 502, a main memory 504 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), a static memory 506 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 518, which communicate with each other via a bus 530.
  • Processing device 502 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device 502 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 502 is configured to execute the processing logic 526 for performing the operations and steps discussed herein.
  • The computer system 500 may further include a network interface device 508. The computer system 500 also may include a video display unit 510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 512 (e.g., a keyboard), a cursor control device 514 (e.g., a mouse), and a signal generation device 516 (e.g., a speaker).
  • The data storage device 518 may include a machine-accessible storage medium 530 on which is stored one or more sets of instructions (e.g., software 522) embodying any one or more of the methodologies or functions described herein. The software 522 may also reside, completely or at least partially, within the main memory 504 and/or within the processing device 502 during execution thereof by the computer system 500, the main memory 504 and the processing device 502 also constituting machine-accessible storage media. The software 522 may further be transmitted or received over a network 520 via the network interface device 508.
  • The machine-accessible storage medium 530 may also be used to store versioning compatibility processes 524 as described above. The versioning compatibility 524 may also be stored in other sections of computer system 500, such as static memory 506.
  • While the machine-accessible storage medium 530 is shown in an exemplary embodiment to be a single medium, the term “machine-accessible storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-accessible storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-accessible storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
  • Versioning Compatibility
  • A versioning feature has been added to guarantee compatibility between different versions of the remote access applications of a remoting client and a remoting server. In one embodiment, wire versioning may be used to notify each party of the version used. In other words, the version used by a remoting client and a remoting server may be sent on the wire so that the other side will be able to adjust accordingly. In one embodiment, each remote access application may be configured to be backward compatible with a previous version so as to assure full compatibility guarantee. The remote access application may be configured to the requirements of jms, otherwise jms cannot rely on remoting for its stable transport layer. Although a specific wire format may not be a requirement, one should be able to take control of it. In the case of the http transport, one should be able to map a format version to a header, or first byte of the post content, etc.
  • In accordance with one embodiment, one implementation of the versioning compatibility of remote access application may be as follows. The ConnectionFactory object which is placed in the jndi tree by the server, contains the server's version S. The client knows it's own version C. When the client gets hold of a connection factory from jndi it now knows the server version. For any connections created using that connection factory, the client will use version X, where X is Math.min(S, C) to form some kind of handshake to agree on the lowest common denominator version performed once upon connection setup. This means a client can support many different versions concurrently for different connections depending on the server versions for the respective connection factories. In the marshaller, every invocation from client to server is prefixed on the wire by a byte containing the value X. Any response is also prefixed with the value X. This means that the entire wire format can evolve over time, this include the remote Java API, and the wire format of objects.
  • In one implementation, the version byte goes at the beginning of each request or response (it doesn't go in each TCP packet—a request/response can be composed of many such packets). This is so the server knows how to deal with the request (or the client with the response). Imagine in version 1.x we have a wireformat for a send request like the following:
  • byte 0: “23”—represents a send request
  • bytes 1 . . . serialized form of the message
  • and the format for an ack was:
  • byte 0: “27”—represents ack
  • bytes 1 . . . message id etc.
  • but in version 2.x we changed it to, for a send:
  • byte 0: “27” represents send
  • bytes 1 . . . serialized form of the message
  • Now a client sends a version 1.x send request to the server. All the server knows about is the stream of bytes it's receiving so if version info is not added to the stream then the server doesn't know whether the request is a version 1.x send or a version 2.x ack.
  • One could overcome this by fixing the request codes across all versions and just vary, say, the serialized form of the request body between versions, which would allow to avoid passing the version number. However, this would be far less flexible and prevent one from being able to change the remote API over time.
  • In accordance with one embodiment, the version byte is just an incrementing version number starting at zero. So for every new wireformat version to support, the version byte may be increased by one. If a release doesn't change the wireformat then the byte is not changed. This means up to 256 changes can be supported to the wireformat. Changes to the wireformat may be for major releases only. So this would be good for up to 256 major releases.
  • As for features, older features should be usable in future versions (so can use old clients with newer servers). However, newer clients won't necessarily work with older servers (at least the new features won't be supported by the server).
  • FIG. 6 illustrates a flow diagram of one embodiment of wire versioning from a client side. At 602, a version indicator of a client remote access application of the remoting client is provided to the remoting server. In one embodiment, an invocation request is formed with a client invoker of the remoting client by forming a socket connection with the client invoker. The invocation request is converted from an object format to a wire data format with a data marshaller of the remoting client for communication over a network to the remoting server. The invocation request may be prefixed with the version indicator of the client remote access application. At 604, the remoting client receives a communication from the remoting server. The communication includes a prefix including the version indicator of the server remote access application of the remoting server. The communication from the remoting server may be converted from a wire data format to an object format with a data unmarshaller of the remoting client. At 606, a compatible version between the client remote access application and the server remote access application is determined based on the version indicator of the client remote access application and the version indicator of the server remote access application. At 608, the client remote access application may adjust its version in response to the compatible version.
  • FIG. 7 illustrates a flow diagram of another embodiment of wire versioning from a server side. At 702, a remoting server receives a communication from the remoting client. The communication comprises a prefix including the version indicator of the client remote access application of the remoting client. The communication may be converted from a wire data format to an object format with a data unmarshaller of the remoting server.
  • At 704, a version indicator of a server remote access application of the remoting server is provided to the remoting client. In one embodiment, a response to the remoting client is generated by processing the response with a thread from an invocation handler of the remoting server. The server invoker of the remoting server processed the response. A data marshaller converts the response from an object format to a wire data format for communication over a network to the remoting client. The response may include a prefix including the version indicator of the server remote access application. At 706, a compatible version between the client remote access application and the server remote access application is determined based on the version indicator of the client remote access application and the version indicator of the server remote access application. At 708, the server remote access application may be adjusted its version in response to the compatible version.
  • In the above description, numerous details were set forth. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
  • Some portions of the detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
  • It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
  • The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
  • A machine-accessible storage medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-accessible storage medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).
  • Thus, a method and apparatus for providing compatibility between a remoting client and a remoting server has been described. It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (36)

1. A computer-implemented method for providing compatibility between a remoting client and a remoting server, the method comprising:
providing a version indicator of a client remote access application of the remoting client to the remoting server;
receiving a version indicator of a server remote access application of the remoting server; and
determining a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.
2. The method of claim 1 further comprising:
adjusting a version of the client remote access application in response to the compatible version.
3. The method of claim 1 further comprising:
forming an invocation request with a client invoker of the remoting client; and
converting the invocation request from an object format to a wire data format with a data marshaller of the remoting client for communication over a network to the remoting server.
4. The method of claim 3 further comprising:
prefixing the invocation request from the remoting client to the remoting server with the version indicator of the client remote access application.
5. The method of claim 3 wherein forming the invocation request further comprises:
forming a socket connection with the client invoker.
6. The method of claim 1 further comprising:
receiving a communication from the remoting server, the communication comprising a prefix including the version indicator of the server remote access application; and
converting the communication from a wire data format to an object format with a data unmarshaller of the remoting client.
7. A computer-implemented method for providing compatibility between a remoting client and a remoting server, the method comprising:
receiving a version indicator of a client remote access application of the remoting client;
providing a version indicator of a server remote access application of the remoting server to the remoting client; and
determining a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.
8. The method of claim 7 further comprising:
adjusting a version of the server remote access application in response to the compatible version.
9. The method of claim 7 further comprising:
generating a response to the remoting client with an invocation handler of the remoting server;
forming the response with a server invoker of the remoting server; and
converting the response from an object format to a wire data format with a data marshaller of the remoting server for communication over a network to the remoting client.
10. The method of claim 9 further comprising:
prefixing the response with the version indicator of the server remote access application.
11. The method of claim 9 wherein generating the response further comprises:
processing the response with a thread from the invocation handler.
12. The method of claim 7 further comprising:
receiving a communication from the remoting client, the communication comprising a prefix including the version indicator of the client remote access application; and
converting the communication from a wire data format to an object format with a data unmarshaller of the remoting server.
13. A remoting client comprising:
a client remote access application to provide a version indicator of the client remote access application of the remoting client and to receive a version indicator of a server remote access application of a remoting server;
a client invoker coupled to the client remote access application to generate an invocation request;
a marshaller coupled to the client invoker to convert the invocation request from an object format to a data format for communication over a network to the remoting server; and
an unmarshaller coupled to the client invoker to convert a communication from the remoting server from the data format to the object format,
wherein the client remote access application is to determine a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.
14. The remoting client of claim 13 wherein the remoting client is to adjust a version of the client remote access application in response to the compatible version.
15. The remoting client of claim 13 wherein the version indicator of the client remote access application of the remoting client is included in a prefix of the invocation request.
16. The remoting client of claim 13 wherein the client invoker is to further form a socket connection.
17. The remoting client of claim 13 wherein the remoting client is to receive a communication from the remoting server, the communication comprising a prefix including the version indicator of the server remote access application.
18. The remote client of claim 13 wherein the client remote access application comprises an application programming interface (API).
19. A remoting server comprising:
a server remote access application to generate a response to an invocation request from a remoting client, the response comprising a version indicator of the server remote access application, the invocation request comprising a version indicator of a client remote access application of the remoting client;
a server invoker coupled to the server remote access application to receive the invocation request;
an unmarshaller coupled to the server invoker to convert the invocation request from a data format to an object format; and
a marshaller coupled to the server invoker to convert the response from an object format to a data format for communication over a network to the remoting client,
wherein the server remote access application is to determine a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.
20. The remoting server of claim 19 wherein the remoting server is to adjust a version of the server remote access application in response to the compatible version.
21. The remoting server of claim 19 wherein the version indicator of the server remote access application is included in a prefix of the response.
22. The remoting server of claim 19 wherein the server invoker is to process the response with a thread from an invocation handler.
23. The remoting server of claim 19 wherein the invocation request comprises a prefix including the version indicator of the client remote access application.
24. The remoting server of claim 19 wherein the server remote access application comprises an invocation handler.
25. An article of manufacture comprising:
a machine-accessible storage medium including data that, when accessed by a machine, cause the machine to perform a method comprising:
providing a version indicator of a client remote access application of a remoting client to the remoting server;
receiving a version indicator of a server remote access application of a remoting server; and
determining a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.
26. The article of manufacture of claim 25 wherein the method further comprises:
adjusting a version of the client remote access application in response to the compatible version.
27. The article of manufacture of claim 25 wherein the method further comprises:
forming an invocation request with a client invoker of the remoting client; and
converting the invocation request from an object format to a wire data format with a data marshaller of the remoting client for communication over a network to the remoting server.
28. The article of manufacture of claim 27 wherein the method further comprises:
prefixing the invocation request from the remoting client to the remoting server with the version indicator of the client remote access application.
29. The article of manufacture of claim 27 wherein forming the invocation request further comprises:
forming a socket connection with the client invoker.
30. The article of manufacture of claim 25 wherein the method further comprises:
receiving a communication from the remoting server, the communication comprising a prefix including the version indicator of the server remote access application; and
converting the communication from a wire data format to an object format with a data unmarshaller of the remoting client.
31. An article of manufacture comprising:
a machine-accessible storage medium including data that, when accessed by a machine, cause the machine to perform a method comprising:
receiving a version indicator of a client remote access application of a remoting client;
providing a version indicator of a server remote access application of a remoting server to the remoting client; and
determining a compatible version between the client remote access application and the server remote access application based on the version indicator of the client remote access application and the version indicator of the server remote access application.
32. The article of manufacture of claim 31 wherein the method further comprises:
adjusting a version of the server remote access application in response to the compatible version.
33. The article of manufacture of claim 31 wherein the method further comprises:
generating a response to the remoting client with an invocation handler of the remoting server;
forming the response with a server invoker of the remoting server; and
converting the response from an object format to a wire data format with a data marshaller of the remoting server for communication over a network to the remoting client.
34. The article of manufacture of claim 33 wherein the method further comprises:
prefixing the response with the version indicator of the server remote access application.
35. The article of manufacture of claim 33 wherein generating the response further comprises:
processing the response with a thread from the invocation handler.
36. The article of manufacture of claim 31 wherein the method further comprises:
receiving a communication from the remoting client, the communication comprising a prefix including the version indicator of the client remote access application; and
converting the communication from a wire data format to an object format with a data unmarshaller of the remoting server.
US11/897,632 2007-08-30 2007-08-30 Remote procedure call supporting multiple versions Active 2031-07-25 US10120733B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/897,632 US10120733B2 (en) 2007-08-30 2007-08-30 Remote procedure call supporting multiple versions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/897,632 US10120733B2 (en) 2007-08-30 2007-08-30 Remote procedure call supporting multiple versions

Publications (2)

Publication Number Publication Date
US20090064126A1 true US20090064126A1 (en) 2009-03-05
US10120733B2 US10120733B2 (en) 2018-11-06

Family

ID=40409549

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/897,632 Active 2031-07-25 US10120733B2 (en) 2007-08-30 2007-08-30 Remote procedure call supporting multiple versions

Country Status (1)

Country Link
US (1) US10120733B2 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090024991A1 (en) * 2007-07-16 2009-01-22 International Business Machines Corporation Method, system and program product for managing download requests received to download files from a server
US20090064208A1 (en) * 2007-08-30 2009-03-05 Thomas Mitchell Elrod SSL socket builder
US20120246614A1 (en) * 2011-03-23 2012-09-27 Microsoft Corporation Automated generation of client/driver communication interfaces
US20140282468A1 (en) * 2013-03-15 2014-09-18 Microsoft Corporation Local store data versioning

Citations (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5630135A (en) * 1993-06-04 1997-05-13 Hitachi, Ltd. Multiple-execution method of multiple-version programs and computer system therefor
US5682534A (en) * 1995-09-12 1997-10-28 International Business Machines Corporation Transparent local RPC optimization
US5872973A (en) * 1995-10-26 1999-02-16 Viewsoft, Inc. Method for managing dynamic relations between objects in dynamic object-oriented languages
US5913027A (en) * 1996-07-02 1999-06-15 Hitachi, Ltd. Data processing method for a computer system including computers connected via a communication path to each other and computer-readable recording media for use with the computers
US5915112A (en) * 1996-01-02 1999-06-22 International Business Machines Corporation Remote procedure interface with support for multiple versions
US5926636A (en) * 1996-02-21 1999-07-20 Adaptec, Inc. Remote procedural call component management method for a heterogeneous computer network
US20010056505A1 (en) * 2000-03-29 2001-12-27 Massoud Alibakhsh System and method for providing look ahead socket generation
US20020078262A1 (en) * 2000-12-14 2002-06-20 Curl Corporation System and methods for providing compatibility across multiple versions of a software system
US6477586B1 (en) * 1998-06-29 2002-11-05 International Business Machines Corporation Remote procedure calls in distributed systems
US6496871B1 (en) * 1998-06-30 2002-12-17 Nec Research Institute, Inc. Distributed agent software system and method having enhanced process mobility and communication in a computer network
US20030145315A1 (en) * 2002-01-23 2003-07-31 Tuomo Aro Exchange of data between components of distributed software having different versions of software
US6622302B1 (en) * 2000-06-30 2003-09-16 Lsi Logic Corporation Methods and apparatus for dynamic version transition of management applications and attached subsystems
US6658659B2 (en) * 1999-12-16 2003-12-02 Cisco Technology, Inc. Compatible version module loading
US20040003085A1 (en) * 2002-06-26 2004-01-01 Joseph Paul G. Active application socket management
US20040045012A1 (en) * 2002-08-30 2004-03-04 Sun Microsystems, Inc. Barrier mechanism for firmware upgrade
US20040088349A1 (en) * 2002-10-30 2004-05-06 Andre Beck Method and apparatus for providing anonymity to end-users in web transactions
US20040133644A1 (en) * 2003-01-03 2004-07-08 Microsoft Corporation System and method for improved synchronization between a server and a client
US20040172462A1 (en) * 2003-02-28 2004-09-02 Iterum Skef F. Supporting interactions between different versions of software for accessing remote objects
US6826750B1 (en) * 2000-03-23 2004-11-30 International Business Machines Corporation Method of automatically selecting program and data updates based upon versions
US6868425B1 (en) * 1999-03-05 2005-03-15 Microsoft Corporation Versions and workspaces in an object repository
US6993759B2 (en) * 1999-10-05 2006-01-31 Borland Software Corporation Diagrammatic control of software in a version control system
US6996817B2 (en) * 2001-12-12 2006-02-07 Valve Corporation Method and system for upgrading and rolling back versions
US7043735B2 (en) * 2000-06-08 2006-05-09 Hitachi, Ltd. System and method to dynamically select and locate server objects based on version information of the server objects
US20060195834A1 (en) * 2005-02-25 2006-08-31 Microsoft Corporation Method and system for availability checking on distributed objects
US7107594B1 (en) * 2002-06-27 2006-09-12 Siebel Systems, Inc. Method and system for providing a version-independent interface to a computer resource
US7120652B2 (en) * 2002-04-25 2006-10-10 Sun Microsystems, Inc. Method, system and program for determining version of storage devices and programs indicated in the resource information installed in the computer system
US7140012B2 (en) * 2001-03-09 2006-11-21 Bea Systems, Inc. Method and apparatus for multi-version updates of application services
US7260818B1 (en) * 2003-05-29 2007-08-21 Sun Microsystems, Inc. System and method for managing software version upgrades in a networked computer system
US20070220507A1 (en) * 2006-03-20 2007-09-20 Microsoft Corporation Managing version information for software components
US7466659B1 (en) * 2005-04-29 2008-12-16 Network Appliance, Inc. System and method for performing version negotiation of a network protocol and associated interfaces
US20090064208A1 (en) * 2007-08-30 2009-03-05 Thomas Mitchell Elrod SSL socket builder
US7506334B2 (en) * 2005-02-25 2009-03-17 Microsoft Corporation Common, multi-version interface that allows a distributed sybsystem to communicate with multiple versions of the distributed subsystem
US7519950B2 (en) * 2005-02-25 2009-04-14 Microsoft Corporation Method and system for version negotiation of distributed objects
US7600219B2 (en) * 2003-12-10 2009-10-06 Sap Ag Method and system to monitor software interface updates and assess backward compatibility
US7610316B2 (en) * 2000-11-21 2009-10-27 Microsoft Corporation Extensible architecture for versioning APIs
US7653914B2 (en) * 2001-04-23 2010-01-26 Nokia Corporation Handling different service versions in a server

Patent Citations (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5630135A (en) * 1993-06-04 1997-05-13 Hitachi, Ltd. Multiple-execution method of multiple-version programs and computer system therefor
US5682534A (en) * 1995-09-12 1997-10-28 International Business Machines Corporation Transparent local RPC optimization
US5872973A (en) * 1995-10-26 1999-02-16 Viewsoft, Inc. Method for managing dynamic relations between objects in dynamic object-oriented languages
US5915112A (en) * 1996-01-02 1999-06-22 International Business Machines Corporation Remote procedure interface with support for multiple versions
US6493768B1 (en) * 1996-01-02 2002-12-10 International Business Machines Corporation Remote procedure interface with support for multiple versions
US5926636A (en) * 1996-02-21 1999-07-20 Adaptec, Inc. Remote procedural call component management method for a heterogeneous computer network
US5913027A (en) * 1996-07-02 1999-06-15 Hitachi, Ltd. Data processing method for a computer system including computers connected via a communication path to each other and computer-readable recording media for use with the computers
US6477586B1 (en) * 1998-06-29 2002-11-05 International Business Machines Corporation Remote procedure calls in distributed systems
US6496871B1 (en) * 1998-06-30 2002-12-17 Nec Research Institute, Inc. Distributed agent software system and method having enhanced process mobility and communication in a computer network
US7593958B2 (en) * 1999-03-05 2009-09-22 Microsoft Corporation Versions and workspaces in an object repository
US6868425B1 (en) * 1999-03-05 2005-03-15 Microsoft Corporation Versions and workspaces in an object repository
US6993759B2 (en) * 1999-10-05 2006-01-31 Borland Software Corporation Diagrammatic control of software in a version control system
US6658659B2 (en) * 1999-12-16 2003-12-02 Cisco Technology, Inc. Compatible version module loading
US6826750B1 (en) * 2000-03-23 2004-11-30 International Business Machines Corporation Method of automatically selecting program and data updates based upon versions
US20010056505A1 (en) * 2000-03-29 2001-12-27 Massoud Alibakhsh System and method for providing look ahead socket generation
US7043735B2 (en) * 2000-06-08 2006-05-09 Hitachi, Ltd. System and method to dynamically select and locate server objects based on version information of the server objects
US6622302B1 (en) * 2000-06-30 2003-09-16 Lsi Logic Corporation Methods and apparatus for dynamic version transition of management applications and attached subsystems
US7610316B2 (en) * 2000-11-21 2009-10-27 Microsoft Corporation Extensible architecture for versioning APIs
US20020078262A1 (en) * 2000-12-14 2002-06-20 Curl Corporation System and methods for providing compatibility across multiple versions of a software system
US7140012B2 (en) * 2001-03-09 2006-11-21 Bea Systems, Inc. Method and apparatus for multi-version updates of application services
US7653914B2 (en) * 2001-04-23 2010-01-26 Nokia Corporation Handling different service versions in a server
US6996817B2 (en) * 2001-12-12 2006-02-07 Valve Corporation Method and system for upgrading and rolling back versions
US20030145315A1 (en) * 2002-01-23 2003-07-31 Tuomo Aro Exchange of data between components of distributed software having different versions of software
US7120652B2 (en) * 2002-04-25 2006-10-10 Sun Microsystems, Inc. Method, system and program for determining version of storage devices and programs indicated in the resource information installed in the computer system
US20040003085A1 (en) * 2002-06-26 2004-01-01 Joseph Paul G. Active application socket management
US7107594B1 (en) * 2002-06-27 2006-09-12 Siebel Systems, Inc. Method and system for providing a version-independent interface to a computer resource
US20040045012A1 (en) * 2002-08-30 2004-03-04 Sun Microsystems, Inc. Barrier mechanism for firmware upgrade
US20040088349A1 (en) * 2002-10-30 2004-05-06 Andre Beck Method and apparatus for providing anonymity to end-users in web transactions
US20040133644A1 (en) * 2003-01-03 2004-07-08 Microsoft Corporation System and method for improved synchronization between a server and a client
US20040172462A1 (en) * 2003-02-28 2004-09-02 Iterum Skef F. Supporting interactions between different versions of software for accessing remote objects
US7055147B2 (en) * 2003-02-28 2006-05-30 Sun Microsystems, Inc. Supporting interactions between different versions of software for accessing remote objects
US7260818B1 (en) * 2003-05-29 2007-08-21 Sun Microsystems, Inc. System and method for managing software version upgrades in a networked computer system
US7600219B2 (en) * 2003-12-10 2009-10-06 Sap Ag Method and system to monitor software interface updates and assess backward compatibility
US20060195834A1 (en) * 2005-02-25 2006-08-31 Microsoft Corporation Method and system for availability checking on distributed objects
US7519950B2 (en) * 2005-02-25 2009-04-14 Microsoft Corporation Method and system for version negotiation of distributed objects
US7506334B2 (en) * 2005-02-25 2009-03-17 Microsoft Corporation Common, multi-version interface that allows a distributed sybsystem to communicate with multiple versions of the distributed subsystem
US7466659B1 (en) * 2005-04-29 2008-12-16 Network Appliance, Inc. System and method for performing version negotiation of a network protocol and associated interfaces
US20070220507A1 (en) * 2006-03-20 2007-09-20 Microsoft Corporation Managing version information for software components
US20090064208A1 (en) * 2007-08-30 2009-03-05 Thomas Mitchell Elrod SSL socket builder

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090024991A1 (en) * 2007-07-16 2009-01-22 International Business Machines Corporation Method, system and program product for managing download requests received to download files from a server
US9876847B2 (en) 2007-07-16 2018-01-23 International Business Machines Corporation Managing download requests received to download files from a server
US8347286B2 (en) * 2007-07-16 2013-01-01 International Business Machines Corporation Method, system and program product for managing download requests received to download files from a server
US9106627B2 (en) 2007-07-16 2015-08-11 International Business Machines Corporation Method, system and program product for managing download requests received to download files from a server
US20090064208A1 (en) * 2007-08-30 2009-03-05 Thomas Mitchell Elrod SSL socket builder
US8683428B2 (en) * 2011-03-23 2014-03-25 Microsoft Corporation Automated generation of client/driver communication interfaces
US20120246614A1 (en) * 2011-03-23 2012-09-27 Microsoft Corporation Automated generation of client/driver communication interfaces
US20140282468A1 (en) * 2013-03-15 2014-09-18 Microsoft Corporation Local store data versioning
US9229701B2 (en) * 2013-03-15 2016-01-05 Microsoft Technology Licensing, Llc Local store data versioning

Also Published As

Publication number Publication date
US10120733B2 (en) 2018-11-06

Similar Documents

Publication Publication Date Title
Stal Web services: beyond component-based computing
EP0767563B1 (en) Method and apparatus for multiprotocol operation in a client/server system
US6643650B1 (en) Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US7356562B2 (en) Dynamic generator for fast-client static proxy from service interface definition document
US6385643B1 (en) Clustered enterprise Java™ having a message passing kernel in a distributed processing system
US7702795B2 (en) Peer networking host framework and hosting API
US8412768B2 (en) Integration gateway
US7693955B2 (en) System and method for deploying a web service
US6347342B1 (en) Method and apparatus for dynamically brokering object messages among object models
EP1322084B1 (en) Scaling and delivering distributed applications
US6918084B1 (en) Spawning new repository spaces using information provided in advertisement schema messages
US7769825B2 (en) System and method for web services Java API-based invocation
Segall et al. Content based routing with elvin4
AU2002240200B2 (en) A digital television application protocol for interactive television
US20020087657A1 (en) Stateless distributed computer architecture with server-oriented state-caching objects maintained on network or client
US20030105800A1 (en) Dynamically routing messages between software application programs using named routing nodes and named message queues
US20080177872A1 (en) Managing aggregation and sending of communications
US20040001514A1 (en) Remote services system communication module
US20050080930A1 (en) Method and apparatus for processing service requests in a service-oriented architecture
US20100257539A1 (en) System, method and apparatus for providing functions to applications on a digital electronic device
US8301687B2 (en) Systems and/or methods for standards-based messaging
CN100428117C (en) Method and apparatus for providing multi-client support in a SIP-enabled terminal
US20020073158A1 (en) Method and system for general-purpose interactive notifications
US7296072B2 (en) Enhanced port type agnostic proxy support for web services intermediaries
US6247068B1 (en) Winsock-data link library transcoder

Legal Events

Date Code Title Description
AS Assignment

Owner name: RED HAT, INC., NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ELROD, THOMAS MITCHELL;SIGAL, RON;REEL/FRAME:019807/0686;SIGNING DATES FROM 20070828 TO 20070829

Owner name: RED HAT, INC., NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ELROD, THOMAS MITCHELL;SIGAL, RON;SIGNING DATES FROM 20070828 TO 20070829;REEL/FRAME:019807/0686

STCF Information on status: patent grant

Free format text: PATENTED CASE