Open Issues

The CIO must take into account that in the case of confederations, there are few well established practices and generally accepted solutions. It is mainly due to the fact, that the concept of software confederation is so powerful that it does not require sophisticated methods beyond its basic principles. Nevertheless, the developers should be aware of the open issues. Let us give a short overview of them.

Configuration Management for Confederation

SWC is open and very dynamic. If it is formed by a large number of components, (it is now fortunately a rare case) something like configuration control must be implemented and used. However, until now, only ad hoc solutions have been found. Again, an optimal balance between flexibility and security must be found.

Transactions

This is a quite difficult problem. As the components can accept commands influencing real world some commands cannot be revoked (rolled back). The dynamic structure of the confederation implies that even in the case, that all the actions of a transaction can be rolled back, the control of the rolling back should be performed by no central authority but rather by the component initiating the transaction. Often it will be a user component (compare Rowe, 2002).

Moving and Cloning the Components

It is not difficult to move the components around the underlying computer network to work on different hosts to achieve a better performance of the system (response times or costs). It is even possible to clone components (i.e., to make copies of them) and to move the copies around to optimize the system behavior.

Similar tasks are solved in distributed database system when the system administrator must decide where the data and/or their replications should reside.

We did not find any theory and any satisfactory implementation of such an idea, allowing performing the optimization in a semi-automated way. We have no current satisfactory criteria function (Fisher et al., 2000).

Languages of Messages — XML

There can be tens and even hundreds of components in a large confederation. Many components can have a very complex interface. New components can be added quite easily. The functions of particular components can vary. It is therefore impractical to standardize all the message formats and to successfully use such standards. Message formats must be very flexible and specified by the parties involved in particular collaboration modes. The format agreements must be realized in a rather decentralized way. The idea is not to standardize formats, but to standardize a "metatool" for the format definition seems to be a very good idea, as well as its implementation in the Extensible Markup Language, XML. It is not clear, however, how to use the tool properly (for example, whose XML dialects are necessary).

A confederation providing the services of an information system should have the classical three-tier architecture: user interface, application logics provided by a network of components, and a data tier. We need different XML dialects for all three tiers:

1. The dialects for user interface (XSL and XSLT).

2. The application specific dialects for specific groups of activities (see e.g., ebXML, RIXML, GML) or the object-oriented command interface (SOAP, Simple Object-oriented Access Protocol, 2001). These dialects are used in the definition and construction of gates to application tiers. It is not clear what format is optimal. SOAP supports object-oriented attitude, but it is not clear whether it is too programming-oriented (and not enough application-oriented) and as such, not optimal for the partners of the given component. The use of SOAP can limit the modifiability and openness of the confederation, as it implies object-oriented architecture of the application tier, and it need not be true.

3. The data-oriented dialects like RDF (1999) for metadata definition; various query formats (XQL) see e.g., Pokorný (2000) and especially metadata-oriented formats like UDDI (Universal Description, Discovery, and Integration, 2001).

The present number of XML dialects induces the hesitation whether a new Babel will not appear (compare the problems of TeX). Should the definition of dialects be more centralized or at least coordinated? The messages in XML dialects can be interpreted as declarations/data definitions and/or programs. It is not clear when and why it is better to treat a message as a command and when as a meta-data. We believe that the XML dialects will be often used as programming languages (languages of commands) — especially in the case of the design of component gates allowing using component functions.

The communication between components is based on the exchange of texts in an appropriate language L that can evolve. Therefore, the components communicate like people in a human group. This is the situation forecast by Winograd and Flores (1986).

The collaboration of components is more complex than the merely simple exchange of messages. A multiparty discussion and/or complex coordination (workflow) process is often necessary. Like in the human society, the process can be implicit, i.e., based on the implicit knowledge of individual components how to react on particular input messages (stimuli), or explicit — controlled in an explicit way by a specific data structure (workflow specification) interpreted by a middleware service. It is open what attitude is more feasible.

Addressing Strategies and Dynamic Configuration Control

As mentioned above the communication of components should be in the language of a very complex syntax. The syntax of the messages can be used to identify the correct addressees. The proposal WSDL (Web Service Definition Language) can be used. The addressee can be any component able to understand the message, i.e., able to parse the syntax of the message to process it. This schema can be used to find the components all over the WWW. The chosen components form the system, which in turn exists only virtually. These issues must be solved:

• Can be such a schema implemented effectively enough?

• Can be the identification of the components robust enough (i.e., can be the identification of components in the sense of configuration control reliable enough)?

• Can the process of acceptance of new components be secure and to what degree it can be automated?

• Is SOAP a good solution for complex commands? Note that in databases, we use SQL or UDDI instead. It indicates that the question is relevant.

Components as Software Agents

The majority of tasks performed by a confederation must be implemented/supported by a 'team' (group) of components. It must be supported by appropriate tool allowing starting the cooperation of the components from the group. There are several possibilities:

1. The collaboration is implicit, i.e., organized because of the activities of the components without any explicit support of the middleware. Any component knows to what components send messages as a response to some particular message and the given history.

2. The identification of the components involved in the group are somewhat coded into the messages implicitly like in collaboration diagrams in UML (1999).

3. A negotiation strategy similar to the strategy of negotiation between software agents known from multi-agent theories (Weiss, 1999; Fisher et al., 2000) is used. Unfortunately, no effective implementation of the theories applicable in a confederation is known at present. It is unclear, whether the results valid for a multi-agent system can ever be used in a confederation, as the components differ from SW agents in the usual sense.

4. It is open how to control that a task was successfully finished and how to implement transactions for software agents. We can use results for distributed databases. However, it is unclear, whether known algorithms work successfully for components with complex activities.