System for connecting a client to a server with a protocol stack dynamically constructed by using top and bottom service descriptions as query parameters

Abstract

A method and system for providing services in an object oriented system. The method and system are in the form of an interface reference framework of objects which create services in response to requests. Clients request services which are created in response to the requests. In response to the request the framework first develops a description of the service. The description is in the form of a stack of descriptions of services. From the stack descriptions the actual services are created by maker objects.

Claims

Having thus described our invention, what we claim as new, and desire to secure by letters patent is:

1. Apparatus for providing a service to a client upon a request by the client, the apparatus operating in a computer system having a processor, a memory, a locator means for dynamically locating service maker entities from within the computer system based on query parameters to create a service maker pool and a service device having a device protocol, and the apparatus comprising:

(a) means for creating a pool of service maker entities in the memorials with a predefined input communication protocol into output signals with another predefined output communication protocol;

(b) means responsive to the request for dynamically creating a stack description in the memory, including:

means for creating a top service description which receives the request having a request protocol and translates the request protocol into signals with a first intermediate protocol,

means for creating a bottom service description which receives signals with a second intermediate protocol and accesses the device according to the device protocol, and

means for constructing an ordered list of service maker entities for translating signals with the first intermediate protocol into signals with the second intermediate protocol by selecting one or more service maker entities from the cool using the top service

description and the bottom service description as query parameters to the locator means to dynamically locate service maker entities and matching the output communication protocol generated by a first selected service maker entity to the input communication protocol received by a second selected service maker entity;

(c) means for dynamically creating a service stack in the memory by using the stack description to sequentially instantiate service maker objects from the entities in the ordered list to form a chain of service maker objects that receives the request in one protocol and accesses the service in another protocol; and

(d) means responsive to the request for providing service to the client by accessing the device through the service stack.

2. The apparatus of claim 1 wherein the service maker object creating means constructs each service maker object from one of a plurality of interface maker class definitions in the memory, each interface maker class definition including a top interface definition specifying one of the communication protocols and a bottom interface definition specifying another of the communication protocols.

3. The apparatus of claim 2 wherein the means for constructing an ordered list of service maker objects matches the bottom interface definition of one service maker object with the top interface definition of another service maker object to construct the ordered list.

4. The apparatus of claim 3 wherein the bottom service definition is associated with a particular device so that the particular device can be connected to the client by a plurality of different service maker object chains.

5. The apparatus of claim 4 wherein the program logic in each of the plurality of service maker objects is responsive to a bottom interface definition for down casting the bottom interface definition to a top interface definition by generating program logic for translating a bottom interface definition to a top interface definition.

6. A method for providing a service to a client upon a request by the client, the method operating in a computer system having a processor, a memory, and a service device having a device protocol, and the method comprising the steps of:

(a) using a locator means in the computer system for dynamically locating service maker entities from within the computer system based on query parameters to create a service maker pool in the memory, each of the service maker entities having program logic for translating input signals with a predefined input communication protocol into output signals with another predefined output communication protocol,

(b) dynamically creating a stack description in the memory in response to the request, the stack description including:

a top service description which receives the request having a request protocol,

a bottom service description which receives signals with a second intermediate protocol and accesses the device according to the device protocol, and

an ordered list of service maker entities for translating signals with the first intermediate protocol into signals with the second intermediate protocol constructed by using the top service description and the bottom service description as query parameters to the locator means to dynamically locate and select one or more service maker entities from the pool and matching the output communication protocol generated by a first selected service maker entity to the input communication protocol received by a second selected service maker entity,

(c) dynamically creating a service stack in the memory by using the stack description to sequentially instantiate service maker objects from the entities in the ordered list to form a chain of service maker objects that receives the request in one protocol and accesses the service in another protocol; and

(d) providing service to the client by accessing the device through the service stack.

7. The method of claim 6 wherein step (a) comprises the step of:

(a1) constructing each service maker object from one of a plurality of interface maker class definitions in the memory, each interface maker class definition including a top interface definition specifying one of the communication protocols and a bottom interface definition specifying another of the communication protocols.

8. The method of claim 7 wherein step (b) comprises the step of:

(b2) constructing an ordered list of service maker objects by matching the bottom interface definition of one service maker with the top interface definition of another service maker object.

