User Interface in Confederations in the Large | Managing Globally with Information Technology

Any dynamically changeable network of autonomous components can be used efficiently only when it contains a programmable, easily modifiable user interface supporting system (UC). It should support integrated interface to all components communicating with any user. WWW browsers have many good properties for such a purpose.

New utilities based on XML, especially the XSLT, allow to transform message formats, to integrate messages from various autonomous components into one message for screen, and vice versa to decompose the messages from the screen into several messages to be sent to several autonomous components. It allows designing a transparent user interface hiding the internal structure of the confederation if we use the attitude shown in Figure 6.

click to expand
Figure 6: Parallel user access to multiple components

The user interface is to be implemented as a permanent service (i.e., autonomous component) transforming HTML messages from presentation software (browser) into n-tuples of messages in XML dialects (see Figure 4). The XML messages are sent to the gates of destination components and vice versa. HTML messages for the browser are composed from answers from several components. XSLT is a powerful tool working on syntactic trees specified by XML. We do not sufficiently understand its power yet. The knowledge of formal language theory is advantageous, but not yet widely used.

The XSLT based components can be used to enhance the modifiability and reusability of components. Let us discuss the problem:

The gates G1, G2, and G3 in Figure 6 should provide the full functionality provided by the corresponding components. If a component C is designed in the object-oriented way, its gate G tends to provide an object-oriented interface — i.e., (remote) method invocations. If C is a database system, the language of G will be probably a modification of a 4GL language. In other words, the communication partner must know a lot of information on the structure of the component to obtain the required service. Such a requirement is unrealistic since the set of collaborating partners of any component can vary and is unknown prior to development of the component. We say that gates providing full public functionality are basic ports (or basic gates). Any basic port provides all the services that the component may offer. The direct use of the basic ports has some drawbacks:

The use of basic ports is too complex for many users due to the too fine granularity of their commands. Specific groups of users need a specific (often small) set of services expressed in the terms of user problem domain. The users therefore need a specific problem-oriented messages formulated in a language in which the user is familiar.
The basic port discloses too much information about the architecture of the component. For example, it is usually necessary to know that such a component is a relational database or an object-oriented application. It limits the possibility to replace the component by another one having different implementation. The main problem is that the change of the implementation philosophy can imply changes in all the components (partners) possibly communicating with the given one. As noted above, it is a quite difficult task, as the partners need not be known during the system development phase.
The basic ports tend to use fine grain commands. If they are directly used, it increases the effort needed to design a dialog with the component. It also often increases the load of the communication infrastructure.

We must cope with the dilemma that we must somehow use the basic port, but we are not happy with it. The way out can be based on the following observation. The commands for the basic port of a component C can be viewed as elements of a "quite simple" implicit language L_C (a high level analogy of assembly languages).

As pointed out above it is required that the messages from a sender can be in a sender specific language L. L should be able to formulate the commands or queries in a form specifying 'what' to do rather than 'how' to do it (L is problem domain oriented). The syntax and semantics of L should fit the needs, knowledge, and habits of senders. The way to implement the requirement is to direct the messages from sender to a new autonomous component transforming the messages in L into (sequences of) messages in L_C and sending the messages in L_C to the basic port of C. We can view any message M in L as a command or a query for the component C generated by M. The message in L must be translated into "program" in L_C or interpreted via sequences of commands in L_C. The front-end gate can be a new component (Figure 7) used as a front-end processor of C. It is not difficult to see that front-end gate components (FEC) have functions quite similar to the functions of the user component in Figure 6.

Figure 7: The extended component scheme

Any component can have more than one FEC. The development of FEC's should be as easy as possible as there can be many FEC's and they should be easily modifiable.

Now we can use the results of the theory of syntax directed translation and compilation and syntax directed interpretation (Aho and Ullman 1972, 1973, Bison system). The FEC can have the following structure (see Figure 7):

The data specifying the syntax directed transformation — i.e., syntax and associated semantic symbols. We can use some compiler writing system. It requires, however, a specific knowledge. It is open whether we should use a dialect of XML, something like XSLT, for this purpose. Simple transformations can be obviously defined via XSLT. The use of XML and XML-based tools could broaden the number of people able to design new FEC's.
Outputs of the FEC are external messages in some problem-oriented language L (e.g., in a dialect of L). The sequences of commands in L_C can be viewed as the interpretation of the external messages in L.

The FEC can translate sequences of messages in L_C into messages in L. The techniques known from front-ends of syntax directed compilers could be used.

The open question is whether the XSLT systems are powerful enough to fully cope with such problems.

Our discussion indicates it is meaningful to distinguish three types of autonomous components:

Application autonomous components (AAC) providing the main functionality of the system.
Front-end gate components (FEC) enhancing the middleware services.
User interface components (UC).

All the components are standard peers of the network forming a software confederation. They differ only in the functions they provide.

The use of syntax-directed FEC could substantially simplify the design and the modifications of the confederated systems. It supports the generation of multiple interfaces of a component. The interfaces can be quite declarative (i.e., problem oriented). The use of FEC implies a greater freedom in modifications of components (there is a greater chance that a modification of a component does not influence "declarative" front-end interface) and simplifies the design of the communication. The use of the syntax directed (compiler writing) techniques substantially simplifies the development of the FEC's. It is believed that the implementation of syntax-directed FEC in the YACC/Bison style could be specified via a new XML dialect (i.e., in XML). A good candidate can be a system combining the philosophy of XSLT and compiler writing systems. The advantages and/or limits of such a solution are the topics of future research.

It is quite easy to add log facilities mentioned above to the functions of FEC; it provides one the main functions of the Post discussed in the section Software Confederations in the Small. This is a very useful tool for system maintenance. Any problems analysis starts from the analysis of log files. Properly used statistics can indicate whether some component is in the "worn out" stage, i.e., if it should be rewritten.