REGISTER  |  SIGN IN
United States Patent7243356
Saulpaugh , ; et al.July 10, 2007
Title
Remote method invocation with secure messaging in a distributed computing environment
Abstract
A secure interface between clients and services in a distributed computing environment is described. Method gates may provide an interface to remotely invoke functions of a service. A method gate may be generated from an advertisement that may include definitions for one or more messages for remotely invoking functions of the service. A client may generate messages containing representations of method calls. The service may invoke functions that correspond to the set of messages. A method gate on the service may unmarshal the message and invoke the function. The client may receive the results of the function directly. Alternatively, the results may be stored, an advertisement to the results may be provided, and a gate may be generated to access the results. Message gates may perform the sending and receiving of the messages between the client and service. In one embodiment, functions of the service may be computer programming language (e.g. Java) methods. In one embodiment, a message including a representation of a method call may be generated when no actual method call was made. In one embodiment, a method call may be transformed into messages that may be sent to the service; the service may not know that the messages were generated from a method call. In one embodiment, a service may transform messages requesting functions into method calls; the client may not know that the service is invoking methods to perform the functions. A credential may be embedded in messages and used for message authentication on the service.
Inventors:Saulpaugh; Thomas E. (San Jose, CA), Slaughter; Gregory L.  (Palo Alto, CA), Traversat; Bernard A.  (San Francisco, CA), Duigou; Michael J.  (Fremont, CA)
Assignee:Sun Microsystems, Inc. (Santa Clara, CA)
Appl. No.:09/672,145
Filed:September 27, 2000
PCT Pub Date:July 10, 2007
Current U.S. Class:719/330 709/225 
Current International Class:G06F 9/44 (20060101) G06F 15/173 (20060101)
Field of Search:709/200-203,310-320,328-332,216,226
U.S. Patent Documents
4491946January 1985Kryshow, Jr. et al.
4713806December 1987Oberlander et al.
4809160February 1989Mahon et al.
4823122April 1989Mann et al.
4939638July 1990Stephenson et al.
4956773September 1990Saito et al.
5088036February 1992Ellis et al.
5109486April 1992Seymour
5187787February 1993Skeen et al.
5218699June 1993Brandle et al.
5257369October 1993Skeen et al.
5293614March 1994Ferguson et al.
5297283March 1994Kelly, Jr. et al.
5307490April 1994Davidson et al.
5311591May 1994Fischer
5339435August 1994Lubkin et al.
5386568January 1995Wold et al.
5390328February 1995Frey et al.
5423042June 1995Jalili et al.
5440744August 1995Jacobson et al.
5448740September 1995Kiri et al.
5452459September 1995Drury et al.
5455952October 1995Gjovaag
5471629November 1995Risch
5475792December 1995Stanford et al.
5475817December 1995Waldo et al.
5481721January 1996Serlet et al.
5504921April 1996Dev et al.
5511197April 1996Hill et al.
5524244June 1996Robinson et al.
5553282September 1996Parrish et al.
5555367September 1996Premerlani et al.
5555427September 1996Aoe et al.
5557798September 1996Skeen et al.
5560003September 1996Nilsen et al.
5561785October 1996Blandy et al.
5577231November 1996Scalzi et al.
5594921January 1997Pettus
5603031February 1997White et al.
5617537April 1997Yamada et al.
5628005May 1997Hurvig
5640564June 1997Hamilton et al.
5644768July 1997Periwal et al.
5652888July 1997Burgess et al.
5655148August 1997Richman et al.
5659751August 1997Heninger
5671225September 1997Hooper et al.
5675796October 1997Hodges et al.
5680573October 1997Rubin et al.
5680617October 1997Gough et al.
5684955November 1997Meyer et al.
5689709November 1997Corbett et al.
5706435January 1998Barbara et al.
5706502January 1998Foley et al.
5724588March 1998Hill et al.
5727145March 1998Nessett et al.
5737607April 1998Hamilton et al.
5745678April 1998Herzberg et al.
5745695April 1998Gilchrist et al.
5745703April 1998Cejtin et al.
5745755April 1998Covey
5748897May 1998Katiyar
5754849May 1998Dyer et al.
5757925May 1998Faybishenko
5761656June 1998Ben-Shachar
5764897June 1998Khalidi
5768532June 1998Megerian
5774551June 1998Wu et al.
5778187July 1998Monteiro et al.
5778228July 1998Wei
5778368July 1998Hogan et al.
5787425July 1998Bigus
5787431July 1998Shaughnessy
5790548August 1998Sistanizadeh et al.
5802367September 1998Held et al.
5808911September 1998Tucker et al.
5809507September 1998Cavanaugh, III
5813013September 1998Shakib et al.
5815149September 1998Mutschler, III et al.
5815709September 1998Waldo et al.
5815711September 1998Sakamoto et al.
5818448October 1998Katiyar
5829022October 1998Watanabe et al.
5832219November 1998Pettus
5832529November 1998Wollrath et al.
5832593November 1998Wurst et al.
5835737November 1998Sand et al.
5842018November 1998Atkinson et al.
5844553December 1998Hao et al.
5845129December 1998Wendorf et al.
5860004January 1999Fowlow et al.
5860153January 1999Matena et al.
5864862January 1999Kriens et al.
5864866January 1999Henckel et al.
5872928February 1999Lewis et al.
5872973February 1999Mitchell et al.
5875335February 1999Beard
5878411March 1999Burroughs et al.
5884024March 1999Lim et al.
5884079March 1999Furusawa
5887134March 1999Ebrahim
5890158March 1999House et al.
5892904April 1999Atkinson et al.
5933497August 1999Beetcher et al.
5935249August 1999Stern et al.
5940827August 1999Hapner et al.
5944793August 1999Islam et al.
5946485August 1999Weeren et al.
5946694August 1999Copeland et al.
5966531October 1999Skeen et al.
5969967October 1999Aahlad et al.
5987506November 1999Carter et al.
5996075November 1999Matena
5999179December 1999Kekic et al.
6003763December 1999Gallagher et al.
6009103December 1999Woundy
6016496January 2000Roberson
6016500January 2000Waldo et al.
6026414February 2000Anglin
6031977February 2000Pettus
6061699May 2000DiCecco et al.
6061713May 2000Bharadhwaj
6108715August 2000Leach et al.
6249822June 2001Kays et al.
6453362September 2002Bittinger et al.
Foreign Patent Documents
11-45187Oct., 1997JP
2 253 079Aug., 1992GB
2 262 825Jun., 1993GB
2 305 087Mar., 1997GB
300 516Jan., 1989EP
351 536Jan., 1990EP
384 339Aug., 1990EP
456 920Nov., 1991EP
472 874Mar., 1992EP
474 340Mar., 1992EP
497 022Aug., 1992EP
555 997Aug., 1993EP
565 849Oct., 1993EP
569 195Nov., 1993EP
625 750Nov., 1994EP
651 328May., 1995EP
660 231Jun., 1995EP
697 655Feb., 1996EP
718 761Jun., 1996EP
767 432Apr., 1997EP
778 520Jun., 1997EP
794 493Sep., 1997EP
803 810Oct., 1997EP
803 811Oct., 1997EP
805 393Nov., 1997EP
810 524Dec., 1997EP
817 020Jan., 1998EP
817 022Jan., 1998EP
817 025Jan., 1998EP
836 140Apr., 1998EP
92/07335Apr., 1992WO
92/09948Jun., 1992WO
93/25962Dec., 1993WO
94/03855Feb., 1994WO
96/03692Feb., 1996WO
96/10787Apr., 1996WO
96/18947Jun., 1996WO
96/24099Aug., 1996WO
965 917Dec., 1999EP
969 366Jan., 2000EP
98/02814Jan., 1998WO
98/04971Feb., 1998WO
Other References
Instaweb Online Computing Dictionary, Instaweb, 1997, http://www.instantweb.com/foldoc/foldoc.cig?query=XML. cited by examiner .
Dave Winer, "XML-RPC Specification", Jun. 15, 1999. cited by examiner .
Dave Winer, XML-RPC fopr Newbies:, Jun. 14, 1998. cited by examiner .
Czerwinski et al., "An Architecture for a Secure Service Discovery Service", 1999, MObicom '99, Seattle, Washington, USA. cited by examiner .
Czerwinski, et al., "An Architecture for a Secure Service Discovery Service," Mobicom 99, Proceedings of the 5.sup.th Annual ACM/IEEE International Conference on Mobile Computing and Networking, Aug. 15, 1999, XP000896069, pp. 24-35. cited by other .
K. Edwards "Core Jini", Jun. 1999, Prentice Hall PTR, 1.sup.st Edition, XP002212109, pp. 636-637, 651-657. cited by other .
International Search Report for PCT/US 01/15277, mailed Sep. 27, 2002. cited by other .
Jaworski, "Java 1.1 Developer's Guide, 2.sup.nd Edition," Sams.net, 1997. cited by other .
Coulouris, et al., "Distributed Systems Concepts and Designs," Second Edition, Addison-Wesley, 1994. cited by other .
Mullender, "Distributed Systems" Second Edition, Addison-Wesley, 1993. cited by other .
Lindholm, et al., "The Java.TM. Virtual Machine Specification," Addison Wesley, 1996. cited by other .
"SOAP: Simple Object Access Protocol," msdn online Web Workshop, Microsoft, Apr. 26, 2000, http://msdn.Microsoft.com/xml/general/soapspec.asp, 34 pages. cited by other .
Rob Guth, "Sun tries on JacaSpaces for Distributed OS," Aug. 1997, vol. 19, Issue 34, 2 pages. cited by other .
Microsoft, "Microsoft.NET: Realizing the Next Generation Internet," A Microsoft White Paper, Jun. 2000, 8 pages. cited by other .
K. F. Eustice, et al., "A Universal Information Appliance," IBM Systems Journal, vol. 38, No. 4, 1999, pp. 575-601. cited by other .
Wycoff et al., "T Spaces," IBM Systems Journal, vol. 37, No. 3-Java Technology, Aug. 1998, 36 pages. cited by other .
Steve Morgan, "Jini to the Rescue," IEEE Spectrum, Apr. 2000, vol. 37, No. 4, 8 pages. cited by other .
"XML-RPC for Newbies", Dave Winer, Jul. 14, 1998, 7 pages. cited by other .
"XML-RPC.COM", Davie Winder, Jun. 15, 1999, 7 pages. cited by other .
"Java.TM. Remote Method Invocation Specification," Sun Microsystems, Inc., <java.sun.com/products/dk1.2beta1>, 1997. cited by other .
Agha, et al., "Actorspaces: An Open Distributed Programming Paradigm," University of Illinois, Report No. UIUCDCS-R-92-1766, Open Systems Laboratory TR No. 8, pp. 1-12, Nov. 1992. cited by other .
Ahmed, et al., "A Program Building Tool for Parallel Applications," Yale University, pp. 1-23, Dec. 1, 1993. cited by other .
Aldrich, et al., "Providing Easier Access to Remote Objects in Client-Server Systems," System Sciences, 1998, Proceedings of the 31.sup.st Hawaii Internat'l. Conference, Jan. 6-9, 1998, pp. 366-375. cited by other .
Aldrich, et al., "Providing Easier Access to Remote Objects in Distributed Systems," Calif. Institute of Technology, www.cs.Caltech.edu/%7Ejedi/paper.html, Nov. 21, 1997. cited by other .
Anderson, et al., "Persistent Linda: Linda + Transaction + Query Processing," Proceedings of the 13.sup.th Symposium on Fault Tolerant Systems, pp. 93-109, 1991. cited by other .
"Transparent Network Computing," Locus Computing Corporation, Jan. 5, 1995. cited by other .
Alexander, et al., "Active Bridging," Proceedings of the ACM/SIGCOMM'97 Conference, Cannes, France, Sep. 1997. cited by other .
Beech, et al., "Object Databases as Generalizations of Relational Databases," Computer Standards & Interfaces, vol. 13, Nos. 1/3 pp. 221-230, Amsterdam, NL, Jan. 1991. cited by other .
Bertino, et al., Object-Oriented Database Management Systems: Concepts and issues,: Computer, vol. 24, No. 4, pp. 33-47, Los Alamitos, CA, Apr. 1991. cited by other .
Betz, et al, "Interoperable Objects: Laying the Foundation for Distributed Object Computing," Dr. Dobb's Journal, vol. 19, No. 11, p. 18(13), Oct. 1994. cited by other .
Bevan, et al., "An Efficient Reference Counting Solution To The Distributed Garbage Collection Problem,"Parallel Computing, NL, Elsevier Science Publishers, Amsterdam, vol. 9, No. 2, pp. 179-192, Jan. 1989. cited by other .
Birrell, et al., "Distributed Garbage Collection for Network Objects," Digital Systems Research Center, No. 116, pp. 1-18, Dec. 15, 1993. cited by other .
Birrell, et al., "Grapevine: An Exercise in Distributed Computing," Communications fo the ACM, vol. 25, No. 4, pp. 260-274, Apr. 1982. cited by other .
Birrell, et al., "Network Objects," DEC SRC Research Report 115, Feb. 28, 1995. cited by other .
Birrell, et al., "Implementing Remote Procedure Calls," ACM Transactions on Computer Systems, vol. 2, No. 1, pp. 39-59, Feb. 1994. cited by other .
Birrell, et al., "Network Objects," Operating Systems Review, 27(5), pp. 217-230, Dec. 1993. cited by other .
Cannon, et al., "Adding Fault-Tolerant Transaction Processing to LINDA," Software-Practice and Experience, vol. 24(5), pp. 449-466, May 1994. cited by other .
Cardelli, "Obliq, A Lightweight Language For Network Objects," Digital SRC, pp. 1-37, Nov. 5, 1993. cited by other .
Carriero, et al., "Distributed Data Structures in Linda," Principles of Programming Language pp. 1-16, 1986. cited by other .
Carriero, et al., "Distributed Data Structures in Linda," Yale Research Report YALEU/DCS/RR-438, Nov. 1985. cited by other .
Chung, et al., "A Tiny' Pascal Compiler: Part 1: The P-Code Interpreter," BYTE Publications, Inc., Sep. 1978. cited by other .
Chung, et al., "A Tiny' Pascal Compiler: Part 2: The P-Complier," BYTE Publications, Inc., Oct. 1978. cited by other .
Dave, et al., "Proxies, Application Interface, And Distributed Systems," Proceedings International Workshop On Object Orientation In Operating Systems, pp. 212-220, Sep. 24, 1992. cited by other .
Deux, et al., "The O2 System," Communications Of The Association For Computing Machinery, col. 34, No. 10, pp. 34-48, Oct. 1, 1991. cited by other .
Dijkstra, "Self-stabilizing Systems in Spite of Distributed Control," Communications of the ACM, vol. 17, No. 11, pp. 643-644, Nov. 1974. cited by other .
Dolev, et al., "On the Minimal Synchronism Needed for Distributed Consensus," Journal of the ACM, vol. 34, No. 1, pp. 77-97, Jan. 1987. cited by other .
Dollimore, et al., "The design of a System for Distributing Shared Objects," The Computer Journal, No. 6, Cambridge, GB, Dec. 1991. cited by other .
Dourish; "A Divergence-Based Model of Synchrony and Distribution in Collaborative Systems," Xerox Technical Report EPC-1194-102, pp. 1-10, 1994. cited by other .
Drexier, et al., "Incentive Engineering for Computational Resource Management," The Ecology of Computation, Elsevier Science Publishers B.V., pp. 231-266, 1988. cited by other .
Gelernter, et al., "Parallel Programming in Linda," Yale University, pp. 1-21, Jan. 1995. cited by other .
Droms, "RFC 1541 Dynamic Host Configuration Protocol," <http://www.cis.ohio-state.edu.htbin/rfc/rfc1541.html>, pp. 1-33, Oct. 1993. cited by other .
Emms, "A Definition Of AN Access Control Systems Language," Computer Standards And Interfaces, vol. 6, No. 4, pp. 443-454, Jan. 1, 1997. cited by other .
Fleisch, et al., "High Performance Distributed Objects Using Distributed Shared Memory & Remote Method Invocation," System Sciences, 1998, Proceedings of the 31.sup.st Hawaii Internat'l. Conference, Jan. 6-9, 1998, pp. 574-578. cited by other .
Gelernter, "Generative Communication in Linda," ACM Transactions on Programming Languages and Systems, vol. 7, No. 1, pp. 80-112, Jan. 1985. cited by other .
Gottlob, et al., "Extending Object-Oriented Systems with Roles," ACM Transactions On Information Systems, vol. 14, No. 3, pp. 268-296, Jul. 1996. cited by other .
Gray, et al. "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency," ACM, pp. 202-210, 1989. cited by other .
Guth, "JavaOne: Sun to Expand Java Distriubted Computing Effor," <http://www.sunworld.com/swol-02-1998/swol-02-sunspots.html>, XP-002109935, p. 1, Feb. 20, 1998. cited by other .
Guyennet, et al., "A New Consistency Protocol Implemented in the CaliF System," IEEE, 1994 7266/97, pp. 82-87, 1997. cited by other .
Guyennet, et al., "Distributed Shared Memory Layer for Cooperative Work Applications," IEEE, 0742-1303/97, pp. 72-78, 1997. cited by other .
Hamilton, et al., "Subcontract: A Flexible Base for Distributed Programming," Proceedings of 14.sup.th Symposium of Operating System Principles, Dec. 1993. cited by other .
Hamilton, "Java and the Shift to Net-Centric Computing," Computer, pp. 31-39, Aug. 1996. cited by other .
Harris, et al., "Proposal for a General Java Proxy Class for Distributed Systems and Other Uses," Newscape Communications Corp., Jun. 25, 1997. cited by other .
Hartman, et al., "Liquid Software: A New Paradigm For Networked Systems," Technical Report 96-11, Dept. of Comp. Sci., Univ. of Arizona, Jun. 1996. cited by other .
Howard, et al., "Scale and Performance in a Distributed File System," ACM Transactions on Computer Systems, vol. 6, No. 1, pp. 51-81, Feb. 1988. cited by other .
Pier, "A Retrospective on the Dorando, A High-Performance Personal Computer," Xerox Corporation, Aug. 1983. cited by other .
Pinakis, "Using Linda as the Basis of an Operating System Microkernel," University of Western Australia, Dept. of Computer Science, pp. 1-165, Aug. 1993. cited by other .
Riggs, et al., "Picking State in the Java.TM. System," USENIX, Association Conference on Object-Oriented Technologies and Systems, CP-002112719, pp. 241-250, Jun. 17-21, 1996. cited by other .
Rosenberry, et al., "Understanding DCE," Chapters 1-3, 6, 1992. cited by other .
Sharrott, et al., "ObjectMap: Integrated High Performance Resources into a Distributed Object-oriented Environment," ICODP, 1995. cited by other .
Stevenson, "Token-Based Consistency of Replicated Servers," IEEE, CH2686-4/89/0000/0179, pp. 179-183, 1989. cited by other .
Thompson, "Regular Expression Search Algorithm," Communications of the ACM, vol. II, No. 6, p. 149 et seq., Jun. 1968. cited by other .
Venners, "Jini Technology, Out of the Box," JAVAWORLD, Online!, pp. 1-4, Dec. 1998. cited by other .
Waldo, et al., "Events in An RPC Based Distributed System," Proceedings Of The 1995 USENIX Technical Conference, Proceedings USENIX Winter 1995 Technical Conference, New Orleans, LA, USA, 16-20, pp. 131-142, Jan. 1995. cited by other .
Wilson, et al., "Design of the Opportunistic Garbage Collector," Proceedings of the Object Oriented Programming Systems Languages And Applications Conference, New Orleans, vol. 24, No. 10, Oct. 1989. cited by other .
Wollrath, et al., "A Distributed Object Model for theJaca.TM. System," USENIX Association, Conference on Object-Oriented Technologies and Systems, Jun. 17-21, 1996. cited by other .
Wu, "A Type System For An Object-Oriented Database Systems," Proceedings of the International Computer Software and Applications Conference (COMPSAC), Tokyo, Japan, pp. 333-338, Sep. 11-13, 1991. cited by other .
Yemini, et al., "Towards Programmable Networks," IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, L'Aquila, Italy, Oct. 1996. cited by other .
Yin, et al., "Using Leases to Support Server Driven Consistency in Large-Scale Systems," Computer Services Department, University of Texas at Austin, p. 285-294, May 26-28, 1998. cited by other .
Yin, et al., "Volume Leases for Consistency in Large-Scale Systems," IEEE Transactions on Knowledge & Data Engineering, vol. 11, No. 4, pp. 563-576, Jul./Aug. 1999. cited by other .
Mitchell, et al., "An Overview of the Spring System," Feb. 1994. cited by other .
Mitchell, et al., "Mesa Language Manual," Xerox Corporation, Palo Alto Research Center, 1978. cited by other .
McDaniel, "An Analysis of a Mesa Instruction Set," Xerox Corporation, May 1982. cited by other .
McGrath, "Discovery and its Discontents: Discovery Protocols for Ubiquitous Computing," Presented at Center for Excellence in Space Data and Information Science, NASA Goddard Space Flight Center, Apr. 5, 2000. cited by other .
Mummert, et al., "Long Term Distributed File Reference Tracing: Implementation and Experience," Carnegie Mellon University School of Computer Science, pp. 1-28, Nov. 1994. cited by other .
Orfali, et al., "The Essential Distributed Objects Survival Guide," Chapter 11: Corba Commercial ORBs, pp. 203-215, John Wiley & Sons, Inc., 1996. cited by other .
Ousterhout, et al., "The Sprite Network Operating System," Computer, IEEE, pp. 23-36, Feb. 1988. cited by other .
Pier, "A Retrospective on the Dorando, A High-Performance Personal Computer," IEEE Conference Proceedings, The 10.sup.th Annual International Symposium on Computer Architecture, 1993. cited by other .
Hunt, "IDF: A Graphical Data Flow Programming Language for Image Processing and Computer Vision," Proceedings of the International Conference on Systems, Man, and Cybernetics, pp. 351-360, Los Angeles, Nov. 4-7, 1990. cited by other .
IBM.TM. Technical Disclosure Bulletin, "Object Location Algorithm," vol. 36, No. 09B, pp. 257-258, Sep. 1993. cited by other .
IBM, "Chapter 6--Distributed SOM (DSOM)," SOMobjects Developer Toolkit Users Guide, Version 2.1, pp. 6-1-6-90, Oct. 1994. cited by other .
Anonymous, "Change-Notification Service for Shared Filed," IBM Technical Disclosure Bulletin, vol. 36, No. 8, pp. 77-82, XP002109435 New York, US, Nov. 1973. cited by other .
IBM.TM. Technical Disclosure Bulletin, "Retrieval of Qualified Variable Using Extendible Hashing," vol. 36, No. 12, pp. 301-303, Dec. 1993. cited by other .
Anonymous, "Resource Preemption for Priority Scheduling," IBM Technical Disclosure Bulletin, vol. 16, No. 6, p. 1931, XP002109435 New York, US, Nov. 1973. cited by other .
IBM.TM. Technical Disclosure Bulletin, "Local Network Monitoring to Populate Access Agent Directory," vol. 36, No. 09A, pp. 403
Primary Examiner: Lim; Krisna
Assistant Examiner: Strange; Aaron
Attorney, Agent or Firm:Kowert; Robert C. Meyertons, Hood, Kivlin, Kowert & Goetzel, P.c.
Parent Case Text


