Object-oriented communication system with support for multiple remote machine types6438617Abstract An apparatus for communicating with a plurality of remote machines, of a plurality of machine types includes a computer system including a processor and memory a data communication means, coupled to the computer system and to the plurality of remote machines, for communicating with each of the plurality of remote machines, a first plurality of software objects within the memory for describing services for the plurality of remote machines, and a plurality of operations within the memory associated with the first plurality of software objects, the plurality of operations for satisfying requests described by the services of the first plurality of software objects. Claims What is claimed is: Description COPYRIGHT NOTICE
Component Describes a remote machine
Service
ServiceCollection Collection of service items
SC_ServiceModel A Component's model
SC_AppServices A Component's application
items
SC_Queue A collection of
SI_QueueItems
(and other various other special-purpose collections)
SI_ServiceItem Describes a remote service
SI_ModelItem machine model - description
only
SI_GuiItem a GUI element representing
an item
SI_AppItem application state for an
item
SI_QueueItem a queued read or write on
an item
2.2. Component and Associated Objects FIG. 4 illustrates a typical Component 700 (object instance in the memory 50 of computer system 1 representing a remote machine 90) and the objects to which it refers. These objects are its "state" attribute 600, an SC_AppServices object, its "model" attribute 630, an SC_ServiceModel object, its writeQueue and readQueue attributes 670, each an SC_Queue object, and its "session" attribute 710, a reference to an instance of a subclass of class SI_CommunicationSession. An SC_ServiceModel 630 is a collection of "model items" 640, 650, each model item being an instance of a subclass of SI_ModelItem. Collectively the SC_ServiceModel 630 is a description of the services provided by the remote machine 90 represented by Component 700. An SC_AppServices 600 is a collection of "application items" 610, 620, each application item being an instance of class SI_AppItem, and having a reference to a corresponding SI_ModelItem 640, 650 and SI_CallbackList 520, 530. Each application item 610, 620 contains information about the current value (if known) of the corresponding service in the remote machine, and any requested operations or data transfers involving that service. The SC_AppServices object 600 is initialized by means of the "initServices" operation on class Collection 700; one of its parameters is an optional pointer to a function from pointer-to-SI_ModelItem to Boolean that allows an application to select from the machine model 630 only those services that are actually used by the application. An SI_CallbackList 520, 530 is a collection of SI_GuiItem objects 540, 550, 570, 580, 590, each of which refers to and is referred to by a single object that represents a "control" in the graphical user interface which displays information and with which the user may interact. The purpose of the SI_GuiItem is to ensure that changes made by the user using the graphical user interface cause equivalent changes in the appropriate SI_AppItem 610, 620 in the application state 600, and that changes in an SI_AppItem 610, 620 in the application state 600 that result from the operation of the program, and particularly from communication with the remote machine, cause equivalent changes in the information presented to the user by the graphical user interface. The operation "newValueSet" of class SI_AppItem is used to request a change of state (write operation) in the service. The operation "readRequest" of class SI_AppItem is used to request a read operation. When a read or write operation is requested, an object 680, 690 of class SI_QueueItem is constructed that refers to the SI_AppItem 610, 620 and also contains the requested operations: read or write and, in the case of a write, the data to be written. The SI_QueueItem is placed on either a read queue 670 or a write queue that are attached to Component 700. These queue items accumulate until the user or the application requests a batch communication session with the remote machine, as will be further described in conjunction with the communications module. When the batch communication session is performed, the currentValue attribute of each SI_AppItem is updated to reflect the value stored in or retrieved from the remote machine. Each SI_GuiItem 500 associated with SI_AppItems 610, 620 is automatically notified of the update as a side effect of the "currentValueSet" operation. A Component object is itself a container for "sub-components" (not shown), corresponding to separately-controllable machines connected to the remote machine. For example, the top-level Component object 700 may be a line-adapter multiplexer, to which a plurality of copiers are attached, represented by the contents of the top-level Component 700. FIG. 5 illustrates the relationship between the machine model 860 (630 in FIG. 4), the application state 810 (600 in FIG. 4), and the remote machine 90. For this illustration we will use a facsimile machine similar to the Ricoh model FAX-60, in which the remotely-accessible services are represented by data contained in an electronically-erasable read-only memory 910, from which data may be retrieved or in which data may be modified by presenting the facsimile machine 90 with a suitably-formatted request containing a starting address and size. It can easily be seen by one skilled in the art that other protocols are possible, involving different ways of identifying the data to be transferred, and different encodings for the data. Since the remote facsimile machine stores service items in a memory, the machine model 860 contains objects 870, 880 that are instances of class SI_MemoryItem, a subclass of SI_RemoteItem which in turn is a subclass of SI_ServiceItem. For example, SI_MemoryItem 870 has a size 3 in its "itemSize" attribute, specifying a string of length 3. The data type "Chars" in SI_MemoryItem 870 is represented in the "valueDscr" attribute by a pointer to an instance of a subclass of class R_ValueDscr. Some of the remotely-accessible data consists of bitfields stored within bytes in the memory; FIG. 5 illustrates two such bitfields 921, 922 contained within a byte 920 in memory 910 of remote facsimile machine 90, each represented by an instance 890, 900 of class SI_BitfieldItem, both contained within the SI_MemoryItem object 880 that represents the byte 920. Each service item that can be manipulated by the remote service application program has a current state within the application state 810 represented by an instance 820, 830, 840, 850 of class SI_AppItem. In a preferred embodiment of the present invention, the machine model is composed of instances of subclasses of SI_ModelItem, having the following hierarchy (note indentation denotes inheritance):
SI_ModelItem machine model - description only
SI_InternalItem internal to application
SI_ExternalItem external storage or server
SI_DirectoryItem directory
SI_FileItem file
SI_TableItem database table
SI_QueryItem database query
SI_TupleItem database tuple
SI_FieldItem database field
SI_RemoteItem remote machine
SI_MemoryItem stored in remote memory
SI_BitfieldItem bitfield in word
SI_ProgramItem accessed by remote program
The abstract class SI_ModelItem provides an abstract programming interface for performing access and update operations to a service item located on a remote machine; the various subclasses of SI_ModelItem provide implementations of these operations for operating on particular kinds of remote data using communication protocols specific to particular remote machines. The subclassing allows SI_MemoryItem objects 870, 880 to have behavior specific to remote service items stored in a remote machine's memory, and SI_BitfieldItem objects 890, 900 to have behavior specific to bitfields that are contained in a word stored in a remote machine's memory. For example, the "packedSize" attribute is computed by a function that in an SI_BitfieldItem simply returns the value of the "itemSize" attribute, but in an SI_MemoryItem returns the value of the "itemSize" attribute multiplied by 8, the number of bits in a byte. SI_InternalItem and SI_ExternalItem are the two main subclasses of SI_ModelItem. SI_InternalItem objects describe data associated with the remote machine, but internal to the remote service application (for example, the machine's serial number, which may not be accessible remotely but which may be obtained from a customer database). When data is external to the remote service application a subclass of SI_ExternalItem subclass is used. For example, SI_TableItem describes a table in a remote database server, and SI_MemoryItem describes a data item in the memory of a remote facsimile machine. The data itself, i.e. its data type (integer, cardinal number, float, string, etc.), size, range of values, and other attributes, are described in a data structure called a "value descriptor" (class R_ValueDscr). These value descriptors are runtime class descriptors similar to those used in languages such as Smalltalk. A pointer to the value descriptor and the default value of the data are combined in an object of class Rvalue, which is the "defaultValue" attribute of the SI_ModelItem object. Some attributes of the value descriptor may be overridden by corresponding attributes of the SI_ModelItem. If a value is a reference to an instance of some object, its class name and publicly-accessible attributes are described by an instance of class R_ClassDscr which is returned by the virtual function "dscr" of the object instance. Each SI_AppItem object 820, 830, 840, 850 in the application state 810 stores the information that the remote service application has about the current state of the remote machine, the state of the user interface, and the relationship between them. Each instance of class SI_AppItem 820, 830, 840, 850 has an attribute "model" containing a reference to a single instance of class SI_ModelItem 870, 889, 890, 900 that describes the permissible states for that item, and its location or access information on the remote machine. Each SI_AppItem also has an attribute "currentValue," that contains information about the current state of that service item in the remote machine, as well as an attribute, "newValue," that represents a requested update state for the remote item. Compound Data When a service item in the remote machine consists of a compound data structure such as an array or structure, it is described by an SI_ModelItem object having a collection of one or more subsidiary SI_ModelItem objects, also known as its "children." An SI_ModelItem representing an array will have a single child describing the array item objects and an SI_ModelItem representing a structure will have a separate child describing each field. The corresponding SI_AppItem may have either a child SI_AppItem for each sub-item (array element of structure field), or else a single compound value that refers to an array of sub-item values. Each SI_AppItem representing an array element has a value in its "location" attribute that is an index from the start of the array. The application programmer decides which of these two representations is most appropriate for any given application. For example, in FIG. 5, remote data byte 920, described by SI_AppItem object 830 and SI_MemoryItem object 880 contains bitfields that are described by SI_AppItem objects 840 and 850 and SI_Bitfield objects 890 and 900. Remote Machine History Optionally, the history of a remote machine may be stored in a historical database (not illustrated). Types of historical data include for example, the number of copies made on a copier every month, the options purchased by the customer, etc. To track the history, the SI_AppItem has an attribute, "history," that points to another SI_AppItem of a different component. The different component is typically one that describes a database or file. The history item's "currentValue" reflects what is known about the item when the application is started (e.g. The previous month's copy count in a billing application). When there is a change in what the system knows about the item, "currentValueSet" is called to reflect the change and the history item's "newValueSet" operation is called with the same value. In some applications (e.g. remote setup) it may be very useful to be able to revert a service item's value to the value it had when the program was started, so as to effectively undo any changes that may have been made by the application's user. Defining New Model Items As can be seen, the application programmer may readily define new subclasses to the class SI_ModelItem in order to describe new sorts of service items provided by any new remote machine, database, or other external resource. Any application linked with a library containing the code for such a subclass will be able to make use of the new service items at runtime; such applications need not be recompiled, but only relinked. By putting the new classes in a dynamic link library (DLL), suitably-constructed applications can make use of new service items even after being linked and distributed to users. Initialization It can be seen by one skilled in the art that the application program must construct in its memory a Component and its associated machine model and application state, in order to communicate with some remote machine. In a preferred embodiment of the present invention, this can be done by parsing one or more files that contain a textual or binary representation of the object instances to be constructed, including the names of their classes, the names and values of their attributes, and the textual or binary representations of the objects contained in each collection object. The resulting parse tree is created using the constructors for the various classes represented in the file; its root is the required Component object instance 700, 800; its "model" attribute contains the machine model 630, 860, and its "state" attribute contains the application state 600, 810. The application state may either be constructed by parsing a separate Case file 330, 420, or constructed and initialized with default values from the machine model file 350, 430. As an example, if the application program needs to communicate with a facsimile machine, the application program first retrieves a machine model file describing the facsimile machine. Such a file may appear as follows (partial):
SC_ServiceModel: (.linevert split.
name=k50
.linevert split.
SI_MemoryItem: (.linevert split.
name=R17D4
defaultValue=BCD1:51
description=`drmk50.dat#R17D4`
itemValueList=[]
features=S_FeatureSet: (SYSTEM
RemoteSetting)
readOnly=-
msbFirst=+
isremote=+
bitOffset=0
offset=6100
label=`NCU 13`
.linevert split.)
SI_MemoryItem: (.linevert split.
name=R17D5
defaultValue=BCD1:256
description=`drmk50.dat#R17D5`
itemValueList=[]
features=S_FeatureSet: (SYSTEM
RemoteSetting)
readOnly=-
msbFirst=+
isremote=+
bitOffset=0
offset=6101
label=`NCU 14`
.linevert split.)
SI_MemoryItem: (.linevert split.
name=R17D6
defaultValue=BCD1:256
description=`drmk50.dat#R17D6`
itemValueList=[]
features=S_FeatureSet: (
SYSTEM
RemoteSetting)
readOnly=-
msbFirst=+
isremote=+
bitOffset=0
offset=6102
label=`NCU 15`
. . .
As illustrated, the description file a textual representation of a SC_ServiceModel (model) for a "K50" facsimile machine. Instances of SI_MemoryItem are described including R17D4, R17D5, and R17D6. Virtual functions within the appropriate instances are executed to handle the specific communication protocol. As another example, if the application program needs to communicate with a copier machine, the application program first retrieves a file describing the Copier machine. Such a file may appear as follows (partial):
SC_ServiceModel: (.linevert split.
name=FT8780
.linevert split.
SI_CopierItem: (.linevert split.
name=LampThermistor
writeDCode=`1302;`
features=S_FeatureSet: (
ReadOnly
RemoteSetting)
msbFirst=-
writeInfCode=`16040070101`
isremote=+
offset=0
label=LampThermistor
separator=`;`
IDCode=[]
defaultValue=Nchars2:"00"
size_for_specify_data_length=2
description=[]
readOnly=-
bitOffset=0
readInfCode=`16040070101`
size=2
readDCode=`1302;`
.linevert split.)
SI_CopierItem: (.linevert split.
name=SC_ChargerLeak
writeDCode=`1302;`
features=S_FeatureSet: (
RemoteSetting
ScCall)
msbFirst=-
writeInfCode=`32000930201`
isremote=+
offset=0
label=SC_ChargerLeak
separator=`;`
IDCode=[]
defaultValue=Nchars1_1:"0"
size_for_specify_data_length=2
description=[]
readOnly=-
bitOffset=0
readInfCode=`32000930201`
size=1
readDCode=`1302;`
.linevert split.)
SI_CopierItem: (.linevert split.
name=FusingTempADJ
writeDCode=`1304;`
features=S_FeatureSet: (
ReadWrite
RemoteSetting)
msbFirst=-
writeInfCode=`51011050101`
isremote=+
offset=0
label=FusingTempADJ
separator=`;`
IDCode=[]
defaultValue=Nchars3s_16:"00"
size_for_specify_data_length=2
description=[]
readOnly=-
bitOffset=0
readInfCode=`51011050101`
size=1
readDCode=`1302;`
.linevert split.)
. . .
As illustrated, the description file contains a textual representation of a SC_ServiceModel (model) for a "FT8780" copier machine. Instances of SI_CopierItem are described including LampThermistor, SC_ChargerLeak, and FusingTempADJ. An application can communicate with a plurality of remote machines by creating a plurality of Component objects 700, 800 and associated machine models 630, 860 and application states 600, 810 in its memory, either sequentially or concurrently. 2.3. Exemplary Class Descriptors The following C++ code consists of class declarations for an illustrative subset of a preferred embodiment of the machine model classes. 2.3.1. Service Class The Service class is the general abstract base class for service items and service collections.
class Service: public R_Nameable {
Description:
R_ABSTRACT(Service, R_Nameable);
public:
Pseudo-Attributes:
R_FUNC_RX(Service *, parent);
R_CONTAINER_IS(parent);
The parent of this service in the
tree. Null if this Service is at the
root of the Service tree (i.e. its
parent is a Component). "parent" can
either be set when the Service is
created, or by the parent itself when
the child is appended to it.
R_FUNC_RO_RC(R_Collection, children);
R_CONTENTS_IS(children);
A collection to hold the children of
this service. It is put here so that
it can be initialized and deleted in
one place. The downside of this is
that downcasting has to be done in
the subclasses in order to
specialize.
virtual void setValueAt(Rcard i, Rvalue const
&nv);
virtual void setValueOf(RKey const &key, Rvalue
const & nv);
virtual void append(Rvalue const &nv);
Override the operations that add
children, so they can call parentSet.
virtual Service *getChildByName(R_Symbol *nm);
Given a service name, find a child
that matches it. Should be
overridden in subclasses that can do
fast lookup.
virtual Component *component() const;
The component to which this service
is attached, if any. Declaration of
the contents is deferred until it can
be strongly typed. This is done with
"S_TYPED_CHILDREN(child_type,
collection_type)"
#define S_TYPED_CHILDREN(childType, collectionType).backslash.
R_CONTENTS_INIT_NEW(collectionType, children);.backslash.
R_CHILDREN_ARE_TYPED(childType, collectionType,
parentSet)
Constructors:
Service(R_Symbol &nm, Service *prnt = 0);
By convention, all ServiceItem
constructors take a reference to a name as
their first argument, and an optional
pointer to a parent as their last
argument.
Usage:
"parent. append(new Service (name, &parent))"
Service(R_Base const &o);
When constructing a service using its
copy constructor, we are typically
building a tree from the bottom up
and so do not know the parent. It
has to get assigned on append, which
we do with parentSet.
Destructor:
Service();
Delegated Collection Operations:
operations that append a service to a
parent service have to set the
child's "parent" field if necessary.
2.3.2. SI_ServiceItem Class The SI_ServiceItem class provides a uniform interface for all service items.
class SI_ServiceItem: public Service {
Public:
S_TYPED_CHILDREN(SI_ServiceItem,
RT_Table<SI serviceItem>);
Returns information about this
service item: This information
is used to describe this service
item to the application
(features) and to the user
(label, description)
R_ATTR_XX_RC(R_String, label);
A string used to display label this
ServiceItem for presentation to the
user. It the default name and may be
different from the name because of
application-specific renaming or
language translation.
R_FUNC_GET(R_string *, description);
A string that gives a brief
description of what this
ServiceItem does. In general,
the description will be looked
up in a database or file rather
than being stored in the
application's working memory
before it is needed.
R_FUNC_GET(S_FeatureSet*, features);
Returns a set of symbolic features
for this service.
R_FUNC_GET(Rcard, offset);
Returns the address of this item (in
bytes) relative to its parent.
R_FUNC_GET(Rcard, bitOffset);
Returns the offset in bits of this
item relative to the low order bit of
the item that contains it, if any.
R_FUNC_GET(Rcard, index);
The index of this item in its parent,
if the parent is an array of
identical items. Zero otherwise.
R_FUNC_GET(Rcard, address);
The absolute address of the item (in
bytes) relative to the start of the
memory, file, or whatever that
normally contains it. Computed from
offset, index, and size.
Value Description Information The following functions are normally delegated to a descriptor, specifically the value descriptor of defaultValue. A few functions such as the sizes and valueList, can be overridden by attributes in SI_ModelItem. R_FUNC_GET(Rvalue, defaultValue); The item's default value, if any. The default value's R_ValueDscr is the descriptor used for all instances of this item. R_FUNC_GET(R_ValueDscr&, defaultDscr); The default value descriptor. Should be identical to "defaultValue().dscr()," but deferred for efficiency (i.e. so the user does not wind up passing the whole value around through several levels of indirection). R FUNC GET(Rcard, minSize); R_FUNC GET(Rcard, maxsize); The minimum and maximum number of bytes required to hold an item's value, i.e., to store the item in the remote machine's memory, to transmit it to the machine, or to store it in a database. A maxsize of Rinvalidindex indicates a variable-length object with no upper bound on its size. R_FUNC_GET(Rcard, packedSize); The number of bits required to hold the item's value. R_FUNC_GET(Rcard, minwidth); R_FUNC_GET(Rcard, maxwidth); R_FUNC_GET(Rcard, minHeight); R_FUNC_GET(Rcard, maxHeight); The minimum and maximum number of characters and lines required to represent a value as a string for printing or display. R_FUNC_GET(Rvalue, minvalue); R_FUNC_GET(Rvalue, maxvalue); The item's minimum and maximum values. Return Rnullvalue for string-valued items. R_FUNC_GET(Rvalue, unit); R_FUNC_GET(Rvalue, scaleFactor); A unit and scale factor to be displayed after the item's value. For example, a voltage's unit and scale factor might be V and 1000 for a value expressed in kilovolts. R_FUNC_GET(R_Base *, valueList); The permissible values for an item with a small set of named values. It should be a collection indexed by numeric value and keyed by symbolic name. R_FUNC_GET(Rbool, msbFirst); Byte ordering. R_FUNC_GET(Rbool, readonly); True if the item cannot be modified on the remote machine. 2.3.3. SI_ModelItem Class A ModelItem is part of a machine's description, i.e., the program's model of the machine. It contains no information whatever about the current state of the machine, only how to get that state and what values are permissible. Essentially, a ModelItem contains everything that can be known in advance about an item without actually calling up a remote machine or looking in a database. class SI_ModelItem: public SI_ServiceItem { R_ABSTRACT(SI_ModelItem, SI_ServiceItem); public: R_String *descriptioninit(); Initialize the description. R_ATTR_RW_RC(S_FeatureSet, features); The features of this item. R_ATTR_RO(Rcard, offset); The address of this item relative to the start of machine memory or the file or protocol buffer that normally contains it. R_ATTR_RO(Rcard, bitoffset); The offset in bits of this item relative to the low order bit of the item that contains it, if any. Value Description Information: Most value descriptor attributes are delegated one more level to a ValueDescriptor; some can be overridden here if necessary. R_ATTR RO(Rvalue, defaultValue); The item's default value, if any. The default value's descriptor is the descriptor used for all instances of this item. R FUNC_GET(R ValueDscr&, defaultDscr); The descriptor of the default value. R_ATTR_RW(RBool, msbFirst); Byte ordering. R_ATTR_RW_RC(R_Base, itemValueList); R_FUNC_GET(R_Base *, valueList); A local value list that can override the one in the descriptor. R_ATTR_RW(RCard, itemsize); A local override for size; either in bits or bytes depending on whether the item is a bitfield or a string. R_FUNC_GET(RCard, minsize); R_FUNC_GET(RCard, maxsize); R_FUNC_GET(RCard, packedSize); Reading and Writing: SI_RemoteItem contains operations for reading and writing the item on a remote machine, however these are overridden in the protocol-specific subclasses. These operations are incorporated to SI_ModelItem because this is the class an SI_AppItem refers to. There is no reason why SI_AppItem should have to treat remote items and database items differently---for example, some machines may be able to report their own serial numbers, while others may have serial numbers only on the nameplate and in the customer database. Note that the remote access operations take an SI_AppItem argument; this is the application item on behalf of which the work is being done. All operations return immediately, if the SI_AppItem is marked's "sbusy" a callback method is invoked when the work is actually done.
R_FUNC_GET_IS(RBool, readOnly, rFalse);
R_FUNC_GET_IS(RBool, isRemote, rFalse);
true if the service is actually
contained on a remote machine. This
can be used as a hint to warn the
user that performing the read or
write may take some time.
virtual RBool updateParentNewValue(SI_AppItem *,
RValue const &);
Update the appItem's parent's
newValue if necessary
virtual RBool updateChildrenNewValue(SI_AppItem *,
RValue const &);
Update the appItem's childrens'
newValue if necessary
virtual RBool updateParentCurrentValue(SI_AppItem *,
RValue const &);
Update the appItem's parent's
currentValue if necessary
virtual RBool updateChildrenCurrentValue (SI_AppItem
*, RValue const &);
Update the appItem's childrens'
currentValue if necessary
virtual void readOrEnqueue(sI_AppItem *app, RBool
mayQueue);
virtual void writeOrEnqueue (SI_AppItem *app,
RValue const &v, RBool
mayQueue);
read or write the AppItem's current
value. If isRemote() and mayQueue are
both true, the operation will
actually be queued.
virtual void readNotify (SI_AppItem *app, RValue
const &v, R_Symbol
*status);
virtual void writeNotify (SI_AppItem *app, RValue
const &v, R_Symbol
*status);
Notify the application item that a
value has been read or written, with
the appropriate status (null means
that all went well). This is what
actually stores the value in the
AppItem.
virtual void readEnqueue(SI_AppItem *app);
virtual void writeEnqueue(sI_AppItem *app, RValue
const &v);
Make a queue entry.
virtual void readValue(SI_AppItem *app);
virtual void writeValue(SI_AppItem *app, RValue
const &v);
Actually perform the read or write,
and notify the AppItem accordingly.
May be called from a queue entry.
The default is for readValue to
return the ModelItem's defaultValue,
and for writeValue to notify the
AppItem that the value has been
written.
virtual Rcard readValueFromBuffer (SI_AppItem *app,
R_Buffer const
&buf, Rcard
buf_addr = 0,
RCard hdr_size =
0);
virtual RCard writeValueIntoBuffer (SI#AppItem *app,
RValue const &v,
R_Buffer &buf,
Rcard buf_addr =
0, RCard hdr_size
= 0);
Perform the read or write on a
buffer, and notify the AppItem.
The buf_addr parameter is the
starting address of the {.backslash.em
buffer} relative to the
machine's memory location zero;
hdr_size is the location in the
buffer corresponding to
buf_addr, less any protocol
header information.
Initialization:
virtual void initAppItem(class SI_AppItem *,
RValue&) {};
Called when an SI_AppItem is created,
in case the AppItem's current value
needs to be initialized. The routine
is given direct access to the current
value.
2.3.4. SI_RemoteItem Class SI_RemoteItem is the parent class for those service items actually performed by, stored in, or retrieved from a remote machine. This class represents the actual memory location for a memory-based service item, this class also contains information about individual bits, if necessary. If a remote machine has contents, this class gives individual names and descriptions to the components in the form of a data structure. Arrays of identical items have only one component. class SI_RemoteItem: public SI_ModelItem { R_ABSTRACT(SI_RemoteItem, SI_ModelItem); public: R_ATTR_GET_IS(RBool, isRemote, rTrue); R_ATTR_RW(RBool, readOnly); Constructors: SI_RemoteItem(R_Base const &o); SI_RemoteItem(R_Symbol &nm, RValue const &dflt, Service *prnt=0). 2.3.5. SI_MemoryItem Class The SI_MemoryItem class represents locations in a memory on a remote machine. As described in the background section, some remote machines may provide direct access to the remote machine memory. class SI_MemoryItem: public SI_RemoteItem { R_CONCRETE(SI_MemoryItem, SI_RemoteItem); public: Attributes: R_FUNC_GET_IS(RCard, start, address()); starting address. Reading and Writing: virtual RBool updateChildrenNewValue(SI_AppItem *, RValue const &); virtual RBool updateChildrenCurrentValue(SI_AppItem *, RValue const &); Constructors: R_COPY_CONSTRUCTOR SI_MemoryItem(R_Base const &o); SI_MemoryItem (R_Symbol &nm, RValue const &dflt, RCard addr=0, Service *prnt=0); SI_MemoryItem (R_Symbol &nm, RValue const &dflt, RCard byteAddr, RCard bitAddr, Service *prnt=0). 2.3.6. SI_BitfieldItem Class The SI_BitfieldItem class represents a bitfield within an SI_MemoryItem that contains it. The bit number is relative to the low-order bit of the containing memory item, which in turn may be up to 32 bits long. It is up to the default value's descriptor to specify the size (packedSize) of the bitfield. class SI_BitfieldItem: public SI_MemoryItem { R_CONCRETE(SI_BitfieldItem, SI_RemoteItem); public: R_FUNC_GET(RCard, minsize); R FUNC GET(RCard, maxSize); R_FUNC_GET(RCard, packedSize); These have to be overridden in order to compute size correctly when itemSize is non-zero. virtual void readOrEnqueue(SI_AppItem *app, RBool mayQueue); virtual void writeOrEnqueue (SI_AppItem *app, RValue const &v, RBool mayQueue); virtual void readEnqueue(SI_AppItem *app); virtual void writeEnqueue (SI_AppItem *app, RValue const &v); virtual RBool updateParentNewValue (SI_AppItem *, RValue const &); virtual RBool updateParentCurrentValue (SI_AppItem *, RValue const &) 3. Communication Module 3.1. Overview The communication module 180 works with the machine module 170 to perform operations and access data on a remote machine 90, in accordance with requests made by executing the "readRequest" and "newValueSet" operations on instances of class SI_AppItem. The objective of the communication module 170, located in the core layer 190 in FIG. 2, is to provide a programming interface for carrying out an interaction, called a "communication session," between the computer system 1 running the remote service application program (e.g. 100, 110, 120, 130 in the Application Layer 140 of FIG. 2) and some remote machine 10. The implementation of this programming interface is contained in subclasses of the basic communication classes, the subclasses being located in the interface layer 260 of FIG. 2. A preferred embodiment of the present invention uses a single programming interface, defined in the communication module 170, for all kinds of remote machines. The subclasses in Interface Layer 260 provide implementations for that programming interface suitable for interacting with particular kinds of remote machines. In a preferred embodiment of the present invention, the session class hierarchies consists of the following (note indentation denotes inheritance):
SI_DeviceCallBack
SI_CommunicationSession
SI_BufferedSession buffered session
SI_MemorySession memory based session
SI_256BytesSession 256bytes per call
session
SI_CopierSession program based session
SI_UnBufferedSession unbuffered session
SI_DBSession data base session
SI_CustAccessSession customer data
base access
SI_HistorySession history db
TI_TaskItem
TI_CommunicationItem communication task item
TI_MemoryItem memory based task item
TI_ProgramItem program based task
item
TI_HistoryItem data base task item
3.2. Detailed Description The SI_DeviceCallBack class contains a set of abstract programming interfaces for asynchronous communication between the remote service application and an external process, communication device, or remote machine. Since such an asynchronous input or output operation may require some time to complete, the application merely issues the request and continues to process user interface events. When the operation has been completed, the device driver will "call back" the application using the "connectDone" operation. "SI_CommunicationSession" is the abstract base class for all sessions, i.e. interactions with remote machines. There are two subclasses of SI_CommunicationSession: buffered and unbuffered. Buffered sessions (SI_BufferedSession and its subclasses) handle communications using a protocol that requires data to be transmitted and received in blocks, possibly including a header that contains protocol information. The data and header are then stored in a buffer prior to being sent, or after being received. The SI_BufferedSession contains the code required to move data between the buffer and the remote service application's internal data structures (contained in the application state 600, 810), using information in the machine model 630, 860 to specify the format of the data and its location within the buffer. SI_MemorySession, SI.sub.-- 256BytesSession, and SI_CopierSession are illustrative subclasses of SI_CommunicationSession which provide communication specific information for different remote machines. Unbuffered sessions (SI_UnbufferedSession and its subclasses) are used as an interface to entities, such as database servers or file servers, for which an application programming interface is provided by some operating system or library, that supports direct data transfers between the remote machine and the data in the application state 600, 810, e.g. by remote procedure call. SI_DBSession, SI_CustAccessSession, and SI_HistorySession are illustrative subclasses of SI_UnbufferedSession which provide communication specific information for different remote databases, etc. TI_TaskItems are used to break a communication session into a sequence of steps. FIG. 6 illustrates a typical session between a computer system 1 and a remote machine 90, 1110. A session 1000 contains a local read queue 1040 and a local write queue 1070, a virtual batching operation to execute requested operations on service items, and a virtual mapping operation to translate data between the external format used by the remote machine 90, 1110 and the computer system 1. The queues 1040 and 1070 are instances of SC_Queue, and contain instances 1050, 1060, 1080, 1090 of SI_QueueItem. Each SI_QueueItem, e.g. 1050 or 1080, contains a Boolean attribute "read" which is true for read requests 1050 and false for write requests 1080, an Rvalue attribute "value" which is undefined for read requests 1050 and contains the value to be written for write requests 1080, and an attribute "appItem" containing a reference to the SI_AppItem 1051, 1081 that represents the remote service to be operated upon. The SI_AppItem 1051, 1081 in turn refers to an instance 1052, 1082 of a subclass of SI_ModelItem that describes the data type, size, and location of the service. The session 1000 also has an attribute "callSchedule" that refers to a list 1010 of instances 1020, 1030 of some subclass of class TI_TaskItem. The subclass used is specific to the type of remote machine 1110 being communicated with. The call schedule list determines the order of operations to be done in a single call, and may be used for optimization, for example by re-ordering references to items 920, 930 in a remote facsimile machine's memory 910 in order to minimize the number of separate calls required to access them, in a facsimile machine that transfers a maximum 256 consecutive bytes per call. When the session 1000 is initialized, it requests a device manager object for an instance 1100 of a subclass of CM_CommunicationDevice that provides an interface to the communication device 70 by which the application program can communicate with a remote machine 90, 1110. The request made by session 1000 includes a specification of the protocol to be used in communicating with the remote machine 90, 1110; the device manager returns an instance 1100 of a device 70 that can use the requested protocol and is not already in use. When the remote service application requests that the queued-up communication requests be executed, typically in response to the user, the session 1000 iterates through its read queue 1040 and write queue 1070 to construct a callSchedule 1010. If necessary, it accumulates data to be written in a buffer using the virtual function "putValueIntoBuffer" of each corresponding SI_ModelItem 1082 to translate the data from its internal format in the SI_QueueItem 1080 to its external representation and store it in the buffer. The session 1000 then iterates through the call schedule 1010 and tells each task item 1020, 1030 to perform its operation. Each task item 1020, 1030 in turn tells session 1000 what operation to perform on remote machine 1110. Session 1000 then uses the device controller 1100 (referred to above) to perform the low level read or write operation with remote machine 1110. If necessary, it then uses the virtual function "getValueFromBuffer" of each the corresponding SI_ModelItem 1052 to extract the data from the buffer, translate it from external to internal representation, and store it in the SI_AppItem 1051 using the SI_AppItem 1051's "currentValueSet" operation. 3.3. Defining New Session Types As can be seen, the application programmer may readily define subclasses to the class SI_CommunicationSession in order to describe new ways of communicating with any new remote machine, database, or other external resource. Any application linked with a library containing the code for such a subclass will be able to make use of the new session type at runtime; such applications need not be recompiled, but only relinked. By putting the new classes in a dynamic link library (DLL), suitably-constructed applications can make use of new session types even after having been linked and distributed to users. 4. Communication Device Interface 4.1. Overview A communication device 70, (device) is a computer system peripheral such as a modem, through which remote service applications communicate with a remote machine. In a preferred embodiment of the present invention, a communication device 70 is represented within an application program as an instance 1100 of a subclass of class CM_CommunicationDevice. In a preferred embodiment of the present invention, the device class hierarchies consist of the following (note indentation denotes inheritance):
CM_CommunicationDevice
CM_Modem modem
CM_CCA Communication adapter for a FAX
CM_USACCA . . . adapter for 256-byte protocol
CM_LADP Line adapter/multiplexer
CM_DBACESS device for a database
CM_DeviceManager
4.2. Detailed Description The class CM_CommunicationDevice encapsulates all attributes and operations relevant not only to physical communication devices such as modems, but also application programming interfaces to such things as databases and database servers. An instance of CM_CommunicationDevice has attributes that contain the communication address of a remote machine, a list of protocol restrictions specific for the remote machine, and virtual functions "initDevice," "connect," "read," "write," and "disconnect" which provide a generic programming interfaces for all devices. The class CM_CCA is a preferred embodiment of a class that defines all attributes and operations that are applicable to communication controller adapters used to communicate with a remote facsimile machine. A CCA (Communication Control Adapter) is one embodiment of a special-purpose fax modem that can access the internal memory of the remote machine. The CM USACCA class defines a preferred embodiment of how to access/modify a facsimile machine that uses a 256-byte protocol. The class CM_LADP is a preferred embodiment of a class used for communication with copiers. This class uses an instance of CM_Modem as a communication channel. The LADP (Line Adapter) is one embodiment of a combination modem and multiplexer that interfaces between a telephone line and up to five copiers. The class CM_DBACESS is a preferred embodiment of a class that allows the remote service application to view a database as if it were a remote device. This class has a handle to a database and uses operations defined by a database interface library to access and update data items in the database. The class CM_DeviceManager is a preferred embodiment of class for a global object the function of which is to keep track of all of the communication devices 70 attached to a computer system 1, their status (idle or busy), and the protocols which they support. A communication session object 1000 requests a device object 1100 from the device manager, which returns a reference to a device 1100 that is currently idle and that is capable of handling the communication protocol required by remote machine 90, 1110. 4.3. Adding New Devices As can be seen, the application programmer may readily define subclasses to the class CM_CommunicationDevice in order to define a protocol for any new remote device, database, or other external resource. Any application linked with a library containing the code for such a subclass will be able to make use of the new protocol at runtime; such applications need not be recompiled, but only relinked. By putting the new classes in a dynamic link library (DLL), suitably-constructed applications can make use of new protocols even after being linked and distributed to users. CONCLUSION In the foregoing specification, the invention has been described with reference to a specific exemplary embodiment thereof. Many changes, modifications, and additional extensions to the framework facilitating the modeling of remote devices are readily envisioned and are included within other embodiments of the present invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than in a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.
|
Same subclass Same class Consider this |
||||||||||