WO2007027911A1

WO2007027911A1 - Distributed object interface discovery

Info

Publication number: WO2007027911A1
Application number: PCT/US2006/034056
Authority: WO
Inventors: Robert Drury; Mark Lawrence Chen
Original assignee: Ektasis, Inc.
Priority date: 2005-09-02
Filing date: 2006-09-01
Publication date: 2007-03-08

Abstract

A request from a client is sent to a name server. The request includes a unique identifier and a function name. In response to the request, the name server returns to the client a locator object. The client then invokes a method on the locator object, wherein the method sends a session request to a target server. In response to the session request, the target server returns a connector object to the client. The client invokes an interface on the object to conduct the transaction between the target server and the client.

Description

Distributed Object Interface Discovery

Related Application Data

The present application claims the benefit of and priority to United States

Application for Provisional Patent, Application No. 60/713,700, filed 02 September 2006, the contents of which are incorporated herein by reference.

Background of the Invention

Field of the Invention

The present invention relates generally to transactions between hosts over a network and, more particularly, to a transaction session conducted between such hosts in a protocol independent manner.

Description of the Related Art

As is well known, transactions between hosts, such as between a client and a server or as between peers, over a network generally require negotiation of the protocol layers of corresponding protocol stacks at each of the hosts to effect the communication.

In a typical transaction, data as developed at the application layer of the protocol stack at one host, exemplarily being the sending host, is to be communicated to the application layer of the protocol stack of other host, exemplarily being the receiving host, whereat such data is to be consumed. The data, upon being developed at the application layer of the sending host, is passed to the transport layer of the protocol stack at the sending host. At the transport layer the data is encapsulated into packets with a header containing information specifying the address and port of the host at which the data is developed and the host that is to receive such data. The packets are then passed to the network layer of the protocol stack at the sending host. At the network layer an additional header containing information, which enables routing of the packets from the network of the sending host to the network of the receiving host, is added. From the transport layer the packets are passed to the media layer at which the packets are framed with information enabling node-to-node routing through and between one or more networks from the sending host to the receiving host.

When the packets arrive at the receiving host, the protocol stack at the receiving host is negotiated in reverse order as had been performed at the sending hpst to strip the header information added at each protocol layer of the sending host until the data, as developed at the application layer of the sending host, is received for consummation at the application layer of the receiving host, thereby completing the transaction. Of particular interest herein are the protocols of the host layers that provide for the exchange of data developed for transactions between hosts in network communication with each other, as opposed to the network and media layers that provide for the routing of the packets across and through networks.

Many different types of host-to-host transactions are known, and each type of these transactions relies upon a specific set of host layer protocols developed for the specific type of transaction. For example, a web page obtained from a server is rendered at a client using the Hypertext Transfer Protocol (HTTP). In another' example, a text message may be composed at the client and sent to a mailbox on a mail server at a particular domain using the SMTP protocol. Each of these protocols, being application layer protocols, rely on the Transmission Control Protocol (TCP), as the transport layer protocol to establish a connection between the client and server and form the packets in which the data is communicated. TCP ensures that all of the HTTP or SMTP structured data developed at the application layer of the sending host and to be consumed at the application layer of the receiving host is reliably and completely communicated between the server and the client by requiring that all TCP packets that have been sent from the sending host are received at the receiving host.

In an exemplary peer-to-peer transaction between hosts, there is no dedicated network device that provides a service or manages the network resources. Instead, all responsibilities are uniformly divided among all network devices, known as peers. For example, in some file sharing systems similar components of executable code are respectively running at two peers and each are generating data in response to user input. This data is then transferred between the peers over the network and the executable code at each peer receiving the data then renders such data for the user interface. Similarly as above, a transport layer protocol is still required to establish a connection between peers and encapsulate the data into packets.

Another example of an application layer protocol is the Real Time Transfer Protocol (RTP) used exemplary for streaming of video from the server to the client. Packets of the video are communicated from the server to the client using the User Datagram Protocol (UDP). In such applications, UDP is preferable to TCP in that not all UDP packets need be received at the receiving host prior to the data in each packet being reconstructed for consummation at the application layer. Instead, should a UDP packet be lost in transmission in an exemplary streaming video application, the video may still be viewed from reconstructing the data contained in the remaining UDP packets with imperceptible loss of information.