PRIORITY INFORMATION

This application claims benefit of priority to the following provisional applications, each of which is hereby incorporated by reference in its entirety:

Ser. No. 60/202,975 filed May 9, 2000 titled Distributed Computing Environment;

Ser. No. 60/208,011 filed May 26, 2000 titled Distributed Computing Environment;

Ser. No. 60/209,430 filed Jun. 2, 2000 titled Distributed Computing Environment;

Ser. No. 60/209,140 filed Jun. 2, 2000 titled Distributed Computing Environment; and

Ser. No. 60/209,525 filed Jun. 5, 2000 titled Distributed Computing Environment.
Claims

What is claimed is:
1. A method for remotely invoking methods in a distributed computing environment, comprising: a service providing to a client a service advertisement comprising a data representation language message schema comprising descriptions of data representation language messages the client is authorized to send to the service; the client generating a message in a data representation language, wherein the message includes information representing a computer programming language method call, wherein said generating a message is performed in accordance with a description of the message comprised in the message schema, and wherein the message further includes a credential for allowing the client access to a service configured to perform functions on behalf of clients in the distributed computing environment; the client sending the message to the service; the service examining the credential included in the message; if said examining determines the credential is authentic, the service performing a function on behalf of the client in accordance with the information representing the computer programming language method call included in the message; and if said examining determines the credential is not authentic, the service not performing the function on behalf of the client.

