Invocation of additional processing using remote procedure calls

FIELD

The present disclosure relates generally to inter-process communication. In one example embodiment, the disclosure relates to the invocation of additional processing using remote procedure calls.

BACKGROUND

A remote procedure call (RPC) is a protocol that a program can use to request a service from a program located in another computing device on a shared network without a programmer explicitly coding details for this remote interaction. That is, RPC is an inter-process communication mechanism that enables data exchange and invocation of functionality residing in a different process. With RPC enabled, the programmer writes essentially the same code whether the subroutine is remote or local to the executing program.

RPC is especially well suited for client-server interaction where a requesting program is a client and a service-providing program is a server. The client can initiate an RPC by transmitting a request message to a remote server to execute a function with supplied parameters. In turn, the remote server can transmit a response to the client as a result of the execution of the requested function.

In standard RPC, the functions provided by a standard client run-time library have fixed application programming interfaces that require strict contracts for implementation. Particularly, other than the processing needed to move data to and from a client, a remote server cannot perform additional processing other than the processing resulting from the execution of the requested function. As a result, many existing RPC protocols cannot be integrated into, for example, existing enterprise systems that provide many different or additional functionalities that are not supported by standard RPC protocols.

BRIEF DESCRIPTION OF DRAWINGS

The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a block architectural diagram depicting an enterprise system, in accordance with an example embodiment, that can invoke additional processing using remote procedure calls;

<figref idref="DRAWINGS">FIG. 2</figref> depicts a block diagram of modules, in accordance with an embodiment, that may be included in one or more of the client computing devices depicted in <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 3</figref> depicts a block diagram of modules, in accordance with an embodiment, that may be included in the server computing device depicted in <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> depicts a flow diagram of a general overview of a method at, for example, the client computing device depicted in <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, for invoking additional processing using RPC, in accordance with an example embodiment;

<figref idref="DRAWINGS">FIG. 5</figref> depicts a flow diagram of a general overview of a method at, for example, the server computing device depicted in <figref idref="DRAWINGS">FIGS. 1 and 3</figref>, for processing RPCs at a server computing device, in accordance with an example embodiment;

<figref idref="DRAWINGS">FIG. 6</figref> depicts a timing diagram illustrating the transmittal of messages between the modules depicted in <figref idref="DRAWINGS">FIGS. 2 and 3</figref> to invoke additional processing at a server computing device, in accordance with an example embodiment;

<figref idref="DRAWINGS">FIG. 7</figref> depicts a flow diagram of a general overview of a method for invoking a type of additional processing, as generally described in <figref idref="DRAWINGS">FIG. 5</figref>, in accordance with an example embodiment;

<figref idref="DRAWINGS">FIG. 8</figref> depicts a flow diagram of a general overview of a method for invoking another type of additional processing, as generally described in <figref idref="DRAWINGS">FIG. 5</figref>, in accordance with an another example embodiment; and

<figref idref="DRAWINGS">FIG. 9</figref> depicts a block diagram of a machine in the example form of a computing device, such as the computing devices depicted in <figref idref="DRAWINGS">FIG. 2</figref> and <figref idref="DRAWINGS">FIG. 3</figref>, within which may be executed a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of an example embodiment of the present disclosure. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details.

Embodiments provide various techniques for invoking additional processing using remote procedure calls. One technique involves the addition of metadata to an RPC message. This metadata is different from parameters required in the execution of a function. As explained below, the metadata provides information about the invocation of processes that enable additional features, which are not supported by standard RPC protocols. The different types of additional processes that can be invoked are explained in more detail below.

<figref idref="DRAWINGS">FIG. 1</figref> is a block architectural diagram depicting an enterprise system <b>100</b>, in accordance with an example embodiment, that can invoke additional processing using remote procedure calls. The enterprise system <b>100</b> illustrates an example of a client-server database environment, which includes a server computing device <b>110</b> in communication with client computing devices <b>102</b> by way of a network <b>104</b>. The server computing device <b>110</b> (e.g., an application/database server) may operate to receive, store, manage, and provide data, which may be received from sources such as client computing devices <b>102</b> or generated by the server computing device <b>110</b>. As depicted, the server computing device <b>110</b> is configured to host various applications <b>150</b>, enterprise applications <b>112</b>, and a database <b>113</b>.