9. The method of claim 8 wherein step (b) comprises the step of:

(b3) associating the bottom service definition with a particular device so that the particular device can be connected to the client by a plurality of different service maker object chains.

10. The method of claim 9 wherein step (c) comprises the step of:

(c1) down casting the bottom interface definition to a top interface definition by generating program logic for translating a bottom interface definition to a top interface definition.

11. A computer program product for providing a service to a client upon a request by the client, the computer program product operating with a computer system having a processor, a memory, and a service device having a device protocol, the computer program product comprising a computer usable medium having computer readable program code thereon, including:

program code which uses locator code for dynamically locating service maker entities from within the computer system based on query parameters to create a service maker pool in the memory, each of the service maker entities having program logic for translating input signals with a predefined input communication protocol into output signals with another predefined output communication protocol:

program code for dynamically creating a stack description in the memory in response to the request, the stack description including:

a top service description which receives the request having a request protocol,

a bottom service description which receives signals with a second intermediate protocol and accesses the device according to the device protocol, and

an ordered list of service maker entities for translating signals with the first intermediate protocol into signals with the second intermediate protocol by using the top service description and the bottom service description as query parameters passed to the locator code to dynamically locate and select one or more service maker entities from the pool and matching the output communication protocol generated by a first selected service maker entity to the input communication protocol received by a second selected service maker entity:

program code for dynamically creating a service stack in the memory by using the stack description to sequentially instantiate service maker objects from the entities in the ordered list to form a chain of service maker objects that receives the request in one protocol and accesses the service in another protocol, wherein the client can access the device through the service stack to obtain the service.

12. The computer program method of claim 11 wherein the program code for creating a pool of service maker entities comprises a plurality of interface maker class definitions for constructing each service maker object, each interface maker class definition including a top interface definition specifying one of the communication protocols and a bottom interface definition specifying another of the communication protocols.

13. The computer program product of claim 12 wherein the dynamically creating a stack description comprises program code for constructing an ordered list of service maker objects by matching the bottom interface definition of one service maker with the top interface definition of another service maker object.

14. The computer program product of claim 13 wherein the program code for dynamically creating a stack description comprises program code for associating the bottom service definition with a particular device so that the particular device can be connected to the client by a plurality of different service maker object chains.

15. The computer program product of claim 14 wherein the program code for dynamically creating a service stack comprises program code for down casting the bottom interface definition to a top interface definition by generating program logic for translating a bottom interface definition to a top interface definition.

Description

FIELD OF THE INVENTION

This invention generally relates to improvements in computer systems, and more particularly to a system and method for service creation in an object oriented operating system.

BACKGROUND OF THE INVENTION

Computer systems in general are very rigid. Application developers and users of the system must often know intimate details of hardware protocol and configurations in order to provide a system in which information flows smoothly. Details of each particular type of port and IO device must be dealt with on an individual basis. Application developers and users must also be kept constantly abreast of each change in the system in order to provide corresponding changes to the software and hardware so that the changes can be taken full advantage of.

The rate at which IO devices change, as well as the rate of change of intermediate elements which are used to transfer information to and from an IO device, is extremely fast. Each change requires a learning process of system users so that the system may be kept performing in an optimum manner.

A computer system can be thought of as a large collection of clients which need services performed. Clients could be considered to be virtually any part of the system which may need something. For example, the CPU could be considered to be a client which needs a service performed by a particular element in the system. The performance of the service may involve many steps, and many elements to provide the requested service. A service could be considered to be anything which provides something which is needed by another entity in the system. For example, a particular chip may provide a particular type of digital signal processing as a service for another system element. A single element could at one time be a client, and at another time provide a service to a client.

The interplay of clients and services often requires great attention by developers and users in order to make the requests for services, and providing of services, a smooth process. The protocol for requests and providing is often very inflexible, and requires intervention in minute details to change the protocol. In many respects, requests for services and providing services could be considered to be set in stone.

There is therefore, a need to provide a flexible system for requesting and providing services. The system needs to overcome the above difficulties concerning the level of detail involved, the problems associated with system changes, and the overall rigidity of software and hardware between clients and service providers.

SUMMARY OF THE INVENTION