2. The method as recited in claim 1, wherein the client comprises a client method gate configured to provide an interface to the service by generating data representation language messages including information representing method calls, and wherein said generating a message is performed by the client method gate.

3. The method as recited in claim 2, wherein said sending the message is performed by the client method gate.

4. The method as recited in claim 2, wherein the client further comprises a client process, the method further comprising: the client process generating the computer programming language method call; and the client method gate receiving the method call generated by the client process; wherein said generating a message is performed in response to said receiving the method call.

5. The method as recited in claim 2, wherein the client further comprises a client message endpoint, wherein said sending the message to the service comprises: the client method gate sending the message to the client message endpoint, wherein the client message endpoint is configured to send messages in the data representation language to the service; the client message endpoint attaching the credential to the message; and the client message endpoint sending the message to the service.

6. The method as recited in claim 1, further comprising the client generating a client method gate in accordance with the service advertisement, wherein the client method gate is configured to provide to the client an interface to the service by generating the data representation language messages described in the message schema, wherein said generating a message is performed by the client method gate.

7. The method as recited in claim 1, wherein the service advertisement further comprises an address for receiving the data representation language messages on the service, wherein said sending the message to the service comprises sending the message to the address.

8. The method as recited in claim 7, wherein the address is a Uniform Resource Identifier (URI).