The applications <b>150</b> running on the server computing device <b>110</b> are accessible from one or more client computing devices <b>102</b> (e.g., desktop computers, mobile phones, laptops, tablet computers, and personal digital assistants) through thin client interfaces, such as a Web browser. The applications <b>150</b> are computer programs that provide a variety of functionalities that may be based on the access of data stored in the database <b>113</b>. Examples of applications <b>150</b> include social networking websites, video sharing websites, hosted services, web applications, and other applications.

Each of these applications <b>150</b> relies on one or more enterprise applications <b>112</b>, which refer to the underlying structure supporting communications among units of work (also referred to as services) executed on behalf of the applications <b>150</b>. An example of an enterprise application <b>112</b> is the ADOBE LIVECYCLE Data Services ES, which is a framework used in the development of various enterprise applications <b>112</b> that automate a broad range of business processes. Such enterprise applications <b>112</b> can, for example, provide data capture (e.g., create and deploy Extensible Markup Language (XML) based form templates such as ADOBE PDF or HyperText Markup Language (HTML) for use with the ADOBE READER, ADOBE FLASH Player, and web browsers), information assurance (e.g., digital signatures and rights management), document output (e.g., ADOBE PDF Generator, form generators, and output production prints), content services, and process management to deliver business processes such as account opening, services and benefits enrollment, correspondence management, requests for proposal processes, and other business-related workflows.

The applications <b>150</b> communicate with enterprise applications <b>112</b> over one or more interfaces provided by the enterprise applications <b>112</b>. The applications <b>150</b> may, in turn, support client applications executed by client computing devices <b>102</b>. Such a client application may, for example, include a Web browser to access and display reports generated by the applications <b>150</b>. In this regard, the server computing device <b>110</b> may, for example, be a Web server that manages interactions with the client computing devices <b>102</b>.

In this enterprise system <b>100</b>, the server computing device <b>110</b> is configured to process RPCs. An RPC is a protocol that a program can use to request a service from a program located in another computing device on a shared network without a programmer explicitly coding details for this remote interaction. Particularly, an RPC is an inter-process communication mechanism that enables a program to cause a function (e.g., subroutine and procedure) to execute in another computing device on a shared network. In the enterprise system <b>100</b> depicted in <figref idref="DRAWINGS">FIG. 1</figref>, a client computing device <b>102</b> can initiate an RPC, thereby sending an RPC message to a known remote server computing device <b>110</b> requesting execution of a specified function with supplied parameters. The remote server computing device <b>110</b> may transmit a response to the client computing device <b>102</b> based on the execution of the function. Examples of RPC protocols include XML-RPC, Simple Object Access Protocol (SOAP), and Java Remote Method Invocation (JAVA-RMI).

In accordance with embodiments of the present invention, additional metadata may be included in one or more RPC messages transmitted from the client computing devices <b>102</b> to the server computing device <b>110</b>. As explained in more detail below, in one embodiment, the metadata may be embodied as an annotation in a function definition. This metadata can invoke additional processing at the client computing devices <b>102</b> and/or server computing device <b>110</b>, the additional processing of which is not supported by standard RPC protocols. As also explained in detail below, examples of additional processing include paging, load associated property on demand, notifications of modifications, change objects on updates, changes made to objects, and a variety of other different processes.

It should be appreciated that other system topologies may be used in conjunction with other embodiments, and that the computing devices <b>102</b> and <b>110</b> may include other elements that are not shown and may be used during operation thereof, such as any suitable program code, scripts, or other functional data that are executable to interface with other elements of the enterprise system <b>100</b>, other applications, other data files, operating system files, and device drivers. Furthermore, two or more elements of the enterprise system <b>100</b> may be located remote from one another and may communicate with one another via the network <b>104</b> and/or a dedicated connection. Moreover, each displayed element of enterprise system <b>100</b> may comprise any number of hardware and/or software elements, some of which are located remote from each other element. The elements described herein as communicating with one another are directly or indirectly capable of communicating over any number of different systems for transferring data, including, but not limited to, shared memory communication, a local area network (LAN), a wide area network (WAN), a telephone network, a cellular network, a fiber-optic network, a satellite network, an infrared network, a radio frequency network, and any other type of network <b>104</b> that may be used to transmit information between computing devices. Additionally, communication between systems or computing devices (e.g., between client computing device <b>102</b> and server computing device <b>110</b>) may proceed over any one or more transmission protocols that are or become known, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).

