This section presents the most important definitions in the modulesTyp,Ftyp andAtyp. The moduleEx, which contains a couple of generally usable exception definitions, does not need to be explicitly discussed here. It has to be noted that APMT defines sequences for many of the types that are presented in the following. The name of the sequence is simply the name of the component type with a trailings.
7.4.1 Basic Types
The module Typ contains useful definitions like Date,Percentage,Fraction and Rect-angle. Important for the remainder of this thesis are the definitions for the stringified object referenceStringRef and the name of an interface:
typedef string StringRef;
typedef string InfIdent;
The moduleTyp also contains the two basic types used for event notification with the CORBA event service:
typedef string EventKey;
struct Event { EventKey key;
Time::TimeT time;
any data;
};
Component Module Remark
All Components ::Typ basic type definitions that are useful for all other APMT definitions ::Ftyp flagged types
::Ex basic set of exceptions that can be used by all APMT definititions ::Atyp basic architecture specific types
Terminal ::Tc all terminal control interfaces that are visible to applications ::Ta terminal administration interfaces (not defined)
::Ts basic terminal server types and the terminal server base interface ::TclTk Tcl/Tk applet handler definitions
::Java Java applet handler definitions
Application Pool ::Pc all application pool control interfaces visible to applications and terminals ::Pa pool administration interfaces (not defined)
::App application interfaces
::Put base interface for application pool utilities ::Pac participation control interfaces
User Agent Pool ::Uap user agent pool and user agent interfaces
Table 7.1. APMT platform architecture modules.
The event key is a string that uniquely identifies an event within the APMT definitions. An event key is defined as a string constant in the interface to which the event is related:
const string EventNameEventK = "module:interface:EventName";
An event key is used by event consumers to register for the generation and reception of specific events, and by the event producer to mark the events that it generates, as can be seen in the event data structure. Besides the event key, the event data structure contains a time stamp and event specific data in form of an any type. The actual type used for event specific data is defined in the same interface as the event key, and is often a structure or a typedef:
struct EventNameEventD { .... };
typedef type EventNameEventD;
For the moment, APMT uses only untyped event communication, which means that the event data structure is communicated in form of anany type to event consumers. Event consumers need to be able to associate the events that they receive with the objects that created them. In APMT, event channels are always owned by event producers, which allows event consumers to associate a separate CosEventComm::PushConsumer or CosEventComm::PullCon-sumer interface instance with every event producer, and consequently identify the producer of an event via the interface through which the event was communicated.
The moduleFtyp contains definitions of flagged types, i.e., structures that contain a value and a boolean flag that tells if the value is valid. Flagged types are used to pass optional param-eters in operations. The following definition shows for instance a flagged string:
struct StringF { boolean flag;
string value;
};
Flagged types are denoted by a trailingF in the type name. Not only basic CORBA types, but also many APMT types have a flagged counterpart.
7.4.2 Advanced Types
The module Atyp contains definitions that express architecture concepts. Internet hostnames are defined as strings, and the major architecture components terminal, application pool and user agent server are defined as hostnames:
typedef string HostName;
typedef HostName TerminalName;
typedef HostName PoolName;
typedef HostName UapName;
The terminal name identifies the host on which an object implementing the Tc::Terminal interfaces is instantiated. The same is true for the application pool name, which identifies the host on which an implementation of the Pc::Pool interface can be accessed, and the user agent pool name, which identifies the host on which an implementation of the Uap::Access interface can be accessed. The hostname alone is not sufficient to construct an IIOP IOR. What is needed in addition is a port number and an object key that are reserved for APMT. As for now the IIOP standard does not address the issue of standard object keys. Object keys are con-sidered to be opaque values that an ORB may format as it wishes, with the consequence that ORB’s tend to encapsulate their proprietary object reference within the object key of an IIOP IOR. However, there is a clear need for standard object keys that allow clients to construct
IIOP IOR’s for certain objects from a hostname and a port number, and it is assumed that future versions of the CORBA standard support this by allowing implementations to choose standard values for the object key of their IIOP IOR reference. If it should turn out that CORBA will not support this there is the less elegant alternative to design a bootstrapping ser-vice on top of TCP similar to the Internet finger serser-vice [Zimm91] that allows clients of termi-nals, application pools and user agent pools to retrieve an initial object reference. The need to construct IIOP IOR’s from hostnames and port numbers disappears as soon as they can be retrieved via a global directory service.
A user name is simply a string. User names do not need to be unique. They become unique in combination with the name of the user agent pool that houses the agent of the user:
typedef string UserName;
struct User { UapName home;
UserName name;
};
Users that do not have access to a public user agent pool may run a private one on their multi-media terminal. TheUapName in their identifier will then be identical to the name of the termi-nal that they are normally using. The user identifier may be written as a string similar to an E-mail address:
UserName@UapName
This form will for instance be used in graphical user interfaces, or in general whenever the identifier of a user is communicated via other means than CORBA operations.
The moduleAtyp defines two identifiers that are used to identify applications and content on application pools:
typedef string ApplicationName;
typedef string TitleName;
The application name is a preferably unique identifier for a certain application. Users start applications with an application name whenever they are interested in application logic. They use title names whenever they are interested in some content rather than in the application logic that mediates this content. They use both an application and a title name whenever they want to view some content with a specific application. In this case it may happen that a given combination of application and content is invalid. Since title names associate application logic with data they are more important than application names that can only identify functionality.
An application pool assigns a locally unique session identifier to every running application.
This session identifier together with the name of the application pool represents a unique ses-sion address:
typedef unsigned long SessionId;
struct SessionAddress { PoolName paddr;
SessionId id;
};
The initiator of a session may reserve a session identifier prior to application startup and dis-tribute it together with the application pool name to other interested users. These users can then join the session once it is active.
An application session can be in the statesIDLE,ACTIVE andEXITING. It isIDLE until the application pool control has initialized the application. Once it is initialized it is in state ACTIVE. It enters stateEXITING when it is asked to release its resources and to terminate:
enum SessionState {IDLE,ACTIVE,EXITING};
The moduleAtyp further contains the definition of the three important information structures UserRecord,ParticipantRecord andSessionDescription. The user record contains the user identifier, his E-mail address, the address of his Web page, and a general information field:
struct UserRecord{
UapName home;
UserName name;
Url homepage;
Email mailaddr;
string<1000> info;
};
The participant record consists of a participant identifier, a user record, a terminal name and a timestamp taken at the moment when the user joined the session. The session description finally consists of the session address, the application name, the optional title name, the session state, the session start time and a list of participant records:
struct SessionDescription{
PoolName pn;
SessionId id;
ApplicationName an;
TitleNameF tn;
SessionState state;
ParticipantRecords prs;
Typ::Date start;
};
The session description is available to every session participant, i.e., it can be accessed inde-pendently from the application via the control panel. Applications are likely to supplement the APMT session description with application and session specific information that can only be accessed via the application itself.