Marshalling interface between provider and server

Electrical computers and digital processing systems: interprogra – Remote procedure call

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C711S217000, C711S218000

Reexamination Certificate

active

06785895

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The subject invention relates generally to data processing systems and more particularly to a method and apparatus for marshalling data for transmission across an interface.
2. Description of Related Art
In the present state of the art, data is located everywhere: on mainframe servers, on PC desktops, on the web. Data resides in these environments in many different formats: relational and non-relational database management systems, ISAM files, e-mail, spreadsheets, audio, video, real time data feeds for news and stock, CAD/CAM systems, and so on.
With today's tools and software technology, there is increasing pressure to provide access to this diverse data from multiple clients using standard interfaces, without moving the data from its origin. Businesses need to build solutions that span desktops, servers, and the Internet. In addition, the end user wants to access this data in the same way, regardless of the language used.
In order to facilitate access to structured and unstructured data in such diverse locations, Microsoft Corporation has developed a software interface specification known as OLE DB. OLE DB particularly provides a set of Component Object Model (COM) interfaces. According to OLE DB, data “providers” are employed to expose data stored as OLE DB compliant data sources so as to allow access to them by OLE DB data “consumers”.
One type of data provider wherein the subject invention finds use may be viewed as a two-tiered application consisting essentially of two main components denoted the “client” and the “server”, which communicate with one another across a TCP/IP connection. The client sends messages called “requests” across the connection to the server, and the server returns messages called “results” across the connection to the client. Requests and results consist of strings of bytes.
Client data is stored in PC format, which means that alpha data is encoded in ASCII characters and integers are stored with their bytes in reverse order (a characteristic of the Intel processors that are used on PC's). The format of data on the host (server) is typically quite different. For example, alpha data on the host may be encoded in EBCDIC and integers may be stored with their bytes in normal order. Such encoding and storage is employed for example in Clearpath and A-Series environments present on computer systems manufactured by Unysis Corp., Blue Bell, Pa. Because of such differences between client and server data, the format of all data to be sent in requests by the client to the server must first be reformatted appropriately.
Client data is also organized in complex data structures often involving disconnected data located by pointers (memory addresses). Such data cannot simply be sent “as-is” to the server since the pointers point into the client's memory space and would be meaningless in the host environment. At the very least, the memory addresses must first be converted to relative references such that the server can use them. Also, each item must be converted to the appropriate host format, and the structures must be reorganized in a buffer as a single string of bytes. The process by which all of this is accomplished is known as “marshalling”, and the buffer used is referred to as the “request buffer”. The marshalling technique wherein the preferred embodiment of this invention finds application involves providing a serial string of data structures called “chunks” wherein it is desired to maintain information in one chunk as to the location of a subsequent chunk.
A number of problems arise when designing object-oriented program code to marshal such request messages. A first problem is that, in allocating a new chunk, the request buffer might have to be resized, which could, and likely would, cause the buffer to be moved to a new location in memory. Thus, conventional pointers (absolute memory addresses) cannot be used to reference subsequent chunks. A second problem is how to avoid consuming large amounts of memory on the stack when objects representing the data chunks are instantiated. As known to those skilled in the art, the “stack” is an area of memory designated to hold data required by functions of the program.
SUMMARY OF THE INVENTION
According to the invention, chunks in a request buffer are referenced by the marshalling code without pointers. This approach is implemented by using objects to represent the various data structures or “chunks” in the request message, which objects contain only (1) an offset representing the offset of a particular data structure from the start of a message and (2) a pointer to a request object. The request object, which represents the message as a whole, includes methods for reformatting data to server-compatible format. Since the objects representing the data structures need only include an offset and a pointer, they consume very little stack memory when instantiated.
Thus, according to one aspect of the invention a request message is formed by a method comprising the steps of: representing each of a plurality of data chunks to be stored in the message by a respective chunk object; declaring each of the chunk objects as a variable on the stack; storing a first data chunk in a first area of the message; storing a second data chunk in a second area of said message; and employing the chunk object representing the first data chunk to locate the first data chunk in subsequent steps. Such subsequent steps may include the loading into the first chunk of an offset representing a location in the second chunk. Thus, an offset stored on the stack is used to locate a previous chunk in order to store in that previous chunk an offset value, instead of a pointer, where the offset value represents an offset from the start of the message.
Various objects, features and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only the preferred embodiment of the invention, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive, and what is intended to be protected by Letters Patent is set forth in the appended claims. The present invention will become apparent when taken in conjunction with the following description and attached drawings, wherein like characters indicate like parts, and which drawings form a part of this application.


REFERENCES:
patent: 4922414 (1990-05-01), Holloway et al.
patent: 5212778 (1993-05-01), Dally et al.
patent: 5636371 (1997-06-01), Yu
patent: 5918252 (1999-06-01), Chen et al.
patent: 5974416 (1999-10-01), Anand et al.
patent: 5991777 (1999-11-01), Momoh et al.
patent: 6002852 (1999-12-01), Birdwell et al.
patent: 6003024 (1999-12-01), Bair et al.
patent: 6088777 (2000-07-01), Sorber
patent: 6182202 (2001-01-01), Muthukkaruppan
patent: 6453383 (2002-09-01), Stoddard et al.

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Marshalling interface between provider and server does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Marshalling interface between provider and server, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Marshalling interface between provider and server will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3344487

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.