<figref idref="DRAWINGS">FIG. 2</figref> depicts a block diagram of modules, in accordance with an embodiment, that may be included in one or more of the client computing devices <b>102</b> depicted in <figref idref="DRAWINGS">FIG. 1</figref>. It should be appreciated that the client computing device <b>102</b> may be deployed in the form of, for example, a personal computer, a laptop computer, a tablet personal computer, a personal digital assistant, or other computing device. The client computing device <b>102</b> may form a part of an enterprise system, such as the enterprise system <b>100</b> depicted in <figref idref="DRAWINGS">FIG. 1</figref>. Referring to <figref idref="DRAWINGS">FIG. 2</figref>, in various embodiments, the client computing device <b>102</b> may be used to implement computer programs, logic, applications, methods, processes, or software to invoke additional processing using RPC, as described in more detail below.

As depicted in <figref idref="DRAWINGS">FIG. 2</figref>, the client computing device <b>102</b> includes client application <b>202</b>, client RPC service module <b>203</b>, and client data management service module <b>206</b>. The client RPC service module <b>203</b> enables the client application <b>202</b> to make asynchronous requests to remote services that process the requests and then returns data directly to the client computing device <b>102</b>. For example, the client application <b>202</b> can access data through client RPC service module <b>203</b> that includes HTTP GET or POST (HTTP services), SOAP (web services), or Java objects (remote object services). In an embodiment, the client RPC service module <b>203</b> can also embed metadata in RPC messages to invoke additional processing, which is explained in more detail below. In addition to calling a remote service, the client RPC service module <b>203</b> can store the response data from the service, from which the client application <b>202</b> can obtain the data.

The client data management service module <b>206</b> is configured to call methods on a server computing device. Additionally, this module <b>206</b> can also fill client-side data collections with data from remote data sources and synchronize the client and server versions of data. The client data management service module <b>206</b> can also automatically track changes made to the data at the client side using property change events, thereby allowing the creation of applications that work with distributed data. Large collections of data and nested data relationships, such as one-to-one and one-to-many relationships, can be managed using the client data management service module <b>206</b>. Accordingly, by using the client data management service module <b>206</b>, client applications <b>202</b> can be built that provide real-time data synchronization, data replication, on-demand data paging, and occasionally connected application services.

<figref idref="DRAWINGS">FIG. 3</figref> depicts a block diagram of modules, in accordance with an embodiment, that may be included in the server computing device <b>110</b> depicted in <figref idref="DRAWINGS">FIG. 1</figref>. It should be appreciated that the server computing device <b>110</b> may be deployed in the form of, for example, an enterprise server, an application server, or other server computing devices. The server computing device <b>1110</b> may form a part of an enterprise system, such as the enterprise system <b>100</b> depicted in <figref idref="DRAWINGS">FIG. 1</figref>. Referring to <figref idref="DRAWINGS">FIG. 3</figref>, in various embodiments, the server computing device <b>110</b> may be used to implement computer programs, logic, applications, methods, processes, or software to process remote procedure calls, as described in more detail below.

As depicted in <figref idref="DRAWINGS">FIG. 3</figref>, the server computing device <b>110</b> is configured to host enterprise applications <b>112</b>, which, in one example embodiment, include server RPC service module <b>304</b> and a data service module <b>306</b>. When the server computing device <b>110</b> receives an RPC message, the server RPC service module <b>304</b> converts the RPC message from a network transmission format to a format required by the server computing device <b>110</b>. Thereafter, the server RPC service module <b>304</b> calls the function, which is requested by the RPC message, in the server computing device <b>110</b>. The function then executes, possibly generating output data, which the server RPC service module <b>304</b> may then return to the client computing device. Embodiments of the server RPC service module <b>304</b> can also extract metadata from the RPC message. As explained in more detail below, this metadata can be used to invoke additional processing that is otherwise not provided by the execution of the function.

The data service module <b>306</b> generally processes messages from a client computing device. For example, the data service module <b>306</b> may control the creation, maintenance, and the use of data stored in, for example a database. Particularly, the data service module <b>306</b> provides facilities for controlling data access, enforcing data integrity, and managing concurrency control. Additionally, the data service module <b>306</b> can invoke a variety of different processing performed on the input and/or output of the functions based on the extracted metadata, some of the processing of which are described below.