9. The method as recited in claim 7, further comprising the client generating a client message endpoint in accordance with the service advertisement, wherein the client message endpoint is configured to send messages to the address, and wherein said sending the message to the service is performed by the client message endpoint.

10. The method as recited in claim 1, wherein the service comprises a service message endpoint configured to receive messages in the data representation language from the client, wherein said performing a function comprises the service message endpoint receiving the message from the client.

11. The method as recited in claim 1, wherein the service comprises one or more computer programming language methods executable within the service, wherein said performing a function comprises executing a computer programming language method of the service in accordance with the information representing the computer programming language method call included in the message.

12. The method as recited in claim 1, wherein the service comprises one or more computer programming language methods executable within the service, wherein the information representing the computer programming language method call includes an identifier of the method call, and wherein said performing a function comprises: regenerating the method call in accordance with the identifier of the method call included in the information representing the method call; and executing a computer programming language method of the service in accordance with the regenerated method call.

13. The method as recited in claim 12, wherein the information representing the computer programming language method call further includes one or more parameter values of the method call, and wherein said executing a computer programming language method in accordance with the regenerated method call comprises providing the one or more parameter values from the information representing the method call as parameter values of the method call.

14. The method as recited in claim 12, wherein the service further comprises a service method gate configured to provide an interface to the one or more computer programming language methods of the service by receiving data representation language messages and invoking computer programming language methods specified by the messages, and wherein said regenerating the method call is performed by the service method gate.