Accordingly, it is a primary object of the present invention to provide a system and method for improving the interaction between clients and services.

It is another object of the present invention to provide a system and method for improving the flexibility in adjusting to changes in a system of clients and service providers.

It is vet another object of the present invention to provide a system and method for allowing requests for services without concern for details of the service requested.

It is another object of the present invention to provide a system and method for allowing requests for services without concern for details of the service provider.

These and other objects are realized by an interface framework which creates services in response to a request. The system receives an interface reference, and from the reference creates a previously nonexistent service. The interface reference creates in interface maker, which performs the actual creation and activation of a requested service. Activation of the service can be thought of as a two step process in which a service stack description is created, and from this description a service stack is created.

The interface reference is an entity which encapsulates all information necessary to create a service. The client has the interface reference, and activates the reference to create the service which is needed. The interface reference first creates a service stack description by determining the service interfaces which make up the top and bottom of the service stack, and then searching to find a set of services between the top and bottom interfaces which will form the required service stack. The interface maker serves the purpose of "buffering" service provider classes from the service stack framework.

From the service stack description interface makers corresponding to the stack description are created. This creation occurs from the bottom of the description up. The service stack description can be thought of as a list of references to interface makers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a typical hardware configuration of a computer in accordance with the subject invention;

FIG. 2 is a diagram showing a client using an interface reference;

FIG. 3 is a representation of a drag and drop operation;

FIG. 4 shows service stacks associated with a printer and serial data transfer;

FIG. 5 shows service stacks associated with a printer and parallel data transfer;

FIG. 6 is a Booch diagram showing the relationships among the services for a printer;

FIG. 7 is a block diagram illustrating the concept of a personality neutral layer in accordance with the present invention acting as an interface between operating systems and hardware;

FIG. 8 is an overview of the operation of an interface reference;

FIG. 9 illustrates the Interface Reference classes;

FIG. 10 is a block diagram showing possible service stack configurations;

FIG. 11 illustrates the Interface Maker classes;

FIG. 12 demonstrates the hierarchical restrictions among service makers;

FIG. 13 illustrates the freedom of the hierarchy of services;

FIG. 14 illustrates the TInterfaceBundle classes;

FIG. 15 illustrates the hardware configuration for THardwareInterfaceReference;

FIG. 16 illustrates a hypothetical "pool" of service maker entities (i.e. these are the entities which would be found from a TServiceMakerLocator property search);

FIG. 17 demonstrates stack creation by THardwareReference object;

FIG. 18 shows various class relationships of some of the elements of FIG. 17;

FIG. 19 illustrates the creation of the stack description for THardwareInterfaceReference activation;

FIG. 20 illustrates the overall operation of stack creation for THardwareInterfaceReference;

FIG. 21, FIG. 22, and FIG. 23 collectively illustrate, by visual design language, service stack creation by THardwareInterfaceReference;

FIG. 24 is an overview of the hardware configuration for stack description creation for a mouse;

FIG. 25 shows the calculated stack "description" for THardwareInterfaceReference object;

FIG. 26 is an overview of the hardware configuration for stack description creation for a serial port via a switch box;

FIG. 27 is an overview of the hardware configuration for SCSI stack description creation;

FIG. 28 is an example of how THardwareInterfaceReference can be used by the printer framework for an ImageWriterII;

FIG. 29 illustrates Maker Class diagrams;

FIG. 30 illustrates Service Class diagrams;

FIG. 31 shows the hierarchy of TPresentableViews;

FIG. 32 shows the class hierarchy of services if a common class hierarchy was not avoided; and

FIG. 33 and FIG. 34 together demonstrate the development of a maker.

DETAILED DESCRIPTION OF THE INVENTION

The detailed embodiments of the present invention are disclosed herein. It should be understood, however, that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore, the details disclosed herein are not to be interpreted as limiting, but merely as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention.

The history of object-oriented programming and the developments of frameworks is well-established in the literature. C++ and Smalltalk have been well-documented and will not be detailed here. Similarly, characteristics of objects, such as encapsulation, polymorphism and inheritance have been discussed at length in the literature and patents For an excellent survey of object oriented systems, the reader is referred to "Object Oriented Design With Applications" by Grady Booch.