It should be appreciated that in other embodiments, the computing devices <b>102</b> and <b>110</b> may include fewer or more modules apart from those shown in <figref idref="DRAWINGS">FIGS. 2 and 3</figref>. For example, in an alternate embodiment, the server RPC service module <b>304</b> depicted in <figref idref="DRAWINGS">FIG. 3</figref> can be instead embodied as two separate modules, namely an RPC module and a remote messaging service module. The modules <b>203</b>, <b>206</b>, <b>304</b>, and <b>306</b> may be in the form of software that is processed by a processor. In another example, as explained in more detail below, the modules <b>203</b>, <b>206</b>, <b>304</b>, and <b>306</b> may be in the form of firmware that is processed by application specific integrated circuits (ASICs), which may be integrated into a circuit board. Alternatively, the modules <b>203</b>, <b>206</b>, <b>304</b>, and <b>306</b> may be in the form of one or more logic blocks included in a programmable logic device (for example, a field programmable gate array (FGPA)). The described modules <b>203</b>, <b>206</b>, <b>304</b>, and <b>306</b> may be adapted, and/or additional structures may be provided, to provide alternative or additional functionalities beyond those specifically discussed in reference to <figref idref="DRAWINGS">FIGS. 2 and 3</figref>. Examples of such alternative or additional functionalities will be discussed in reference to the flow diagrams discussed below.

<figref idref="DRAWINGS">FIG. 4</figref> depicts a flow diagram of a general overview of a method <b>400</b> at, for example, the client computing device depicted in <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, for invoking additional processing using RPC, in accordance with an example embodiment. The method <b>400</b> may be implemented by the client RPC service module <b>203</b> and the client data management service module <b>206</b> and employed in the client computing device <b>102</b> depicted in <figref idref="DRAWINGS">FIG. 2</figref>. In <figref idref="DRAWINGS">FIG. 4</figref>, at <b>402</b>, the client computing device receives from a remote computing device (e.g., a server computing device) a list of functions supported by the remote computing device. The list may be included in a client run-time library, which includes a mapping of client functions to remote functions. From this list, one or more functions that require metadata are identified at <b>404</b>. As used herein, “metadata” refers to a set of data that describes or that gives information about additional processing associated with the function. Examples of metadata include object properties, page number, the name or names of properties that when combined provide a unique identity for an instance of an object, a notation of what type of operation will be performed when a specific RPC function is invoked (e.g., create, update, delete, read), a specific type of object that a particular function operates on (e.g., a delete function deletes an account object), and information about specific properties that were changed in an update operation, along with a copy of the original values of the change properties. This metadata is different from an argument required by the function. In particular, an “argument” refers to any expression within the parentheses of a function call, and is the value that is passed from a program application to the function call. Such an argument can also be considered as input to the function from the program from which it is called. Accordingly, in contrast to an argument, metadata cannot be an expression within the parentheses of a function call. Furthermore, a user defines a functional call and its arguments. In contrast, the metadata is defined by the client computing device (e.g., within the client run-time library).

In one embodiment, the list received from the remote computing device includes descriptions of the functions supported by the remote computing device. Alternatively, the descriptions may include or describe the metadata required by the functions. Accordingly, the function that requires metadata can be identified from the descriptions, and once the function is identified, the client computing device can then access the metadata and arguments required by the function at <b>406</b>. The client computing device then composes an RPC message at <b>408</b> that includes both the metadata and the argument required by the function. As explained in more detail below, the metadata can, in one embodiment, be defined within a function definition. The client computing device then transmits the RPC message to the remote computing device at <b>410</b> to call the execution of the particular function at the remote computing device, which calls the function with the argument as input and also invokes additional processing based on the metadata.