15. The method as recited in claim 1, wherein said performing a function generates results data, the method further comprising the service providing the generated results data to the client.

16. The method as recited in claim 1, wherein said performing a function generates results data, and wherein the service comprises a service message endpoint configured to send messages in the data representation language to the client for the service, the method further comprising: the service message endpoint sending a results message to the client, wherein the results message includes the generated results data.

17. The method as recited in claim 1, wherein said performing a function generates results data, the method further comprising: storing the generated results data to a space service in the distributed computing environment; providing an advertisement for the stored results data to the client, wherein the advertisement comprises information to enable access by the client to the stored results data; and the client accessing the stored results data from the space service in accordance with the information in the provided advertisement.

18. The method as recited in claim 17, wherein the client accessing the stored results data comprises: generating a client results message endpoint in accordance with the information in the provided advertisement, wherein the client results message endpoint is configured to send messages in the data representation language to the space service for the client; generating a results request message in the data representation language, wherein the results request message requests the results data be provided to the client; the client results message endpoint sending the results request message to the space service; and the space service sending the requested results data to the client results message endpoint in response to the results request message.

19. The method as recited in claim 17, wherein the information to enable access by the client to the stored results data comprises one or more Uniform Resource Identifiers (URIs) for accessing the stored results data.

20. The method as recited in claim 1, wherein said data representation language is eXtensible Markup Language (XML).

