CA2169639A1 - Service creation in an object oriented system - Google Patents

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.

Description

~16~3~
AMEN~E~

SERVICE C~EATION IN ~N OBJEC~ Ql~IENl~D SYSTEM
,, COPYRIGH~ NO 1 l~LC~llON
- Portions of thLC patOElt application conta~n mA~r~~lc ~hat are subiec~ to copyrigrLt protec~on. ~he copyr~ght owner h~s no obiec~.on to ~e facs~nile reproduction ~y anyone of ~e patent docu:ment or ~e paeent disclasure, ~s it appea~s in th~ EPO
rec~rds, but o~erwi~e les~lv~ all copfflght right~ wha~oeyer.

Field o~2e ~nz7enhon ~is ~nvention gerLerally rel~tes tQ imp V~ ents in C~3LLL~)ULeL sys~Pms, and more particularly to a sy~tem and me~hod for ser~ice creaiion in an object oriented ope~a~ring 6y~tem.

~ aclcgrowld of the Invention Computer systems in general are ~rery ngid. App~ica~ion developers and users of ~e system m~st often k~ow in~imate details of hardware pro~cocol and configura~ions in order to pro~ide a system in which information fl~w6 smoo~hly. Detail~ of each particular type of po~t and IO de~ce mtlst be dealt wi~ on an indr~idual ~asis.
Application deYeloper~ and users must also be ke~t coL~ tly abreast of each change in '.he system ~n ordeI to provide co~Tesponc~ing ch~nges to ~e software and ha~dware s~ ~at the changes can be taken full a~ e of.

PROCEEDI~GS OF 'r~E ~NI:1 ~ER~Al'IONAL WORKSHOP ON OBJ~CT
O~NIA~ON ~ OPEl~A~G SYSTEMS, I:~ave et al., "Pro~aes, Appiica~on ~terfac~ and ~)~st~ibuted Sys~:em~s, pp. 21~-2 a, 24 September 1~2, discLoses proxy objects which are local representa~ives of remc,~e objec~s in a d~s~ibu~ed sys~cem.
Proxies are ~ ~f;l; 7~d to cons~uct a t~ t AF~plication PrO~L dllUYUng IrLterface ~API) for ~e Choices distribut~d operating syste~. hl earlier work, proxies were used ~n Choices to provide a protected, objec~-ori~ interface to system objects. The a~iti~ of RemoteProxies allows applications to access a~ resou~ces in a uni~orm w~y by simply in~-ok~ng methods on objec~, irrespec~ive of whe~er they are local, in ~e kernel, in a different user v ir~uai address space or ' ~C~ =\IL E~Ht~ 7 ~ 1.7 ~ J~s~ : .5 ~ 3 3 EO St~
remote. Plc,xies op~ni e access to remo~ and protec~ed obje~ to pro~ride suppor~~or cha~nging servcr interfaces. A new Remote Procedure C211 (RPC) facility ~ al~o discussed for invoking me~tods on remote obJects ~rough the proxy mechanism. TheAPI is made dynam;~lly reconfi~urable by using table lookup to perform all functi<~n~
normally provided by stubs in conventional RPC implementa~ons. Finally~ ~e API
permi~s new versions of a se~ice to be introduced wi~out r~quinng rec.ompila~on of application code.

The rate at w~Lich IO de~ices changet as well as ~e ra~ of change of intermediate elements whi~ are uæd to tLd~ft:r informa~on ~o and from an IO de~ice, is ex~emely fast. Each change requires a Leaming process of syste~ users so ~a~ t~Le sys~em may be kept ~ ing in an op~;Lum manne~.

A compu~:er sy~tem can be ~ought o~ a~ a large ~ P~t ;on of clien~ whic~ need servIces perfotsrLed. Clients cQuld be t~nnsi~red to be ~irtually any part of the system which may need so~e~ing. For example, ~e CPU could be co$~idered to be a client w~ich needs a service ~ OL~ y a pa~cular eleme~t in the system. Ihe p~rfr~ e of tl Le ser~ice may involve many steps, and ma~y elemen~s to provide ~e requestecl se~vice. A service could ~e ~n~ red to be any~ing which provides some~ir~g which is ~ y ano~e~ enti~ in the system. FOI example, a par~icular c~ip may pr~vide a WO 9S/17720 . PCT/US94/OS470 ~1~9~39 - i . ~

particular type of digital signal proc~.~sing as a service for another system el~m~nt A single elPm~nt 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 s developers and users in order to make the requests for services, and providingof services, a smoothe process. The protocol for requests and providing is oftenvery inflexible, and requires illL~I ./enlion in minute details to change the protocol. In many respects, requests for services and providing services could be con~i~lered to be set in stone.
lo There is thererore, a need to provide a flexible ~ysL~ for requesting and providing services. The ~ysl~lll needs to overcome the above difficulties conc~rning the level of detail involved, the problems associated with ~yslem 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 :jysl~:ln and method for ill~roving the interaction between clients and services.
It is another object of the present invention to provide a system and 20 method for illl~r~,vil.g the flexibility in adjusting to changes in a system of clients and service providers.
It is yet 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 reAli7e~ by an interface framework which creates services in response to a request. The system receives an int~rfAce re~erence, and from the refeLellce creates a previously nonexistent service. Theil t~rf~ce re~rence creates in int~rface maker, which performs the actual creation and activation of a requested service. Activation of the service can bethought of as a two step process in which a service stack ~P~rription is created, and from this rlP~rription a service stack is created.

~, wo gsll7no 2 1 6 9 6 3 ~ PCT/U~94/ns470 The int~rf~ce reLer~l-ce is an entity which encapsulates all information r ~c~s~ . y to create a service. The client has the intPrf~ce rereL~,~ce, and aclivaLes the rererence to create the service which is r~e~le-l The interfAce rerer~.ce first creates a service stack le~ rirtion by le~rming the service int~rf~ which - 5 make up the top and bottom of the service stack, and then searching to find a set of services between the top and bottom int~rf~c~ which will form the required service stack. The int~rface maker serves the purpose of "bllff~ring"
service provider classes from the service stack framework.
From the service stack ~iesrrirtion intPrf~ce m~k~rs correspontiing to the lo stack ~l~.cl~ription are created. This creation occurs from the bottom of thedescription up. The service stack ~l~srrirtion can be thought of as a list of reLerel.ces to intPrf~ce m~k.ors.

Brief Description Of 17te Drawings Figure 1 illustrates a typical hardware configuration of a com~uler in accordance with the subject inv~ntion;
Figure 2 is a diagram showing a client using an i~t~rf~ce reLel~.ce;
Figure 3 is a representation of a drag and drop operation;
Figure 4 shows service stacks associated with a printer and serial data transfer;
Figure 5 shows service stacks associated with a printer and parallel data transfer;
Figure 6 is a Booch diagram showing the relationships among the services for a printer;
Figure 7 is a block diagram illustrating the concept of a personality neutral layer in accordance with the present invention acting as an intPrf~ce between operating systems and hardware;
Figure 8 is an overview of the operation of an ir~t~rf~ce reLelence;
Figure 1 illustrates a typical hardware configuration of a computer in accordance with the subject inv~ntion;
Figure 2 is a diagram showing a client using an interface rerel~ce;
Figure 3 is a r~resel-Ldtion of a drag and drop operation;
Figure 4 shows service stacks associated with a ~li-llel and serial data transfer;

wo 95117720 Pcr/uss4/os470 , 3 9,, ,,, ,, " '~

Figure 5 shows service stacks associated with a ~rilllel and parallel data transfer;
Figure 6 is a Booch diagram showing the relation~hips among the services for a ~
Figure 7 is a block diagram illustrating the concept of a personality neutral layer in accordance with the ~res~l,t invenlion acting as an interface between operating systems and hardware;
Figure 8 is an overview of the operation of an interf~ce re~r~l~ce;
Figure 9 illustrates the Int~rf~re Reference classes;
Figure 10 is a block diagram showing possible service stack configurations;
Figure 11 illustrates the TntPrface Maker classes;
Figure 12 demonstrates the hierarchical restrictirn~ among service makers;
Figure 13 illustrates the freedom of the hierarchy of services;
Figure 14 illustrates the TInt~rfaceP~undle classes;
Figure 15 illustrates the hardware configuration for THardwareInterfaceReference;
Figure 16 illustrates a hypothetical "pool" of service maker entities (i.e.
these are the entities which would be found from a TServiceMakerLocator property search);
Figure 17 demonstrates stack creation by THardwareRefere~ce object;
Figure 18 shows various class relationships of some of the elements of FIG. 17;
Figure 19 illustrates the creation of the stack description for THardwar.ol~ntPrfac~eference activation;
Figure 20 illustrates the overall operation of stack creation for THardwar~Tnt.orfaceT~eference;
Figure 21, Figure 22, and Figure 23 collectively illustrate, by visual design language, service stack creation by THardwareInterfac~l~eference;
Figure 24 is an overview of the hardware configuration for stack ription creation for a mouse;

WO 95/17720 ~ 1 6 9 6 3 9 PCT/US94105470 Figure 25 shows the r~lc~ te-l stack "description" for THardwarPTnterf~cPl~eference object;
Figure 26 is an overview of the hardware configuration for stack ~lP~rription creation for a serial port via a switch box;
Figure 27 is an overview of the hardware configuration for SCSI stack description creation;
Figure 28 is an example of how THardwareIntPrf~cPl~eference can be used by the p~ ler framework for an ImageWriterII;
Figure 29 illustrates Maker Class diagrams;
0 Figure 30 illustrates Service Class diagrams;
Figure 31 shows the hieldr~lly of TPresentableViews;
Figure 32 shows the class hierarchy of services if a common class hierarchy was not avoided; and Figure 33 and Figure 34 together demonstrate the development of a maker.
Detailed DescripRon Of The Invention The detailed embo~limr-nt~ of the present invention are ~ rlnse~
herein. It should be lln~lPr~tood, however, that the rli~rlose~l embol1iTnPnts are merely exemplary of the invention, which may be embodied in various forms. Thererole, the details disclosed herein are not to be inlelpLeled as limiting, but merely as the basis for the claims and as a basis for teaching oneskilled in the art how to make and/or use the invention.
The history of object-oriPnte~l programming and the developments of frameworks is well-established in the literature. C++ and Srn~llt~lk have been well-documented and will not be detailed here. Simil~rly, characteristics of objects, such as encapsulation, polymorphism and inheritance have been discussed at length in the literature and patents. For an exc~llPnt Sul~/~y of object oriented ~y~lems, 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 ~y~lelll performing rll-limPnt~ry input and output, the present ~ysl~lll is used to provide system level support for particular features. It should be kept in mind, however, that innovative objects ~ loserl herein may also appear in layers above the ~y~ m level in order to provide object support at different levels of the processing hierarchy.