While many object oriented systems are designed to operate on top of a basic operating system performing rudimentary input and output, the present system is used to provide system level support for particular features. It should be kept in mind, however, that innovative objects disclosed herein may also appear in layers above the system level in order to provide object support at different levels of the processing hierarchy.

The invention is preferably practiced in the context of an operating system resident on a personal computer such as the IBM.RTM. PS/2.RTM. or Apple.RTM. Macintosh.RTM. computer. A representative hardware environment is depicted in FIG. 1, which illustrates a typical hardware configuration of a computer in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units interconnected via a system bus 12. The computer shown in FIG. 1 includes a Read Only Memory (ROM) 16, a Random Access Memory (RAM) 14, an I/O adapter 18 for connecting peripheral devices such as disk units 20 and other I/O peripherals represented by 21 to the system bus 12, a user interface adapter 22 for connecting a keyboard 24, a mouse 32, a speaker 28, a microphone 26, and/or other user interface devices such as a touch screen device (not shown) to the bus 12, a communication adapter 34 for connecting the workstation to a data processing network represented by 23. A display adapter 36 for connecting the bus to a display device 38. The workstation has resident thereon an operating system such as the Apple System/7.RTM. operating system.

The following discussion will describe the requirements, client needs and classes provided by a preferred embodiment of the present invention, which will herein be referred to as the "Interface Reference framework."

The Interface Reference framework is designed to provide advances which impact a variety of segments of the computer industry:

1. Designers and developers of the "Computer Viewer", "Low-level hardware configuration framework" and "Network browser".

2. Developers of new types of TModelSurrogates which appear in the computer viewer and network browser.

3. Developers of services (e.g. CAMs, DAMs, Device Channels).

The Interface Reference framework is designed to address needs of developers who want to isolate themselves from the details of how services are created. Developers who use the Interface Reference framework can shield their clients from rudimentary service creating techniques, such as message streams. All of these details are encapsulated by the Interface Reference framework.

The first benefit of the Interface Reference framework is that it provides an abstraction which insulates clients from the details of how services are created. An instance of a subclass of TInterfaceReference represents the ability to create and use a service for a particular device, with an interface specified by the client. In c++, the client typically specifies the interface by just instantiating a particular class. Consider a client who requires a TImageWriter service. There may be lots of concrete TImageWriter service classes available, such as TImageWriterOn Serial, TImageWriterOnParallel, TImageWriterOnMessageStream, TImageWriterOnSCSI. Each of these concrete classes supports the TImageWriter interface. Which one do you choose? The only way you can choose is to know something about where the device is actually connected. But you don't want to know that type of detail. So, we encapsulate this knowledge inside of the interface reference. It determines for you which of the concrete classes to instantiate all the way down to the "metal." For example, consider an ImageWriter. It may be connected to any serial or parallel port on a computer, or even to the network. Each case requires creating a different set of services in order to communicate with the printer. The Interface Reference framework insulates clients from the details of how the Imagewriter is connected and how the services to access the ImageWriter are created.

FIG. 2 presents a high-level scenario of a client 200 (an ImageWriter TModel object) that requires an "ImageWriter" service 202. In FIG. 2, an arrow having a line on both sides indicates message sending which sets up a collaboration. A plain line with a "+" at one end means creation.

The client is given an interface reference 206 to an ImageWriter 204 connected to a built-in serial port on the system. The client sets "ImageWriter" 204 as the top interface and activates the interface reference 206. This causes an ImageWriter service 202 to be created and returned for the target printer. The ImageWriter service 202 itself happens to require a serial service 208. Furthermore, the serial service 208 requires a UART service 210. The ImageWriter TModel object 200 is oblivious to the needs of any of these services. The advantage of this scenario is that the computer viewer and the network browser can both create the same model using the same constructor. This simplifies the model writer's job because he is only required to write one model, not two.

A second benefit of the Interface Reference framework is that service associations are guaranteed to remain valid after a user changes a connection via the computer viewer. For example, as shown in FIG. 3, a user of a graphics interface 300 can drop a printer 302 onto a document 304. This "associates" the document 304 with the printer service. The document 304 uses this printer 302 whenever the default document print command is issued. If the printer's connection is changed, all of the documents which are "associated" with it will still print to the same printer. If this was not supported, then the user would be required to fix each document affected by the modified connection.