21. The method as recited in claim 1, wherein said computer programming language is the Java programming language, and wherein the information representing the method call in the message represents a Java method call to a Java method implemented on the service, and wherein the service performing a function comprises invoking the Java method on the service in accordance with the information representing the Java method call included in the message.

22. 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.

23. The method as recited in claim 22, wherein the virtual machine is a Java Virtual Machine (JVM).

24. A distributed computing system, comprising: a service device comprising one or more functions executable on the service device on behalf of client devices in the distributed computing system; a client device configured to: generate a message in a data representation language, wherein the message includes information representing a computer programming language method call, and wherein the message further includes a credential for allowing the client device access to the service device; and send the message to the service device; wherein the service device is configured to: provide to the client device a service advertisement comprising a data representation language message schema comprising descriptions of data representation language messages a client device is authorized to send to the service device, wherein said generate a message is performed in accordance with a description of the message comprised in the message schema; examine the credential included in the message; if said examining verifies the credential, perform a function on behalf of the client in accordance with the information representing the computer programming language method call included in the message; and if said examining does not verify the credential, not perform the function on behalf of the client.

25. The system as recited in claim 24, wherein the client device comprises a client method gate configured to provide an interface to the service by generating data representation language messages including information representing method calls, and wherein said generating a message is performed by the client method gate.

26. The system as recited in claim 25, wherein the client device further comprises a client process, wherein the client process is configured to generate the computer programming language method call; wherein the client method gate is further configured to receive the method call generated by the client process; and wherein said generating a message is performed by the client method gate in response to said receiving the method call.

27. The system as recited in claim 25, wherein the client device further comprises a client message endpoint, wherein the client method gate is further configured to send the message to the client message endpoint; and wherein the client message endpoint is configured to: attach the credential to the message; and send the message to the service device.

28. The system as recited in claim 24, wherein the client device is further configured to: generate a client method gate in accordance with the service advertisement, wherein the client method gate is configured to provide to the client device an interface to the service device by generating the data representation language messages described in the message schema; and wherein said generating a message is performed by the client method gate.

29. The system as recited in claim 24, wherein the service advertisement further comprises an address for receiving the data representation language messages on the service device.

30. The system as recited in claim 29, wherein the address is a Uniform Resource Identifier (URI).

31. The system as recited in claim 29, wherein the client device is further configured to: generate a client message endpoint in accordance with the service advertisement, wherein the client message endpoint is configured to send the data representation language messages to the address; and wherein said sending the message to the service device is performed by the client message endpoint.

32. The system as recited in claim 24, wherein the service device comprises one or more computer programming language methods executable within the service device, wherein the information representing the computer programming language method call includes an identifier of the method call, and wherein, in said performing a function, the service device is further configured to: regenerate the method call in accordance with the identifier of the method call included in the information representing the method call; and execute a computer programming language method of the service device in accordance with the regenerated method call.

33. The system as recited in claim 32, wherein the information representing the computer programming language method call further includes one or more parameter values of the method call, and wherein, in said executing a computer programming language method in accordance with the regenerated method call, the service device is further configured to: provide the one or more parameter values from the information representing the method call as parameter values of the method call.

34. The system as recited in claim 32, wherein the service device further comprises a service method gate configured to provide an interface to the one or more computer programming language methods of the service by receiving data representation language messages and invoking methods specified by the messages, and wherein said regenerating the method call is performed by the service method gate.

35. The system as recited in claim 24, wherein said performing a function generates results data, wherein the service device comprises a service message endpoint configured to send a results message in the data representation language to the client device, wherein the results message includes the generated results data.

36. The system as recited in claim 24, further comprising: a space service; wherein the service device is further configured to: store results data generated by said performing a function to the space service; provide an advertisement for the stored results data to the client device, wherein the advertisement comprises information to enable access by the client device to the stored results data; and wherein the client device is further configured to access the stored results data from the space service in accordance with the information in the provided advertisement.

37. The system as recited in claim 36, wherein, in accessing the stored results data, the client device is further configured to generate a client results message endpoint in accordance with the information in the provided advertisement; wherein the client results message endpoint is configured to: generate a results request message in the data representation language, wherein the results request message requests the results data be provided to the client device; and send the results request message to the space service; and wherein the space service is configured to send the requested results data to the client results message endpoint in response to the results request message.

38. The system as recited in claim 36, wherein the information to enable access by the client device to the stored results data comprises one or more Uniform Resource Identifiers (URIs) for accessing the stored results data.

39. The system as recited in claim 24, wherein said data representation language is eXtensible Markup Language (XML).

40. The system as recited in claim 24, wherein said computer programming language is the Java programming language, and wherein the information representing the method call in the message represents a Java method call to a Java method implemented on the service, and wherein, in said performing a function, the service device is further configured to invoke the Java method on the service device in accordance with the information representing the Java method call included in the message.

41. The system as recited in claim 24, further comprising: a virtual machine executable within the client device; and a client process executable within the virtual machine, wherein said generating a message and said sending the message are performed by the client process.

