Generating results gates in a distributed computing environment7016966
Abstract
Embodiments of a mechanism for providing results gates to clients in the distributed computing environment to be used by the clients to access results generated by services on behalf of the clients. A client generates a request message for a service. The request message is generated by a client method gate. The service then generates results in response to the message. A results gate is generated for accessing the results. A gate on the client generates the results gate. The results are then accessed through the results gate. The results are structured as an object (e.g. Java object), and the results gate an object proxy for the results object. The results gate is returned to the process as results of the method call made by the process. In one embodiment, the results gate is a method gate and provides a method interface to the results.
Claims
What is claimed is:
1. A method for accessing results data in a distributed computing environment, comprising:
a client sending a first message in a data representation language to a service accessible through the distributed computing environment, wherein the client comprises a client message gate and wherein said sending a first message comprises the client message gate sending the first message to the service;
wherein the first message includes information representing a computer programming language method call, wherein the service comprises one or more computer programming language methods executable within the service, and wherein one of the methods executable within the service corresponds to the method call included in the first message;
wherein the client message gate comprises a client method gate, wherein said sending a first message comprises:
the client method gate receiving the computer programming language method call from a first process executing within the client; and
the client method gate generating the first message for the first process;
the service generating first results in response to the first message;
the client method gate receiving a second message in the data representation language in response to said generating first results;
generating a first results gate configured to provide an interface to the first results through messages in the data representation language, wherein the first results gate is distinct from the client message gate, wherein said generating a first results gate is performed by the client method gate in response to said receiving a second message; and
the client accessing the first results through the first results gate.
2. The method as recited in claim 1, wherein the client comprises a client process, wherein said sending a first message comprises:
the client message gate receiving from the client process a request for the service to perform a function on behalf of the client process; and
the client message gate sending the first message to the service in response to said receiving a request.
3. The method as recited in claim 2, wherein said generating a first results gate is performed by the client gate.
4. The method as recited in claim 2, further comprising the client gate attaching an authentication credential to the first message prior to said sending the first message, wherein the authentication credential identifies the client.
5. The method as recited in claim 4, wherein the first results gate is configured to attach the authentication credential to outgoing messages.
6. The method as recited in claim 2, further comprising:
providing the first results gate to the client process as results of the function.
7. The method as recited in claim 1, wherein the first message includes information requesting the service to perform a function, and wherein said generating first results comprises:
the service performing the function; and
generating the first results as output of said performing the function.
8. The method as recited in claim 7, wherein the client comprises a client process, the method further comprising:
the service storing the first results;
wherein said generating a first results gate comprises the client message gate receiving a second message in the data representation language, wherein the second message includes an address of the stored first results; and
wherein said generating a first results gate is performed by the client message gate in accordance with information for generating the first results gate obtained through the address.
9. The method as recited in claim 8, wherein the service is comprised on a first device, wherein the first device further comprises a space service, and wherein the service storing the first results comprises the service storing the first results to the space service.
10. The method as recited in claim 8, wherein the service is comprised on a first device, wherein the service storing the first results comprises the service storing the first results to a space service in the distributed computing environment and external to the first device.
11. The method as recited in claim 8, further comprising the client message gate receiving a second message in the data representation language from the service subsequent to said generating the first results, wherein said generating a first results gate is performed by the client message gate in response to said receiving a second message.
12. The method as recited in claim 11, further comprising the client message gate providing information for accessing the first results through the first results gate to the client process.
13. The method as recited in claim 1, further comprising:
a client process executing within the client generating the method call;
wherein said sending a first message, said generating first results, and said generating a first results gate are performed without client process intervention.
14. The method as recited in claim 1, wherein said generating results comprises:
the service executing a computer programming language method in accordance with the information representing the computer programming language method call included in the first message; and
generating the first results as output of said executing a method.
15. The method as recited in claim 1, further comprising:
the service storing the first results;
wherein said generating a first results gate comprises the client method gate receiving a second message in the data representation language, wherein the second message includes an address of the stored first results, wherein said generating a first results gate is performed by the client method gate in accordance with information for generating the first results gate obtained through the address.
16. The method as recited in claim 15, wherein the service is comprised on a first device, wherein the first device further comprises a space service, and wherein the service storing the first results comprises the service storing the first results to the space service.
17. The method as recited in claim 15, wherein the service is comprised on a first device, wherein the service storing the first results comprises the service storing the first results on a space service in the distributed computing environment and external to the first device.
18. The method as recited in claim 1, further comprising the client method gate providing information for accessing the first results through the first results gate to the first process.
19. The method as recited in claim 1, wherein the first results is comprised in a first computer programming language results object, wherein the first computer programming language results object further comprises one or more computer programming language access methods for accessing the first results, wherein the one or more access methods are invokable through one or more computer programming language access method calls, and wherein said accessing the first results through the first results gate comprises:
the first results gate receiving from a first process executing within the client a first access method call of the one or more access method calls, wherein the first access method call is associated with a first access method of the one or more access methods;
the first results gate sending a second message in the data representation language to a second results gate, wherein the second message includes a data representation language representation of the first access method call; and
the second results gate invoking the first access method in accordance with the representation of the first access method call included in the second message.
20. The method as recited in claim 19, further comprising:
the second results gate sending a third message in the data representation language to the first results gate, wherein the third message includes first access method results; and
the first results gate providing the first access method results to the first process.
21. The method as recited in claim 20, wherein the first access method results includes the first results.
22. The method as recited in claim 20, wherein said providing the first access method results to the first process comprises generating a third results gate configured to provide an interface to the first access method results through messages in the data representation language.
23. The method as recited in claim 1, wherein said accessing the first results through the first results gate comprises:
the first results gate receiving from a first process executing within the client a first computer programming language method call, wherein the first computer programming language method call is associated with a first method for accessing the first results;
the first results gate sending a second message in the data representation language to a second results gate in response to receiving the first computer programming language method call, wherein the second message includes a request for the first results; and
the second results gate sending a third message in the data representation language to the first results gate, wherein the third message includes the requested first results.
24. The method as recited in claim 1, wherein the client is executing within a virtual machine, wherein the virtual machine is executing within a client device in the distributed computing environment.
25. The method as recited in claim 24, wherein the virtual machine is a Java Virtual Machine (JVM).
26. The method as recited in claim 1, wherein the data representation language is eXtensible Markup Language (XML).
27. A distributed computing system comprising:
a service device configured to generate results for clients of the service device;
a client device configured to send a first message in a data representation language to the service device, wherein the client device comprises a client gate unit and wherein said the client gate unit sends the first message to the service, wherein the client device comprises a client process and a client message gate, and wherein the first message includes information requesting the service device to perform a function on behalf of the client device;
wherein the service device is further configured to generate first results in response to the first message; wherein, in said generating first results, the service device is further configured to;
performing the function; and
generate the first results as output of said performing the function;
wherein the service device is further configured to store the first results;
wherein the client message gate is configured to receive a second message in the data representation language, wherein the second message includes an address of the stored first results;
wherein the client device is further configured to:
generate a first results gate configured to provide an interface to the first results through messages in the data representation language, wherein the first results gate is distinct from the client gate unit, wherein said generating a first results gate is performed by the client message gate for the client device in accordance with information for generating the first results gate obtained through the address; and
access the first results through the first results gate.
28. The system as recited in claim 27, wherein the client device comprises a client process, wherein, in said sending a first message, the client gate unit is configured to:
receive from the client process a request for the service device to perform a function on behalf of the client process;
send the first message to the service device in response to said receiving a request; and
provide the first results gate to the client process as results of the function.
29. The system as recited in claim 28, wherein said generating a first results gate is performed by the client gate unit.
30. The system as recited in claim 28, wherein the client gate unit is further configured to attach an authentication credential to the first message prior to said sending the first message, wherein the authentication credential identifies the client process, wherein the first results gate is configured to attach the authentication credential to outgoing messages.
31. The system as recited in claim 27, wherein the service device comprises a space service, and wherein the service device storing the first results comprises the service storing the first results to the space service.
32. The system as recited in claim 27, further comprising:
a space device comprising a space service;
wherein, in said storing the first results, the service device is further configured to store the first results to the space service.
33. The system as recited in claim 27, wherein the client message gate is further configured to receive a second message in the data representation language from the service subsequent to said generating the first results, wherein said generating a first results gate is performed by the client message gate in response to said receiving a second message.
34. The system as recited in claim 33, wherein the client message gate is further configured to provide information for accessing the first results through the first results gate to the client process.
35. The system as recited in claim 27, wherein the first message includes information representing a computer programming language method call, wherein the service device comprises one or more computer programming language methods executable within the service device and wherein one of the methods executable within the service device corresponds to the method call included in the first message.
36. The system as recited in claim 35,
wherein the client device comprises a client process configured to generate the method call;
wherein said sending a first message, said generating first results, and said generating a first results gate are performed without client process intervention.
37. The system as recited in claim 35, wherein, in said generating results, the service device is further configured to:
execute a computer programming language method in accordance with the information representing the computer programming language method call included in the first message; and
wherein the first results are generated as output of said executing a method.
38. The system as recited in claim 35, wherein the client device comprises a client method gate, wherein, in said sending a first message, the client method gate is configured to:
receive the computer programming language method call from a first process executable within the client device; and
generate the first message for the first process.
39. The system as recited in claim 38,
wherein the service device is further configured to store the first results;
wherein, in said generating a first results gate, the client method gate is further configured to:
receive a second message in the data representation language, wherein the second message includes an address of the stored first results; and
generate the first results gate in accordance with information for generating the first results gate obtained through the address.
40. The system as recited in claim 39, wherein the service device further comprises a space service, and wherein, in said storing the first results, the service device is further configured to store the first results to the space service.
41. The system as recited in claim 39, further comprising:
a space device comprising a space service;
wherein, in said storing the first results, the service device is further configured to store the first results to the space service.
42. The system as recited in claim 38, wherein the client method gate is further configured to receive a second message in the data representation language from the service in response to said generating first results, wherein said generating a first results gate is performed by the client method gate in response to said receiving a second message.
43. The system as recited in claim 42, wherein the client method gate is further configured to provide information for accessing the first results through the first results gate to the first process.
44. The system as recited in claim 27, further comprising:
a second results gate;
wherein the first results is comprised in a first computer programming language results object, wherein the first computer programming language results object further comprises one or more computer programming language access methods for accessing the first results, wherein the one or more access methods are invokable through one or more computer programming language access method calls;
wherein, in said accessing the first results, the first results gate is configured to:
receive from a first process executing within the client device a first access method call of the one or more access method calls, wherein the first access method call is associated with a first access method of the one or more access methods;
send a second message in the data representation language to the second results gate, wherein the second message includes a data representation language representation of the first access method call; and
wherein the second results gate is configured to invoke the first access method in accordance with the representation of the first access method call included in the second message.
45. The system as recited in claim 44,
wherein the second results gate is further configured to send a third message in the data representation language to the first results gate, wherein the third message includes first access method results; and
wherein the first results gate is further configured to provide the first access method results to the first process.
46. The system as recited in claim 45,
wherein, in said providing the first access method results to the first process, the first results gate is further configured to generate a third results gate;
wherein the third results gate is configured to provide an interface to the first access method results through messages in the data representation language.
47. The system as recited in claim 27, further comprising:
a second results gate;
wherein, in said accessing the first results through the first results gate, the first results gate is further configured to:
receive from a first process executing within the client a first computer programming language method call, wherein the first computer programming language method call is associated with a first method for accessing the first results; and
send a second message in the data representation language to the second results gate in response to receiving the first computer programming language method call, wherein the second message includes a request for the first results; and
wherein the second results gate is configured to send a third message in the data representation language to the first results gate, wherein the third message includes the requested first results.
48. The system as recited in claim 27, wherein the client device comprises a virtual machine, and wherein said send a first message, generate a first results gate, and access the first results through the first results gate are performed within the virtual machine execution environment.
49. The system as recited in claim 48, wherein the virtual machine is a Java Virtual Machine (JVM).
50. The system as recited in claim 27, wherein the data representation language is eXtensible Markup Language (XML).
51. A device comprising:
a first gate unit configured to
send a first message in a data representation language to a service accessible through a distributed computing environment, wherein the service is operable to generate first results in response to the first message;
wherein, in said sending a first message, the first gate unit is further configured to:
receive the computer programming language method call from the client component; and
generate the first message for the client component;
generate a first results gate, wherein the first results gate is configured to provide an interface to the first results through messages in the data representation language; and
wherein the first gate unit is further configured to receive a second message in the data representation language from the service, wherein said generating a first results gate is performed by the first gate unit in response to said receiving a second message; and
a client component configured to access the first results through the first results gate.
52. The device as recited in claim 51, wherein said sending a first message and said generating a first results gate are performed without client component intervention.
53. The device as recited in claim 51, wherein, in said sending a first message, the first gate unit is further configured to:
receive a request for the service to perform the function from the client component, wherein the first message includes information requesting the service to perform the function on behalf of the client component, and wherein the service generates the first results as output of performing the function; and
send the first message to the service in response to said receiving a request.
54. The device as recited in claim 53,
wherein, in said generating a first results gate, the first gate unit is further configured to receive a second message in the data representation language, wherein the second message includes an address of the first results;
wherein said generating a first results gate is performed by the first gate unit in accordance with information for generating the first results gate obtained through the address.
55. The device as recited in claim 53, wherein the first gate unit is further configured to receive a second message in the data representation language from the service, wherein said generating a first results gate is performed by the first gate unit in response to said receiving a second message.
56. The device as recited in claim 55, wherein the first gate unit is further configured to provide information for accessing the first results through the first results gate to the client component.
57. The device as recited in claim 51, wherein the first message includes information representing a computer programming language method call, wherein the service comprises one or more computer programming language methods, and wherein one of the methods corresponds to the method call included in the first message.
58. The device as recited in claim 51, wherein the first results are generated as output of the method corresponding to the method call included in the first message.
59. The device as recited in claim 51, wherein, in said generating a first results gate, the first gate unit is further configured to:
receive a second message in the data representation language, wherein the second message includes an address of the first results; and
generate the first results gate in accordance with information for generating the first results gate obtained through the address.
60. The device as recited in claim 51, wherein the first gate unit is further configured to provide information for accessing the first results through the first results gate to the client component.
61. The device as recited in claim 51,
wherein the first results is comprised in a first computer programming language results object, wherein the first computer programming language results object further comprises one or more computer programming language access methods for accessing the first results, wherein the one or more access methods are invokable through one or more computer programming language access method calls;
wherein, in said accessing the first results, the first results gate is configured to:
receive from the client component a first access method call of the one or more access method calls, wherein the first access method call is associated with a first access method of the one or more access methods;
send a second message in the data representation language to a second results gate, wherein the second message includes a data representation language representation of the first access method call; and
wherein the second results gate is configured to invoke the first access method in accordance with the representation of the first access method call included in the second message.
62. The device as recited in claim 61, wherein the first results gate is further configured to:
receive a third message in the data representation language from the second results gate, wherein the third message includes first access method results produced by the second results gate invoking the first access method in accordance with the representation of the first access method call included in the second message; and
provide the first access method results to the client component.
63. The device as recited in claim 62,
wherein, in said providing the first access method results to the client component, the first results gate is further configured to generate a third results gate;
wherein the third results gate is configured to provide an interface to the first access method results through messages in the data representation language.
64. The device as recited in claim 51, wherein, in said accessing the first results, the first results gate is further configured to:
receive from the client component a first computer programming language method call, wherein the first computer programming language method call is associated with a first method for accessing the first results; and
send a second message in the data representation language to a second results gate in response to receiving the first computer programming language method call, wherein the second message includes a request for the first results; and
receive a third message in the data representation language from the second results gate, wherein the third message includes the requested results.
65. The device as recited in claim 51, wherein the data representation language is eXtensible Markup Language (XML).
66. A computer accessible medium comprising program instructions, wherein the program instructions are computer-executable to implement:
a client sending a first message in a data representation language to a service accessible through the distributed computing environment, wherein the client comprises a client gate and where said sending a first message comprises the client gate sending the first message to the service, wherein the client comprises a client process and a client message gate;
the service generating first results in response to the first message;
the service storing the first results;
generating a first results gate configured to provide an interface to the first results through messages in the data representation language, wherein the first results gate is distinct from the client gate, wherein, in said generating a first results gate, the program instructions are further computer-executable to implement the client message gate receiving a second message in the data representation language, wherein the second message includes an address of the stored first results;
wherein said generating a first results gate is performed by the client message gate in accordance with information for generating the first results gate obtained through the address; and
the client accessing the first results through the first results gate.
67. The computer accessible medium as recited in claim 66, wherein the client comprises a client process, wherein, in said sending a first message, the program instructions are further computer-executable to implement:
the client gate receiving from the client process a request for the service to perform a function on behalf of the client process; and
the client gate sending the first message to the service in response to said receiving a request; and
providing the first results gate to the client process as results of the function.
68. The computer accessible medium as recited in claim 67, wherein said generating a first results gate is performed by the client gate.
69. The computer accessible medium as recited in claim 67, wherein the program instructions are further computer-executable to implement the client gate attaching an authentication credential to the first message prior to said sending the first message, wherein the authentication credential identifies the client, and wherein the first results gate is configured to attach the authentication credential to outgoing messages.
70. The computer accessible medium as recited in claim 66, wherein the first message includes information requesting the service to perform a function on behalf of the client, and wherein, in said generating first results, the program instructions are further computer-executable to implement:
the service performing the function; and
generating the first results as output of said performing the function.
71. The computer accessible medium as recited in claim 66, wherein the program instructions are further computer-executable to implement:
the client message gate receiving a second message in the data representation language from the service in response to said generating first results, wherein said generating a first results gate is performed by the client message gate in response to said receiving a second message; and
the client message gate providing information for accessing the first results through the first results gate to the client process.
72. The computer accessible medium as recited in claim 66, wherein the first message includes information representing a computer programming language method call, wherein the service comprises one or more computer programming language methods executable within the service, and wherein one of the methods executable within the service corresponds to the method call included in the first message.
73. The computer accessible medium as recited in claim 72, wherein, in said generating results, the program instructions are further computer-executable to implement:
the service executing a computer programming language method in accordance with the information representing the computer programming language method call included in the first message; and
generating the first results as output of said executing a method.
74. The computer accessible medium as recited in claim 72, wherein the client comprises a client method gate, wherein, in said sending a first message, the program instructions are further computer-executable to implement:
the client method gate receiving the computer programming language method call from a first process executing within the client; and
the client method gate generating the first message for the first process.
75. The computer accessible medium as recited in claim 74,
wherein the program instructions are further computer-executable to implement the service storing the first results; and
wherein, in said generating a first results gate, the program instructions are further computer-executable to implement:
the client method gate receiving a second message in the data representation language, wherein the second message includes an address of the stored first results, wherein said generating a first results gate is performed by the client method gate in accordance with information for generating the first results gate obtained through the address.
76. The computer accessible medium as recited in claim 74, wherein the program instructions are further computer-executable to implement:
the client method gate receiving a second message in the data representation language in response to said generating first results, wherein said generating a first results gate is performed by the client method gate in response to said receiving a second message; and
the client method gate providing information for accessing the first results through the first results gate to the first process.
77. The computer accessible medium as recited in claim 66, wherein the first results is comprised in a first computer programming language results object, wherein the first computer programming language results object further comprises one or more computer programming language access methods for accessing the first results, wherein the one or more access methods are invokable through one or more computer programming language access method calls, and wherein, in said accessing the first results through the first results gate, the program instructions are further computer-executable to implement:
the first results gate receiving from a first process executing within the client a first access method call of the one or more access method calls, wherein the first access method call is associated with a first access method of the one or more access methods;
the first results gate sending a second message in the data representation language to a second results gate, wherein the second message includes a data representation language representation of the first access method call; and
the second results gate invoking the first access method in accordance with the representation of the first access method call included in the second message.
78. The computer accessible medium as recited in claim 77, wherein the program instructions are further computer-executable to implement:
the second results gate sending a third message in the data representation language to the first results gate, wherein the third message includes first access method results; and
the first results gate providing the first access method results to the first process.
79. The computer accessible medium as recited in claim 78, wherein, in said providing the first access method results to the first process, the program instructions are further computer-executable to implement generating a third results gate configured to provide an interface to the first access method results through messages in the data representation language.
80. The computer accessible medium as recited in claim 66, wherein, in said accessing the first results through the first results gate, the program instructions are further computer-executable to implement:
the first results gate receiving from a first process executing within the client a first computer programming language method call, wherein the first computer programming language method call is associated with a first method for accessing the first results;
the first results gate sending a second message in the data representation language in response to receiving the first computer programming language method call, wherein the second message includes a request for the first results; and
the second results gate sending a third message in the data representation language to the first results gate, wherein the third message includes the requested results.
81. The computer accessible medium as recited in claim 66, wherein the data representation language is eXtensible Markup Language (XML).
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to distributed computing environments including Web-centric and Internet-centric distributed computing environments, and more particularly to a method for receiving results data in a heterogeneous distributed computing environment based upon a message passing model for connecting network clients and services.
2. Description of the Related Art
Intelligent devices are becoming increasingly common. Such devices range from smart appliances, personal digital assistants (PDAs), cell phones, lap top computers, desktop computers, workstations, mainframes; even, super computers. Networks are also becoming an increasingly common way to interconnect intelligent devices so that they may communicate with one another. However, there may be large differences in the computing power and storage capabilities of various intelligent devices. Devices with more limited capabilities may be referred to as small footprint devices or "thin" devices. Thin devices may not be able to participate in networks interconnecting more capable devices. However, it may still be desirable to interconnect a wide variety of different types of intelligent devices.
The desire to improve networking capabilities is ever increasing. Business networks are expanding to include direct interaction with suppliers and customers. Cellular phones, personal digital assistants and Internet-enabled computers are commonplace in both business and the home. Home networks are available for interconnecting audio/visual equipment such as televisions and stereo equipment to home computers, and other devices to control intelligent systems such as security systems and temperature control thermostats. High bandwidth mediums such as cable and ASDL enable improved services such as Internet access video on demand, e-commerce, etc. Network systems are becoming pervasive. Even without a formal network, it is still desirable for intelligent devices to be able to communicate with each other and share resources.
Currently, traditional networks are complex to set up, expand and manage. For example, adding hardware or software to a network often requires a network administrator to load drivers and configure systems. Making small changes to a network configuration may require that the entire network be brought down for a period of time. Also, certain intelligent devices may not support the necessary interfaces to communicate on a given network.
What is needed is a simple way to connect various types of intelligent devices to allow for communication and sharing of resources while avoiding the interoperability and complex configuration problems existing in conventional networks. Various technologies exist for improving the addition of devices to a network. For example, many modern I/O buses, such as the Universal Serial Bus, 1394 and PCI, support plug and play or dynamic discovery protocols to simplify the addition of a new device on the bus. However, these solutions are limited to specific peripheral buses and are not suitable for general networks.
A more recent technology, Jini from Sun Microsystems, Inc., seeks to simplify the connection and sharing of devices such as printers and disk drives on a network. A device that incorporates Jini may announce itself to the network, may provide some details about its capabilities, and may immediately become accessible to other devices on the network. Jini allows for distributed computing where the capabilities of the various devices are shared on a network. The Jini technology seeks to enable users to share services and resources over a network. Another goal of the Jini technology is to provide users with easy access to resources anywhere on the network while allowing the network location of the user to change. Jini also seeks to simplify the task of building, maintaining and altering a network of devices, software and users.
Jini requires that each Jini enabled device has a certain amount of memory and processing power. Typically, a Jini enabled device is equipped with a Java Virtual Machine (JVM). Thus, Jini systems are Java technology centered. Java is a high level object oriented programming language developed by Sun Microsystems, Inc. Java source code may be compiled into a format called bytecode, which may then be executed by a Java Virtual Machine.
Bytecode is computer source code that is processed by a virtual machine, rather than the "real" computer machine, the hardware processor. The virtual machine converts generalized machine instruction (the bytecode) into specific machine instructions (instructions that the computer's processor will understand). Using a language that comes with a virtual machine for each platform, the source language statements may be compiled only once and may then run on any platform that supports the virtual machine. The Java programming language is an example of such a language, and the Java Virtual Machine (JVM) is an example of a virtual machine platform that supports programs written in the Java programming language.
Since Java Virtual Machines may be provided for most computing platforms, Java and thus Jini provide for a certain amount of platform independence. The Jini architecture leverages off the assumption that the Java programming language is the implementation language for the components of the Jini system. The ability to dynamically download and run Java code is central to many features of the Jini architecture.
The purpose of the Jini architecture is to federate groups of devices and software components into a single dynamic distributed system. A key concept within the Jini architecture is that of a service. A service is an entity that can be used by a person, a program, or another service. Two examples of services are printing a document and translating from one word processor format to another. Jini allows the members of a Jini system to share access to services. Services in a Jini system communicate with each other by using a service protocol, which is a set of interfaces written in the Java programming language. Services are found and resolved in a Jini system by a look-up service. A look-up service maps interfaces indicating the functionality provided by a service to sets of objects that implement the service.
Descriptive entries may also be associated with a service. Devices and applications use a process known as discovery to register with the Jini network. Once registered, the device or application places itself in the look-up service. The look-up service may store not only pointers to these services on the network, but also may store the code for accessing these services. For example, when a printer registers with the look-up service, it loads its printer driver and/or an interface to the driver into the look-up service. When a client wants to use the printer, the driver and driver interface get downloaded from the look-up service to the client. This code mobility means that clients can take advantage of services from the network without pre-installing or loading drivers or other software.
Communication between services in a Jini system is accomplished using the Java Remote Method Invocation (RMI). RMI is a Java programming language enabled extension to traditional remote procedure call mechanisms. RMI allows not only data to be passed from object to object around the Jini network, but full objects including code as well. Jini systems depend upon this ability to move code around the network in a form that is encapsulated as a Java object.
Access to services in a Jini system is lease based. A lease is a grant of guaranteed access over a time. Each lease is negotiated between the user of the service and the provider of the service as part of the service protocol. A service may be requested for some period and access may be granted for some period presumably considering the request period. Leases must be renewed for a service to remain part of the Jini system.
FIG. 1 illustrates the basic Jini technology stack. The Jini technology defines a distributed programming model 12 (supported by JavaSpaces, leases, and object templates). Object communication in Jini is based on an RMI layer 14 over a TCP/IP capable networking layer 16.
Jini is a promising technology for simplifying distributed computing. However, for certain types of devices, Jini may not be appropriate. The computing landscape is moving toward a distributed, Web-centric service and content model where the composition of client services and content changes rapidly. The client of the future may be a companion type device that users take with them wherever they go. Such a device may be a combination of a cell phone and a PDA for example. It would be desirable for such devices to be able to communicate and share resources with more powerful devices as well as thinner or less powerful devices.
Also, with the advent of the Internet and resulting explosion of devices connected to the net, a distributed programming model designed to leverage this phenomenon is needed. An enabling technology is needed that facilitates clients connecting to services in a reliable and secure fashion. Various clients from thick to thin and services need to be connected over the Internet, corporate Internets, or even within single computers. It is desirable to abstract the distance, latency and implementation from both clients and services.
The key challenge for distributed computing technology is to be scalable from powerful thick clients down to very thin clients such as embedded mobile devices. Current distributed computing technologies, such as Jini, may not be scalable enough for the needs of all types of clients. Some devices, such as small footprint devices or embedded devices, may lack sufficient memory resources and/or lack sufficient networking bandwidth to participate satisfactorily in current distributed computing technologies. The low end of the client spectrum, including embedded mobile devices, often have limited or fixed code execution environments. These devices also may have minimal or no persistent storage capabilities. Most small, embedded mobile devices do not support a Java Virtual Machine. Most code-capable small clients run native code only. Also, most small devices have little more than flash memory or battery backed RAM as their sole persistent storage media. The size of the storage is often very small and sometimes read-only in nature. Furthermore, the access time of this type of storage media is often an order of magnitude greater than hard disk access time in more powerful clients.
Existing connection technologies, such as Jini, may not be as scalable as desired because they are too big. For example, Jini requires that all participants support Java; however, many small clients may not have the resources for a Java Virtual Machine. Furthermore, due to its use of RMI, Jini requires that clients be able to download code and content. Jini may augment the existing client platform by downloading new classes, which may pose security and size concerns for small devices such as embedded devices. Jini works by clients and resources communicating by passing code and data. When a client activates a Jini service, the service may return its results to the client, which may include a large amount of code or content. In Jini, a client may call a method and a large object may be returned, and thus downloaded. The client may not have the resource to accept the returned object. Also, RMI and Java itself require a lot of memory. Many small foot print devices may not have the resources to participate effectively or at all in current distributed computing technologies.
Another concern with existing distributed computing technologies is that they often require certain levels of connection capability and protocols. For example, Jini assumes the existence of a network of reasonable speed for connecting computers and devices. Jini also requires devices to support TCP/IP network transport protocol. However, many smaller devices may have limited connection capabilities. Small devices may have high latency or low speed network connections and may not support TCP/IP.
As mentioned above, Jini requires devices to support Java and thus include a Java Virtual Machine, which requires a certain amount of processing and storage capabilities that might not be present for many small devices. This also restricts the flexibility of Jini in that non-Java devices may not directly participate in a Jini system. Since Jini requires Java, it may be deemed a homogenous environment. However, it is desirable to have a distributed computing facility for heterogeneous distributed computing that scales from extremely small embedded devices through PDA's and cell phones to laptops and beyond even to the most powerful computers.
Other heterogeneous solutions exist, such as the Common Object Request Broker Architecture (CORBA). CORBA is an architecture that enables program objects to communicate with one another regardless of the programming language they were written in or what operating system they're running on. However, CORBA does not address all of the connection issues that are addressed by Jini. Also, CORBA suffers from similar scalability problems as Jini.
Technology such as Jini and CORBA use a code-centric programming model to define the interface between remote components. A code-centric programming model defines programmatic interfaces or API's for communication between remote clients or components. The API's may be defined in a particular programming language. The API's must be agreed to by all software components to ensure proper interoperability. Since all access to components is through the use of these standards API's, the code that implements these API's must be present in the client platform. The code may be statically linked into the platform or dynamically downloaded when needed. Many embedded or mobile devices simply cannot accept code dynamically from a network due to the quality control issues involved as well as the reliance on a single language and program execution environment. Data-centric models, such as networking protocols, may avoid the dependence on moving code; however, such protocols are not rich enough to easily provide for distributed computing and they also lack the ease of programming with code and other programming features, such as type safety.
Conventional distributed computing systems rely on the ability of a program executing on a first device to be able to remotely call a program on a second device and have the results returned to the first device. The Remote Procedure Call (RPC) is a basic mechanism for remotely calling a program or procedure. CORBA and Jini are both based on the ability to remotely invoke program methods. However, communicating by passing code or objects, such as in Jini or CORBA, may be somewhat complex. For example, as mentioned above, Jini uses the Java Remote Method Invocation (RMI) to communicate between services. In order for a client to move Java objects to and from remote locations, some means of serialization/deserialization is needed. Such current facilities in the Java Development Kit (JDK) rely upon the reflection API to determine the content of a Java object, and ultimately that code must consult the Virtual Machine. This code is quite large and inefficient.
The fundamental problems with the current method for doing serialization/deserialization include its size, speed, and object traversal model. Code outside the JVM does not know the structure or graph of a Java object and thus must traverse the object graph, pulling it apart, and ultimately must call upon the JVM. Traditional serialization and reflection mechanisms for storing and moving Java objects are just not practical for all types of devices, especially thinner devices. Some of the difficulties with Java reflection and serialization are that an object's graph (an object's transitive closure) reflection is difficult to do outside the JVM. Serialization is too large, requiring a large amount of code. Also, serialization is a Java specific object interchange format and thus may not be used with non-Java devices.
The Jini distributed computing model requires the movement of Java objects between Java devices. Thus, the serialization mechanism itself is not platform independent since it may not be used by non-Java platforms to send and receive objects. Serialization is a homogenous object format—it only works on Java platforms. Serialization uses the reflection API and may be limited by security concerns, which often must be addressed using native JVM dependent methods. The reflection API may provide a graph of objects, but is inefficient due to the number of calls between the JVM and the code calling the reflection methods.
The use of Java reflection to serialize an object requires an application to ping pong in and out of the JVM to pick apart an object one field at a time as the transitive closure of the object is dynamically analyzed. Deserializing an object using Java deserialization requires the application to work closely with the JVM to reconstitute the object one field at a time as the transitive closure of the object is dynamically analyzed. Thus, Java serialization/deserialization is slow and cumbersome while also requiring large amounts of application and JVM code as well as persistent storage space.
Even for thin clients that do support Java, the Jini RMI may not be practical for thin clients with minimal memory footprints and minimal bandwidth. The serialization associated with the Jini RMI is slow, big, requires the JVM reflection API, and is a Java specific object representation. Java deserialization is also slow, big and requires a serialized-object parser. Even Java based thin clients may not be able to accept huge Java objects (along with needed classes) being returned (necessarily) across the network to the client as required in Jini. A more scalable distributed computing mechanism is needed. It may be desirable for a more scalable distributed computing mechanism to address security concerns and be expandable to allow for the passing of objects, such as Java objects, and even to allow for process migration from one network mode to another.
Object based distributed computing systems need persistent storage. However, as discussed above, attempts at object storage are often language and operating system specific. In addition, these object storage systems are too complicated to be used with many small, embedded systems. For example, the Jini technology uses JavaSpaces as persistent object containers. However, a JavaSpace can only store Java objects and cannot be implemented in small devices. Each object in a JavaSpace is serialized and pays the above-described penalties associated with Java serialization. It may be desirable to have a heterogeneous object repository for distributed computing that may scale from small to large devices.
It is desirable in object oriented distributed systems to be able to locate object repositories and find particular objects within those repositories. As mentioned above, the Jini look-up server may not be practical for small devices with small memory footprints. A more efficient mechanism for locating object stores may be desirable.
Distributed object access also desires a fair and efficient sharing mechanism. As described above Jini currently uses a leasing mechanism to share objects. However, Jini leases are time based which may result in a number of problems. For example, the current object holder might have no idea how long to lease an object and may hold it too long. Also, the use of time-based leases may require that time be synchronized between multiple machines. Moreover time based leasing may require operating system support. Also, Jini leases are established and released via RMI. Thus, the Jini leasing mechanism suffers from the above-noted problems with using RMI. Other leasing mechanisms may be desirable.
Generally speaking, it is desirable for small memory foot print mobile client devices to be able to run a variety of services, both legacy and new, in a distributed environment. The types of small clients may include cell phones and PDA's with a variety of different networking interfaces, typically low bandwidth. Often these devices have very small displays with limited graphics, but they could include laptops and notebook computers, which may have a larger display and more sophisticated graphics capabilities. The services may be a wide range of applications as well as control programs for devices such as printers. It is desirable for a mobile client to be able to use these services wherever they may be.
A mobile client will often be at a temporary dynamic network address, so networking messages it sends cannot be routed beyond that networking interface (otherwise there may be collisions when two different clients on different networks have the same dynamic address). Mobile clients often do not have the capability for a full function browser or other sophisticated software. The displays may limit the client from running certain applications. Traditional application models are based on predetermined user interface or data characteristics. Any change to the application requires recompilation of the application.
It may be desirable for such clients to have a mechanism for finding and invoking distributed applications or services. The client may need to be able to run even large legacy applications which could not possibly fit in the client's memory footprint. As discussed above, current technology, such as Jini, may not be practical for small footprint devices. The pervasiveness of mobile thin clients may also raise additional needs. For example, it may be desirable to locate services based on the physical location of the user and his mobile client. For example, information about the services in a local vicinity may be very helpful, such as local restaurants, weather, traffic maps and movie info.
Similarly, information about computing resources, such as printers in a particular location, may be helpful. Current technologies do not provide an automatic mechanism for locating services based on physical location of the client. Another need raised by thin mobile clients is that of addressing the human factor. Thin mobile clients typically do not contain ergonomic keyboards and monitors. The provision of such human factor services and/or the ability to locate such services in a distributed computing environment may be desirable.
SUMMARY OF THE INVENTION
Embodiments of a mechanism for providing results gates in a distributed computing environment are described. Results gates may be provided to clients in the distributed computing environment and used by the clients to access results generated by services on behalf of the clients. A client may generate a request message for a service. The request message may include information requesting the service to perform a function on behalf of the client. In one embodiment, the request message may be generated by a client method gate, and may include a data representation language (e.g. XML) representation of the method call.
The client may send the message to the service. In one embodiment, the message may be sent by a client message gate. In another embodiment, the message may be sent by a client method gate. In yet another embodiment, the message may be generated by a client method gate, passed to a client message gate, and sent to the service by the client message gate. The service may receive the message and generate results in response to the message. In one embodiment, the message includes a data representation language representation of a computer programming language method call. In this embodiment, a service method gate may receive the message and regenerate the method call from the representation of the method call. A computer programming language method (e.g. Java method) may then be invoked using the method call. The invoked method may generate the results. The service may store the generated results. The service may then send an address (e.g. URI) of the results to the client. Alternatively, the service may return the results directly to the client in one or more messages. In one embodiment, the results may be comprised in a data representation language document. In another embodiment, the results may be comprised in a data representation language representation of a computer programming language object (e.g. Java object).
A results gate may be generated for accessing the results. In one embodiment, the results gate may be generated by the service and sent to the client. In another embodiment, the service may send an address of the results to the client, and the client may generate the results gate from information (e.g. an advertisement for the results) located through the address. In yet another embodiment, the service may send the results to the client, and the client may generate a results gate for the results. In one embodiment, a message schema may be provided in used in generating the results gate. The message schema may include information describing one or more data representation language messages for accessing the results. In one embodiment, a gate on the client may generate the results gate. In one embodiment, the gate may provide information to a gate factory, and the gate factory may generate the results gate. In one embodiment, the gate may be a method gate, and the results may have been generated in response to a computer programming language method performed by the service. In one embodiment, the results gate may share authentication information with the generating gate. For example, the gate may attach an authentication credential of the client to outgoing messages. The gate may provide the same authentication credential to the results gate for use in outgoing messages.
The results may be accessed through the results gate. In one embodiment, the results are an object (e.g. Java object), and the results gate is an object proxy for the results object. In this embodiment, a client process (e.g. Java program) accessing the results object through the results gate may not be able to distinguish the results gate object proxy from the real results object. In this embodiment, the results gate may be returned to the process as results of the method call made by the process. In one embodiment, the results gate is a method gate and provides a method interface to the results. In this embodiment, the results gate supports a set of method calls for accessing the results. When receiving a method call from a client process, the results gate may convert the method call into a data representation language representation of the method call and send the representation in a message to the results location (e.g. space service) where the method call may be regenerated and the method invoked with the method call.
In one embodiment, a results gate may generate another results gate. For example, the results gate may generate a message to access the results, and may receive a response to the message. The results gate may then generate a second results gate subsequent to receiving the response.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an illustration of a conventional distributed computing technology stack;
FIG. 2 is an illustration of a distributed computing environment programming model according to one embodiment;
FIG. 3 is an illustration of messaging and networking layers for a distributed computing environment according to one embodiment;
FIG. 4 is an illustration of a discovery service for finding spaces advertising objects or services in a distributed computing environment according to one embodiment;
FIG. 5 illustrates client profiles supporting static and formatted messages for a distributed computing environment according to one embodiment;
FIG. 6 is an illustration of a distributed computing model employing XML messaging according to one embodiment;
FIG. 7 illustrates a platform independent distributing computing environment according to one embodiment;
FIG. 8 is an illustration of a distributed computing model in which services are advertised in spaces according to one embodiment;
FIG. 9 is an illustration of a distributed computing model in which results are stored in spaces according to one embodiment;
FIG. 10a is an illustration of client and service gates as messaging endpoints in a distributed computing model according to one embodiment;
FIG. 10b is an illustration a message endpoint generation according to a schema for accessing a service according to one embodiment.
FIG. 11a illustrates gate creation in a distributed computing environment according to one embodiment;
FIG. 11b illustrates gate creation and gate pairs in a distributed computing environment according to one embodiment;
FIG. 12 is an illustration of possible gate components in a distributed computing environment according to one embodiment;
FIG. 13 is an illustration of proxy client for a conventional browser to participate in the distributed computing environment according to one embodiment;
FIG. 14 illustrates the use of a method gate to provide a remote method invocation interface to a service in a distributed computing environment according to one embodiment;
FIG. 15 is an illustration of the use of a space in a distributed computing environment according to one embodiment;
FIG. 16 illustrates advertisement structure according to one embodiment;
FIG. 17 illustrates one example of advertisement state transitions that an advertisement may undergo during its lifetime according to one embodiment;
FIG. 18 is an illustration various space location mechanisms in a distributed computing environment according to one embodiment;
FIG. 19 is an illustration of space federations in a distributed computing environment according to one embodiment;
FIG. 20 is a flow diagram illustrating client formation of a session with a space service in a distributed computing environment according to one embodiment;
FIG. 21 is an illustration of a space event type hierarchy for one embodiment;
FIG. 22 is a flow diagram illustrating service instantiation in a distributed computing environment according to one embodiment;
FIG. 23 is an illustration of a default space in a distributed computing environment according to one embodiment;
FIG. 24 illustrates an example of a device bridging proximity-based devices onto another transport mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the proximity range of the devices, according to one embodiment;
FIG. 25 is an illustration of the use of lease renewal messages in a distributed computing environment according to one embodiment;
FIG. 26a is a flow diagram illustrating an authentication service providing an authentication credential to a client according to one embodiment;
FIG. 26b is a flow diagram expanding on step 1002 of FIG. 26a and illustrating an authentication service generating an authentication credential according to one embodiment;
FIG. 27 illustrates one embodiment of a bridging mechanism;
FIG. 28 illustrates an example of a space discovery protocol mapped to an external discovery service according to one embodiment;
FIG. 29 illustrates bridging a client external to the distributed computing environment to a space in the distributed computing environment according to one embodiment;
FIG. 30 is an illustration of a proxy mechanism according to one embodiment;
FIG. 31 illustrates one embodiment of a client with an associated display and display service according to one embodiment;
FIGS. 32A and 32B illustrate examples of using schemas of dynamic display objects according to one embodiment;
FIG. 33A illustrates a typical string representation in the C programming language;
FIG. 33B illustrates an example of a conventional string function;
FIG. 33C illustrates an efficient method for representing and managing strings in general, and in small footprint systems such as embedded systems in particular according to one embodiment;
FIG. 34 illustrates a process of moving objects between a client and a service according to one embodiment;
FIGS. 35a and 35b are data flow diagrams illustrating embodiments where a virtual machine (e.g. JVM) includes extensions for compiling objects (e.g. Java Objects) into XML representations of the objects, and for decompiling XML representations of (Java) objects into (Java) objects;
FIG. 36 illustrates a client and a service accessing store mechanisms in the distributed computing environment, according to one embodiment;
FIG. 37 illustrates process migration using an XML representation of the state of a process, according to one embodiment;
FIG. 38 illustrates a mobile client device accessing spaces in a local distributed computing network, according to one embodiment;
FIG. 39a illustrates a user of a mobile device discovering the location of docking stations, according to one embodiment;
FIG. 39b illustrates a mobile client device connecting to a docking station, according to one embodiment;
FIG. 40a illustrates an embodiment of embedded devices controlled by a control system and accessible within the distributed computing environment, according to one embodiment;
FIG. 40b illustrates a device control system connected via a network (e.g. the Internet) to embedded devices accessible within the distributed computing environment, according to one embodiment;
FIG. 41 is a flow diagram illustrating creating a gate according to one embodiment;
FIG. 42a is a flow diagram illustrating a client sending a message to a service according to one embodiment;
FIG. 42b is a flow diagram illustrating a service receiving a message from a client and using an authentication service to authenticate the message according to one embodiment;
FIG. 42c is a flow diagram illustrating the general process of a client and service exchanging messages with embedded authentication credential according to one embodiment;
FIG. 43 is a flow diagram illustrating a mechanism for checking the integrity of messages according to one embodiment;
FIG. 44 is a flow diagram illustrating a mechanism for leasing resources according to one embodiment;
FIGS. 45a-45e are flow diagrams illustrating various embodiments of a mechanism for communicating between clients and services using method gates;
FIG. 46 is a flow diagram illustrating a mechanism for sending objects from services to clients using XML representations of the objects;
FIG. 47 is a flow diagram illustrating a mechanism for secure object decompilation on a client device;
FIG. 48 is a flow diagram illustrating a mechanism for migrating processes using data representation language representations of the processes in a distributed computing environment; and
FIG. 49 is a flow diagram illustrating a mechanism for providing results gates according to one embodiment.
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
Overview of Embodiments for Distributed Computing
Turning now to FIG. 2, a distributed computing environment programming model is illustrated. The model includes API layer 102 for facilitating distributed computing. The API layer 102 provides an interface that facilitates clients connecting to services. The API layer 102 is concerned with the discovery of and the connecting of clients and services. The API layer 102 provides send message and receive message capabilities. This messaging API may provide an interface for simple messages in a representation data or meta-data format, such as in the eXtensible Mark-up Language (XML). Note that while embodiments are described herein employing XML, other meta-data type languages or formats may be used in alternate embodiments. In some embodiments, the API layer may also provide an interface for messages to communicate between objects or pass objects, such as Java objects. API's may be provided to discover an object repository or "space", find a particular object, claim and release an object, and write or take an object to or from the object repository. Objects accessible through API layer 102 may be represented by a representation data format, such as XML. Thus, an XML representation of an object may be manipulated, as opposed to the object itself.
API layer 102 sits on top of a messaging layer 104. The messaging layer 104 is based on a representation data format, such as XML. In one embodiment, XML messages are generated by messaging layer 104 according to calls to the API layer 102. The messaging layer 104 may provide defined static messages that may be sent between clients and services. Messaging layer 104 may also provide for dynamically generated messages. In one embodiment, an object, such as a Java object, may be dynamically converted into an XML representation. The messaging layer 104 may then send the XML object representation as a message. Conversely, the messaging layer 104 may receive an XML representation of an object. The object may then be reconstituted from that message.
In one embodiment, messages sent by messaging layer 104 may include several basic elements, such as an address, authentication credentials, security tokens, and a message body. The message system transmission and receive mechanisms may be completely stateless. Any notion of state may be embedded in the message stream between sender and receiver. Thus, message transmission may be done asynchronously. In a preferred embodiment, no connection model is imposed. Thus, transports such as TCP are not required. Also, error conditions may be limited to non-delivery or security exceptions.
Messaging layer 104 sits on top of a message capable networking layer 106. In a preferred embodiment, messaging layer 104 does not require that a particular networking protocol be used. TCP/IP and UDP/IP are examples of message capable protocols that may be used for message capable networking layer 106. However, other more specialized protocols such as the Wireless Application Protocol (WAP) may also be used. Other possible message protocols are IrDA and Bluetooth network drivers beneath the transport layer. Networking layer 106 is not limited to a single reliable connection protocol, such as TCP/IP. Therefore, connection to a larger variety of devices is possible.
In one embodiment, message capable network layer 106 may be implemented from the networking classes provided by the Java2 Micro Edition (J2ME) platform. The Java2 Micro Edition platform may be suitable for smaller footprint devices that do not have the resources for a full Java platform or in which it would not be efficient to run a full Java platform. Since J2ME already provides a message capable family of networking protocols (to support sockets), it follows that for the small footprint cost of adding messaging layer 104, distributing computing facilities may be provided for small devices that already include J2ME.
Message capable networking layer 106 may also be provided by the Java Development Kit's (JDK) java.net networking classes. Alternatively, any message capable networking facilities may be used for message capable networking layer 106. In a preferred embodiment, a reliable transport is not required, thus embedded devices supporting an unreliable data gram transport such as UDP/IP may still support the messaging layer.
Thus, thin clients may participate in a distributed computing environment by simply adding a thin messaging layer 104 above a basic networking protocol stack. As shown in FIG. 3, a basic system includes messaging layer 104 on top of a networking layer 106. The networking layer may provide for reliable messages, e.g. TCP, or unreliable messages, e.g. UDP. The Internet Protocol (IP) is shown in FIG. 3 as an example of protocol that may be used in networking layer 106. However, the distributed computing environment does not require IP. Other protocols may be used in the distributed computing environment besides IP. A network driver such as for Ethernet, Token Ring, Bluetooth, etc. may also be part of the networking layer. Many small clients already provide a network driver and transport protocol such as UDP/IP. Thus, with the addition of the thin XML based messaging layer, the device may participate in the distributed computing environment.
Thus, the foundation for the distributed computing environment is a simple message passing layer implemented on top of reliable connection and/or unreliable data grams. The messaging technology is very different from communications technologies employed in other distribution computing systems, such as Jini which employs the Java remote method invocation (RMI). The message passing layer 104 supports an asynchronous, stateless style of distributed programming, instead of the synchronous, state-full style predicated by RMI. Moreover, message passing layer 104 is based on a data representation language such as XML and thus copies data, but not code, from source to destination, unlike RMI. By using a representation data language, such as XML, messaging layer 104 may interoperate with non-Java and non-Jini platforms in a seamless fashion because Java code is not assumed on the sending or receiving end of a message. Moreover, unlike RMI, messaging layer 104 does not require a reliable transport mechanism such as TCP/IP.
The message passing layer may provide simple send( ) and receive( ) methods to send a message specified as an array or string of bytes, for example. The send( ) method may return immediately, performing the data transfer asynchronously. For flow control purposes a callback method may be supplied which is invoked in the event that the send( ) method throws an exception indicating it cannot handle the send( ) request. The receives method may be synchronous and may return the next available message.
The message passing layer may also provide methods for storing XML representations of objects, services and content in "spaces". A space is named and accessed on the network using an URI (Uniform Resource Identifier). The URI may be a URL (Uniform Resource Locator) or a simpler version of a URL. In some embodiments, the URL class may be too large. For such embodiments a simpler resource locator may be used that specifies the protocol for moving the messages between client and server, protocol dependent host ID, protocol dependent port ID, and a space name.
An XML representation of an object may be added to a space using a write( ) method provided by the messaging layer. In one embodiment, the object and the client-specified name may be supplied as parameters. In one embodiment, the write method may translate the object into its XML representation. A take( ) method may be provided to return the object and remove it from the space. A find( ) method may be provided to return a specified object from its XML representation in a space. The find( ) method may also be used to return an array of matching objects in a space given a class. Each of these space methods is implemented using the message-passing layer. A lease mechanism may also be provided, as described in more detail below.
A discovery service may be provided for clients as a general search facility that may be used by a client to locate a particular space. Rather than attempt to define a complicated search protocol which may not be feasible for a thin client to implement, the discovery service may offload the actual search to XML-based search facilities, leaving the discovery service simply to provide interface functionality to the client. The approach is illustrated in FIG. 4. In one embodiment, the discovery service receives a string specifying something to locate, and it sends an XML message to a known discovery front-end (perhaps found in a default space), which then parses the string and makes a corresponding XML query to a search facility (which may be an internet search facility). The discovery front-end may parse what it obtains from the search facility and repackage it as an array of strings (each string may be a URI for each found space) which it may send in an XML message to the client. It should be noted that the discovery service does not require that the messaging be atop a connection-oriented transport. Thus, even very thin clients that do not have TCP could use such a discovery service. The discovery front-end makes it possible for the client to discover spaces without a browser or search facility on the client. The client only needs a simple facility that sends a string that specifies keywords to the front-end, which interfaces with a search facility.
A client may be any platform that can send a message using at least a subset of the API and messaging layers. In one embodiment the API layer may provide for both static (or raw) and formatted (or cooked) messages. A server may be any platform capable of receiving and fulfilling message requests. An explicit raw message send may be provided that moves a series of bytes from a client to a server or to another client. The message type may be specified as reliable (e.g. TCP) or unreliable (e.g. UDP). The smallest of devices may use raw unreliable message passing as their sole means of participation in the distributed computing environment. The device may use these messages to announce its presence and its status. Such small devices may also receive raw messages to implement certain functions, such as turning a feature on or off.
Message-based services such as spaces may send and receive reliable formatted messages. A space message may be formatted with a well-defined header and with XML. In one embodiment, a formatted message send may occur when a client uses a space method to claim, write, or take objects from a space. The message contents may be dynamically formatted in XML and contain well-defined headers. FIG. 5 illustrates client profiles supporting formatted and static messages. By using static messages, small devices may use a smaller profile of code to participate in the distributed computing environment. For example, a small device could just send basic pre-defined messages. Depending on the client, the static pre-defined messages may consume a small amount of memory (e.g. <200 bytes). Static messages may also be an option even for larger devices. On the other hand, the dynamic XML messages may be useful when object values are not known at compile time.
Turning now to FIG. 6, a distributed computing model is illustrated that combines a messaging system with XML messages and XML object representation. The platform independence of XML may be leveraged so that the system may provide for a heterogeneous distributed computing environment. Thus, client 110 may be implemented on almost any platform instead of a particular platform like Java. The messaging system may be implemented on any network capable messaging layer, such as Internet protocols (e.g. TCP/IP or UDP/IP). Thus, the computing environment may be distributed over the Internet. In one embodiment, the messaging system may also use shared memory as a quick interprocess message passing mechanism when the client and/or space server and/or service are on the same computer system. The distributed computing model of FIG. 6 may also be very scalable because almost any size client can be configured to send and/or receive XML messages.
As shown in FIG. 6, two kinds of software programs may run in the distributed computing model: services 112 and clients 110. Services 112 may advertise their capabilities to clients wishing to use the service. The services 112 may advertise their capabilities in spaces 114. As illustrated in FIG. 7, clients 110 and services 112 may or may not reside within the same network device. For example, devices 120 and 124 each support one client, whereas service 112a and client 110b are implemented in the same device 122. Also, as illustrated in FIG. 7, no particular platform is required for the devices to support the clients and services. For example, device 120 is Java based, whereas device 124 provides a native code runtime environment.
A device may be a networking transport addressable unit. Example devices include, but by no means are limited to: PDAs, cellular/mobile phones, notebook computers, laptops, desktop computers, more powerful computer systems, even supercomputers. Both clients and services may be URI-addressable instances of software (or firmware) that run on devices. Using the distributed computing environment architecture, a client may run a service. A space is a service that manages a repository of XML documents. Even though it is redundant, the term, space service, may be used herein for readability. A software component may be both a client and service at different times. For example, when a service uses a space (e.g. to advertise itself), that service is a client of the space.
FIG. 8 illustrates the basic model of the distributed computing environment in one embodiment. The distributed computing environment may connect clients 110 to services 112 throughout a network. The network may be a wide area network such as the Internet. The network may also be a combination of networks such as a local area network (LAN) connected to a wireless network over the Internet. As shown in FIG. 8, a service 112 publishes an advertisement 132 for itself (represented in XML) in a space 114. The advertisement 132 specifies the service's XML schema and URI address. Then, a client 110 may look up the advertisement 132. The client 110 may use the advertisement 132 to instantiate a gate 130. The gate 130 allows the client 110 to run the service 112, by sending (and receiving) XML messages to (and from) the service 112.
Some results of running a service may be returned to the client in an XML message. However, since other results may be too large for a small client to receive and consume at once, a service 112 may put those results or an XML representation of the results 134 in a space 114, as shown in FIG. 9, and return them by reference (in an XML message) to the client 110, rather than by value. Examples of methods of returning a reference to results include, but are not limited to: returning in the message a URI referencing the results in a space, and: returning in the message an XML document including the URI of the results. Later, the client 110 may access the results, or pass them by reference to another service. The space in which results may be stored may be different from the space in which the service is advertised.
In one embodiment, the distributed computing environment uses XML for content definition, advertisement and description. New content for the distributed computing environment (messages and advertisements for example) are defined in XML. Existing content types (e.g. developed for other environments) may also be described using XML as a level of indirection (meta-data). XML provides a powerful means of representing data throughout a distributed system because, similar to the way that Java provides universal code, XML provides universal data. XML is language agnostic and is self-describing. The XML content may be strongly typed and validated using schemas. Using a provided XML schema, the system may ensure that only valid XML content is passed in a message. XML content may also be translated, into other content types such as HTML and WML. Thus, clients that do not understand XML may still use the distributed computing environment services.
In one embodiment, the distributed computing environment messages may define the protocol used to connect clients with services, and to address content in spaces and stores. The use of messages to define a protocol allows many different kinds of devices to participate in the protocol. Each device may be free to implement the protocol in a manner best suited to its abilities and role. For example, not all devices are capable of supporting a Java runtime environment. The distributed computing environment protocol definition does not require nor imply the use of Java on a device. Nor does it preclude it.
A service's capabilities may be expressed in terms of the messages the service accepts. A service's message set may be defined using an XML schema. An XML message schema defines each message format using XML typed tags. The tag usage rules may also be defined in the schema. The message schema may be a component of an XML advertisement along with the service's message endpoint used to receive messages. The distributed computing environment may allow clients to use all or some subset of a service's capabilities. Security policies may be employed to enforce the set of capabilities given to a client. For example, once a set of capabilities has been given to a client, the client may not change that set without proper authorization. This model of capability definition allows for services levels that range from a base set of capabilities to an extended set. Extensions may be added to services by adding to the number of recognized messages.
In one embodiment, all operations in the distributed computing environment are embodied as XML messages sent between clients and services. Storage (both transient and persistent) providers are examples of services that enable clients and services to store, advertise, and address content. Clients and services may find each other and broker content using a transient storage space. Services may place a content or service advertisement in a space. The advertisement may describe the content type or the capabilities of the service. Clients may subsequently browse spaces looking for advertisements that match a desired set of capabilities. When a client finds a matching advertisement, a communication channel may be established which may enable bi-directional message passing to the service backing the advertisement. In one embodiment, the communication channel is authenticated. Results (which are just another content type) from service operations may be returned directly to the client in a response message, advertised and stored in a space, or advertised in a space, but stored persistently. Stored results may be addressed using a URI (e.g. returned in the response message) and may have an associated authentication credential.
Message Gates
As discussed above, the distributed computing environment leverages off the use of a data description language, such as XML. XML may be used to describe a target entity (e.g. document, service, or client) to an extent such that code may be generated to access that entity. The generated code for accessing the target entity may be referred to as a message gate. Thus, in one embodiment, the distributed computing environment differs from other distributed computing environments in that instead of passing the necessary code between objects necessary to access the other object, the environment provides access to XML descriptions of an object or target so that code may be generated based on the XML description to access the target. The distributed computing environment may use an XML schema to ensure type safety as well as a programming model (e.g. supported messages) without having to agree upon language specific APIs, just XML schemas.
Code generated from an XML schema may also incorporate the language, security, type safety, and execution environment characteristics of the local platform. The local platform may thus have control over the generated code to ensure that it is bug-free and produces only valid data according to the schema. The generated code may conform to the client's code execution environment (e.g. Java, C++, Smalltalk), as well as its management and security framework (Web-server and/or operating system).
Note that the distributed computing environment does not require that code generated from an XML schema be generated "on the fly" at runtime. Instead, some or all of the code may be pre-generated for categories (or classes) of services, and then linked-in during the platform build process. Pre-generation of code may be useful for some clients, such as embedded devices, where certain XML schemas are already known. In one embodiment, some or all of the code doesn't actually have to be generated at all. A private code-loading scheme (within the client) might be used in one embodiment to augment the generation process. In addition, the distributed computing environment may specify, in some embodiments, an interface to download code for additional features in accessing a service (see, e.g., message conductors described below). Typically, such downloaded code may be small and the client may have the option to download the code or not.
The phrase "generated code" may refer to code that originates within the client under the control of the client code execution environment, or to code that is generated elsewhere (such as on the service system or on a space service system) and that may be downloaded to the client system after generation. Binding time, however, may be at runtime. At runtime, the generated code may be bound to a service address (URI), so that a message may be sent to that service instance.
As discussed above, the interface to any service in the distributed computing environment may be specified by an XML schema, defining the set of messages that a client may send (and receive from) that service. As illustrated in FIG. 10, the client 110 and service 112 may each construct a message gate 130 for communicating according to the specified XML schema. From the XML schema advertised for the service 112 (and possibly other information in the service advertisement), a message gate 130a or 130b may be constructed by the client 110a or 110b respectively. A corresponding message gate 130c generated from the same XML schema may also exist on the service 112a. A gate 130 is a message endpoint that may send and/or receive type-safe XML messages, and that may verify the type correctness of XML messages when sending and/or receiving the messages. The message gate may also provide for authentication and/or other security mechanisms to ensure that the message endpoint is secure. In one embodiment, message gates are always secure.
The distributed computing environment messaging layer described above may be coupled to or may be part of the gate. The messaging layer asynchronously delivers an ordered sequence of bytes, using a networking transport, from the sender to the receiver, maintaining the notion on both the sender and receiver that this sequence of bytes is one atomic unit, the message. The distributed computing environment does not assume that the networking transport is IP-based. Instead, the messaging layer may sit atop whatever networking transport layer is supported by the device.
Message gates may provide a mechanism to send and receive XML messages between clients and services. The XML messages may be "typed". For example, the messages may include tags to indicate if a message data field is, e.g., integer, floating point, text data, etc. A message gate may be constructed to verify the type correctness of messages sent or received. A message gate also may authenticate (e.g. securely identify) the sender of a received message. An XML schema may be provided for a service that describes the set of messages accepted by the service and/or sent by the service. A message gate may verify the correctness of messages sent or received according to the XML schema for which the gate is constructed.
A gate may be constructed as a single atomic unit of code and data that performs type verification and/or message correctness verification and/or sender identification for messages between a client and a service in the distributed computing environment. In one embodiment, once the atomic unit of code and data for a message gate has been created, it cannot be altered as to its typing, message descriptors, and sender identification. In another embodiment, the gate may be modified as to the contents of the message schema after the gate is created, including deleting, adding, or modifying messages in the message schema.
A message gate is the message endpoint for a client or service in the distributed computing environment. A message gate may provide a secure message endpoint that sends and receives type-safe XML messages. Messages gates may allow clients and services to exchange XML messages in a secure and reliable fashion over any suitable message transport (e.g. HTTP). For a client, a message gate may represent the authority to use some or all of a service's capabilities. Each capability may be expressed in terms of a message that may be sent to a service. Each such message may be sent through a client message gate which may verify the correctness of the message. The message may be received by a service message gate which may authenticate the message and verify its correctness.
A message gate may provide a secure communication endpoint that type checks XML messages. As further discussed below, a message gate may also provide a mechanism to restrict the message flow between clients and services. In one embodiment when a client desires to access a service, a client and service message gate pair is created, if not already existing. In one embodiment, the service message gate may be created when the service receives a first message from the client message gate. In one embodiment, one or more service message gates may be created when the service is initialized, and may be used to pair with client message gates when created. The creation of a message gate may involve an authentication service that may negotiate the desired level of security and the set of messages that may be passed between client and service. In one embodiment, the authentication service may accept a client ID token (also referred to as a client token), a service ID token (also referred to as a service token), and a data representation language message schema that describes the set of data representation language messages that may be sent to or received from the service. For example, messages may be described that may be sent from a client to a service to invoke the service or to invoke aspects of the service. Messages may also be described that are to be sent from the service, such as response messages and event notification messages. Refer to the Authentication and Security section below for a further discussion of how the authentication service may be used in the construction and use of message gates.
A client message gate and a service message gate pair may allow messages to be sent between the client and the service. In one embodiment, message gates may be created that only send and/or receive a subset of the total set of messages as described in the message schema for a service. This limited access may be used within the distributed computing environment to implement a policy of least privilege whereby clients are only given access to specific individual message types, based on a security policy. Refer to the Authentication and Security section below for a further discussion of security checks for gate usage and gate creation.
Client and service gates may perform the actual sending (and receiving) of the messages from the client to the service, using the protocol specified in the service advertisement (URI of service in the service advertisement). The client may run the service via this message passing. A message gate may provide a level of abstraction between a client and a service. A client may access a service object through a message gate instead of accessing the service object directly. Since the gate abstracts the service from the client, the service's code may not need to be loaded, and then started, until the client first uses the service.
The client gate may also perform verification of the message against the XML schema, or verification of the message against the XML schema may be performed by the service gate, e.g. if the client indicates it has not yet been verified. In some embodiments, verification may not be practical for simple clients and may thus not be required at the client. In some embodiments, verification may be performed by the service. The gates may also perform authentication enablement and/or security schemes. In one embodiment, if a client does not support the protocol specified in the service advertisement, then it may not be able to construct the right gate. To avoid this problem, service advertisements (used for gate construction) may include a list of possible URIs for a service, so a variety of clients may be supported.
A basic message gate may implement an API to send and receive messages. The API moves data (e.g. XML messages) in and out of the gate, validating messages before sending and/or upon receiving. In one embodiment, message gates may support a fixed minimum API to send and receive messages. This API may be extended to other features as discussed below. As illustrated in FIG. 10b, a gate 130 may be generated according to an XML schema 132. The generated gate code verifies messages based upon the XML schema. The gate may verify correct message types and/or content through the message API. As illustrated in FIG. 10b, through the message API a verified message may be sent to a service. The message may be received by a corresponding gate at the service. In response to the message, the service may generate results 180. The service may return result data 182 through its gate. The results data may be the results themselves or a reference to the results, such as a URI to results stored in a space. In various embodiments, the message API may support synchronous messages (request-response), asynchronous messages (response is disconnected from request), unicast messages (point to point), multi-cast messages (broadcast), and publish and subscribe (event messages), for example. Other type of messages may also be supported, such as remote method invocation messages.
Each message sent by a gate may include an authentication credential so that the receiving gate may authenticate the message. Each message may also include a token which includes information allowing the receiving gate to verify that the message has not been compromised or altered. For example, the sender may compute a hash or checksum of the message which may be verified by the receiver. The sender may also encrypt this token and/or the entire message using the sender's private key and may include in the encrypted message the corresponding public key so that the receiver may verify that the token was not changed. See the section below on Authentication and Security.
A pair of message gates may provide a mechanism for communicating requests from clients to services and response from services to clients. Two associated message gate endpoints may be used to create a secure atomic bi-directional message channel for request-response message passing. Thus, the distributed computing environment may employ a message transport in which a message gate exists on both the client and the service sides. The two gates may work together to provide a secure and reliable message channel.
Turning now to FIG. 11a, an illustration is provided for one embodiment showing construction of a gate 130a in a client 110 from a service advertisement or other service description 132. The client may have a gate factory 140 that is trusted code on the client for generating gates based on XML service descriptions. The use of the gate factory 140 may ensure that the gate it generates is also trusted code, and that the code is correct with respect to the service advertisement. As shown in FIG. 11b, a gate 130c may also be constructed at a service 112. The client gate 130a and the service gate 130c provide message endpoints for communications between the client and service. In one embodiment, the pieces the gate factory needs to construct a gate 130 are the XML schema of the service (from the service advertisement) and the URI of the service (from the service advertisement). In another embodiment, an authentication credential may also be obtained and used in gate construction by running an authentication service specified in the service advertisement.
A gate factory may provide a trusted mechanism to create message gates. In some embodiments, in order to ensure that a message gate is a trusted message endpoint, the code used to create the gate must be trusted code. A gate factory 140 may be a trusted package of code that is used to create gates. In one embodiment, each client and service device platform that desires to send and receive messages in the distributed computing environment may have a gate factory. In some embodiments, gates may be pre-constructed by a separate gate factory so that a device with pre-constructed gates may not need a full gate factory, or may include a partial gate factory for binding a service URI and/or an authentication credential to the pre-constructed gate at runtime (e.g. when messaging is desired).
A gate factory for a device may generate gate code that may incorporate the language, security, type safety, and/or execution environment characteristics of the local device platform. By constructing gates itself, a device has the ability to ensure that the generated gate code is bug-free, produces only valid data, and provides type-safety. An advantage of a device generating its own gate code as opposed to downloading code for accessing a service is that the client code management environment has the control. The generated code may conform to the client's code execution environment (e.g. Java, C++, Smalltalk), as well as its management and security framework (Web-server and/or operating system). Generated code is also trusted code, because the client's runtime environment was involved in its creation. Trusted security information therefore may also be added by the trusted generated code. Thus, a device may receive an XML message schema for a service and then construct a gate based on that schema to access the device. The XML schema may be viewed as defining the contract with the service and the generated gate code as providing a secure way to execute the contract. Note that open devices, in which un-trusted (e.g. downloaded) code may be run, may be configured so that gates may be generated only by trusted code. Open devices may employ a process model in which gates are enclosed in a protected, isolated code container that is not accessible to tools, such as debuggers, capable of discovering the gate's implementation, especially the gates authentication credential.
A gate factory 140 may negotiate on behalf of a client with a service to create a gate to send messages to the service. Similarly, a gate may be constructed at the service to receive messages from the client gate and send messages to the client gate. Together, the client and service gates may form a secure bi-directional communication channel.
A gate factory may provide a level of abstraction in gate creation. For example, when a client desires to use a service, instead of the client directly creating a gate to access the service, the gate may be created by a gate factory as part of instantiating the service.
The gate factory may create or may include its own trusted message gate that is Ln used to communicate with an authentication service (e.g. specified by a service advertisement) to receive an authentication credential for the gate being constructed. For services that do not restrict access, a gate may be constructed without an authentication credential. The gates for such services may not need to send an authentication credential with each message since the service does not restrict access. The authentication service is an example of a service that does not restrict access, in one embodiment. Thus, a gate factory may be configured to optimize gate construction by checking whether a service restricts access. If the service does not restrict access, then the gate factory may avoid running an authentication service as part of gate construction and may avoid included provisions for an authentication credential as part of the constructed gate. The gate factory may also receive or download an XML message schema (e.g. specified by a service advertisement) to create a gate matching that schema. The gate factory may also receive or download a URI for the service and/or for a service message gate for use in creating the client message gate to communicate with the URI.
In addition, another gate construction optimization may be employed for certain clients that do not desire to perform checking of messages against a service's XML schema. The client may be too thin to perform the checking or may rely on the service gate to perform the checking or may simply choose not to perform the checking (e.g. to reduce gate memory footprint). The gate factory may be configured to receive an indication of whether or not a gate should be constructed to verify messages against the provided XML schema. In some embodiments, certain clients may have a gate factory that does not provide for message verification against a schema for its constructed gates. In some embodiments, gates may be pre-constructed not to verify messages. In some embodiments, a gate may be constructed to verify outgoing messages only, or verify received messages only. Thus, in some embodiments, a client may avoid or may chose to avoid building some or all of the gate code that checks the messages against the XML schema.
In some embodiments, devices may maintain a cache of gates to avoid constructing them each time the same service is run. For example, when a new gate is constructed by a gate factory, the gate may be maintained in a gate cache. When the gate is no longer being used, it is kept in the gate cache instead of being deleted. If the gate cache becomes full, one or more gates may be removed from the gate cache according to a cache replacement algorithm, such as least recently used. When the gate factory is called to construct a gate, it first checks the gate cache to see if a matching gate already exists so that construction of a new gate may be avoided.
The building of a gate may be made lightweight by appropriate reuse of pieces used to construct other gates. Certain portions of each gate may be the same, and thus may be reused from gate to gate, such as parts of the message verification code. Also, for some devices, common gate code may be built into the system software for the device and shared by all gates on that device. Thus, the gate factory may avoid rebuilding this common code for each gate. Instead, the gate factory may simply bind the gate to this system software portion. For example, a system software portion may be provided to handle the message layer over whatever transports are provided on the device.
Space services in particular may be good candidates for many of the gate construction optimizations described above since a service gate constructed for a space service may perform many of the same functions as other service gates for that space service. Refer to the Spaces section below for more information on space services.
In some instances, a more efficient form of method invocation may exist. For example, if the target service runs in the same Java Virtual Machine as the client application, a more efficient form of method invocation may be to create a Java dynamic proxy class for the service. In such a case, a java.lang.reflect.Method invocation may be faster than sending a message. A gate binding time procedure may check for such an optimization and use it instead of running the gate factory to create a gate or bind an existing gate.
In one embodiment, such as for special-purpose clients or small embedded devices, the generation of gate code at runtime may not be desirable due to memory consumption and code generation time. Thus, instead of having a gate factory that generates gates at runtime, in some embodiments gates may be pre-generated and built into the device. For example, message gates may be generated during the build of embedded software as a means of including a built-in secure message endpoint that does not have to be constructed at runtime. Thus, a client with built-in gates may not need a full gate factory, or may require only a partial gate factory for performing certain runtime binding to a built-in gate, such as for the URI and/or authentication credential.
A generation tool may be provided for the pre-construction of gates. The generation tool may include an XML parser, a code generator and a code compiler. In one embodiment, the code generator may be a Java source code generator and the code compiler may be a Java code compiler. During the build of the software for which built-in message gates is desired, the generation tool is run with input from all the relevant XML schemas for which gates are desired.
As an example, if it is desired for a device to have a built-in message gate that can send and receive messages from a digital camera, the build of the device software may include running the gate generation tool with the camera's XML message schema as input. The XML schema may be parsed by the XML parser that may convert the XML schema into an internal form suitable for quick access during a message verification process. The tool's code generator may provide source code for a gate corresponding to the camera's schema. In some embodiments, the generation tool may also compile the source code and the gate code may be linked into the software package for the device. At runtime, the camera service may be discovered in the distributed computing environment. The message URI for the camera service may be bound to the built-in gate for the camera within the device. The binding of the URI to the pre-constructed gate may be performed by a gate constructor within the device. This gate constructor may be a much smaller, simpler gate factory. When the camera service is instantiated, the URI for the camera service is passed to the gate constructor as an XML message. The gate constructor may then bind the URI to the pre-constructed gate.
Thus, a gate may be partially or fully generated at runtime, or a gate may be pre-generated before runtime with a binding process (e.g. for a URI or credential) performed at runtime. In one embodiment, a gate generation tool such as the gate factory or the generation tool for pre-constructed gates may be a Java-based tool to provide some level of platform independence. Alternatively, gate generation tools may be provided in any language, such as the native code for a particular device in the distributed computing environment.
Note that the distributed computing environment does not preclude a device from downloading part or all of a gate's code. For example, in some embodiments, a service may provide gate code that may be downloaded by a client wishing to access that service. However, downloaded code may present size, security and/or safety risks.
A more detailed illustration of possible gate components for one embodiment is shown in FIG. 12. A gate may include its address (or name) 150, a destination gate address 152, a valid XML schema (or internal form thereof) 154, and a transport URI 153. In other embodiments, a gate may also include an authentication credential 156. Some gates may also include a lease 158 and/or a message conductor 160 to verify message ordering.
A gate's name 150 may be a unique ID that will (for the life of the gate) refer only to it. A gate may be addressed using its gate name 150. In one embodiment, gate names may be generated as a combination of a string from an XML schema (e.g. from a service advertisement) and a random number, such as a 128-bit random number. The name 150 may allow clients and services to migrate about the network and still work together. In a preferred embodiment, the gate address is independent of the physical message transport address and/or socket layer. Thus, a gate name may provide a virtual message endpoint address that may be bound and un-bound to a message transport address. In one embodiment, a gate's name may be a Universal Unique Identifier (UUID) that may, for the life of the gate, refer only to it.
A gate name may persist as long as the gate persists so that different applications and clients executing within the same device may locate and use a particular gate repeatedly. For example, a gate may be created for a first client process executing within a device to access a service. After the first client process has completed its activity with the service, it may release the gate. Releasing the gate may involve un-binding the gate from the first client process's message transport address (e.g. IP and/or Port address). The gate may be stored in a gate cache or repository. A second client process executing within the same device that desires to run the same service may locate the gate by its name and use it to access the service. To use the gate, the second client process may bind the gate to its message transport address, so that the message endpoint for the second client process is a combination of the gate name and the second client process's transport address. In another example, a client may receive a dynamic IP address (e.g. a mobile client). When the client's transport address changes, a gate name (or gate names) may be re-bound to the client's new transport address so that the client may still access a service(s) that it previously accessed without having to relocate the service and recreate the gate. A gate name may also be useful for process migration. A process and any associated gates may be checkpointed or saved at one node in the distributed computing environment and moved to another node. The process may be restarted at the new node and the associated gates may be bound to the transport address for the new node so that the process will still have access to the external services to which it had access before being migrated. A gate may track the current location of another gate to which it is paired. Thus a service or client may be migrated and still be accessible. For example, replicated or load-balanced service implementations may be abstracted from clients of the service by the gate.
Thus, a gate name 150 provides a flexible mechanism by which to address a message endpoint in the distributed computing environment. A gate name may be used to locate and/or address a gate over a wide range of networks, from a local network to the Internet. Gate names may be independent of message transport so that a message endpoint (gate) may be moved from transport to transport by unbinding and rebinding to different underlying transport addresses (e.g. IP/Port address pairs).
In one embodiment, a gate may also be separated from a service so that the same gate may be used to send requests to different services over time. This may involve un-binding the gate's destination gate address 152 and binding a new destination gate address to the gate.
A gate may be implemented as a layer above a device's transport layer (e.g. networking sockets). Each gate may include a transport reference 153. The gate name 150 may be bound to the transport reference 153 as described above. Multiple gates may share the same message transport. For example, multiple gates may have transport references 153 to the same TCP/IP socket. By sharing the same message transport, the size and complexity of each gate may be reduced. A device in the distributed computing environment may have a large number of gates that need to send and receive messages. The message handling complexity for multiple gates may be reduced by sharing a common message transport. The transport reference 153 may be a transport URI (e.g. URL) or socket reference and may provide a mechanism for naming an underlying transport and sharing the transport with other gates. Multiple local gates may include a reference 153 to the same transport, however, each local gate may behave independently of the other local gates sending and receiving messages to and from its paired remote gate.
The schema 154 may be downloaded from a space into the gate by the gate factory. The schema may be compiled into an internal form suitable for quick access during a message verification process. In one embodiment, the schema may specify two groups of messages: client service messages and provider service messages. The client service messages group includes the description of all messages that the client may send (that the provider supports), and the provider service messages group includes the description of all messages that the provider may send (that the client receives). In one embodiment, either the client or provider may send a particular request to the space service to obtain a response message with either: the entire client service messages, the entire provider service messages, the entire client and provider service messages, or a specific message of either the client service messages or the provider service messages. In addition, once a gate has been constructed, a client may query as to the capabilities of the service without the gate actually sending a message, but instead by inspecting the gate's set of messages.
As described above, a message gate may verify the sender of the message using an authentication credential, message content for type safety and according to an XML schema. However, it may also be desirable to verify that messages are sent between a client and a service in the correct order. It may be desirable to be able to provision applications (services) for clients to run without any pre-existing specific functionality related to the application on the client (e.g. no GUI for the application on the client). For example, a Web browser may be used on a client as the GUI for a service instead of requiring an application-specific GUI. Of the possible messages in the XML schema, the client may need to know what message next to send to the service. It may be desirable for the client to be able to determine which message to send next without requiring the client to have specific knowledge of the service. In one embodiment, the service may continually send response messages indicating the next input it needs. The service would then accept only the corresponding messages from the client with the requested input specified. Other ad hoc scheme for message ordering may also be employed.
In another embodiment, a message conductor 160 may be employed in the gate or associated with the gate to verify the correct sequence of messages, as opposed to verifying each message's syntax (which may already be performed in the gate according to the schema). Message conductor 160 may provide a more general approach for application provisioning. The message conductor 160 may be specified in a service's advertisement. The message conductor indication in a schema may allow code to be generated on or downloaded to the client during gate construction, which may provide the choreography needed to decide which message to send next to the service. A message conductor may be implemented as a Java application, a Java Script, WML script, or in other programming or scripting languages.
In one embodiment, the message conductor may accept as input an XML document (e.g. from a service advertisement) that presents the valid order or choreography for messages that may be sent between a client and the service. This XML document may also specify user interface information and other rules. The conductor may parse this XML document into an internal form and enforce message ordering (and/or other rules) according to the enclosed ordering information. The conductor may prevent messages from being sent out of order. Or, if a message is sent out of order, an exception may be raised within the sending device. If a message is received out of order, the conductor may send an automatic response message back declaring the ordering error. The sender may then resend messages in the correct order. Note that in some embodiments, part or all of a conductor may be shared by several gates. Thus, a conductor may be linked to multiple gates.
In one embodiment of a distributed computing environment, front ends for services (service interfaces) may be built in to clients. In one embodiment, the service interface may be a preconstructed user interface provided to the client by the service. In one embodiment, the service interface may be provided to the client in the service advertisement. The service interface may interact on the client with the user of the service to obtain input for running the service, and then may display results of running the service on the client. A "user" may be |