<figref idref="DRAWINGS">FIG. 5</figref> depicts a flow diagram of a general overview of a method <b>500</b> at, for example, the server computing device depicted in <figref idref="DRAWINGS">FIGS. 1 and 3</figref> for processing RPCs at a server computing device, in accordance with an example embodiment. The method <b>500</b> may be implemented by the server RPC service module <b>304</b> and the data service module <b>306</b>, and employed in the server computing device depicted <b>110</b> in <figref idref="DRAWINGS">FIG. 3</figref>. As depicted in <figref idref="DRAWINGS">FIG. 5</figref>, the server computing device receives an RPC message from a remote computing device (e.g., a client computing device) at <b>502</b>. With the receipt of the RPC message, the server computing device at <b>504</b> extracts metadata from the RPC message about the function being called. In one embodiment, the server computing device extracts the metadata by parsing the RPC message and reading the metadata from the parsed RPC message from a location in the parsed RPC message that has been defined to include the metadata.

Thereafter, the server computing device executes the requested function at <b>506</b>, based on arguments included in the function call. Additionally, the server computing device may invoke, at <b>508</b>, additional processing based on the extracted metadata. It should be noted that this invocation of additional processing is separate from the execution of the function. In one embodiment, the additional processing is performed on the argument that is input into the function, and such additional processing before execution of the function is referred to as “pre-processing.” For example, the metadata sent by the client computing device can be provided as context to the execution of a function.

In another embodiment, additional processing is performed on the output from the execution of the function, and such additional processing after the execution of the function is referred to as “post-processing.” The server computing device can invoke a variety of different pre-processing and post-processing of data. As explained in more detail below, such processes can include paging, load associated property on demand, notifications of modifications, change objects on updates, changes made to objects, and a variety of other different processes.

<figref idref="DRAWINGS">FIG. 6</figref> depicts a timing diagram <b>600</b> illustrating the transmittal of messages between the modules depicted in <figref idref="DRAWINGS">FIGS. 2 and 3</figref> to invoke additional processing at a server computing device, in accordance with an example embodiment. As depicted in <figref idref="DRAWINGS">FIG. 6</figref>, the timing diagram <b>600</b> depicts client application <b>202</b>, client RPC service module <b>203</b>, and client data management service module <b>206</b>, all of which are associated with the client computing device <b>102</b>. The timing diagram <b>600</b> additionally depicts data service module <b>306</b> and server RPC service module <b>304</b>, all of which are associated with the server computing device <b>110</b>.

Initially, the server RPC service module <b>304</b> transmits a list <b>650</b> of functions that are supported by the server computing device <b>110</b> to the client RPC service module <b>203</b>. As explained above, this list <b>650</b> may be in the form of a client runtime library that includes a mapping of client functions to remote functions supported by the server computing device <b>110</b>. It should be noted that this list <b>650</b> may not include all supported functions. Instead, the list <b>650</b> may include a number of functions that can be processed in a particular way by the client application <b>650</b>. In one embodiment, the list <b>650</b> includes descriptions about the metadata that are required by one or more of the listed functions. For example, the description can define the particular metadata required for each function included in the list <b>650</b>. As a result, the client RPC service module <b>203</b> can identify the metadata required for a function from the descriptions.

The client application <b>202</b> can make a call <b>652</b> for a local function. Instead of containing the actual code that implements the remote function, the client RPC service module <b>203</b> accesses or retrieves the required arguments from a client address space. The client RPC service module <b>203</b> also identifies the required metadata from the descriptions included in the received list and accesses or retrieves the required metadata. The client RPC service module <b>203</b> then composes an RPC message <b>656</b> calling a function, and this RPC message includes the metadata and the arguments required by the function. In one embodiment, the metadata may be added or included in a function definition, which includes a function declaration and a body of a function. For example, the metadata may be embodied as an annotation in a function definition. As used herein, an “annotation” provides data about a function that is not part of the function itself. Such annotations have no direct effect on the operation of the code they annotate. It should be appreciated that annotations can be applied to a function's declarations of classes, fields, methods, and other program elements. The following Table A depicts an annotation in JAVA that is embodied in a function definition:

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE A</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>@Delete</entry></row><row><entry>public void closeAccount (Account account) throws Exception</entry></row><row><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>If (account == null)</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry>throw new Exception (“You forgot to specify an account. Try</entry></row><row><entry /><entry>again.”);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry>accountDAO.deleteAccount (account);</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In JAVA, annotations are differentiated from other elements (e.g., class and interface) by an “@” symbol preceding the annotations. As depicted in Table A, an “@” symbol precedes the “Delete” keyword, thereby designating the “Delete” keyword as an annotation.

In an alternate embodiment, the metadata may be embodied or collected within a configuration file. An XML configuration file is an example of a configuration file where a user may create such an XML configuration file to store his preferences and, in this embodiment, also the metadata.

