Client/server computing has become more and more important over the past few years in the information technology world. This type of distributed computing allows one process (the client) to delegate some of its work to another process (the server) that might, for example, be on a different machine and be better suited to perform that work. For example, the server could be on a high-powered computer running a database program managing the storage of a vast amount of data, while the client could be on a desktop personal computer (PC) which requests information from the database to use in one of its local programs. Note that “client” is used to refer to a process that sends a request and this could refer to either a pure client process, that is not capable of receiving requests, or a server process behaving as a client. “Server” is used to refer to the process that receives a request, and generally all servers are capable of being clients. Note also that computers are generally capable of running more than one process and so it cannot be assumed that the terms client and server refer to any particular computer.
Use of Object Oriented Programming techniques is commonplace in client/server systems and typically an object in a client, requests an object in a server, to carry out work on its behalf. For example, when an object in a client process wishes to make a request to an object in a server process, it first locates a server that supports that object. Having found a suitable server it then either creates a new instance, or finds an existing instance, of the required server object, before sending it the request for work to be done. The request may, for example, be a method to call with a list of input and output parameters. The server object may then return results from the method call.
Note that in processing a client request, a server object may delegate some work to another server object in a different server. As a result the original client request can involve a chain of servers where, for a given server, servers ahead of the given server in the chain (i.e.: nearer to the original client) are upstream servers and servers behind a given server in the chain are downstream servers.
In a typical client or server, the programs that run can be logically divided into application software, system software and the operating system. In the example described the application software could be the client object and the server object, which perform the basic function of the application, for example obtaining the balance on a bank account and displaying it to the user. The system software then provides services to the application software in order to minimise the complexity of applications, such that the application programmer primarily need only be concerned with application functionality. For example, the systems software will provide services to locate servers that support given objects, communicate requests to different servers, provide transaction support etc. As a result the application software and system software are usually produced by different organisations. The operating system provides underlying services to application and systems software.
The system software handles communication between clients and servers and must provide a consistent set of services to the application program whichever client or server the application is executed in. In a distributed client/server computing environment, it is most advantageous if work can be freely delegated around a network as this enables, for example, a client application to obtain data that has been consolidated from information available from several different servers on several different machines. However there are many providers of system software and whilst the software from a single provider should provide this capability, a set of servers from a variety of providers will only be able to do so if they agree, for example, a common way to communicate. As a result organisations exist that define standards such that if client/server system software of different providers conform to the standards specified, their clients and servers can communicate and delegate work to each other.
One such organisation is the Object Management Group, Inc. (OMG) which is an international consortium of organisations involved in various aspects of client/server computing, on heterogeneous platforms, with distributed objects. The OMG has set forth published standards for client/server communication and application services. These standards are specified in the Common Object Request Broker Architecture (CORBA (Trademark of Object Management Group, Inc.)). The clients and servers of system software that conform to these standards are able to communicate and provide a consistent set of standard services to the application. Hence adherence to these standards by different system software providers ensures that clients and servers of those providers can distribute work to each other.
As part of the CORBA standards, the OMG has also set forth standards related to a transactions service. The transactions standards are known as the OTS or Object Transaction Service. See, e.g., CORBA Object Transaction Service Specification 1.1, available from http://www.omg.org. Computer implemented transaction processing systems are used for critical business tasks in a number of industries. A transaction defines a single unit of work that must either be fully completed or fully purged. For example, in the case of a bank automated teller machine from which a customer seeks to withdraw money, the actions of issuing the money, reducing the balance of money on hand in the machine and reducing the customer's bank balance must either all succeed or all fail. Failure of some but not all of the subordinate actions would lead to inconsistency between the records and the actual occurrences. With this type of transaction the sort of benefit that a standard such as OMG can provide is that a transaction can span two different banks using client/server software from two providers if both providers conform to the OMG OTS standard. The standard achieves this by specifying an interface to a set of transaction services with details of how the service should work and how the service should communicate the presence of the transaction between clients and servers.
One drawback of standards conformance is that it can be difficult for system software providers to provide additional or improved functionality over the standard and/or competitor software. This is because, when a client makes a request, it cannot be sure as to which server will process the request. Similarly when a server receives a request, it cannot be sure as to which client sent the request. As a result, it is difficult to deviate from flows specified by the standard, even in communication between a client and a server from the same provider.
However the standard does make some allowance for different behaviour between system software providers by use of a context. The OMG standards specify a data section, known as a context, which is included with a standard flow from one process to another. The context is not critical to the delivery of the request but enables client/server processes to exchange information. The contents of the context are largely specified by the standard but also include a pre-defined free format section which is available for the exchange of provider specific data. For example, the OTS standard defines a propagation context for a transactional flow which is used to communicate, in a standards specified format, the identity of the transaction under which the flow was made. However, the standard also specifies that the propagation context includes an optional, effectively free format, section known as the implementation specific data (ISD). Client/server processes can use this section to exchange information that is not part of the standard.
A specific problem with using the ISD is how to ensure that any received ISD was created by the sending client and not simply passed on from a different client. For example, consider a transaction which is distributed across client/servers A-B-C, where A and C have an OTS implementation of one provider, say provider X, and B has another. The OTS implementation of A and C uses the ISD in a request flow to indicate “provider X” and the ISD in a reply flow to return additional information to a provider X client. If A sends ISD to B then B will not understand it and cannot use it. If B calls C, it may pass its own ISD it may pass A's ISD or it may pass none. C's biggest problem occurs when B passes A's ISD as it contains “provider X” and appears to C to have come from a provider X client. As a consequence C includes additional data, intended for A, in the ISD associated with its reply flow. However B receives this reply and may then decide to reply to A either with no context or with a context that includes the ISD originally received from A. This would result in the additional information being lost and, if the additional information is critical, an undefined failure of the transaction. Given that this scenario is possible, even if unlikely, the ISD cannot be used for this purpose as a transaction service that causes transaction failures in certain scenarios would not be acceptable.
USPTO Backgrounds
USPTO Backgrounds