wo 9S/17720 PCr~Sg4/OS470 ~6~3~ --The illv~ lion is ~referdbly pr~ctice-l in the context of an operating :lll resident on a personal computer such as the IBM (E~) PS/2 ~ or Apple ~l~rintQsh ~ computer. A represe ~laLve hardware e Ivirol-l..ent is depicted in FIG. 1, which illtl~trates a typical hardware configuration of a co~ uler in accordance with the subject i"venlion having a central processing unit 10, such as a conv~ntiorl~l microprocessor, and a number of other units inlercullnected via a ~y~ lll bus 12. The COmpUIel' shown in Figure 1 in~ a Read Only Memory (ROM) 16, a Random Access Memory (RAM) 14, an I/O adapter 18 for connectin~ peripheral devices such as disk units 20 and other I/O peripherals r~res~.,led by 21 to the system bus 12, a user inPrf~ce adapter 22 for ~ onnecting a keyboard 24, a mouse 32, a speaker 28, a microphone 26, and/or other user interf~ e devices such as a touch screen device (not shown) to the bus 12, a ccmmllnir~tion adapter 34 for connecting the workstation to a data proressin~
network represented by 23. A display adapter 36 for connecting the bus to a display device 38. The workstation has resident thereon an operating ~ysl such as the Apple System/7 ~ operating system.
The following rli~cll~sion will ~ rihe the requirements, client needs and classes provided by a ~.ere.led embo~lim~nt of the present i.l~,Lion, which will herein be referred to as the "Interface Reference framework."
The ~terf~ce Reference framework is rlesign~rl to provide advances which impact a variety of ~egm~nt~ 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 Int~rface Reference framework is designed to address needs of developers who want to isolate them~elves from the details of how services are created. Developers who use the lnPrfare Reference framework can shield their clients from rll~iment~ry service creating techniques, such as mess~ge streams. All of these details are encapsulated by the Interfa~ e 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 Tin~rf~r~l~eference represents the abilityto create and use a service for a particular device, with an interface specified by wo 95117720 ~ 1 6 3 6 3 9 ~ vos470 .

the client. In c++, the client typically specifies the interfA~ e by just in~tAntiAtin~
a particular class. C'on~ r a client who requires a TImageWriter service.
There may be lots of concrete TImageWriter service classes available, such as TImageWriterOn Serial, TImageWriterOnParallel, TImageWriterOnMessag~ eal", TImageWriterOnSCSI. Each of these concrete classes supports the TlmageWriter intPrfAce Which one do you choose? The only way you can choose is to know something about where the device is ActllAlly connpcte~l. But you don't want to know that type of detail. So, we encapsulate this knowledge inside of the interfAce rererel,ce. It ~letPrmin~ foryou which of the concrete classes to instAntiAte all the way down to the 'Imetal.'' For example, con~ r an ImageWriter. It may be connected to any serial or parallel port on a CO11IYUL~:L, or even to the network. Each case requires creating a different set of services in order to cornmunicate with the ~ ler.
The Tnt~rfAce 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 highlevel scPnArio 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 in~ic~tP~ mess~ge sPntling which sets up a collaboration. A plain line with a "+" at one end means creation.
The client is given an intPrface re~l~llce 206 to an ImageWriter 204 connecte~l to a built-in serial port on the ~y~ . The client sets "ImageWriter"
204 as the top intPrfAce and activates the intPrfAce rererence 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 TntPrfAce 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 i~tPrfAce 300 can drop a ~ ter 302 onto a document 304. This "associates" the document 304 with the ~l..-ler service. The document 304 uses this ~lilltel 302 whenever the default document print comm~nd is issued. If the plillLel's 216~39 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 e~luil~ed to fix each docnm.ont affected by the modified connection.
A third benefit is that service associations with documents persist across 5 reboots of the system. When the ~ysl~- is rebooted, all of these assori~tinn.
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 inf~rf~ce to a client and expects to use exactly one service below it. The following ~ cll~sion and 0 diagrams illustrate service stacks. Each box represents a service.
The top box 400 in FIG. 4 represents a service that exports "y~ Ler" as its interf~ce to ~ nt~ It requires the service "serial" 402/404 below it in order tofulfill its '~ylinter~ int~rf~ce oblig~tions. The top box 500 in FIG. 5 l~resel-ls a different service than the top box 400 in EIG. 4. Its exported int~rf~ce is the same, but it demands a different interf~ce, parallel 502/504, below. As shown inFIG. 6, these two services 602, 604 are actually subclasses of a common abstraction 600. This structure allows the client of the top service ("p~ r" in this case) to be reused across a variety of lower level services. A key purpose of the m~ h~nisms ieS~ rihed with respect to the ~terface Framework of the present invention is to allow the alltQIn~tic creation of such stacks, to maximize reuse of higher-level clients.
Top Interface: The interf~ce that a client uses when ~cc~sing (or using) a service is called its top intPrf~ce. In the example above, "Serial" 404 is the top interface of the ~ri~l, UART> service. "Parallel" 504 is the top int~rf~ce of the <Parallel, VIA> service.
Bottom Tnterface: The interface that a service provider uses in order to fulfill its "top" interface responsibilities is called its bottom interf~ce. In the example above, "UART" 406 is the bottom interf~ce of the <Serial, UART>
service. "VIA" 506 is the bottom int~rf~ce of the <Parallel, VIA> service.
Access Manag;~r: An Access ~n~r is an IO service which can talk directly to a physical hardware component (e.g. an integrated circuit). It h~n~
a.l,illalion between multiple requests to access the hardware.

RequiremPnt~
~ollowing is the complete list of requirements for the Tnterf~ce Reference framework:

WO 95/17720 2 1 6 9 ~ 3 ~ PCI/US94/05470 g Sl~port for polymorphic creation of services: An extensible mechanism is required which can shield consumers of services from the details of how those sers~ices are created. The consumer must not need to know if the service is provided remotely or locally. FurthPrmore, the consumer of local services - 5 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 connecte-l (e.g. modem port or ~li.,ler port).
Allnw clients to specifv t~e service ;nterface they want to ll~e: All services export an intPrf~ e to their clients. The Interface Reference framework0 must provide a mechanism which enables clients to specify the intPrf~ce they want.
Ability to reestabli~h a service if a "connection" cha~es: When a connection to a local device changes, an appr~Liate new service must be created. lFor example, if a ~linL~l is ~ llLly connected to serial port 1 and a user moves the conn~ctiQn to parallel port 2, a new service, using parallel port2, must be created.
Support for persistent service associations: A service (e.g. an ImageWriter II icon) can be associated with a docllmPnt model. It is important that the TntPrf~ce Reference framework allow clients to yreselve the associations users make between services and documents.
Ability to r~lrulate a description of a service: A service description consists of all of the inform~tion ~ec~s~ry to create a particular service stack. A
service ~l~s~ription may be calculated at any time. As an optimi~tion, it may becached.
Support for lazy activation: A service stack may be created from a service description at any time. This allows clients of the IntPr~ce Reference to defer creating a service until the service is actually required. For example, a document model could have an intPrf~ce rere~ ce to a printer. The creation of the pri-,lel service stack could be deferred until the time the user requeststhe document to print.
Support for multiple stacks per IO 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 activati~n must take advantage of newly "inst~ d" software: Each time a service stack is activated (i.e. created), it must incorporate the latestversior~ of any service that is a member of the stack.

WO 95/17720 ~ 3 PCT/US94/OS470 .