The client RPC service module <b>203</b> then calls the function in the client runtime library and transmits the RPC message <b>656</b> requesting the function to the server computing device <b>110</b> by way of the client data management service module <b>206</b>. At the server computing device <b>110</b>, the data service module <b>306</b> receives the RPC message <b>656</b> and forwards it to the server RPC service module <b>304</b>. It should be appreciated that the data service module <b>306</b> is configured to processes messages from the client application <b>202</b>. Here, the data service module <b>306</b> converts messages from their binary form to an internal message form. After the conversion, the data service module <b>306</b> examines the messages to determine which service and destination within the service to route each message.

Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, the server RPC service module <b>304</b> then extracts the metadata from the RPC message and invokes additional pre-processing and/or post-processing based on the extracted metadata. As an example, the RPC service module <b>304</b> may invoke additional pre-processing on the input arguments before the server computing device <b>110</b> executes the function. In another example, the server RPC service module <b>304</b> may invoke additional post-processing on the output from an executed function.

It should be noted that in alternative embodiments, the client RPC service module <b>203</b> and the server RPC service module <b>304</b> can communicate with each other directly without going through the client data management service module <b>206</b> and the data service module <b>306</b>. As a result, in this alternate embodiment, the client RPC service module <b>203</b> can transmit the RPC message <b>656</b> directly to the server RPC service module <b>304</b>, and in response, the server RPC service module <b>304</b> can transmit a response message directly to the client RPC service module <b>203</b>.

<figref idref="DRAWINGS">FIG. 7</figref> depicts a flow diagram of a general overview of a method <b>700</b> for invoking a type of additional processing, as generally described in <figref idref="DRAWINGS">FIG. 5</figref>, in accordance with an example embodiment. The method <b>700</b> may, for example, be implemented by the server RPC service module <b>304</b> as embodied in the server computing device <b>110</b> depicted in <figref idref="DRAWINGS">FIG. 3</figref>. One example of additional processing that can be invoked is loading object properties on demand. It should be appreciated that a “property” of an object refers to a variable of an object. An example of such a property is a relationship of an object to other objects. Instead of transmitting all object properties, a client computing device can request certain object properties from a server computing device. Here, the client computing device can transmit an RPC message to a server computing device with metadata having instructions to transmit a particular object property. That is, the server computing device can interpret the metadata as an instruction to transmit a particular object property.

For example, a client computing device can transmit a request to a server requesting for a collection of objects. In response, the server computing device transmits some, but not all, the properties of the requested objects to the client computing device. The client computing device then requests a property value that was not transmitted to the client computing device in the original request. In particular, the client RPC service module, for example, may automatically invoke the correct function on the server computing device, as indicated in the metadata, to retrieve the property value from the server computing device. As depicted in <figref idref="DRAWINGS">FIG. 7</figref>, upon receipt of the request as embodied in an RPC message at <b>702</b>, the server computing device invokes the requested function that can access the requested object property at <b>704</b>. Instead of transmitting all properties of a particular object, the server computing device, at <b>705</b>, transmits only the requested object property to the client computing device in response to the request from the RPC message.

<figref idref="DRAWINGS">FIG. 8</figref> depicts a flow diagram of a general overview of a method <b>800</b> for invoking another type of additional processing, as generally described in <figref idref="DRAWINGS">FIG. 5</figref>, in accordance with another example embodiment. The method <b>800</b> may, for example, be implemented by the server RPC service module <b>304</b> as embodied in the server computing device <b>110</b> depicted in <figref idref="DRAWINGS">FIG. 3</figref>. Another example of additional processing that can be invoked is the change notification. In particular, a server computing device can track modifications made to data based on the execution of functions, and upon detection of a modification, the server computing device can transmit immediate notifications to all connected client computing devices that have copies of the same data. In this embodiment, the client computing device can transmit an RPC message to a server computing device with metadata having instructions to transmit a notification of data modification to other client computing devices having copies of the data if the data has been modified.