42. The system as recited in claim 41, wherein the virtual machine is a Java Virtual Machine (JVM).

43. A device, comprising: a client component; and a method gate; wherein the client component is configured to generate a computer programming language method call; wherein the method gate is configured to: access the computer programming language method call generated by the client component; generate a message in a data representation language, wherein the message includes information representing a computer programming language method call, and wherein the message further includes an encrypted credential for allowing the client device access to a service in a distributed computing environment; wherein the method gate comprises a data representation language message schema comprising descriptions of data representation language messages the device is authorized to send to the service, wherein said generating a message is performed in accordance with a description of the message comprised in the message schema; and send the message to the service; wherein the service is operable to verify the message as authentic by examining the credential included in the message, and to perform a function on behalf of the client component in accordance with the information representing the computer programming language method call included in the message if the message is verified as authentic.

44. The device as recited in claim 43, wherein the service is further operable to store results data generated by the function to a space service in the distributed computing environment, and wherein the client component is further configured to: access a data representation language advertisement for the results data, wherein the advertisement comprises information to enable access by the client component to the results data; and access the results data from the space service in accordance with the information in the provided advertisement for the stored results data.

45. The device as recited in claim 43, wherein said computer programming language is the Java programming language, and wherein the information representing a method call in the message represents a Java method call to a Java method implemented on the service.

46. A device, comprising: a client component configured to generate a message in a data representation language, wherein the message includes information representing a computer programming language method call; and a message endpoint configured to: attach an encrypted credential to the message for allowing the client component access to a service in a distributed computing environment; and send the message to a service in a distributed computing environment; wherein the service is operable to verify the message as authentic by examining the credential included in the message, and to perform a function on behalf of the client component in accordance with the information representing the computer programming language method call included in the message if the message is authentic; wherein the service is further operable to store results data generated by the function to a space service in the distributed computing environment; and wherein the client component is further configured to: access a data representation language advertisement for the results data, wherein the advertisement comprises information to enable access by the client component to the results data; and access the results data from the space service in accordance with the information in the provided advertisement for the stored results data.

47. The device as recited in claim 46, wherein the client component is further configured to generate the computer programming language method call, and wherein said generating a message is performed in response to said generating the computer programming language method call.

48. The device as recited in claim 46, wherein the device further comprises a virtual machine executable within the device, wherein the client component and the message endpoint are executable within the virtual machine.

49. The device as recited in claim 48, wherein the virtual machine is a Java Virtual Machine (JVM).

50. The device as recited in claim 46, wherein said computer programming language is the Java programming language, and wherein the information representing a method call in the message represents a Java method call to a Java method implemented on the service.

51. A device comprising: a message endpoint configured to: receive a message in a data representation language sent by a client of the device in a distributed computing environment, wherein the message includes information representing a computer programming language method call, and wherein the message further includes a credential for allowing the client access to the device; and verify the message as authentic by examining the credential included in the message; a service component configured to: perform a function on behalf of the client in accordance with the information representing the computer programming language method call included in the message if the message is verified as authentic by the message endpoint; store results data generated by said performing a function to a space service in the distributed computing environment; and provide an advertisement for the stored results data to the client, wherein the advertisement comprises information to enable access by the client to the stored results data.

52. The device as recited in claim 51, wherein the service component comprises a computer programming language method, wherein the message endpoint is further configured to: regenerate the computer programming language method call in accordance with an identifier of the method call included in the message; and invoke the computer programming language method of the service component with the regenerated method call; wherein, in said performing a function, the service component is further configured to execute the computer programming language method in accordance with the regenerated method call in response to said invocation.

53. The device as recited in claim 52, wherein, in said invoking the computer programming language method, the message endpoint is further configured to provide one or more parameter values included in the message as parameter values of the method call.

54. The device as recited in claim 51, wherein said computer programming language is the Java programming language.

55. A computer-readable, storage medium comprising program instructions, wherein the program instructions are computer-executable to implement: a service providing to a client a service advertisement comprising a data representation language message schema comprising descriptions of data representation language messages the client is authorized to send to the service; the client generating a message in a data representation language, wherein the message includes information representing a computer programming language method call, wherein said generating a message is performed in accordance with a description of the message comprised in the message schema, and wherein the message further includes a credential for allowing the client access to a service configured to perform functions on behalf of clients in the distributed computing environment; the client sending the message to the service; the service examining the credential included in the message; if said examining determines the credential is authentic, the service performing a function on behalf of the client in accordance with the information representing the computer programming language method call included in the message; and if said examining determines the credential is not authentic, the service not performing the function on behalf of the client.

56. The computer-readable, storage medium as recited in claim 55, wherein the program instructions are further computer-executable to implement: the client generating a client method gate in accordance with the service advertisement, wherein the client method gate is configured to provide to the client an interface to the service by generating the data representation language messages described in the message schema; wherein said generating a message is performed by the client method gate.

57. The computer-readable, storage medium as recited in claim 56, wherein the program instructions are further computer-executable to implement: the client generating a client message endpoint in accordance with the service advertisement, wherein the client message endpoint is configured to send the data representation language messages to an address on the service included in the service advertisement; the client message endpoint receiving the generated message from the client method gate; the client message endpoint attaching the credential to the message; and wherein said sending the message to the service is performed by the client message endpoint.

58. The computer-readable, storage medium as recited in claim 55, wherein the service comprises one or more computer programming language methods executable within the service, wherein the information representing the computer programming language method call includes an identifier of the method call, and wherein, in said performing a function, the program instructions are further computer-executable to implement: regenerating the method call in accordance with the identifier of the method call included in the information representing the method call; and executing a computer programming language method of the service in accordance with the regenerated method call.

