In UHR we have two types of parts - container and leaf parts. These allow organizing a system of parts into a tree. We have two types of DK - container and leaf DK. Parts may or may not be parameter driven. If they are, they are provided with a Param by the DK Layer. See Definitions for a quick review of the terms used here.
The job of the DK Layer is to handle the relationship between two essential elements of UHR, DK and parts. The relationship is "DK varies the behavior of reusable parts". Thus this layer manages everything associated with that relationship. This includes:
We could call this the DK layer, but its responsibility is not just DK - it's the relationship between DK and parts, which we summarize with "Parameter Driven".
The goal of Container DK is to define everything needed to create a container at runtime. If this is the root container, then the root Container DK is the entry point to defining the entire system, and is needed to start the system.
The format for Container DK is best explained by this example with two parts:
<?xml version="1.0" ?>
<container>
<parts>
<part>
<name>LogonWindow</name>
<type>uhr.parts.ui.Window</type>
</part>
<part>
<name>SecurityDataReader</name>
<type>uhr.parts.io.FileReader</type>
<dk>url for dk here</dk>
<abilities>service, hidden</abilities>
</part>
</parts>
<connections>
<!--Type, MessageName, Sender and/or Receiver-->
INTEREST_IN, GetUserData, SecurityDataReader;
SIGNAL_OUT, WindowOpened, LogonWindow;
DIRECT, GetSecurityLevel, LogonWindow, SecurityDataReader;
SERVICE_NEED, GetDefaultWindowPosition, LogonWindow;
</connections>
<start_commands>
<!---PartName, Command-->
SecurityDataReader, Init;
LogonWindow, Start;
</start_commands>
</container>
As you can see, container DK has three sections - parts, connections and start_commands. These are in the logical order that the container needs. When a container is started, first it populates itself with the listed parts. Then it hooks up their messages with the connections. Then it calls the start commands, if any.
The <parts> section list the parts in the container. The part names must be unique within the container. By convention and for readability part names start with an upper case letter, and use additional uppercase letters rather than underscores to indicate words. Part <name> and <type> are required. Part <dk> is optional. A part may not be parameter driven, and so not need dk. Or a part may be parameter driven, and its dk can be found automatically by knowing the part name and what container it's in. Part <abilities> is optional. It contains optional boolean properties (a part has an ability or not) for nodes, which are not discussed here.
The <connections> section contains all the connections needed to hookup the parts with their message input and output. A connection is just like a wire between devices. Each connection is defined by the connection Type, MessageName, and the part name for the MessageSender and/or MessageReceiver. See MessageRouter for detailed info on connections. This section is optional if no connections or messages are not used.
The <start_commands> section has the commands that are called after the parts have been created, provided with their DK, and had their message hooked up. Start commands are the last thing done when a contatner is started. Thus the parts are all ready to work. The commands allow the designer to have specific parts start doing certain things to get the container going. Parts receiving a command must implement the StateCommandable interface. The root container will usually have one or more start commands. Other containers usually have no start commands, because when a container receives its first message it is automatically started. This section is optional.
Although this layer has information about parts, connections and commands, it does not actually use this data to do the work implied by the DK. Instead it gives this DK to parts that perform the work. For example other layer parts create parts, hookup parts, and call commands on parts.
The goal of Leaf DK is to define how a leaf part behaves in a particular reuse case. Since leaf parts can have many widely varying responsibilities, their DK can vary widely. Thus leaf DK has a very flexible format, as shown by these two examples:
The first could be the DK for a visual part like a button, panel or label.
<?xml version="1.0" ?>
<leaf>
<Color>red</Color>
<Size>
<Width>100</Width>
<Height>50</Height>
</Size>
</leaf>
The second could be the DK for a data storage and retrival part. It would read further DK out of the database itself for its own further initialization. Only the DK we prefer not to put in that database is here.
<!xml version="1.0"?>
<leaf>
<Server>sunny.com</Server>
<Database>world/africa</Database>
<LockPolicy>
<Timeout>2000</Timeout>
<Exclusive>
<Admin>TomD</Admin>
<Shutdown>BetsyA</Shutdown>
</Exclusive>
<TimeoutAlert>SteveA@somewhere.com</TimeoutAlert>
</LockPolicy>
</leaf>
Note that within an element, subelements must have unique tag names. An element cannot have both character data and subelements. These simple rules allow parsing any leaf or container DK text into the same Param object.
The above XML is designed to be very easy to manually read and edit. Currently we are using a very lightweight, feature limited parser. It supports only the XML aspects shown in these examples. We expect to use a third party parser as needs arise and they become more appropriate for our needs. See SimpleParserXML.
The part designer needs to express what DK is allowed for a part. An XML DTD can define what element structure is allowed in a document. This covers only the tag names and element arrangement. There are some issues here:
As of 11/24/99, XML DTDs do not support valid character data definition at all. XML schemas are being introduced to rectify this problem and others, and DTDs will probably be abandoned once schemas are mature. Meanwhile, the above leaf DK format requires one DTD per type of leaf DK.
We shall see where all this leads. We might go with a different DK format that takes advantage of schemas or some other standard.
We could go with leaf DK tags that are the same for all leaf DK. However this prevents a DTD from validating the key data. The keys must still be validated somehow, which requires just as much information as a DTD. Thus we will feel fine about going with custom tags per leaf part for now, because a DTD can at least validate the key structure. Custom tags are also very readable. Each part has variable DK needs, so each part requires a different document type.