As seen from the above examples, some application layer protocols, such as HTTP and SMTP, cannot be transported over UDP, since any loss of a packet during transmission would result in perceptible and unacceptable loss of data when rendered at the receiver, and are therefore dependent upon TCP as the transport protocol. Conversely, other application layer protocols, such as RTP for streaming video, cannot be transported over TCP, since any loss of a packet during transmission would rςsult in video motion being halted upon the occurrence of the first missing packet, and are therefore dependent upon UDP as the transport protocol. Accordingly, applications that develop and consume data using any application layer protocol must be written to implement the appropriate transport layer protocol. Accordingly, there exists a need to provide an apparatus and method to conduct a transaction between hosts in a protocol independent manner.

The forgoing examples of transactions between hosts are highly specific and simplified examples of distributed computing environments. Generally, distributed computing is the process of aggregating the computing resources of several computing entities to run collaboratively a single computational task in a transparent and coherent way, so that these entities appear as a single, centralized system. Various types of hardware and software systems on which processes may be distributed throughout a network of computing devices are known.

In the forgoing examples of transactions, several components of executable code are concurrently running on different hosts in the network. In this particular framework, each of these components, although distributed among different hosts, is nonetheless designed to operate in a standalone mode on its respective host. As described above, distributed computing in this framework is made possible by the system of protocols that enable any one of these components running upon one network device to exchange data over the network with a complementary component running on another network device.

Although application processes running on the above exemplary frameworks are generally referred to as network applications, the code running on each host to implement the exchange of data between hosts over the network is a fully functional standalone application on its host. It is only through consuming data, which has been developed at a remoter host and received from the network, do such application processes provide a useful user experience at the user host. Accordingly, in this type of distributed computing environment, data sharing, rather than resource sharing, is the primary feature.

Software systems for resource sharing distributed computing environments are known to utilize more fully the aggregate computing resources of the network devices. However, in general, these systems may impose a significant burden on the programmer tasked with writing the network application by requiring the implementation and administration of features that are not central to the functioning of its distributed components. Examples of these systems are native implementations of network applications and XML messaging,

Native implementations of the network application are inherently limited in their ability to execute on a variety of different platforms, because any native implementation of the network application must be written and maintained for every target platform on which the network application will execute. Accordingly, these native implementations disadvantageously bind the program developers into a regimen of release versions tailored for every change of any one of the target platforms. Furthermore, changes to any one of the target platforms may further disadvantageously limit the programmer's ability to provide and distribute bug fixes and to maintain compatibility with the variety of platforms.

XML messaging, commonly used in web based frameworks such as SOAP, J2EE, and some proprietary technologies such as Macromedia's Flash and ActionScript, are inherently limited due to interoperability problems. For example, each component of executable code receiving an XML message must have knowledge of the XML tags from a document type definition or schema; otherwise the code will be unable to interpret the data. XML messaging is further disadvantageous in that it is an extremely inefficient method for transmitting data structures between each component of code.

In furtherance of the aggregation of the resources of network connected hosts, many network applications are now developed using object oriented programming, which is a method of programming that abstracts a computer program into manageable sections. The basis of object oriented programming is the concept of encapsulation.

Encapsulation is a methodology that combines the subroutines, or methods, that manipulate data with the declaration and storage of that data. This encapsulation prevents the data from arbitrarily being accessed by other program subroutines, or objects. When an object is invoked, the associated data is available and can be manipulated by any of the methods that are defined within the object to act upon the data.

The basic component of encapsulation is a class. A class is an abstraction for a set of objects that share the same structure and behavior. An object is a single instance of a class that retains the structure and behavior of the class. Objects also contain methods that are the processes that instruct an object to perform some procedure or manipulation of data that the object controls. Classes may also be characterized by their interface that defines the elements necessary for proper communication between objects.

In an object oriented distributed computing platform an object in a first network device, or a first address space, may seamlessly communicate with and manipulate an object contained in a second network device, or second address space. This type of distributed computing platform, although not restricted to the above described communication protocols, nonetheless places protocols in a mid-level software layer that manages communications across a computer network to facilitate a client's access to and manipulation of data contained on a server. Therefore, there is still a requirement for protocol dependency to be written into the application software.