A third benefit is that service associations with documents persist across reboots of the system. When the system is rebooted, all of these associations remain valid.

Service Stack: A service stack is a series of services, piled one on top of the other. Each service in the stack exports exactly one interface to a client and expects to use exactly one service below it. The following discussion and diagrams illustrate service stacks. Each box represents a service.

The top box 400 in FIG. 4 represents a service that exports "printer" as its interface to clients. It requires the service "serial" 402/404 below it in order to fulfill its "printer" interface obligations. The top box 500 in FIG. 5 represents a different service than the top box 400 in FIG. 4. Its exported interface is the same, but it demands a different interface, parallel 502/504, below. As shown in FIG. 6, these two services 602, 604 are actually subclasses of a common abstraction 600. This structure allows the client of the top service ("printer" in this case) to be reused across a variety of lower level services. A key purpose of the mechanisms described with respect to the Interface Framework of the present invention is to allow the automatic creation of such stacks, to maximize reuse of higher-level clients.

Top Interface: The interface that a client uses when accessing (or using) a service is called its top interface. In the example above, "Serial" 404 is the top interface of the <Serial, UART> service. "Parallel" 504 is the top interface of the <Parallel, VIA> service.

Bottom Interface: The interface that a service provider uses in order to fulfill its "top" interface responsibilities is called its bottom interface. In the example above, "UART" 406 is the bottom interface of the <Serial, UART> service. "VIA" 506 is the bottom interface of the <Parallel, VIA> service.

Access Manager: An Access Manager is an IO service which can talk directly to a physical hardware component (e.g. an integrated circuit). It handles arbitration between multiple requests to access the hardware.

Requirements

Following is the complete list of requirements for the Interface Reference framework:

Support for polymorphic creation of services: An extensible mechanism is required which can shield consumers of services from the details of how those services are created. The consumer must not need to know if the service is provided remotely or locally. Furthermore, the consumer of local services must not need to know what type of port the service is using (e.g. serial or SCSI) or to which particular port the service is connected (e.g. modem port or printer port).

Allow clients to specify the service interface they want to use: All services export an interface to their clients. The Interface Reference framework must provide a mechanism which enables clients to specify the interface they want.

Ability to reestablish a service if a "connection" changes: When a connection to a local device changes, an appropriate new service must be created. For example, if a printer is currently connected to serial port 1 and a user moves the connection to parallel port 2, a new service, using parallel port 2, must be created.

Support for persistent service associations: A service (e.g. an ImageWriter II icon) can be associated with a document model. It is important that the Interface Reference framework allow clients to preserve the associations users make between services and documents.

Ability to calculate a description of a service: A service description consists of all of the information necessary to create a particular service stack. A service description may be calculated at any time. As an optimization, it may be cached.

Support for lazy activation: A service stack may be created from a service description at any time. This allows clients of the Interface Reference to defer creating a service until the service is actually required. For example, a document model could have an interface reference to a printer. The creation of the printer service stack could be deferred until the time the user requests the document to print.

Support for multiple stacks per 10 port with arbitration at the bottom: More than one stack, for a given IO port, must be allowed to exist concurrently. The arbitration for the hardware resource (i.e. the chip) is handled by the access manager at the bottom.

Stack activation must take advantage of newly "installed" software: Each time a service stack is activated (i.e. created), it must incorporate the latest version of any service that is a member of the stack.

Features

Following are the features of the Interface Reference framework:

Provides polymorphic creation of local and remote services: The Interface Reference framework provides consumers with a simple mechanism for creating and gaining access to services. Clients are insulated from the specific details required to create the service. Service consumers are only required to supply the "top" interface.

Can be extended to support other types of service stacks: The Interface Reference framework is extensible. For example, two types of services such as local and remote could be supported.

Can create a service on the fly from a description: Services are created automatically by the Interface Reference framework at the time a client requests the service. All of the information required to create the service is encapsulated by a Interface Reference entity.

Does not require a Service class hierarchy: Services used by the Interface Reference framework are not required to subclass from anything special. Any class can be used to provide a service for this framework (as long as the right helper classes are available).

