Introduction

The last 15 years were impressive for the success of object-oriented (OO) software and OO methodology. The OO paradigm was so successful and has become a respected standard. A unified OO methodology known as UML (unified modeling language) was developed by OMG and included into successful CASE tools. The success of OO was so great that it has overshadowed cases when object-orientation is not the best technique to use. Examples are the integration of legacy systems as well as of third-party products providing permanent services. Such systems are used as black boxes. Such architecture becomes crucial for information systems in global world and for global management. The architecture is not properly supported by the standard OO paradigm formalized in UML.

It appears, but is not generally accepted, that OO is good for systems that are mainly sequential. These systems have been developed mainly from scratch (with the exception of the use of OO libraries) and as one logical unit for example, the developers have good knowledge about all the parts of the developed system or they can easily gain it; no large constituent parts of the system must be used as black boxes). The result is that the reusability of the object-oriented code is rather low (Finch, 1998). The number of cases when people must use a paradigm other than an object-oriented one is surprisingly large. This scenario occurs when information technology should support global activities or the cooperation between competing companies.

It is usually required and expected that company information systems should support all company activities. The company cooperates with many external subjects; the set of these subjects and the level of the cooperation with particular partners changes quickly. It is therefore not possible to have an inflexible company IS.

It seems reasonable to enable temporal groups of companies to build information systems supporting their cooperation needs and common activities. On the other hand, it is reasonable that information systems of the members of such groups (coalitions) should be insensitive to the environment changes and protected against the attacks of outsiders (e.g., hackers) on their systems and data.

The easiest way to complete this task is to implement interconnections of existing information systems of the cooperating companies. Access gates of the companies' information systems than can serve both as watchdogs against hacks and espionage and as data transformers (they e.g., can convert the communication protocols from the proprietary one to the public one—and vice versa).

The common feature of such systems is that they have the structure of a peer-to-peer (P2P) network of permanent services. We call such systems software confederations (SWC). We will show in what respect the SWC paradigm differs from the OO model and what challenges and promises for the management it offers.

Let us illustrate the essence of the problem on the typical phenomenon of the global economy, on the example of the purchasing coalition of leading car vendors. The coalition wants to optimize the supply chain of car parts for all the members of the coalition. The information system that supports such a coalition must be implemented as a P2P network with peers being information systems of member car vendors (ISV)(see Figure 1).

Figure 1: An implementation of the IS of the purchasing coalition

The level of collaboration of the members of the coalition can vary.

Some car large vendors (they are in fact competitors) formed lately an alliance to optimize purchasing of car parts (and supply chain management in general). The coalition should behave as a new large subject. The subject needs a support of some new information system (IS). This IS must communicate with the information systems of the members.

It is advantageous to construct the system of the alliance so that the information systems of the members communicate in a peer-to peer manner.

The information systems of individual members should have a unified interface for the communication with information system (IS) of the coalition. The formats of the messages taking part in the communication must be designed, agreed, and implemented.

The implementation of the IS of the coalition is then independent of the implementation details and/or the implementation philosophy of the IS of the coalition members (member IS in the sequel). The number of attached member ISs can vary. The condition is that member IS provides gates able to implement the communication rules and procedures.

ISVs (in Figure 1) generate purchase requirements and other information to newly implemented services optimizing the parts purchasing. It is clear, that ISV (information system of car vendor) must work as an autonomous unit providing some data and services to the information system supporting purchasing activities. If we need to do it automatically, any ISV must be equipped by an appropriate gate and should be permanently active. Due to reasons explained below, it is advantageous to concentrate the functionality of purchasing module into a new permanent service component ISC (information system of the confederation) implementing the functions of the purchasing systems and the user interface into a peer UC. The purchasing information system (PIS) is then formed by a P2P network consisting of the following peers:

• The information systems of the car vendors (ISV). Every ISV is equipped by a gate G performing the communication of the peer with other peers.

• A newly developed peer (ISC) collecting and optimizing car parts orders.

• A peer (UC) implementing the interface of the operator of the purchasing system. It can be again equipped by a gate.

It is not difficult to connect the system with the information systems (ISP) of parts suppliers.

ISP should be again a peer of the P2P network. This feature can be used to support activities known as supply chain management (SCM).

The interconnection of the peers must be supported by a proper middleware, e.g., by Internet.

The structure of the system is shown in Figure 1.

Note that the integration or joining of a new peer is a quite simple task and can be performed via the programming of gates.

There are more cases when one must build a system similar to the just described one. For example, the system of flight tickets reservation has very similar properties - but it is simpler (ISC component is almost missing).

The software confederations like the one from Figure 1 have the following properties:

1. The system is a (virtual) P2P network of permanent autonomous services (called in the sequel autonomous components, AC) communicating via gates and a middleware. In our example ISV, ISP, and UC (user interface component) are autonomous components.

2. AC is ultimately integrated as a black box. It is the condition for the seamless integration of legacy systems and/or third-party products as well as for the modifiability, openness and other important software engineering properties.

3. New AC's can be easily added or excluded. This advantage can be used fully only in the case, that the interface provided by an AC A is very stable as the change of it influences all the components (partners) communicating with A. The problem is that sometimes it can be quite difficult to know all the partners (some can join the system later).

4. The communication between autonomous components is asynchronous. The messages between AC's have usually a quite complex meaning. The autonomous components can accept complex commands and/or provide a complex data queries.

5. The AC's provide often only a part of their functionalities or data; they can have its own users. They must be autonomous and should be developed/maintained independently.

6. The properties of the system can be adapted via changes of gates and via message routing.

7. Newly developed AC's can be developed autonomously and the whole system can be developed in an incremental way. If the structure of messages is agreed, e.g., via a specification of an XML dialect, the components can be tested using appropriate message generators. It simplifies development as well as management of the development.

8. The autonomy of components can be of different level from almost independent (as in above example or the system of flight tickets reservation) to highly dependent (examples are discussed below).

The number of cases, when the use of the architecture is the only feasible way leading to success is quite high. We will discuss some of them.