Distributed computing and object oriented programming have led to the development of distributed object management systems. These distributed object management systems are generally referred to as object request brokers. When an object on a client requests access to an object that exists on a server, the distributed object management system provides the communication link between the two devices and, thus, between the two objects. The distributed object management system removes the requirement of the client object communicating directly with the server object. Instead, current distributed object management systems utilize a remote proxy object on the client which models the interface of the server object. The client that requested access to the server object communicates with the remote proxy object that exists on the client. Therefore, the client can operate as if it is communicating directly with a local object. The remote proxy object contains the necessary communications information to allow the client to access and manipulate an object that actually exists on the server. Remote proxies allow the client to disregard the location of the requested object and the communication details.

A proxy is an object that has an interface and method list identical to another object. However, it does not contain the same detailed computer code. Instead, it contains communications facilities that allow the proxy to communicate directly with another object without knowledge of the requesting object. Proxies can be used to control access to certain objects. They may also be used to remove the labor of network communications from local objects. For example, if object A residing on a first device needs to communicate with object B residing on a second device, object A must know the location of object B and have the necessary computer code to initiate communications with object B. A proxy for object B located on the first device allows object A to simply communicate with the proxy of object B as if object B resided on the same device. The proxy for object B has all the necessary information and computer Code to communicate with the real object B on the second device. This type of proxy is, known as a remote proxy since it exists on a device remote from the device that contains the requested object.

Systems heretofore known have required all possible remote proxies to be built when the software is initially compiled and loaded. This process imposes an administrative burden in ensuring that proxies are current with respect to the objects from which they are generated. In addition, software system designers must predict every possible remote proxy that may be needed in the future so that it can be built when the software is loaded. This process does not allow a system to adapt to its usage and environment. Therefore, a need further exists for an apparatus and method to enable remote object interfaces in network applications to be discovered as needed from unknown locations.

Summary of the Invention

Accordingly, it is a primary object of the present invention to enable remote object interfaces in network applications to be discovered as needed from unknown locations.

It is a further object of the present invention to provide and apparatus and method to conduct a transaction between hosts in a protocol independent manner.

The present invention meets this need through an apparatus and method in which a request from a first host on a network is sent to a name server. The request includes a unique identifier and a function name. In response to the request, the name server returns to this host a locator object. This host then invokes a method on the locator object, wherein the method sends a session request to another second host on the network. In response to the session request, the second host returns a connector object to the first host. The first host invokes an interface on the object to conduct the transaction between the first and second hosts.

A feature of the present invention is that both hosts, when operating in a platform independent object oriented environment, in effect implement a network application in a virtual machine framework wherein each object for the network application is in an initially unknown location. The locator object for the desired function that is returned to the first host encapsulates data relating to the location of the object whose interface defines the desired function. By invoking the method on the locator object, the session request is sent to the second host identified by the encapsulated data. The second host then returns the connector object for which the client may invoke its interface. The methods defined by the interface may then be implemented to conduct the transaction between these hosts as a distributed network application on a virtual machine framework. It can be seen from the forgoing, irrespective of the application being implemented, that the transport layer protocol between the hosts, whether stateful or stateless, can be advantageously specified independently of the application.

These and other objects, features and advantageousness of the present invention will become readily apparent to those skilled in the art from a study of the following Description of the Exemplary Preferred Embodiments when read in conjunction with the attached Drawing and the Append Claims.

Brief Description of the Drawing

Fig. 1 is a schematic block diagram of an apparatus constructed according to the principles of the present invention invention; and Fig. 2 is a flowchart of an exemplary method for distributed object interface discovery in accordance with the present invention.

Description of the Exemplary Preferred Embodiments

Referring to Fig. 1, there is shown a network 10 including a plurality of hosts, exemplarily seen as a client 12 and a server 14, and a name server 16. Each of the client 12, the target server 14 and the name server 16 are enabled in a platform independent, object oriented computing environment. Although only one client 12 and one target server 14 are shown, it is to be assumed that the hosts may include either of multiple clients similar to the client 12 and multiple servers similar to the target server 14 on the network 10.