Enumerates all possible services provided by an 10 port: The set of services that are currently supported by a particular port is available to clients on demand. For example, the services are used by the computer viewer for type negotiation whenever a device is connected by a user.

Client Dependencies

Hardware Configuration Framework/Computer Viewer: Must enable a TModelSurrogate to create a service which can access the physical hardware. A polymorphic interface reference is required to enable the same model class and constructor to be used by the computer viewer and the network browser. For example, an Image Writer can appear in both the computer viewer and the network browser. The same Image Writer model can be used by both the computer viewer and the network browser.

Requires the ability to know when a connection can be changed (a UI issue). It is preferable to prevent a user from changing a connection for a device which is currently in use.

Computer Viewer/Network Browser: Requires that the same TModelSurrogate class for a service to be used by both the computer viewer and the network browser.

Modem. Printer and MIDI Frameworks: Certain clients mustn't care if the service is local or remote and mustn't care what port the device is connected to. Certain objects and surrogates for particular devices may fall into this category of client. Examples include TModem, printer TModelSurrogate and MIDI TModelSurrogate.

Service Dependencies

Identification of a Service Description: Services are required to identify the interface they export to clients (i.e. their "top" interface) and the interface they require below them (i.e. their "bottom" interface), if they are expected to be used by the Interface Reference framework. Currently, this requirement only applies to the "helper" classes (to be described later) and not to the services themselves.

Hardware Configuration Framework: Information about local ports must be accessible in order to support creation of service stacks for local devices. This dependency implies that the computer database must be initialized with a valid root (i.e. motherboard) THardwareModuleHandle object. The THardwareInterfaceHandle on the peripheral providing the service gives us the following:

the ability to navigate the connection to discover to which port the peripheral is connected and

access to the THardwareInterfaceIdentifier for the port.

Personality Neutral Services

The framework could be considered to be part of the personality neutral layer 706. The personality neutral layer 706 provides services to OS personalities (e.g. Taligent OS 704, OS/2 700, AIX 702). Once ported to the personality neutral layer, these OS personalities essentially become hardware platform 708 independent.

Architecture

While the following discussion provides numerous examples on particular elements of the processing hierarchy, it should be kept in mind that these are for purposes of illustration only. The concepts embodied herein regarding the dynamic creation of service stacks through references by clients can be applied to any elements in the processing hierarchy. The only relationship that is necessary is the need for a service by a client.

Survey

Class Diagram

The Interface Reference framework consists of three sets of classes:

(1) Interface Reference classes (FIG. 9),

(2) Interface Maker classes (FIG. 11); and

(3) TInterfaceBundle classes (FIG. 14).

Overview Diagram

FIG. 8 provides an overview of the relationships between all of the classes in the Interface Reference framework.

A client is given an interface reference object 802. The client sets the top interface attribute 800. The client calls Activate 804. The interface reference object creates an interface maker 806, passing it the bundle collection 810. The interface maker creates a service 808. It may optionally pass it the bundle collection, a specific bundle object, or call specific set methods to setup the service (whatever the service requires). The maker class insulates the interface reference framework from the details of setting up the service.

Interface Reference Components

Interface Reference Classes (FIG. 9):

Developed by Taligent. May be subclassed for special needs.

Used by service consumers to create a service.

TInterfaceReference 900

The primary purpose of TInterfaceReference 900, and its associated attributes 902, is to enable clients to create services without concern for how the service is provided. For example, using the Interface Reference framework, a universal TImageWriterModel class can be written. The class is independent of whether the ImageWriter is located on the network or connected locally to the host computer. An instance of a subclass of TInterfaceReference represents the ability to create and access a service for a specific device, with a specific API.

A service stack can be represented by one or more services nested one on top of the other. From one session to the next, the same TInterfaceReference may create a different service stack depending upon whether the connection has changed or whether new software has been installed.

TInterfaceReference 900 has the following attributes 902:

TopInterface: InterfaceName--This value specifies the type of service interface the client requires.

Bundles: TDictionary<InterfaceName,TInterfaceBundle>--Each key in the dictionary is an InterfaceName object and is associated with one instance of a subclass of TInterfaceBundle. The TInterfaceBundle object encapsulates data specific to the type of interface it represents. For example, a serial interface could encapsulate BAUD rate and Parity information. Bundles are optional. When a service is activated, a bundle (when present) is passed into the service maker.