As depicted in <figref idref="DRAWINGS">FIG. 8</figref>, upon receipt of the RPC message with such instructions, the server computing device is configured to detect a modification of data at <b>802</b> and identify one or more different client computing devices that have copies of the same data at <b>804</b>. If a modification is detected, the server computing device transmits, at <b>806</b>, notifications of the modification to all the identified client computing devices having copies of the same data. The client computing devices that receive such notifications may then take various actions regarding the modified data, such as blocking the data from being modified or notifying the user that the data has been modified.

In addition to the additional processing described in <figref idref="DRAWINGS">FIGS. 7 and 8</figref>, the server computing device (as well as the client computing device) can also invoke other processing. In yet another embodiment, paging can be invoked where a collection of data can be broken up into “pages,” which are subsets of data that are transmitted when requested by the client computing device. As an example, in a list of data, only the first ten elements of the data are visible to the client computing device. As a result, the client computing device does not need the entire data set. The client computing device can therefore request additional “pages” from the server computing device when the user scrolls down the list. In this example, the metadata included in an RPC message can define a subset of data to be included in a response. An example of such a subset definition can include a range, such as a page range (e.g., pages 1-10). Upon receipt of such a request, the server computing device accesses and transmits only the subset of data in a response to the client computing device, which requested the subset.

In still another embodiment, automatic updates of modified data can be invoked where modifications made to objects resulting from the execution of a function can be tracked. The server computing device that tracks the modifications can automatically push the modification to other client computing devices that have copies of the same data. These other client computing devices can update their copies of the data accordingly. In this example, the metadata included in an RPC message can include instructions to track modifications made by the execution of a function, which is requested in the RPC message.

<figref idref="DRAWINGS">FIG. 9</figref> depicts a block diagram of a machine in the example form of a computing device <b>900</b>, such as the computing devices <b>102</b> and <b>110</b> depicted in <figref idref="DRAWINGS">FIG. 2</figref> and <figref idref="DRAWINGS">FIG. 3</figref>, respectively, within which may be executed a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

As depicted in <figref idref="DRAWINGS">FIG. 9</figref>, the machine is 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 example of the computing device <b>900</b> includes a processor <b>902</b> (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory <b>904</b> (e.g., random access memory), and a static memory <b>906</b> (e.g., static random-access memory), which communicate with each other via bus <b>908</b>. The computing device <b>900</b> may further include video display unit <b>910</b> (e.g., a plasma display, a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computing device <b>900</b> also includes an alphanumeric input device <b>912</b> (e.g., a keyboard), a user interface (UI) navigation device <b>914</b> (e.g., a mouse), a disk drive unit <b>916</b>, a signal generation device <b>918</b> (e.g., a speaker), and a network interface device <b>920</b>.

The disk drive unit <b>916</b> (a type of non-volatile memory storage) includes a machine-readable medium <b>922</b> on which is stored one or more sets of data structures and instructions <b>924</b> (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The data structures and instructions <b>924</b> may also reside, completely or at least partially, within the main memory <b>904</b> and/or within the processor <b>902</b> during execution thereof by computing device <b>900</b>, with the main memory <b>904</b> and processor <b>902</b> also constituting machine-readable, tangible media.

The data structures and instructions <b>924</b> may further be transmitted or received over a computer network <b>104</b> via network interface device <b>920</b> utilizing any one of a number of well-known transfer protocols (e.g., HTTP).

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., the computing device <b>900</b>) or one or more hardware modules of a computer system (e.g., a processor <b>902</b> or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a FPGA or an ASIC) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor <b>902</b> or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor <b>902</b> configured using software, the general-purpose processor <b>902</b> may be configured as respective different hardware modules at different times. Software may accordingly configure a processor <b>902</b>, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

Modules can provide information to, and receive information from, other modules. For example, the described modules may be regarded as being communicatively coupled. Where multiples of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the modules. In embodiments in which multiple modules are configured or instantiated at different times, communications between such modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple modules have access. For example, one module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further module may then, at a later time, access the memory device to retrieve and process the stored output. Modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors <b>902</b> that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors <b>902</b> may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors <b>902</b> or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors <b>902</b>, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processors <b>902</b> may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors <b>902</b> may be distributed across a number of locations.

While the embodiment(s) is (are) described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the embodiment(s) is not limited to them. In general, techniques invoking additional processes using RPC may be implemented with facilities consistent with any hardware system or hardware systems defined herein. Many variations, modifications, additions, and improvements are possible.

Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the embodiment(s). In general, structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the embodiment(s).