Browse Prior Art Database

DNS Based Remote Programming Objects

IP.com Disclosure Number: IPCOM000204596D
Publication Date: 2011-Mar-05

Publishing Venue

The IP.com Prior Art Database

Abstract

This is a system for accessing remote programming objects using DNS to manage the locating as well as the connecting to the remote object. The remote object could be on another server within the current network, or anywhere on the internet.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

Page 01 of 11

DNS Based Remote Programming Objects

This is a system for accessing remote programming objects using DNS to manage the locating as well as the connecting to the remote object. The remote object could be on another server within the current network, or anywhere on the internet.

With current technology an extensive infrastructure is required to find a remote object. With this process, existing DNS servers are used to locate objects and information about objects. This process means no additional infrastructure is needed, and it is platform independent. For example a Macintosh programmer using Objective C could access a .Net object residing on a Windows Server 2008 machine. Furthermore, unlike most existing remoting technologies, this process does not require the user of a remote object to have any prior knowledge of the remote objects structure. The remote objects structure will be returned in response to the DNS Query.

DNS or Domain Name Service is used to match domain names to IP addresses. There are already extensions to DNS to handle other activities. For example RFC 2230 ( http://www.rfc- archive.org/getrfc.php?rfc=2230 ) defines key exchange via DNS. When one looks up a domain, if the entry defines it as needing encryption keys, then a key exchange is initiated. RFC 5702 allows one to use hashing with DNS records. RFC 5507 defines methods for expanding DNS with a new record.

In this process a given DNS record would include information regarding a remote object. That information would include everything needed to connect to that object. So by simply looking up a domain name, such as www.mydomain.com/myobject a client would immediately be connected to a remote object. If security is required, it will be defined in the DNS entry.

Background

There are several methods for remotely accessing programming objects. COM, DCOM, OLE, .Net, Enterprise Java Beans, and CORBA have all been used. Also patent number 5,881,230 dealt with this issue. The 5,881,230 patent was really just an extension of the OLE concept. In that process a specialized application is required to serve programming objects to clients. That specialized application functions as a proxy, serving up proxy objects and interfaces from the remote object. As with OLE and COM each object has a unique ID called a class identifier (CLSID) also referred to as a GUID (Globally Unique Identifier).

The 5,881,230 patent expressly requires an OLE channel, and the object references are OLE object references. It also requires a minimum of 3 tiers: client, remote server (for objects), and remote object. It also requires encryption.

All current methods (OLE, COM, DCOM, CORBA) have one or more of the following problems:
1. Complex to setup. CORBA and Enterprise Java Beans are notoriously complicated.

2. Technology specific: COM/DCOM is a Windows only technology. While Microsoft

claims it can be used with any platform, the difficulties in using it alternative platforms are tremendous. Enter...