The following scenario illustrates how a universal ImageWriter model, which will work for local and remote devices, is supported. The ImageWriter model knows only that it has a TInterfaceReference; it doesn't care which type. The service can be remote, local serial or local parallel. These details are unimportant from the point of view of the model. All the ImageWriter model requires is a service exporting an interface of "PrinterDeviceChannel".

The ImageWriter model code, to obtain the printer service, might look like this:

    ______________________________________
    TPrinterDeviceChannelMaker*  theDeviceChannelMakerPtr;
    TPrinterDeviceChannel*  theDeviceChannelPtr;
    TInterfaceReference*   theReferencePtr;
    theReferencePtr = this->GetInterfaceReference();
    theReferencePtr->SetTopInterface(kPrinterDeviceChannel);
    theDeviceChannelMakerPtr = (TPrinterDeviceChannelMaker*)
     theReferencePtr->Activate();
    theDeviceChannelPtr = theDeviceChannelMakerPtr->
    GetDeviceChannel();
    ______________________________________

    ______________________________________
    TUARTAccessManagerMaker*  theUARTAccessManager
    MakerPtr;
    TUARTAccessManager*   theUARTAccessManagerPtr;
    theUARTAccessManagerMakerPtr =
     (TUARTAccess ManagerMaker*)anInterfaceReferencePtr->
    Activate();
    theUARTAccessManagerPtr = theUARTAccessManagerMakerPtr->
    GetAccessManager()
    ______________________________________

    ______________________________________
    #ifndef NO.sub.-- SPI
    class TInterfaceReference
     public:
      / /.....................................
      / / Standard methods
      virtual void GetTopInterface(InterfaceName&) const;
      virtual void SetTopInterface(const InterfaceName&);
      virtual void GetBundles(TDictionary<InterfaceName,
      TInterfaceBundle>&) const;
      virtual void SetBundles(const TDictionary<InterfaceName,
      TInterfaceBundle>&);
      virtual void GetPossibleTops(TCollection<InterfaceName>&) const;
      virtual TInterfaceMaker* Activate() = 0;
      / /.......................................
      / / Special Operators
      virtual TStream& operator>>=(TStream& toWhere) const;
      virtual TStream& operator>>=(TStream& fromWhere);
      virtual .about.TInterfaceReference();
     protected:
      / /.......................................
      / / Constructors
      TInterfaceReference();
      TInterfaceReference(const TInterfaceReference& copyFrom);
      TInterfaceReference& operator=(const TInterfaceReference&
      copyFrom);
     private:
    };
    #endif
    ______________________________________

    ______________________________________
    #ifndef NO.sub.-- SPI
    class TNetworkInterfaceReference : public TInterfaceReference
     public:
      / /...................................
      / / Constructors & Destructor
      TNetworkInterfaceReference();
      TNetworkInterfaceReference(const TServiceReference&);
      virtual .about.TNetworkInterfaceReference();
      TNetworkInterfaceReference(const TNetworkInterfaceReference&
      copyFrom);
      TNetworkInterfaceReference& operator=(const
      TNetworkInterfaceReference&
    copyFrom);
      / /...................................
      / / Standard methods
      virtual TServiceReference* CreateServiceReference() const;
      virtual void SetServiceReference(const TServiceReference&);
      / /...................................
      / / Overrides
      virtual TInterfaceMaker* Activate();
      virtual TStream& operator>>=(TStream& toWhere) const;
      virtual TStream& operator<<=(TStream& fromWhere);
     protected:
     private:
    };
    #endif
    ______________________________________

    ______________________________________
    #ifndef NO.sub.-- SPI
    class THardwareInterfaceReference : public TInterfaceReference
     public:
      / /...................................
      / / Constructors & Destructor
      THardwareInterfaceReference();
      THardwareInterfaceReference(const THardwareInterfaceHandle&);
      THardwareInterfaceReference(const THardwareInterfaceIdentifier&);
      virtual .about.THardwareInterfaceReference();
      THardwareInterfaceReference(const THardwareInterfaceReference&
      copyFrom);
      THardwareInterfaceReference& operator=(const
      THardwareInterfaceReference&
    copyFrom);
      / /...................................
      / / Standard methods
      virtual void SetTopInterface(const InterfaceName&,
      Boolean useConnectorName);
      virtual THardwareInterfaceHandle GetConnector() const;
      virtual void SetConnector(const THardwareInterfaceHandle&);
      / /...................................
      / / Overrides
      virtual void SetTopInterface(const InterfaceName&);  // c++
      syntax requireme:
      virtual TInterfaceMaker* Activate();
      virtual TStream& operator>>=(TStream& toWhere) const;
      virtual TStream& operator<<=(TStream& fromWhere);
     protected:
     private:
    };
    #endif
    ______________________________________

    ______________________________________
    #ifndef NO.sub.-- SPI
    class TInterfaceMaker
     public:
      / /...................................
      / / Destructor
      virtual .about.TInterfaceMaker();
      protected:
      / /...................................
      / / Constructors
      TInterfaceMaker();
      TInterfaceMaker(const TInterfaceMaker& copyFrom);
      TInterfaceMaker& operator=(const TInterfaceMaker& copyFrom);
     private:
    };
    #endif
    ______________________________________

    ______________________________________
    #ifndef  NO.sub.-- SPI
    class TUpperInterfaceMaker : public TInterfaceMaker
     public:
      / /...................................
      / / Standard methods
      virtual void Activate(const TInterfaceMaker& below, const
      TInterfaceBundle&) = 0;
      / /...................................
      / / Destructor
      virtual .about.TUpperInterfaceMaker();
     protected:
      / /...................................
      / / Constructors
      TUpperInterfaceMaker();
      TUpperInterfaceMaker(const TUpperInterfaceMaker& copyFrom);
      TUpperInterfaceMaker& operator=(const TUpperInterfaceMaker&
      copyFrom);
     private:
    };
    #endif
    ______________________________________

    ______________________________________
    #ifndef NO.sub.-- SPI
    class TAccessManagerMaker : public TInterfaceMaker
    {;
     public:
      / /....................................
      / / Standard methods
      virtual void Activate(const THardwareInterfaceIdentifier& theMetal,
       const TInterfaceBundle&) =0;
      / /...................................
      / / Destructor
      virtual .about.TAccessManagerMaker();
     protected:
      / /...................................
      / / Constructors
      TAccessManagerMaker();
      TAccessManagerMaker(const TAccessManagerMaker& copyFrom);
      TAccessManagerMaker& operator=(const TAccessManagerMaker&
      copyFrom);
     private:
    };
    #endif
    ______________________________________

    ______________________________________
    #ifndef NO.sub.-- SPI
    class TInterfaceBundle
     public:
      / /....................................
      / / Destructor
      virtual .about.TInterfaceBundle();
      / /....................................
      / / Special Operators
      virtual TStream& operator>>=(TStream& toWhere) const;
      virtual TStream& operator<<=(TStream& fromwhere);
     protected:
      / /....................................
      / / Constructors
      TInterfaceBundle();
      TInterfaceBundle(const TInterfaceBundle& copyFrom);
      TInterfaceBundle& operator=(const TInterfaceBundle& copyFrom);
     private:
    };
    #endif
    ______________________________________

• Inventors
  Andert, Glenn P.; Norman, George William;
• Assignee
  Object Technology Licensing Corp. (Cupertino, CA)
• Published
  Jan-26-1999
• Current US Classes:
  709/203
  709/227
  709/230
  719/328
  719/330
• Application #
  633910
• International Classes
  G06F 013/14; G06F 013/42
• Field of Search
  395/200.33 395/831 395/155 395/682 395/684 395/200.69 395/650 395/200.57
• Examiner
  Lee; Thomas C.
• Agent
  Kudirka & Jobse, Ward; James A.
• US Patent References:
  4407016
  4530052
  4597044
  4821220
  4953080
  5041992
  5050090
  5060276
  5075847
  5075848
  5093914
  5119475
  5125091
  5129084
  5133075
  5151987
  5181162
  5212787
  5226117
  5257369
  5265239
  5287541
  5297283
  5297284
  5315703
  5317741
  5325533
  5327562
  5333319
  5339430
  5339438
  5341477
  5369770
  5421016
  5423023
  5428792
  5432925
  5437027
  5515508
  5548726