3tier_banner.gif Main Index  PREV  NEXT

Valid HTML 4.01!   Valid CSS!

How UNIFACE supports the 3 tier structure

Component Types

The 3 Tier architecture in UNIFACE involves several different types of component.

A typical arrangement of these component types is shown in figure 1:

Figure 1 - UNIFACE component types


Within the sample software which accompanies this document there are no examples of Entity Services as I did not have good reason to employ them. An example of a Custom Service is my Audit Object which is activated each time the database is changed - this will write the 'before' and 'after' details of each change to an audit entity.

XML Streams

Communication between Session Services and the database is via the standard I/O operations in the <read>, <write> and <delete> triggers. If Entity (Object) Services are being employed then the standard I/O operations are automatically routed through the relevant service by the UNIFACE kernel.

Communication between Forms and Session Services is via a set of standard operations which pass XML streams between the two components. An XML stream is a data string which is constructed to the XML standard set by the World Wide Web Consortium.

An XML stream contains data in the form of elements. An element can contain data, other elements, or a combination of data and elements. UNIFACE entities are represented as XML elements in XML streams. The fields of an entity are represented as child elements of the entity's element. Inner entities are represented as child elements of the outer entity. An XML stream can contain the data for any number of occurrences of any number of entities.

XML streams do not make a distinction between database and non-database fields, or between fields and entities defined in a component or in an application model.

The structure of an XML stream is governed by a Document Type Definition (DTD). XML streams can be accessed in UNIFACE by means of the following commands:

The DTDmapping option allows for differences in element names between the XML stream and the component.

Document Type Definitions (DTDs)

Document Type Definitions (DTDs) are maintained using the DTD Editor which can be accessed from within the Model editor. From the pulldown menu within the Model editor select: GoTo - DTDs. After selecting a DTD name the DTD Wizard allows you to quickly identify the entities and fields within the XML stream.

Elements in an XML stream are either mapped to entities or fields painted in a UNIFACE component. Entity elements are mapped to UNIFACE entities, and field elements are mapped to UNIFACE fields. If there is a difference between the element name in the XML stream and the element name in the UNIFACE component this can be specified in the default mapping option within the DTD.

If the XML stream is required to contain processing information, such as is required to reconnect occurrences to the database, then the relevant attributes must be included in the DTD.

If the DTD contains more than one entity then the relationship between those entities, either side-by-side (siblings) or in a parent/child hierarchy, must be duplicated in the component which is using that DTD otherwise no data can be transferred.

Processing Information

Processing information is not data, it is information about data - whether data is new or already stored in a database, or whether data is valid or nonvalid.

UNIFACE can include processing information in the XML stream, describing the modification and validation status of the occurrences, and also enabling reconnection of the data to its source. These processing attributes are generated automatically by UNIFACE provided that they have been specified in the DTD used by the stream. These attributes are:

The Status, Id, Checksum and Valerr attributes are available for each occurrence. The Valerr attribute is available for each field.

The Status, Id and Checksum attributes are required if the retrieve/reconnect statement is going to be used to reconnect occurrences to the database.

The Proc functions $occcrc, $occstatus, $occproperties and $fieldproperties can be used to access processing information loaded from an XML stream.

DTD Mapping

UNIFACE maps field values to XML elements in the stream using a combination of the following mapping methods:

DTD mapping lists map the values of elements in a DTD stream to fields on a component.

Default DTD mapping lists can be defined in the DTD Editor. DTD mapping lists can also be defined in Proc, for use in the Proc statements xmlload and xmlsave.

DTD mapping lists are UNIFACE associative lists. Each list item has the following syntax:



ElementName - is the name of an element in the DTD. ElementName is case-sensitive.

TargetName - is the name of a field or entity. The fields or entities do not have to be present on the target component. Values that cannot be mapped to a painted field are ignored. TargetName is not case-sensitive.

These mapping techniques work in parallel, with local mapping overriding all other mappings for a given element or field, and name matching only being applied to those elements for which no other mapping is defined.

Disconnected Record Sets

In a three-tier architecture, it is the responsibility of the data layer to communicate with the underlying databases. The other application tiers should not communicate directly with the databases. This implies that:

Data which has been passed to the Presentation layer in an XML stream, modified, then returned to the Business layer can only be reconnected to the database provided that the relevant processing information is contained within the XML stream. This will help determine if occurrences are to be inserted, modified or deleted.

Two Application Models

As has been stated in the previous section the Presentation layer components should use non-database entities and should avoid using database entities. Data is provided in the form of disconnected record sets which are retrieved from and returned to Business layer components in the form of XML streams.

Non-database entities can be defined in the following ways:

The disadvantage of using existing entities or entity subtypes is that you cannot alter their structure - you cannot add fields, remove fields or rename fields. You cannot merge entities or split entities, or define entities that do not actually exist. You cannot take a complex physical structure and simplify it for use by the Presentation layer.

If you are going to create new entities just for the Presentation layer it makes sense not to mix them up with the Business layer entities but to keep them in a separate application model. This is what I call the Presentation Application Model or PAM. Any differences between entity and field names between the Business Application Model (BAM) and the Presentation Application Model (PAM) can be dealt with by defining default mapping options in the DTD.

In my methodology I prefer to use a separate application model for the Presentation layer because of the greater flexibility it gives me. A typical example of this is where an entity contains a foreign key to another entity, and in my presentation layer component I need to display fields from both entities. By using a totally separate application model I am able to merge fields from a foreign entity with those of the main entity - it is only the business layer component (session service) that needs to know that multiple entities are involved.

copyright.gif http://www.tonymarston.net