Referring now to Fig. 2, there is shown a flowchart 18 of an exemplary method to implement the distributed object interface discovery of the present invention. As indicated at 20, the client 12 sends a request to the name server 16. The request, which may be in any format recognized by the name server 16, includes a unique identifier, which identifies a desired server as described in greater detail below, plus the name of a well-known function.

The unique identifier is used to identify a particular location in the network 10. For example, the unique identifier may be an Internet domain name or the name of a particular computer within the network 10. The function may be any typical transaction that occurs between hosts on the network 10, such as a mail transaction or a file transfer transaction. The hosts in the forgoing example would be the client 12 and the target server 14, or a particular address space at the target server 14.

In response to the request, the name server 16 returns to the client 12 a locator object, as indicated at 22. The locator object implements a well-known interface for the function identified in the request. For example, if the function identified in the request were for the mail transaction, the locator object returned may exemplarily be called "MailLocator" and the well-known interface would then contain a method exemplarily called "ConnectToMailServer."

The locator object also contains a location of the server, or an address space within a server, in the network 10 identified by the unique identifier in the request. Typically, this location is given by an IP address. This IP address is determined from a lookup query based on the unique identifier. In the forgoing example, the IP address would be the IP address of the domain (from the unique identifier) residing at the target server 14.

As indicated at 24, the client 12 then invokes a well-known method on the received locator object. This method then sends a session request to the location identified by the locator object. In the forgoing example, the invoked method would send a request for a mail session to the domain at the IP address at the target server 14 contained in the "MailLocator" locator object.

In response to the session request, the target server 14 then returns a connector object to the client 12, as indicated at 26. In the forgoing example, the connector object may be an object called "MailConnector."

Upon receipt of the connector object from the target server 14, the client 12 then invokes a well-known interface on the connector object, as indicated 28. When the interface is invoked, the transaction between the client 12 and the target server 14 may then be conducted.

For the forgoing example, the object MailConnector may then implement a well- known interface called "sendMail." To implement the interface, the client would pass a mail message to the "sendMail" method on the MailConnector object. The Mail Connector object would then pass the mail message to the domain identified by the unique identifier at the target server 14. In another embodiment of the present invention, the locator object may further encapsulate data relating to a plurality of hosts, such as a plurality of target servers each being similar to the target server 14, The method invoked on the locator object may then search for one of these target servers based on predefined criteria. A feature of using such criteria is that one of these target servers can be advantageously selected as the target server 14 to reduce network latency. For example, the selection of the target server 14 from all such target servers could be based on its physical proximity to the client 12, as determined by the IP address of each of the target servers. Selection of the target server 14 from each of the target servers could also be made in accordance with the current load of each of the target servers.

Furthermore, the connector pbject supplied by the selected target server 14 could further test response time performance of the selected target server 14. A feature of this embodiment of the invention is that the client 12, running the locator and connector objects can thereby measure the time duration between invoking the method, as indicated at 24, and receiving the connector object, as indicated at 26. The client 12 carl therefore advantageously acts as a load balancer for the target servers.

From the forgoing example, it is apparent to those skilled in the art that various network transactions, implemented in accordance with protocol definitions, can now be implemented in a protocol independent manner through the use of distributed objects in a platform independent, object oriented computing environment, in accordance with the principles of the present invention described hereinabove. Any application layer protocol, such as FTP, NNTP, in addition to all other application layer protocols can be implemented using the distributed objects described above, independently of the transport layer protocol defined for use with such protocol.

There has been described hereinabove a novel method for distributed object interface discovery. Those skilled in the art may now make numerous uses of, and departures from, the above described embodiments without departing from the inventive principles disclosed herein. Accordingly, the present invention is to be defined solely by the lawfully permitted scope of the appended Claims.

Claims

The Claims

What is claimed as the invention is:

L A method to conduct a transaction between hosts on a network in a protocol independent manner comprising steps of: sending a request from one of said hosts to a name server wherein said request includes a unique identifier and a Junction name; returning to said one of said hosts from said name server in response to said request a locator object; invoking at said one of said hosts a method on said locator object wherein said method on said locator object sends a session request to one other of said hosts; returning to said one of said hosts in response to said session request at said one other of said hosts a connector object; and invoking at said one of said hosts an interface on said connector object to conduct said transaction with said one other of said hosts.