59. The computer-readable, storage medium as recited in claim 58, wherein the information representing the computer programming language method call further includes one or more parameter values of the method call, and wherein, in said executing a computer programming language method in accordance with the regenerated method call, the program instructions are further computer-executable to implement providing the one or more parameter values from the information representing the method call as parameter values of the method call.

60. The computer-readable, storage medium as recited in claim 58, wherein the service further comprises a service method gate configured to provide an interface to the one or more computer programming language methods of the service by receiving data representation language messages and invoking computer programming language methods specified by the messages, and wherein said regenerating the method call is performed by the service method gate.

61. The computer-readable, storage medium as recited in claim 55, wherein said performing a function generates results data, and wherein the program instructions are further computer-executable to implement: storing the generated results data to a space service in the distributed computing environment; providing an advertisement for the stored results data to the client, wherein the advertisement comprises information to enable access by the client to the stored results data; and the client accessing the stored results data from the space service in accordance with the information in the provided advertisement.

62. The computer-readable, storage medium as recited in claim 55, wherein said data representation language is eXtensible Markup Language (XML).

63. The computer-readable, storage medium as recited in claim 55, wherein said computer programming language is the Java programming language, and wherein the information representing the method call in the message represents a Java method call to a Java method implemented on the service, and wherein, in said performing a function, the program instructions are further computer-executable to implement invoking the Java method on the service in accordance with the information representing the Java method call included in the message.
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 heterogeneous distributed computing environment including a secure remote method invocation mechanism 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 method gates are described that provide a method interface between clients and services in a distributed computing environment. A method gate may be bi-directional, allowing remote method invocations from client to service and from service to client. A method gate may be generated from data representation language schema information (e.g. from a service advertisement in a space). The data representation language schema information may include definitions for one or more method interfaces. From this information, code may be generated as part of the gate for interfacing to one or more methods. Each method invocation (e.g. from a client application) in the generated code may cause a message to be sent to the service containing the marshaled method parameters. The message syntax and parameters to be included may be specified in the data representation language schema. Thus, the method gate provides a data representation language message interface to remotely invoke a service method. The method gate may be generated on the client or proxied on a server, such as the space server where the service method was advertised or a special gateway server.

A service may have a corresponding method gate that implements or is linked to a set of object methods that correspond to the set of method messages implemented in a data representation language and defined in the service's data representation language schema. There may be a one to one correspondence between the object methods implemented by or linked to the service's method gate and the method messages defined by the service's data representation language schema. Once a service's corresponding method receives a message from a client to invoke one of the service's methods, the service's method gate may unmarshal or unpack the parameters of the message invocation and then invoke the method indicated by the received message and pass the unmarshaled parameters.

The method gate may provide a synchronous request-response data representation language message interface in which clients remotely call methods causing services to return results. The underlying message passing mechanics may be completely hidden from the client. This form of remote method invocation may deal with method results as follows. Instead of downloading result objects (and associated classes) into the client, only a result reference or references may be returned in data representation language messages, in one embodiment. An object reference may be a generated results gate representing the real object result. In other embodiments, the client may choose to receive the actual result object. In addition, once a client has received a result object reference, the client may use this reference to receive or manipulate the actual result object. In one embodiment, the result reference includes one or more URIs to the real result.

The real result object(s) may be stored in a service results space. This temporary results space may act as a query results cache. Results returned from each method invocation may be advertised in the results space. A result itself may be or may include a method that could then be remotely instantiated by a client, thus generating its own method gate. Therefore, the distributed computing environment may support recursive remote method invocation.

When a client uses a method gate to remotely invoke a service method, a reference to the method results may be returned from the service method gate instead of the actual results. From this reference, a results gate may be generated to access the actual result. Thus, the client or client method gate may receive a result URI and perhaps a result data representation language schema and/or authentication credential for constructing a gate to access the remote method results.

A service method gate may return a results gate to the client gate as the result of the method. The client may then use the results gate to access the actual results. In one embodiment, the client receiving the results gate cannot distinguish between the results gate and the result itself in which case the results gate may be an object proxy for the actual result object. The results gate may also be a method gate that supports remote method invocation to result objects. In this manner, a chain of parent and child method/results gates may be created.

Client and service message gates may perform the actual sending and receiving of the method invocation and results messages from the client to the service, using a protocol specified in a service advertisement.

In one embodiment, the remote methods may be Java methods. In this embodiment, method results may be correctly typed according to the Java typing system. When a Java method is remotely invoked as described above, the results gate may be cast into the Java type that matches the result type. In this embodiment, method gates may be used in the distributed computing environment to allow remote Java objects to behave as local Java objects. The method invocation and results may appear the same to the client Java software program whether the real object is local or remote.

In one embodiment, a message including a representation of a method call may be generated on a client when no actual method call was made. In this embodiment, a process on the client may invoke computer programming language methods on a service without the client actually generating computer programming language method calls.

In one embodiment, a client may transform a method call into one or more messages that may be sent to the service, wherein the messaged do not include information that may be unmarshaled into a method call, but instead include information that may be used by the service to perform a function on behalf of the client. In this embodiment, the service may not know that the messages were originally generated from a method call. These messages may still be considered a "representation" of the method call, but may not be in a form that the service recognizes as a marshaled method call that may be unmarshaled to regenerate a method call.

In one embodiment, a service may transform one or more messages requesting the service to perform one or more functions into a method call. In this embodiment, no method call may have been made on the client to generate the messages. Thus, the client may not know that the service is invoking a method to perform the requested function(s).

In one embodiment, credentials may be used for verifying clients and messages on services. A credential may be embedded in each message sent by the client to the service. The service may check the messages from the client to verify that the messages include the proper credential for the client. In one embodiment, the service method gate may perform the verification. In another embodiment, a service message gate may perform the verification, and may then pass the verified message to the service method gate.

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. 10 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; and

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.

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 receive( ) 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