Features Following are the features of the Interface Reference framework:
Prov;~es polymorphic creatil~n of local and remote services: The 5 Tnt~rf~ce Reference framework provides consumers with a simple mPlh~ni~m for creating and ~ining access to senices. Clients are insulated from the specific details required to create the service. Service consumers are only required to supply the "top" int~rf~ce.
(~~n be extended to support other tvpes of service stacks: The Tnt.orf~ce 0 Reference framework is extensible. For example, two types of services such as local and remote could be supported.
(~~n create a senice on the fly from a description: Senices are created alltom~ti~ ~lly by the TntPrf~ce Reference framework at the time a client requests the service. All of the inform~tion required to create the service is encapsulated by a Int~rf~ce Reference entity.
noes not require a Service class hierarchy: Services used by the Tnt~rf~ce 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).
Fnumerates ~11 possible services provi-led by an IO port: The set of services that are cul.~nLly supported by a particular port is available to clients on demand. For example, the services are used by the computer viewer ~or type negotiation whenever a device is connecte~1 by a user.

Client Dependencies Hardware Configuration Fr~mework/Computer Viewer: Must enable a l~ModelSurrogate to create a service which can access the physical hardwa~e. A
polymorphic intPrf~ce r2rerellce is required to enable the same model cl~ss and constructor to be used by the computer viewer and the network browser. For 30 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 ~re~lable to ~revel,t a user from changing a connection for a device 35 which is currently in use.

WO 9S/17720 2 1 6 9 ~ 3 9 PcrluS94/o547o .

(~o~ uler Viewer/Network Browser: Requires that the same TModelSurrogate class for a service to be used by both the computer viewer and - the network browser.
Mo~Pm. P,il~ler and MIDI Frameworks: Certain clients mustn't care if .- 5 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 cale~,o,y of client. Examples include TModem, ~,illlel TModelSurrogate and MIDI TModelSurrogate.

Service Depen.l~nries Identification of a Service Description: Services are required to identify the interf~ce they export to clients (i.e. their "top" int.orface) and the intPrf~ce they require below them (i.e. their "bottom" intPrf~ce), if they are expected to be used by the Tnterf~ce Reference framework. Cu,l~l-lly, this requirement only applies to the "helper" classes (to be described later) and not to the services themselves.
Hardware Confi~uration ~amework: Inforrn~tion about local ports must be ~ccessihle in order to support creation of service stacks for local devices.
This dependency implies that the computer database must be inih~ e~l with a valid root (i.e. motherboard) THardwareModuleHandle object. The THardwareIntPrf~cP~Iandle 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 NeutTal Services The framework could be considered to be part of the personality neutral layer 706. The personality neutral layer 706 provides services to OS
person~litiPs (e.g. Taligent OS 704, OS/2 700, AIX 702). Once ported to the personality neutral layer, these OS personalities P~Pnti~lly become hardware platform 708 independent.

Architecture While the following discussion provides numerous examples on particular PlPnlPnt~ of the processing hierarchy, it should be kept in mind thatthese are for purposes of illustration only. The concepts embodied herein WO 95/17720 ~2; 1 6 !~ ~ 3 9 PCI~/US94/OS470 regarding the dynamic creation of service stacks through rereLel,ces by clients can be applied to any Plpment~ in the processing hierarchy. The only relationship that is r PcP~SAry is the need for a service by a client.

Survey .
Class Di~ m The TntPrf~ e Reference framework consists of three sets of I 1A~SP~
(1) IrltPrfAce Reference classes (EIG. 9), (2) Ir terf~ce Maker classes (FIG. 11); and (3) TIntPrf~ceT~undle classes (FIG. 14).

Overview Di~ m FIG. 8 provides an overview of the relationships between all of the classes in the Interf~ce Reference framework.
A client is given an int~rfAce Lerer~:.lce object 802. The client sets the top intPrf~ce attribute 800. The client calls Activate 804. The intPrface rerel~nce object creates an interface maker 806, passing it the bundle collection 810. TheintPrface 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 interfacerereLt:nce framework from the details of setting up the service.

Interface Reference Co~ vl,ents IntPrf~ce Reference Classes (FIG. 9):
- Developed by Taligent. May be sub~ la~se~l for special needs.
- Used by service consumers to create a service.

TTntPrfAcPl~eference 900 The primary purpose of TIntPrfacPReference 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 TInterfacPT~eference 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. Prom one session to the next, the same TInterfa- Pl~eference WO 9S/17720 i~ 1 6 ~ ~ 3 9 PCT/U 91~'~S470 .

may create a different service stack depending upon whether the co~nechon has changed or whether new software has been installed.
- TInterfAc~T~eference 900 has the following attributes 902:
TopInterface: TntPrfac~Name -- This value specifies the type of service .- 5 intprface the client requires.
Blm~ TDictionary~TnterfacPl~ame,TTnterfac~Rundle> -- Each key in the dictionary is an Tnt~rfaceName object and is associated with one instance ofa subclass of TTnterfaceBundle. The TInt~rf~c~Rundlè object encapsulates data specific to the type of irlt.orface it represents. For example, a serial int.orface o 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 uluve,sal ImageWriter model, which will work for local and remote devices, is supported. The ImageWriter model knows only that it has a TTntPrf~c~T~eference; 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 inPrface of "I'~ ,DeviceChannel".
The ImageWriter model code, to obtain the printer service, might look like this:

TPrinterDeviceChannelMaker* theDeviceChannelMakerPtr;
TPrinterDeviceChannel* theDeviceChannelPtr;
TInterfaceReference~ theReferencePtr;
theReferencePtr = this->GelI~ , r~c~Reference();
theReferencePtr->SetTopInterface(kPrinterDeviceChannel);
theDeviceChannelMakerPtr =
(TPrinterDeviceChannelMaker*)theReferencePtr->Activate();
theDeviceChannelPtr = theDevice~~hannell~/IakerPtr->GetDeviceChannel();
TNetworkIntPrf~ceT~eference 908 The purpose of TNetworkTntPrfaceReference 908 is to shield clients- from the details of how a service for a remote device is created. An active TNetworkTnt~orfaceReference object represents access to a remote service.
TNetworkTntPrfac~Reference 908 has the following attributes 910:
Service Reference: TServiceReference 910 -- This value specifies the network service re~eL~l-ce to use when the TNetworlcTnterfacel~eference object , . .' f ~

is activated. When a TNetworkTnterfaceReference 908 object is activated, it uses~he "top" intPrface and the TServiceReference attribute 910 to create the service stack.
The bottom service of this service stack is a TRequest~Pncl~.~,L~ealll 5 object. FIG. 10 illustrates possible variation~ of the service stacks. If the top -intPrface is "TRequestSenderSkeam", then the stack consists of just this single service, as shown by 1000. If the "top" intPrface is "~ ler", then the set of services, with "~ lle-" on top and "TRequestSenderStream" on bottom, is created. This is flPmon~trated by FIG. 10, at items 1002 and 1004. If the "top"
o intPrface is "modem", then the set of services, with "modem" on top and "TRequest!~Pn~lPrStream" on bottom, is created. This is rlpmc)n~trated by FIG.
10, at items 1006 and 1008.

THardwarPTnterfac~Reference 904 l~e purpose of THardwareIntPrfacPReference 904 is to shield clients from the details of how a service for a local device is created. An active THardwarPTnterfaceReference object 904 represents access to a service provided by a real local device.
THardwareInterfacPReference has the following attributes 906:
Connector: THardwareInterfaceHandle -- THardwarPTntPrfacPHandle represents a connector on the device actually performing the service the intPrface reference represents. THardwareIntPrfacPReference 906 can detPrmine the absolute "bottom" interface required to construct the service stack by following this connector's hardware connection.
UseConnectorName: Boolean -- If TRUE, then when the interface lefer~llce object is activated, it will ignore the given "top" intPrface name and instead, use the InterfaceName in the connector as the "top" interface name.
This is useful for clients who know what abstract protocol they must use, but don't want to specify a concrete protocol. For example, a client may use a pointing device protocol, but may not want to get involved with the ~1e~ i~ion of whether to use "LogiTechPointingDevice" protocol or "AppleADBMouse"
protocol. This 1P~ n is made automatically by the THardwareIntPrfac~Reference object 904 if the UseConnectorName value is set to TRUE.
As shown and discussed above with respect to FIGS. 4 and 5, when a THardwareIntPrhcPl~eference object is activated, it uses the "top" intPrface and wo95/l7720 ~1~69~6~9 rcTluss4los47u the "bottom" i~terfAce, letPrmin-p~ from the THardwarPTnt~rf~cPT~andle attribute, to create the service stack.
-TInterfaceMaker TntPrf~ce Maker ~ qs-ps (FIG. 11):
- Developed by access mana~er writers, service class providers or anybody.
- Used internally by the TntPrface Reference classes to create a service.
The purpose of TTntPrfacPMaker 1100 is to insulate all of the service provider classes from the service stack framework and to provide a limit~rl 0 amount of type-safety (e.g. no void~). Each maker object represents the ability to create and initialize a particular service. The intPrface re~erence frameworkdeals directly with interface maker objects, NOT services. For example, to create a service, an illtPrf~ce re~r~llce calls the Activate method (1104, 1108, 1112) on the maker object (1102, 1106, 1110), which creates and iIliha~ P~q the service.
The intPrface le~r~l,ce object never directly touches the service. Never.
The reason for this extra level of indirection is so we don't require every service in the system to derive from a single class defined by the IntPrf~ce Reference framework. For example, a TSerialACIA6850 access manager class is not required to derive from any class in the Tnterface Reference framework.
Service makPrs have very little overhead and are simple to develop.
Service m~kPrs belong to a hierarchy dictated by the int~rf~ce reLel~l.ce framework. FIGS. 12 and 13 contrast the hierarchy restrictions of service makersto the hierarchy freedoms of services. Notice that makPrs have TInterfaceMaker 1200 as a parent. Services on the other hand are free to belong to whatever hierarchy their authors desire.
An active subclass of a TTntPrfaceMIaker object 1200 may be down-cast into the a~o~liate sub-type to safely obtain a pointer to the real service object. Itprovides no protocol. In the example of FIG. 12, a client would down-cast his TTnterfaceMaker 1200 pointer to TUARTAccessManagerMaker 1206 and then safely call GetAccessManager 1208, which returns a pointer to a TUARTAccessManager 1300. The following more cor-liqely rlPfinP~q the relationships between TUARTAcessManagerMaker 1206 and TUARTAcessManager 1300:

TUARTAccessManagerMaker~ theUARTAccessManagerMakerPtr;
TUARTAccessManager~ theUARTAccessManagerPtr;

W O 9S/17720 2 1 6 ~ 6 3 9 PCTrUS94ioS470 -1~
theUARTAccessManagerMakerPtr =
(TUARTAccessManagerMaker*)~nTnterf~ce~eferencePtr->Activate();
theUARTAccessManagerPtr = theUARTAccessManagerMakerPtr->GetAccess~an~er();
-.
TAccessManagerMaker 1202 A TAccess~nAgPrl\/Iaker object 1202 creates and acliv~les an access m~na~Pr. The access mAna~Pr arbitrates access to the device i~1~ntifiP-l by the THardwarPTnterf~cPTtlPntifi~r object passed in to the Activate method. The 0 access mAnagPr is not required to derive from an TntPrfAce Reference base class.
This subclass of TTnterf~cPl\~aker 1200is used to create the bottom service of aservice stack. TAccessManagerMaker objects 1202 are created by TTntPrf~c~Reference objects when the TInterfaceReference object is activated.
The TInterfaceReference passes in the THardwareInterfacPT~PntifiPr object 5 which represents the "metal" the Access Manager controls.

TUpperIntPrfac~ aker A TUppe~ le. ~cPl\~aker object allows TInterfAcPl\~aker to create and activate a specific service object on top of some other service. This subclass of 20 TInterf~cPReference is used to create and activate a specific service object on top of some other service. This subclass of TTnPrfAcPl~aker. is used to create non-bottom services of a service stack. The service is not required to derive from an I~tPrf~ce Reference base class. TUppe-T..l~. r,lcPl\Iaker objects are created byTIr tPrfAcPReference objects when the TIr tPrf~rPReference object is activated.
TInterfaceBundle 1400 TntPrf~ce Bundle Class (FIG. 14):
- Developed by access manager writers or service class providers .
- Used directly by services to provide configuration informAtion.
An instance of a TInterfaceBundle 1400 represents encapsulated informAtion specific to a particular service. A bundle can be passed into service m~kPrs polymorphically at activation time. TInterfaceBundle 1400 is subrlA~se~
to encapsulate the inform~*on specific to a particular type of service.
An instance of a TTnterfAceRundle 1400 can be streamed to a file.
Key Scen~nos WO 9S/17720 2 ~ ~ 9 ~ 3 3 PCI/US94/OS470 .

Activate a THa~ airTnt~rf. -eReference - Overview #1 This scPnario is prP~Pnte-l twice; once using Booch notation and once - using VDL (Visual Design Language) notation. This was done because nPit~er notation does an excellent job of collv~yillg the process of service stack .- 5 activation.
ScenArio: A client has a TTntPrf~cPT~eference pointer to an object whose actual subclass is THardwarPTntPrf~cPT~eference and whose top intPrf~ce is set to "P~ leL". The client calls its Activate() method. Activation occurs in two stages: (I) Creation of a stack ~lP~rirtion and (II) creation of the service stack.
10FIG. 15 illustrates the hardware configuration for this scPn~rio. Handles 1500 and 1510 are objects used to rerel~el,ce the hardware components. The THardwareInterfaceReference object 1508, the y~ ler~s connector 1514 (an attribute of the THardware~tPrf~cPT~eference object), the connector's identifierobject 1516, the connection object 1512, the connector the y~ er is connpcte~l to 1502, the connector's identifier object 1504 and the "metal" 1506.

(I) Creation of the stack ~ cri~tion:
(1) The first step the THardwareReference object must perform in order to create the stack ~lP~crirtion is to get the "bottom" interhce. The bottom 20 intPrface, in this scenario, is found as follows. First, access the THardwareIntPrf~cPl~eference object's conn~ctQr attribute 1514. Next, retrieve the THardwarPTntPrf~cPT~Pntifier object 1516 from it and test it. The i~iPnhfiPrcan not be activated, so we continue. Next, the THardwarPTntPrf~ceReference object retrieves the connection object 1512 from the printer's connector. The 25 other end 1502 is retrieved from the connection. The THardware~tPrf~cPT~lPntifiPr object 1504 is retrieved from it and tested. This iclPnhfiPr object is activatable, so we can stop. It specifies the bottom interf~ce "6850".
(2) At this stage, we know the very Top ("rlll.Ler") and the very Bottom 30 ("6850") interf~ce of our service stack. The next step involves searching through the file ~y~lell~ (and potPnti~lly NuBus ROM) looking for the set of services which can be joined to form the required service stack (this can be conveniently implemented by subclassing TLocator or TFSLocator).
FIG. 16 illustrates a hypothetical "pool" 1600 of service maker entities (i.e.
35 these are the PnhhiPs which would be found from a TServiceMakerLocator property search). Each entity in the pool represents one TServiceMaker entity which is "installed" on the system. Each entity is i~1PntifiPrl by its top and WO 9~17720 `,, PC'r~S94/OS470 2~9~39 -18-bottom intPrf~re. The dashed lines 1602 indicate the path we would find for our THardwarPTntPrf~cPReference object.
(3) The r~lc~ te-l stack "description" for our THardwarPTnfPrf~c~T~eference object is rlPfine-l by the entities connected by the dotted line in FIG. 16.

(II) Creafion of the stack:
(1) The THardwareReference object creates the stack in the following order, as shown in FIG. 17: (a) Create the bottom most TTnterfacPMaker object 0 in the stack ~ip~-rirtion. The created object 1700 is an instance of the class 1800 shown in FIG. 18. It is activated by passing in the TTntPrfaceklentifier retrieved from the THardwarPTnterf~ce object representing this ACIA port.
FIG. 18 illustrates numerous classes, but only particular classes related to FIG.
17 will be discussed. Many of the relationships shown in FIG. 18 have been discussed previously.
(b) The TIntPrf~rPMaker object creates its corres~onding service (an access m~n~ger) and calls h(), passing in the same TIntPrf~cPT-lPntifier. This new service is labeled 1702 in and is an instance of class 1802 in FIG. 18.
(c) The THardwareReference object continues by getting the next TIrtPrf~cPl\~aker object from the stack description (this is a TUppPrTnterfacPl\/Iaker). It AcLivaLes the TUpperTntPrf~cPMaker, passing in the TAccessManagerMaker object 1700. Next comes the tricky part. Knowing full well that the TAccessManagerMaker object passed into it is an ACIA Maker (that's what we promise and it works if the properties don't lie), it down castsit to the proper type of maker and asks it for the service 1702. The result of this operation is access to the ACLA Access Man~gPr.
(d) Next, the TUpperTntPrfAcPl\/Iaker object creates its colles~onding service (which can be derived from anything), and calls g(), passing it the ACIAAccess ~n~gPr.
(e) The THardwareReference object continues by getting the next TTntPrf~cPl~aker object from the stack ~ipsrrirtion (another TUpper~terfaceMaker). It Activates it, passing in the TAccessManagerMaker object 1704, of class 1804. The down cast magic happens again and asks the TUpperTnterf~cPl~aker object passed in for the service 1706, of class 1806. The result is the Serial-ACIA service.
(f) Finally, the TUppe~ le~ceMaker object creates its corresponding service 1710, of class 1810 calls f(), passing it the Serial-ACIA service.

wo g~/1772~ 2 ~ 6 9 ~ 3 9 ~ 5 s/05470 .. .

Now the service stack is complete. The THardwareReference object retu~s as the result of activate, the top most TTnterf~c~l~aker 1708, of class - 1808. Clients may then do the down cast thing to the result and gain access to the top-most service in the stack.
.- 5 Activate a THanlw~Tnt~rf~Reference - Overview #2 Scenario: A client has a TTnt~rf~c~Reference pointer to an object whose actual subclass is THardware~terf~ceReference. The client calls its Activate() method which ~ ec~ in two stages: (I) creation of the stack ~ f rirtion and (II) creation of the stack.

(I) Creation of the staclk ~escription (FIG. 19):
The creation of the stack description for a THardwareInt~rfAc~T~eference object 1908 for a Top Int~rf~ce 1906 involves the following steps: First, we getthe "bottom" interface from the hardware configuration framework 1900. Next, we locate the set of services 1902 which satisfy the required intPrf?c~. Finally, we calculate the stack description 1904. Thisis accomplished by matching the top int.orface of one service with the bottom int~rfAce of another service, until we find the set of services which can be etA~ke-l one on top of the other to form a stack with the pr~el top and bottom interf~ . There is an assumption that there will only be one service stack description cAlclllAterl from this process. If more than one stack ~ rrirtion is found, then perhaps an exception could be generated.
Note: The service stack itself is not actually created in this process, just a ~ riptionL of the stack. The stack description consists of an ordered list of rerelel,ces to interfAce mAk~r~. Each int~rfAce maker knows how to make its correspondLing service and is called on to do so in the next stage of our sc~n~rio.

(II) Creation of the stack:
The creation of the service stack is shown twice. This first section presents a brief overview. The second section presents a more detailed version.
Overview FIG. 20 illustrates the overall operation of stack creation for THardwareInterfaceReference. The creation of the service stack involves iterating across the stack les~ ription 2008. For each interface maker "rerer~ce"
2010 in the stack rles~ ription, we do the following. First, create an int.orfAce maker object 2000. Next, activate the intPrfAce maker object, passing in the 63~ .

.

a~ropl;ate arg~lmPnt~ (if it's an Access Manager Maker, pass in a THardwarPTntPrf?lcPT(1pntifipr 2002; if it's an Upper IntPrface Maker, pass in apointer to the TTnt~PrfacPl\~aker object below it). If available, the colre~on~in~
TTntPrfaceRundle object 2004 is given to the intPrface maker object 2000. Pinally, the intPrf~ce maker object 2000 creates its colles~o~cling service object2006. The int~rfAce maker object 2000 ir~itiali7P~ the service object 2006. It is intimately aware of what inform~tion is required (e.g. THardwareInterfaceklPntifif~r, pointer to the TTnterfac~ aker object below it, TTntPrf~cPT3undle object, etc.).
0 Details This section presents a riet~iler~ VDL s- Pnario of how a service stack is created.
As shown in FIG. 21, the THardwarPTntPrfac~T~eference object 2104 creates the stack in the following order:
(1) Create the bottom-most TTnterfacPMaker object 2112 in the stack description 2102 (the created object is an instance of the class shown in FIG. 20 with a 2000 beside it). The stack lPs~rirtion is based on the collectiQn of services represented by 2100. The TInterfaceMaker object 2112 is activated by passing in the THardwarPTntPrfacPklPntifipr 2106 retrieved from the lHardwarPTnt~rfacPT~andle object repre~Pnting the ACIA port. Flpments 2108 and 2110 provide represPnt~tiQnS of ACIA and 6850, respectively.
(2) The TInterfaceMaker object 2112 creates its corresponding service (an access manager 2114) and calls its initiali7ing function, h(), passing in the same THardwareIntPrfAcPk1Prl*fier 2106. This new service is labeled 2114 in FIG. 21 and is an instance of class 2002 in FIG. 20.
(3) As shown in FIG. 22, the TEIardwareIntPrfacPl~eference object col,lil.ues by creating the next llnterfaceMaker object2200 from the stack ~Ps~rirtion (this is a TUppPrTnterfacel\/Iaker). It Activates the TUppPrTnterfacPMaker, passing in the TAccessManagerMaker object it created in step 1. Next comes the tricky part. Knowing full well that the TAccessManagerMaker object 2202 passed into it is an ACIA Maker 2200, it down-casts it to the proper type of maker and asks it for the service 2206 created in step 2. The result of this operation is access to the ACIA Access ManagPr.
Many of the elements of FIG. 22 are identical in nature to correspon~ling elements of FIG. 21, and need no further expl~nahon.

wo 95/17720 PCr/USg4/OS470 ~ 2 ~ 3 9

(4) Next, the TUppe~T~-Ie. race~aker object cleales its cc,llespon~lin~
service 2204 (which can be derived from allyLl~i.lg), and calls its inih~li7in~
flmction~ g(), passing it the ACIA Access Manager.

(5) As shown in FIG. 23, the THardwareInt~rfAcPReference object .- 5 continues by creating the next TTntPrfAcel\~aker object 2300 from the stack rription (another TUpperIntPrfAc~l\Iaker). It Aclivales it, pA~sin~ in the TAccessManagerMaker object 2302. The down-cast magic happens again (result is the Serial-ACIA service 2306).

(6) Finally, the TUpperI~ cPl\~Iaker object creates its corles~onding service 2304, calls its inihAli7ing function, f(), passing it the Serial-ACIA service.
Now the service stack is complete. There are no more entries in the stack ~P~ ription. The THardwareI~t~orfarpReference object returns the top-most TTnt.orfAcPl~Iaker created in step 5. Clients then down-cast it and gain access to the top-most service in the stack.
Create Stack Description - Serial Port (Mouse) Scenario: The ~terfA( e Reference framework works when the client isn't real sure about which "top" intPrfAce to use. This scenario is slightly different from the previous sc~nArios because this time the UseConnectorName Class attribute is set to TRUE. This causes the interface re~lel~ce to use the connector's interfAce name as the top interfAce. This is very much like the operations associated with FIG. 15.
A client has a TInt~rf~c~T~eference pointer to an object whose actual subclass is THardwareInterfaceReference and whose top i~tPrf~ce is "PointingDevice". The client calls its Activate() method.
FIG. 24 is an overview of the hardware configuration for this scenario:
the THardware~t~rfAcPReference object 2408, the mouse's connector 2412, the mouse's HardwareInterfaceIdentifier object 2414, the connection object 2410, theport the mouse is connected to 2402, the port's HardwareTnt~rfAc~T~lPntifier object 2404 and the "metal" 2406.
(1) The first step the THardwar~Tnt~rfAc~T~eference object must perform, in order to create the stack description, is to get the "bottom" int~rfAce. This is exactly the same as the previous scenario.
(2) The second step is to get the TntorfAcP~ame~ which is used to specify the "top" interfAce, from the interfAce i~ntifier object 2414. This is ~rcomplished by Accf~sing the connector object 2412 and retrieving the ntifier object, then calling GelL,IP~rac~ame.

WO 9!i/17720 " PCI/US94/05470 2~69~3~ -22-(3) At this point, we know the top interface "LogiTechMouse" and the bottom intPrf~ce of our service stack ("6850"). The next step involves sear~:l,ing through the file system looking for the set of services which can be joined to form the required service stack.
The top rl~c~ rirtion is tested to ensure that it is a subclass of the class specified by the TopIntPrf~ce name attribute of the interfA- e re~eLence.
(4) l~IG. 25 shows the r~lc~ te~l stack '~ ccrirtion~ 2500 for THardwarPTnterfacP~eference object.

lo Create Stack Description - Serial Port via Switch Box Scenario: The Interf~ce Reference framework works with switch boxes.
This scenario demonstrates only the first stage (i.e. creation of the stack rle~C- rirtion) for a ~rilll~ connecte~l to the serial port through a switch box.
A client has a TIntPrf~cPT~eference pointer to an object whose actual subclass is THardwareInterfaceReference and whose top intPrf~ce is set to "Plil.l~.". The client calls its Activate() method.
FIG. 26 is an overview of the ha~dware configuration for this scPn~ric:
the THardwarPTntPrf~cPReference object 2600, the p~ Ler's connector 2602 (an attribute of the THardwarPTntPrfacPReference object), the printer's HardwarPTntPrf~cPTc~entifier object 2604 a connectic-n object 2606, a connector on the switch box 2608,a switch box connector's HardwareInterfacPklPntifi~r object 2610, the switch box's default connector 2612, a connection object 2614, and theport the switch box is connected to 2616.
(1) The first step the THardwareInterfaceReference object must perform, in order to create the stack ~es- ription, is to get the "bottom" interf~ce. It does this by navig~ting across THardwarPTntPrf~cPHandle objects until it finds a THardwareIIlterf~cPT~l~ntifiPr object which can be activated.
Although FIG. 26 looks complic~te.l, it really isn't. The process is a simple repet*ion of the earlier scenario involving a straight serial port.
The bottom int~rfAce is found as follows. First, access the TEIardwareInterf~cPReference object's connector attribute 2602. Next, retrieve the HardwareInt~rf~ceklPntifiPr object 2604 and test it. It can not be activated, so we continue. Next, we retrieve the connection object 2606 from the pli-,Le~'s connector. The switch box HardwareIntPrf~ce object 2608 is retrieved from the connection object. The HardwareIntPrf~cPT-lPntifier object retrieved can not be activated.

WO 9S/17720 ~ 1 6 9 ~ 3 ~ PCT/US94/05470 We have now completed one full pass through a THardware~'onnecti~ nHandle object, but did not find an intPrfAce i~ nhifiPr - which could be activated.
What we must do now is create a service which can represent the device - 5 we got stuck on, element 2608. If a service can not be created for this device, then we fail. The device can be an al1tomAhc or a mAnllAl switch box. An alltonlAhic switch box requires a service which can control the switch box. A
mAnllAl switch box requires a service also, only to be consistent.
To create this service, we create a THardwareIr tPrfAcPl~eference on the switch box's default THardwareInterfAcPHandle object 2612. We set the top intPrfAce l:o MMultiplexer (or something ~ro~liate we can define later).
Next, we Activate it. This results in the conhinllAhon of the search for a "bottom" inPrfAce. It follows the connection object 2614 and ends up at the THardwareInterfAce~Iandle object 2616, which IS activatable. A valid bottom has been found.
The intPrfAce Le~l~lce we created continues by creating a service stack for the switch box (note: this is not the service stack the client is intelesled in, we just got temporarily side tracked because of the switch box). At this point, we have a service which is an MMultiplexer. Developers of alltomAtic switch boxes will have to supply this service thPm~q~lves. For mAntlAl switch boxes, we can provide our own standard service which works for all mAnllAl switch boxes. We call Switch() on MMultiplexer, passing in the cor nector to switch to (i.e. 2608). The Switch method has the responsibility of setting the multiplexerto our connector (only if it's automatic). If it's a m~ml~l switch box, the userhas the responsibility to push the proper button. If it is a m~nllAl switch box, a user alert could be optionally generated to remind the user to push the button on the manual switch box. This alert is only required when the serial port is ~s;l-g a different device from the previous activation (i.e., if we are aclivalillg for the modem a second time in a row, then the user doesn't need to do ally ll.illg).
At this point, we can A~sllme that the switch box has been switched to the a~ro~l;ate position We get the "bottom" intPrhce from the MMultiplexer and delete the MMultiplexer service stack. We no longer need it. We only used it to get the bottom interfAce and to perform the switch. We now have the proper bottom interface from which to construct the client's service stack.

s :~
WO 95tl7720 . . ~ PCT/US94/0~470 i 3 ~

Create Stack Des~;~1ion - SCSI Device Scenario: The TnterfAce Reference framework works for auto-configurable devices too. This scenario lpmo~trates the first stage (i.e. creation of the stack ~les. ri~tion) for a ~ el connPcte-l to the SCSI port. In this example, the client 5 wants to talk to the SCSI device, not the port. A different scPnario is possible, which would create a service stack for the port. The computer viewer does this when the user asks it to refresh the SCSI port.
A client has a TInterfaceReference pointer to an object whose actual subclass is THardwarPTntPrfaceT~eference and whose top intPrfare is set to o "P~ er". The client calls its Activate() method.
FIG. 27 is an overview of the hardware configuration for this scenario:
the THardwareInterfacel~eference object 2700, the printer's connector 2702 (an attribute of the THardwarPTnt~rfacPl~eference object), and the printer's HardwareIntPrfacPT~lPntifiPr object 2704.
(1) The first step the THardwarPTntPrfacPReference object must perform, in order to create the stack description, is to get the "bottom" interface. It does this by navigating across THardwarPTntPrfacPTIandle objects until it finds a THardwareTntPrfacPklPntifier object which can be activated.
The bottom interface is found by ~ccPs~ing the 20 THardwarPTnt~rfacel~eference object's connector attribute 2702. Then the THardwareIntPrfac~T~lPntifier object 2704 is retrieved from it. Next, the HardwareIntPrfAcPTclPntifier object is tested. Since it can be activated, we aredone. The ID specifies "SCSI" as the Bottom Interface.
(2) At this point, we know the very Top and the very Bottom interface of 25 our service stack. The next step involves searching through the file system looking for the set of services which can be joined to form the required servicestack. Note: The SCSI intPrface identifier is passed into the bottom service. The SCSI identifier contains a SCSI device hAn~llP which the bottom service can get and use to talk to the SCSI ~ tel.
Activate a TNel~o~kTn~prf~cel~ference Scenario: For a TNetworkInterfaceReference object whose "Top Interface" is set to "Printer", a client calls its Activate() method. Activationoccurs in two stages: (I) Creation of the stack description and (II) creation of the 35 stack.
(I) Creation of the stack ~l~C~rirtion wo 95/17720 -2~
(1) The first step the TNetworkReference object must perform in order to create the stack r~P~rri~tion is to set the "bottom" interface to "Message~tlea~- (2) At this point, we know the very Top and the very Bottom int.orfAce of our service stack. The rest of this stage plays out exactly like -- 5 THardwar~Tnt~rfAcel~eference.
aI) Creation of the stack:
The l~NetworkReference object creates the stack in the following order:
The TNetworkReference object creates the bottom most TInterfaceMaker object in the stack ~lp~rirtion (a TNetworkMaker object).
o The TNetworkReference object activates it, passing in the TServiceReference object.
The TTnt~rfAc~l~aker object creates its colle~onding service (can be derived from anything).
The TIntPrfAcel\/Iaker object calls its initiAli~ing function f(), passing in the same TServiceReference.

Nelwc,rk service stacks can be deeper than one level.

Inst~nti~te a THaldw~r~Tnt~rf~r~Reference Scenario: The co .mputer viewer has a THardwareModuleHandle object and has created its colre~onding model object. Now it is ready to create and add THardwar~TnPrfAcPReference objects to the model, one for each THardwar.oTnt~rf~ceHandle object owned by the THardwareModuleHandle object.
(1) First, it creates an ileLaLor for the THardwareInt.orfAce~Iandle objects (i.e. connectors) in the THardwareModuleHandle object.
(2) Next, for each THardwareInt.orfAc~Iandle object returned by the iterator, it creates and adds a THardwareInt~rf~c~l~eference object to the modelas follows:
theModel.AddInterfaceReference(THardwareInterfaceReference(aHardwa reInterface));

InsPnti~te a TNelw-J.kTnterf~~eR~ference Scenario: Network Browser issue.

Use a Manually Connected Device (configured via "Let Resources Find You") Scenario: A user prints a docllmPnt using a pri,.ler connecte-l to the local serial port. Ihis scenario illustrates an example of how THardwareIntPrfAc~Reference can be used by the printer framework for an ImageWriterII. FIG. 28 illustrates the scPnario.
(1) A user drags a document icon onto an ImageWriter icon. -.
(2) The ~linler icon accepts the docllm~nt icon. The document and the ,t~l collaborate resulting in the creation of a print job which is added to the TP~ r object 2802 representing the ImageWriter.
(3) The Pl~.leLIIandler object 2804 calls Activate on the 0 THardwar~TntPrf~cPT~eference object 2806 which was passed down from the TPl,l.lel- object 2802.
(4) The THardwareInterfaceReference object creates the appropriate service stack and returns a refeLc:l-ce to it.

Use a M~nll~lly Connected Device (configured via "You find the Resource") Sce~rio: Someone wants to query the computer hardware database for an ImageWriter and access it.
(1) Search the computer hardware database for the THardwareModuleHandle object which has "ApplPTm~geWriterII" as its signature.
(2) Get the proper THardwareIr terf~ce~Iandle object from the THardwareModuleHandle object.
(3) Create a THardwareInterfaceReference, passing in the THardware~tPrf~ce~Iandle object.
(4) Set the top interface of the THardwareIr-tPrfacPReference object.
(5) Activate the refer~,lce object and begin communication with the ImageWriter II.

Change a Conn~ction of a Manually Connecte~ Device Scenario: This scenario demonstrates that a document, whose default printer is a particular local ImageWriter, maintains its ability to print to that printer even after the user has changed the printer's connection. Please refer to the "Low-Level Hardware Configuration ERS" for this scenario.

3.3.12 Developer creates a new service WO 95/17720 2 1 6 9 ~ 3 ~ PCr/US94/0S470 Scenario: Show the classes necP~s~ry to introduce two new services into Pink, using the mechanism defined in this ERS. The new services are:
- UART service for a TxyzUART and a UART service for a TpdqUART.

.- 5 (1) FIG. 29 illustrates Maker Class diagrams.

(2) FIG. 30 illustrates Service Class diagrams. Note: ~ere is a one-to-one colle~c)n~lPnce between the maker classes and the service ~ la~sP~.

0 The shaded classes are written by the developer.

Class T~ r~r~s TTnt~rfa~ ference Class Description Purpose: Please refer to the above ~ cll~sion for the purpose of this class, what an instance of this class represents, what this class is used for and the meaning of its attributes.
Deriving ~ SP~: This class is polymorphic.
Concurrency: This class is not multi-thread safe.
Persisl~lce: An instance of a subclass of TInterfaceReference may be saved to a file and reslored at any time.
Interface:
#ifndef NO_SPI
class TTnterfaceReference {

public:
/ /
// Standard methods virtual void GetTopInterface(InterfaceName&) const;
- virtual void SetTopInterface(const InterfaceName&);
virtual void GetBundles(TDictionary<InterfaceName,TTntt?rfaceBundle>
&) const;
virtual void SetBundles(const TDictionary<InterfaceName,TIntPrface Bundle>&);
virtual void GetPossibleTops(TCollection<InterfaceName>&) const;
virtual TTntPrfac~ aker* Activate() = 0;

wo 95/17720 ~ ~ 6 ~ 6 3 g PCT/US94/OS470 / / Special Ot,t:ial. l~
virtual TSILeall~& operator>>=(TStream& toWhere) const;
virtual TStream& operator<<=(TStream& fromWhere);
virtual~TTnterf~c~Reference();
protected:
//. . .
// Constructors TTn t~rfa ce~eference();

TInterfaceReference(const TInterfaceReference& copyFrom);

llnterfaceReference& operator=(const TInterfaceReference& copyFrom);
private:
};
#endif Member F11nction~
void GetTopTnt~rfrce(Tnt~rfac~l~ame&) const Gets the top interface of this TntPrfacPReference. Clients will rarely call thismethod.
void SetTopTnt~rface(const Tnt~rfac~ame&) This method specifies the interface of the service that you want Activate to return. Clients must call this method sometime before they call Activate.
void GetB~n~l1es(TDictionary~Tnt~rfa~ ~e~TTnt~rf~ceBundle>&) Fills up the collection argument with all of the TTnterfaceRundle objects in this Tnt~rfacPReference. Does not empty the dictionary first. Clients will rarely call this method.
void SetBundles(const TDictionary~Tnt~rfr-Pl~a~me,TTnt~rfa~el~undle>&) Deletes the current Bundles attribute in this IntPrfaceReference, then copies (clones) the given TDictionary [13] object and makes it the new Bundles attribute. Subsequent activations of this Tnt~rf~c~Reference use the new Bundles attribute. Clients call this method if the services they activate require service specific data. See the activate methods of the maker subclasses for moredetails.
void GetpossibleTops(Tcollection~Tnt~rfa~el~ame>&) 21~9~3~

Fills up the collPctinn argument with all of the TntPrface~ame objects that thisTnt~rfaceReference can currently support, given the current "installed" services- on the ~y~l~ n. Each Tnt~rfacPl~ame object in the collection i~entih~ one type of supported service. Clients may call this method to det~rmine what services .- 5 are available for a given InterfaceReference. The computer viewer uses this method during type negotiation between connectors. For example, a user all~ g to connect an ImageWriter to a SCSI port will b`e ~revt:l~led from doing so if the ~terfAce~eference does not say serial is supported by the SCSI
port.
TTntPrhrPl\~alcer* AclivaLe() = O
This method creates a service stack whose top service has an int~rface specifiedby SetTopInterface(). The bottom resource is subclass dependent. It could be a hardware component, a network service or a software service. This method is called directly by clients. A pointer to a TInterfaceMaker object, of the specified type, is ret~lrne~. Clients down-cast this pointer to the ap~r~,iate type and get a pointer to the real service object. After this has been done, the client is required to delete the TInterfaceMaker object.
TStream& operator>>=(TStream& toWhere) const Streams out the entire intPrface re~~ ce object into the toWhere argument.
TStream& opæialor<~=(TStream& fromWhere) Streams in the entire intf~rf~ce referel,ce object from thç fromWhere argument.
~THar~lw~ç~PTnt~rf - -eReference() Destroys the int.orface reÇel~.ce object only. It does not affect the activated service(s), if any.
~5 THal~lwar.~Tnterfa~eReference() Subclasses may call to create an empty THardwar~Tnt.orfaceReference object.
THar~lwareTnterfa-eT~ference(const THal1w~eTnt~rf~R~ference& co~yFlo.ll) Subclasses call (copy constructor).
THar.lw~,PTnt~rhceRef~ience& operdlor_(const THal1war~PTnterf. ~e Reference& copyFrom) Subclasses call.

3 ~ ` --Nel~ ulk TntPrf~e Reference Class Description Purpose: Please refer to section 3.2 for the purpose of this class, what an instance of this class represents, what this class is used for and the me~nin~ of -its attributes.
Deriving ~ P~: This class is polymorphic.
l~oncllrrency: This class is not multi-thread safe.
Persistence: :An instance of a TNetwo*TntPrfAceReference may be saved to a file and restored at any time.
TnPrfAce #ifndef NO_SPI
class TNetworlcIntPrfAceReference: public TIntPrfacPReference public:
//
//Constructors &Destructor TNetworkInterfaceReference();
TNetworkInterfaceReference(const TServiceReference&);
virtual ~TNetworlcTnterfacPReference();
TNetworkInterfaceReference(const TNetworkTntPrfaceReference&
copyFrom);
TNetworkIntPrfAcPReference& operator=(const TNetworkInterface Reference& copyFrom);
/ /
/ / Standard methods virtual TServiceReference~ CreateServiceReference() const;
virtual void SetServiceReference(const TServiceReference&);
//.
/ / Overrides virtual TIntPrfac~Pl\~aker~ Activate();
virtual TStream& operator>>=(TStream& toWhere) const;
virtual TStream& operator<<=(TStream& fromWhere);
protected:
private:
};
#endif WO 95/17720 2 ~ 6 9 ~ 3 ~ PCT/US94105470 .

Member Functions TNel.~vo. k~ntprf~^-e~ference() Creates a default int~rfa~ e re~eL~l~ce for a service connected to a network. The 5 object must be given a "top" interfAce name and a service rere~ ce before Activate is called, or else an exception will be generated. Useful for streaming.
TNel-.ul~-TntPrf^~PT~eference(const TServiceReferPnce~) Creates an interfAce re~r~,ce for a service connected to a network and is represented by the given service re~r~l,ce object. The object must be given a 0 "top" interface name before Activate is called, or else an exception will be generated.
~TNel.. ~ -TntPrf~-eT~pference() Destroys this interface ~ r~,ce object, but does not affect the activated service(s), if any.
5 TNel~ kTntPrf~l-PT~eference(const TNel.. Ol~ TntPrf~ PT~ference& copyFrom) Copies the entire intl~rf~ce re~l~ce object from the copyFrom argument into this object.
TNel~ TntPrf^~PT~eference& o~erdlor-(const TNel~ TntPrf~PReference&
copyFrom) 20 Copies the entire interface refer~l ce object from the copyFrom argument into this object.
TServiceReference* CreateServiceReference() const Creates and returns-~ copy of the Service Reference attribute in this NetworkInterfa~ceReference. Client adopts returned object. Clients are not 25 expected to use this method1.
void SetServiceReference(const TServiceReferPnre~) Sets the Service Reference attribute in this NetworkInterfaceReference.
Creators of NetworkInterfacel~eference objects use this method to specify the network service providing the service.
30 TTnt~rf~P~aker* A.:liv~
This methcd creates a service stack for an entity on a network, whose top service has an interface specified by SetTopTnt~rface(). This method is called directly by clients. A pointer to a TIr t~rfa~ ~l\ Iaker object, of the specified type, is returned. Clients down-cast this pointer to the a~pr~riate type and get a 35 pointer to the real service object. After this has been done, the client is required to delete the TIrterfa~l\Iaker object.

WO 9S/1772~ 3 ~ PCT/US94/OS470 TStream& op~Lal~l>>=(TStream& toWhere) const SLreal.~s out the entire irltPrfare rerelence object into the toWhere arg~mPnt TStream& o~eldlor<<=(TStream& fromWhere) Streams in the entire intPrface re~~ ce object from the fromWhere argument.
s , THa~lw~.~Tnt~rf ^-eR~ference Class Des~ t;on Purpose:.Please refer to section 3.2 for the purpose of this class, what an 0 instance of this class represents, what this class is used for and the meaning of its attributes.
Deriving rl~ses This class is polymorphic.
Concurrency: This class is not multi-thread safe.
Persistence: An instance of a THardwareInterfaceReference may be saved to a file and restored at any tirne.
Interface:
#ifndef NO_SPI
class THardwareInterfaceReference: public TIntPrfacPReference public:
// , / / Constructors & Destructor THardwareInterfaceReference();
THardwareInterfaceReference(const THardwareInterfaceHandle&);
THardwareInterfaceReference(const THardwareInterfacPkl Pnti fiPr&);
virtual ~THardwareInterfaceReference();
THardwareInterfaceReference(const THardwareInterfaceReference&
copyFrom);
THardwareInterfaceReference& operator=(const THardwareInterface Reference& copyFrom);
/ /
/ / Standard methods virtual void SetTopIntPrface(const InterfaceName&, Boolean use ConnectorName);
virtual THardwareTnterfaceHandle GetConnector() const;
virtual void SetC'onnector(const THardwareInterfaceHandle&);
/ / .

WO 95/17720 ~ 1 6 9 ~ 3 ~ ; PCI/US94/05470 // Overrides virtual void SetTopTnterf~ce(const InterfaceName&); // c++ syntax - requirement virtual TTnPrf~cel\~Iaker* Activate();
.- 5 virtual TStream& operator>>=(TStream& toWhere) const;
virtual TStream& operator<<=(TStream& fromWhere);
protected:
private:
};
#endif Member lFunctions THal~lw~eT..t~ Pl~Pference() Creates a default interface erer~lce for a service provided by a device connecte~l to a local computer. The object must be given a "top" interface name and a THardwareInterfaceHandle before Activate is called, or else an exception will be generated. Useful for streaming.
THal~lw~reT~ '- ,PRPference(const THal.lwar~TntPrf~ PT-T~n~le~) Creates an interface rerelel~ce for a service provided by a device connected to a local computer. The device is irlPntifiP-l by the given hardware interface handle. The object must be given a "top" interf~ce name before Activate is called, or else an exception will be generated.
THa~lw~r~T. . l~ eReference(const THal~lwalPTnterf~cPT~lpntifipr&) Creates an interf~ce re~l~el~ce for a service provided by a device connected to a local com~ulel. The device is identified by the given hardware intPrf~ce ntifiPr. The object must be given a "top" interf~ce name before Activate is called, or else an exception will be generated.
~TH~1w;ar~T~ ,eRPference() Deslro~,~ this int~rf~ce rereL~Lce object, but does not affect the activated service(s), if any.
THal~lwareTntPrf~cPl~Pference(const THaflwareTntPrf, -eRPference& coy~Flvll,) Copies the entire interface rereL~l,ce object from the copyFrom argument into this object.
THai~lwaleTntPrf-^~PRPference& operalo~-(const THaL1waleTntPrf~PT~Pference&
copyFrom) Copies the entire interface rereL~llce object from the copyFrom argument into this object.

2~9 G3 ~ .
-3~
void SetTopTnt~rf~ e(const Tnt~rf~-e~ame&, Boolean UseConnectorName) This method specifies the inPrface of the top service object that you want Activate to return. If the UseConnectorName argument is TRUE, then the top TntPrf~t Pl~Jame argument will be treated as a base class name (for type checking) and the real "top" i~t.orf~ce name of the service stack will be retrieved from the connector. If the UseConnectorN~me argument is FALSE, then this method behaves as the normal SetTopIrltPrf~re method.
THa~1w~.~Tnt~rf. ceT~T~n~lle GetC'ollnector() const Returns a copy of the Connector attribute in this HardwarPTnterf~cel~eference. The Connector attribute represents the connector on the physical hardware which actually provides the service (e.g.
the connector on the back of a StyleWriter). This connector is connerte~1 to a port which drives the service (e.g. the serial port on a PC motherboard).
Clients will rarely, if ever, use this method. HardwareIntPrfacPl~eference uses it to ~etPrmine the bottom intPrf~ce.
void SetCormector(const THar~ rareTn~rhr~ n~lle~) Sets the Ccnnector attribute in this HardwareIrterf~cel~eference. Creators of HardwareInt~Prf~c~l~eference objects use this method to specify the connector on the physical hardware which actually provides the service (e.g. the connector on the back of a StyleWriter).
TTnt~rf~ l\Iaker~ Acliv;ate() This method creates a service stack for a device connPcted to a local computer, whose top service has an interface specified by SetTopIr-terf~ce().
This method is called directly by clients. A pointer to a TInterfaceMaker object, of the specified type, is returned. Clients down-cast this pointer to the a~ropliate type and get a pointer to the real service object. After this has been done, the client is required to delete the TTntPrf~c~ aker object.
TStream& o~c~ o,>>=(TStream& toWhere) const Streams out the entire interface rerel~ ce object into the toWhere argllment.
TStream& operator<<=(TStream& fromWhere) Streams in the entire intPrf~ce refelcllce object from the fromWhere argumPnt WO 9S/17720 2 16 9 ~ 3 9 PCT/US94/OS470 TT.~ ~PMaker Class Description Purpose: Please refer to section 3.2 for the purpose of this class, what an - instance of this class represents, what this class is used for and the meaning of 5 its attributes.
Deriving C1~SP~: This class is polymorphic.
Concurrency: This class is not multi-thread safe.
Persistence: Tnt~rf~re Makers are not persistent.
Tnterf~ce:
0 #ifndef NO_SPI
class TTnt~rfaceMaker public:
//
// Destluctor virtual ~TTntPrf~ c~Maker() ~rolecled:
// . .
// Const~uctors TTnt~rfaceMaker();

TInterfaceMaker(const TInterfaceMaker& copyFrom);
TIntPrfac~ aker& operator=(const TIrterf~cPMaker& copyFrom);
private:
}i #endif Member Fl~nctioIlc ~TTntPrf. -PMaker() Destroys this interface maker object.
TTntPrf. ~Maker() Creates a default interface maker for an interface maker subclass.
TTntPrfa~PMaker(const TTntPrfa~Pl\~aker& co~yFlom) Copies the entire intprface maker object from the copyFrom argument into this object.

WO 9S/17720 ~ us94los470 '~169~3g ~

TTntPrf~- ~Maker& o~>elalor-(const TTnt~rf~ aker& co~yF~u)~) Copies the entire intPrface maker object from the copvFrom argument into this object.

5 TUpper~ntPrf^ eMaker Class Desc,;~lion Purpose: Please refer to section 3.2 for the purpose of this class, what an instance of this class represents, what this class is used for and the meaning of 0 its attributes.
Deriving C~ P~ This class is polymorphic.
Concurrency: This class is not multi-thread safe.
Persistence: TntPrf~ce Makers are not persistent.
II-t~rf~ce:
5 ~ifndef NO_SPI
class TuppeLIllle~ racPMaker: public TlnterfacPMaker .
public:
//
// Standard methods virtual void Activate(const TTntPrf~ceMaker& below, const TIntPrf~ce Bundle&) = 0;
/ / , , / / Destructor virtual~TUpperInterfaceMaker();

~role~:led:
/ /
/ / Constructors TUpperTntPrf~cPl\~Iaker();

TUpperTnt~rfaceMaker(const TUpperInterfaceMaker& copyFrom);
TUpperInterfaceMaker& operator=(const TUpperTntPrf~ceMIaker&
copyFrom);
private:
3;
#endif WO g5/17720 PCI/US94/OS470 ~ 2~6~39~.

Member F~lnction~;
virtual void Aclivale(const TTnt~rf~cel~aker& below, const TTnt~rf~~eRundle &)=0 5 Subclasses know what "real" service object to make. This method is called by a TTnterf~c~T~eference object, passing in the below intPrf~ce maker object.
The subclass down-casts it and asks it for the real below service. The real below service is then given to the service object created by the interf~ce maker subclass. Lf the TTnt~rf~c~Reference object has a TTnt~rfaceP~undle 10 associated with the top interface colr~onding to this maker, then the TTnterfAcPT~eference objet will pass it into this function. If the given TInterfaceBundle pointer is not nil, then the callee can safely down-cast it to the type it expects. This object contains special service specific inform~tion (e.g. BAUD rate).
15 ~TUppPrTnf~rf~ eMaker() DesLlvy~ this int.orface maker object.
TUpp~rTnt~rf~ eMaker() Creates a default interface maker for an upper intPrf~ce maker subclass.
TUpper~nt~rfac~ aker(const TUppPrTnt~rf~c~l~aker& copyFrom) 20 Copies the entire intPrf~ce maker object from the copyFrom argument into this object.
TUppPrTnt~rf~ceMaker& ~ aloL-(const TUpperTnt~rf~ceMaker& co~yrlolll) Copies the entire int~rf~ce maker object from the copyFrom argument into this object.
TAccess~n~g~rl~aker Class Description Purpose: Please refer to the above discll~sion for the purpose of this class, what an instance of this class represents, what this class is used for and the0 meaning of its attributes.
Deriving ~ SPS: This class is polymorphic.
Concurrency: This class is not multi-thread safe.
Persistence: Int~rf~ce Makers are not persistent.
Interf~ce.
35 #ifndef NO_SPI
class TAccessManagerMaker: public TInt~rf~c.ol\~aker WO 9S117720 ~ . PCT/US94/OS470 21~39 public:
/ /
// Standard methods virtual void Activate(const THardwareInterfaceIdentifier& theMetal, const TIrt~rf~ceBundle&) = 0;
//
// Destructor virtual ~TAccessManagerMaker();
protected:
//. . --. . -/ / Constructors TAccessManagerMaker();

TAccessManagerMaker(const TAccessManagerMaker& copyFrom);

TAccessManagerMaker& operator=(const TAccessManagerMaker&
copyFrom);
private:
};
#endif Member Functions virtual void Activate(const THal.lwareTntPrfac~T~ntifier& theMetal, const TTnterfa~eR~n~lle~) = O
Subclasses know what "real" Access Manager object to make. This method is called by a TTnt~rf~c~T~eference object, passing in the THardwareInterf~cekl~ntifier object. This is given to the AccessM~n~ger object created by the AccessManagerMaker subclass. The bundle parameter follows the same rules as specified for TUppPIT.~ c~ aker::Activate.
~TAccessManagerMaker() DeslLoy:j this access manager maker object.
TAccessManagerMaker() Creates a default access manager maker for an upper interf~ce maker subclass.
TAccessl~n~g~rMaker(const TAccessManagerMaker& copyFrom) wo 95/17720 ~ 1 ~ 9 ~ 3 ~ PCrlUSg4105470 Copies the entire access mAn~er maker object from the copvFrom argument into this object.
TAccess~n~g~rl~aker& o~ alor-(const TAccessl~na~rl~aker& co~F,to~l) Copies the entire access m~n~er maker object from the copyFrom argument - 5 into this object.

TTntPrf:lreRundle Class Des~;~ol~
Purpose: Please refer to the ~i~cu~ion above for the purpose of this class, 0 what an instance of this class represents, what this class is used for and the meaning of its attributes.
Deriving t'l~s~s: This class is polymorphic.
Concurrency: This class is not multi-thread safe.
Persistence: TntPrfAce Bundles are persistent.
Int~rfAre.
#ifndef NO_SPI
class TInterfaceBundle public:
//
// Destructor virtual ~TInterfaceBundle();

/ /
// Special Operators virtual TStream& operator>>=(TStream& toWhere) const;
virtual TStream& operator<<=(TStream& fromWhere);
protected:
//.
// Constructors TInterfaceBundle();

TInterfaceBundle(const TInterfaceBundle& copyFrom);
TTnterfAceBundle& operator=(const TTntPrfAreBundle& copyFrom);
private:
}i #endif WO 95/17720 . `~ ; PCT/US94/OS470 ~6963~
~o-Member Flln. tiQng ~T~nt~rf^-eRundle() Deslloy~ this int~rface bundle object.
TTnt~rf~ ~Rundle() Creates a default interf~ce bundle for an interface bundle subclass.
TStream& o~al~i~>>=(TStream& toWhere) const ~lreallls out the entire in~rf~ce bundle object into the toWhere argllmPnt-TStream& o~Lalor<<=(TStream& fromWhere) Streams in the entire int~rface bundle object from the fromWhere argument.
TTnt~rf-ce~undle(const TTnt~rfa~ eP~undle& copyFrom) Copies the entire interface bundle object from the copyFrom argument into this object.
TTnt~rf~c~T~lln~lle~r o~elalor-(const TTnt~rf~ceBundle& copyFrom) Copies the entire interf~ce bundle object from the copyFrom argument into this object.

Other corlgi~-~r~tinng It is possible that more than one stack description may be generated during an Activate. There are multiple paths through the sea of service stacks which can adequately provide the requested top service on the desired device ID. Some heuristic will resolve and select one stack. Clients, for example time-based me~ , may be very interested in the middle layers for the various stack choices. Characteristics of these layers may need to be figured into the equation and ~re~lences solicited for use in the s~l~ction.
If a mouse device is not registered (related to the dead mouse issue), there must be the ability to create a driver for the mouse. Two possible solutions:
(1) Register mouse device, Activate the rerer~nce, Unregister the mouse.
(2) CAM creates the driver when it detects the mouse moving.
It may be desirable to delay creation of a service until the point where it is required. For example, delaying the creation of a ~ r service for an ImageWriter, until the point that a user drags a document onto the printer.
Or, the service could be created imme~ tely upon discovery that an ImageWriter is connected. The ~re~lred embodiment allows clients to make either choice.

WO g5/17720 ~ 1 6 9 6 ~ ~ PCT/USg4tO5470 ~1-Seltting the BAUD rate for a serial ImageWriter is performed by storing service specific par~mPtPrs in bundles stored in a TDictio~ry stored in the model. They copy the dictionary into their TInterfaceReference when they get it.
.- 5 Design De~ .c Interface Maker When clients first look at the TInterf~c~l?eference class, they see an abstraction which is capable of creating and returning a particular type of 0 service.
UlL~ollunately, TTntPrfaceReference obscures what is se~mingly a simple and commonplace operation by introducing a maker class. The affect on the client, is the addition of an extra step in order to access the service stack. Developers are burdened with extra implementation effort by being forced to code the 5 maker class. Evelyolle is burdened with the extra mPnt~l effort required to nclerstand the design.
There are reasons for having to deal with the extraneous maker classes, but there are several issues which must be discussed in order to obtain a full understanding of extraneous maker classes. First, we need to examine closely 20 the hierarchy of TPresentableViews 3102, as shown in FIG. 31.
TPrP~nt~bleView 3102 is a subclass of TView 3100. TPr~Pnt~hleView 3102 is used to represent many views throughout the ~y~Lem (e.g. controls, editable text, grid views, interactive views, movies, panes, etc., shown collectively as 3104). There is a common abstraction among all view objects (e.g. drawing, 25 transformations, notification, hit tests, nesting other views, etc.). This suggests a common base abstraction. Furth~rmore, views are used throughout much of the user interf~ce ~y~Lelll, which suggests a need for polymorphism.
Now, lets ex~mine service stacks. As stated above, it is desirable to avoid a common class hierarchy for services. If we rejected this goal, the service 30 hierarchy would be required to look as shown in FIG. 32. There is no commonality between a disk driver associated with 3206, a serial port driver associated with 3208 a rl~L~l associated with 3204, or a mouse driver associatedwith 3202. There is no requirement for polymorphism. Service stacks are not going to be passed around to various parts of the system. All polymorphic 35 requirements are handled by the TIntPrf~c~l~eference class. So, the adv~nt~s of requiring a common abstraction where none exists conceptually do not appear to out weigh the disadvantages.

WO 9S/17720 2 1 6 9 6 3 ~ PCT/US94/OS470 ~2-There is actually a positive side to the maker ~ SSPS. Any service can be supported by the interf~ce re~Lence framework via the introduction of a maker.
For example, if a service were created which was not expected to be used by an in~Prf~re le~r~l.ce, a developer would not be pr~v~l led from using the service in a service stack. All the developer is required to do is write one maker class(much less work than writing the service from scratch or writing a wrapper). A
wrapper would be required if there were no maker classes. This would imply that all services would have to derive from TService 3200. Since the class in question did not, the developer would wrap up the class in a TService 0 derivative.
FIG. 33 illustrates how easy it is for a developer to make any service work within the interface re~l~lce framework by adding one maker class. The disk drive service is not supported by the intprf~re rererel-ce framework (at the time, no one thought it was nPc~s~ry).
In FIG. 34, however, the disk drive service is NOW supported by the intPrf~ce re~el~:l.ce framework (somPon~P had a need, and a maker was developed).
While the invention has been rlesrrihed in terms of a ~r~lfed embo~1imPnt in a specific system environment, those skille-l in the art 20 recognize that the invention can be practiced, with mo~lifir~tion, in other and different hardware and software el-~,ilol ments within the spirit and scope of the appended ~ ims.

Claims (10)

1. In a computer system having a processor (10), a memory (14), and a device (23) connected to the computer system via a communication medium (34), an interface reference framework (900) for providing system services for the device to a client application (700) executing on the computer system, while insulating the client application from the details of now the device is connected to the computer system and how the system services, which access the device, are created, the interface reference framework (900) characterized by:

(a) a plurality of service class definitions (1700,1704,1708), each service class defining a service object (1810) having means for communicating according to a predefined interface (1802);

(b) a plurality of service maker class definitions (1808) in the memory (14), each service maker class (1808) defining a service maker object (1804) having means for creating in the memory a corresponding service object (1810) from one of the service class definitions (1100); and (c) means for providing to the client application an interface reference object(1508) corresponding to the device, wherein the interface reference object includes:

means for receiving from the client application a top interface for defining a protocol for the system services for the device (1514);

means for creating a stack description in the memory, identifying a bottom service for communicating with the device, a top service for communicating with the client application according to the top interface, and an intermediate service for communicating with the top and bottom services over the communication medium according to their predefined interface (1702,1706, 1710);

means for making from the stack definition a service stack in the memory and for returning a reference to the service stack to the client application so thatthe client application can use the service stack to communicate with the device according to the service protocol defined by the top interface, the means for making the service stack (1710) including means for iterating through the stack description and creating a corresponding service maker object in the memory from one of the service maker class definitions for each of the services identified in the stack definition (1708);

means for polymorphically activating the service maker objects to create a corresponding service object from one of the service class definitions to create the service stack having a top service object communicating with an intermediate service object, which, in turn, communicates with a bottom service object (1700).

2. The framework of claim 1, wherein the means for providing includes a hardware interface reference class for devices connected locally to the computer system (2414); and a network interface reference class for devices connected remotely to the computer system, wherein the means for providing dynamically selects, during the execution of the client application, from the hardware interface reference class and network interface reference class, depending upon whether the device is locally or remotely connected, to create the interface reference object therefrom (2614).

3. The framework of claim 1, wherein the interface reference object specifies the bottom service (2600).

4. The framework of claim 1, wherein the interfaces reference object determines the bottom service by accessing a configuration framework (2900).

5. The framework of claim 1, wherein the computer system further includes a locator means for dynamically locating services from within the computer system based on query parameters and wherein the means for creating a stack description uses the top interface and the bottom service as query parameters to the locator means to dynamically locate the intermediate service (2906).

6. In a computer system having a processor (10), a memory (14), and a device (23) connected to the computer system via a communication medium (34), a method of providing system services for the device to a client application (700) executing on the computer system, while insulating the client application from the details of how the device is connected to the computer system and how the system services, which access the device, are created (900), characterized by the steps of;

(a) providing a plurality of service class definitions (1700,1704,1708), each service class defining a service object (1810) having means for communicating according to a predefined interface (1802);

(b) providing a plurality of service maker class definitions (1808) in the memory (14), each service maker class defining a service maker object (1804) having means for creating in the memory (14) a corresponding service object (1810) from one of the service class definitions (1100);

(c) providing to the client application an interface reference object corresponding to the device (1508);

(d) the client application providing a top interface for defining a protocol for the system services for the device to the interface reference object (1514);

(e) the interface reference object creating a stack description in the memory, identifying a bottom service for communicating with the device, a top service for communicating with the client application according to the top interface, and an intermediate service for communicating with the top and bottom services over the communication medium according to their predefined interfaces (1702, 1706, 1710); and (f) the interface reference object making from the stack definition a service stack (1710) in the memory and for returning a reference to the service stack to the client application so that the client application can use the service stack to communicate with the device according to the service protocol defined by the top interface by iterating through the stack description (1708) and creating a corresponding service maker object in the memory from one of the service maker class definitions for each of the services identified in the stack definition and polymorphically activating the service maker objects to create a corresponding service object from one of the service class definitions to create the service stack having a top service object communicating with an intermediate service object, which, in turn, communicates with a bottom service object (1700).

7. The method of claim 6, wherein the system includes a hardware interface reference class for devices connected locally to the computer system; and a network interface reference class for devices connected remotely to the computer system (2414), and wherein step (c) includes the step of (c.1) dynamically selecting, during the execution of the client application, from the hardware interface reference class and network interface reference class, depending upon whether the device is locally or remotely connected, to create the interface reference object therefrom (2614).

8. The method of claim 6 wherein the interface reference object specifies the bottom service (2600).

9. The method of claim 6, wherein the interfaces reference object determines the bottom service by accessing a configuration framework (2900).

10. The method of claim 6, wherein the computer system further includes a locator means for dynamically locating services from within the computer system based on query parameters and wherein the method further includes the step of:
(g) using the top interface and the bottom service as query parameters to the locator means to dynamically locate the intermediate service to create the stack description (2906).