2. A method to conduct a transaction between hosts on a network as set forth in Claim 1 wherein said one of said hosts is a client and said one other of said hosts is a target server.

3. A method to conduct a transaction between hosts on a network as set forth in Claim 2 wherein said unique identifier is an Internet domain name.

4. A method to conduct a transaction between hosts on a network as set forth in Claim 2 wherein said unique identifier is name of a selected computer on said network.

5. A method to conduct a transaction between hosts on a network as set forth in Claim 2 wherein said function is a file transfer transaction.

6. A method to conduct a transaction between hosts on a network as set forth in Claim 2 wherein said function is a mail transaction.

7. A method to conduct a transaction between hosts on a network as set forth in Claim 2 wherein said one other of said hosts is an address space at said target server.

8. A method to conduct a transaction between hosts on a network as set forth in Claim 1 wherein said locator object implements a known interface for said function name.

9. A method to conduct a transaction between hosts on a network as set forth in Claim 1 wherein said locator object contains a location of said one other of said hosts.

10. A method to conduct a transaction between hosts on a network as set forth in Claim 9 wherein said location is an IP address.

11. A method to conduct a transaction between hosts on a network as set forth in Claim 10 wherein such IP address is determined from a lookup query utilizing said unique identifier.

12. A method to conduct a transaction between hosts on a network as set forth in Claim 1 wherein said invoking said method on said locator object step sends said session request for said function name.

13. A method to conduct a transaction between hosts on a network as set forth in Claim 1 wherein said locator object further contains a location of each of a plurality of hosts and further wherein said one other of said hosts is selected from said plurality of hosts in accordance with predefined criteria.

14. A method to conduct a transaction between hosts on a network as set forth in Claim 13 wherein one of said criteria is physical proximity to said one of said hosts.

15. A method to conduct a transaction between hosts on a network as set forth in Claim 14 wherein one of said criteria is a current load of each of said plurality of hosts.

16. A method to conduct a transaction between hosts on a network as set forth in Claim 1 wherein a time duration between said invoking said method on said locator object step and said returning said connector object step determines a response time of said one other of said hosts.

17. An apparatus that conducts a transaction between hosts on a network in a protocol independent manner comprising: a name server; and a plurality of hosts, one of said hosts being operative to send a request to said name server wherein said request includes a unique identifier and a function name, said name server being operative to return to said one of said hosts a locator object in response to said request, said one of said hosts being further operative to invoke a method on said locator object to send a session request to one other of said hosts, said one other of said hosts returning to said one of said hosts a connector object, said one of said hosts further being operative to invoke an interface on said connector object to conduct said transaction with said one other of said hosts.

18. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 17 wherein said one of said hosts is a client and said one other of said hosts is a target server.

19. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 18 wherein said unique identifier is an Internet domain name.

20. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 18 wherein said unique identifier is name of a selected one of said hosts on said network.

21. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 18 wherein said function is a file transfer transaction.

22. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 18 wherein said function is a mail transaction.

23. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 18 wherein said one other of said hosts is an address space at said target server.

24. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 17 wherein said locator object implements a known interface for said function name.

25. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 17 wherein said locator object contains a location of said one other of said hosts.

26. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 25 wherein said location is an IP address.

27. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 26 wherein such IP address is determined from a lookup query utilizing said unique identifier.

28. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 17 wherein said one of said host upon invoking said method on said locator object is further operative to send said session request for said function name.

29. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 17 wherein said locator object further contains a location of each of a plurality of hosts and further wherein said one other of said hosts is selected from said plurality of hosts in accordance with predefined criteria.

30. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 29 Wherein one of said criteria is physical proximity to said one of said hosts.

31. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 30 wherein one of said criteria is a current load of each of said plurality of hosts.

32. An apparatus that conducts a transaction between hosts on a network as set forth in Claim 17 wherein a time duration between said one of said host being operative to invoke said method on said locator object and said connector object being returned to said one of said host determines a response time of said one other of said hosts.