TOWARDS DESIGN RATIONALES OF SOFTWARE

CONFEDERATIONS

Jaroslav Kr

Charles University

Malostransk

e n

am. 25, 118 00 Praha 1, Czech Republic

Michal

Zemli

cka

Charles University

Malostransk

e n

am. 25, 118 00 Praha 1, Czech Republic

Keywords:

Service orientation, software paradigm, user involvement, autonomous component, user-oriented component

interface, software confederations.

Abstract:

The paper discuss reasons why service-oriented architecture is a new software paradigm and the consequences

of this fact for the design of enterprise information systems. It is shown that such systems called confederations

need not use web services in the sense of W3C. It is, however, more or less a necessity in e-commerce.

Confederations (service-oriented systems with known set of services) are typical for manufacturing systems.

As business processes supported by enterprise systems must be supervised by businessmen, the same must

hold for communication inside service-oriented systems. It implies that the interfaces of the services must be

user-oriented (user-friendly). It can be easier achieved in confederations than in e-commerce systems. User

oriented interface has positive consequences for the software engineering properties of the confederation.

Confederations should sometimes include parts based on different implementation philosophies (e.g. data

orientation). Pros and cons of it are discussed. Open issues of service orientation are presented.

1 INTRODUCTION

Enterprise information systems (EIS) tend to have

the service-oriented architecture (SOA), i.e. a peer-

to-peer (virtual) network of almost independent (au-

tonomous) software units providing some services.

EIS differ from the systems supporting e-commerce

as EIS have

• known and almost ﬁxed collection of services,

• user interface to whole system (often called portal),

and

• known set of multistep business processes involv-

ing the services.

Information systems (and software systems in gen-

eral) having such properties are called (software)

confederations whereas the SOA systems support-

ing e-commerce are called alliances (see (Kr

al and

Zemli

cka, 2003a) for details). Note, that in e-

commerce the set of business partners is not known

and the partners must to be looked for. The emphasis

of SOA on peer-to-peer principles is not commonly

accepted (see e.g. (T

uma, 2003)). Peer-to-peer is a

crucial property of SOA.

Middleware

e.g. Internet

¡µ¡

¡ª

-¾ -¾

@R@

¡µ¡

¡ª

Log database

AC ... autonomous component

UC ... user interface component

(e.g. XSLT component or portal)

Figure 1: Software confederation

The structure of a confederation is given in Fig. 1.

It can be meaningful not to limit middleware to be

Internet-based. The middleware can even be based on

a combination of different communication technolo-

gies and/or communication infrastructures. It follows

that the services (peers) in confederations need not be

web services in the sense of W3C (W3 Consortium,

105

Král J. and Žemli

cka M. (2004).

TOWARDS DESIGN RATIONALES OF SOFTWARE CONFEDERATIONS.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 105-112

DOI: 10.5220/0002639301050112

 SciTePress

2002; Jablonski and Petrov, 2003). We use SOA in

this broader sense.

Software confederations appear quite often e.g. in

e-government, health care systems, and public organi-

zations. The user involvement in the activities of soft-

ware confederation is deeper and wider than in classi-

cal logically monolithic software systems

. Confed-

erations open new variants of user involvement into

human interaction with the software systems.

A proper solution of human involvement in the de-

velopment and the use of confederations usually re-

sults into better functions of the confederations and

into enhancement of software engineering properties

of the system (see section 3).

The application of service orientation is nowadays

rather a paradigm than simply a new technique only.

By a paradigm we understand according to the Web-

ster Dictionary ‘a generally accepted perspective of

a particular discipline at a given time’. By a soft-

ware paradigm we understand a consistent collection

of methods, tools, examples of good practices, and

development/activity patterns governed by a speciﬁc

philosophy. New paradigms always require a new

way of thinking and new methods and tools. Any new

paradigm requires therefore a lot of effort and time to

be governed and properly used. Old habits and in-

tuitions must be changed or replaced by new ones.

There should be changes in education and training of

software experts (Kr

al and

Zemli

cka, 2004a; Kr

al and

Zemli

cka, 2004c).

One can object that service orientation is a quite old

technique. It is true for e.g. soft real-time systems like

ﬂexible manufacturing systems (see e.g. (Kr

al and

Demner, 1979; Kr

al et al., 1987)) but service orien-

tation was not a paradigm in the above sense – it was

no generally accepted philosophy at that time. Let us

show that service orientation is becoming a leading

software engineering paradigm now.

We exploit the experience with the development

of the systems having some properties of SOA.

The systems were several successful projects of

Flexible Manufacturing System (later integrated into

CIM systems), several automated warehouse projects

(Kope

cek, 2003; Skula, 2001) and analysis of the sys-

tems for municipal authorities. We often speak about

services as about components to point out that a ser-

vice is provided by a speciﬁc software component

beeing often a complete application.

2 NEW PARADIGM

The concept of service-oriented architecture in the

form of confederation is known for decades. The ﬁrst

Even if sometimes physically distributed.

application of SOA was in soft real-time system like

the ﬂexible manufacturing systems dated back in the

seventies (compare e.g. (Kr

al and Demner, 1979)).

Some features of SOA were even present in COBOL

systems. One can therefore argue that SOA is not a

new paradigm. It is not so due to the following argu-

ments:

1. SOA was not ten years ago in a leading edge

of software development. The classical object-

oriented paradigm was the main topic. Information

systems typically had no service-oriented architec-

ture.

2. The SOA-based philosophy differs from the object-

oriented one like the data-oriented philosophy is

different from the object-oriented one. First SOA

systems used a very simple not too powerful mid-

dleware. SOA were therefore not able to be used

in large distributed information systems. New mid-

dleware opens new ways for software systems how

to be developed and/or used. These challenges are

not investigated enough yet.

3. The conferences, publications and standards on

SOA-related topics/problems has appeared recently

only.

4. The concept of SOA was not generally accepted

and strictly speaking there is now no complete con-

sensus what is SOA about.

5. The practice indicates that it is not easy for the

object-oriented people to accept and properly use

the service-oriented philosophy.

Let us discuss the last point in more details as it

also conﬁrms the conjecture that the service-oriented

paradigm is a new paradigm different e.g. from the

object-oriented one. It is indicated e.g. by the follow-

ing facts (compare (Brown et al., 1998)):

• The antipattern “Stovepipe Enterprise/Islands of

Automation” ((Brown et al., 1998), pp. 147–157)

is in service-orientation rather a pattern if a proper

gate connecting the island to a middleware is avail-

able.

• The basic attitude in SOA is the decomposition

of the system into large components providing

complex functions. It is a turn near to the an-

tipattern “Functional Decomposition”. The mod-

eling of such systems can use a modiﬁcation of

data ﬂow diagrams, a tool that disappeared from

object-oriented methodology during the last ten

years (compare (Rumbaugh et al., 1991) and from

the UML standard (Object Management Group,

2001)).

• Encapsulation and autonomous development of ap-

plications (e.g. legacy systems, third party prod-

ucts) is the main design pattern in SOA. It is,

however, near to the stovepipe system antipattern

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

106

((Brown et al., 1998), pp. 159–190, although the

recommendations from p. 162 can be applied).

Service-orientation simpliﬁes refactoring of or

even excludes the antipatterns: Lava Flow (the tech-

nology changes can be hidden inside the services

behind their interfaces), Vendor Lock-In (possible

but can be easily overcome), Reinvent the Wheel

(legacy systems and third-party products can easily

integrated), Corncob (unpleasant hacker can develop

his own service), etc.

3 HUMAN INVOLVEMENT IN

SERVICE-ORIENTED

SYSTEMS

The lack of user involvement in requirements speciﬁ-

cations is the main reason of software project failures.

The novelty of service orientation is that the involve-

ment of users in the system activities is deeper than in

classical systems. The activities of human beings are

not limited to UC from Fig. 1 only. The communica-

tion (dialog) in e-commerce is usually stateless. The

dialog starts with looking for a service (autonomous

component) that provides the contact and other infor-

mation on potential business partners (e.g. supplier).

This is often done using UDDI and WSDL. It im-

plies that the communication between partners must

be supported by a widely accepted middleware (Inter-

net) and must use generally accepted message formats

based on appropriate standards (XML).

The dialog is usually in a SOAP-based formats.

The dialog is used to perform a business process

(e.g. business agreement conclusion) under the (possi-

ble) personal supervision of businessmen of the part-

ners. The business documents produced in this way

are to be often formally conﬁrmed by businessmen

(signed traditionally or electronically).

MiddlewareAC

-¾ -¾

¢A

Log

££

Figure 2: Semi-automated contract dialog scheme: Users

should be able to supervise communication and to analyse

Log datastore

Business processes are internal matters of the com-

municating parties. The coordination of the business

processes of several partners can be therefore a quite

complicated task. Optimal requirements speciﬁcation

on the supervising activity of individual steps of busi-

ness processes is a corner stone of requirement speci-

ﬁcation of the alliance as a whole.

As the businessmen must able to understand the

communication between the autonomous compo-

nents, they must be able to understand the formats of

the messages produced and/or accepted by the gates

and G

in Fig. 2. This is easy only if the mes-

sage formats are based on the languages of the user

knowledge domains. We say that the interfaces are

user-oriented. It can be more easily achieved in con-

federations where the partners know each other and

can agree message formats according their needs. As

their knowledge domains are usually based on a long

term activities and they are therefore in some sense

”tuned”, the user-oriented interfaces of G

and G

(i.e. the languages deﬁned by message formats) tends

to be stable (not so varying as IT technologies). It has

important software engineering advantages described

below.

In confederations users must be able to deﬁne and

to supervise business process being networks of steps

performable by particular services. The communica-

tion trafﬁc in service-oriented systems can and should

be logged. The confederations admit, however, a

wider set of implementation principles than alliances.

The data deﬁning business processes are best to

store in user interface components (portals). The busi-

ness steps are then supervised via the portal. An ex-

treme solution is that there are no business processes

(workﬂows) deﬁning data and the business processes

are completely controlled by users.

Business data analysis (via e.g. OLAP) must be

based on data-oriented view. In this case the users

(usually managers) must have a transparent access to

data (tiers) of the components.

The notions and/or languages specifying the ac-

tions of components (e.g. bookkeeping) are often re-

markably stable. The same can hold for the languages

of the interfaces of corresponding services. It is quite

possible that the interface of a component does not

vary in spite of the fact that the component implemen-

tation varies. The stability of interfaces is important

for the communication partners of the given compo-

nent and for the stability of the whole confederations.

It has further substantial software engineering advan-

tages (modiﬁability, outsourcing opportunities, reduc-

tion of number of messages, integration of products of

various vendors, openness, etc.).

It is not feasible to limit the philosophy and the

software architecture to one choice. It is especially

important for the confederations. So the crucial

point of the requirements speciﬁcation for confeder-

ations is what philosophy or combination of philoso-

phies will be used. Examples of the philosophies

are classical data ﬂow batch systems (see (Your-

TOWARDS DESIGN RATIONALES OF SOFTWARE CONFEDERATIONS

107

don, 1988)), data driven systems (see (Donnay Soft-

ware Designs, 1999)), object-oriented systems (see

(Rumbaugh et al., 1991; Jacobson and et all, 1995)).

This issue is not addressed in existing CASE tools and

only a little addressed by research.

4 DATA-FLOW BATCH SYSTEMS

(DFBS)

DFBS were typical for the COBOL era more than

thirty years ago when due to the limits of hardware

(and to some degree to then state-of-art at that time)

the possibilities of on-line (interactive) elaboration as

well as of the use of modern database system were

limited, if any. Such systems were usually written in

COBOL. Note that COBOL compilers are still well

supported.

DFBS has many important advantages. The case

Y2K has shown that DFBS are extremely stable. In

many enterprises they had been in use without al-

most any maintenance for years – sometimes even for

decades. The enterprises had even no COBOL pro-

grammers about year 2000 although they had been

using systems written in COBOL and DFBS’s inten-

sively.

DFBS is typically a collection of autonomous pro-

grams providing some services usually written in

COBOL. The tasks of the programs were the trans-

formation of massive data from several input ﬁles into

(massive) data in several output ﬁles. The programs

can be developed almost independently. The batch

character of the systems simpliﬁes the development

and reduces maintenance effort. There are still many

situations when DFBS can and should be used. Exam-

ples are massive data correctness control, data repli-

cation, off-line data ﬁltering and transformations, and

(statistic) data analysis. Note that the philosophy of

DFBS can be easily adapted to the case when the data

are in data stores (e.g. copies of databases), not nec-

essarily in ﬁles. It is, however, assumed that the data

elaboration can be off-line (i.e. performable in the

batch mode). Batch systems can be necessary when

data analysis is very time consuming.

The ﬁrst DFBS’s were based on the analysis of the

data (originally paper documents) ﬂows already ex-

isting in the organization. Such analysis is known as

function decomposition. Function decomposition re-

ﬂects the basic features of workﬂows in enterprises. It

is an advantage that some other speciﬁcation philoso-

phies do not have. On the other hand the use of DFBS

does not properly support the horizontal communica-

tion in organizations. It has further drawbacks espe-

cially in an object-oriented environment. It can make

the business process (re)construction more difﬁcult.

From technical point of view it can be difﬁcult to

synchronize DFBS with the every-day activities of

on-line (interactive) systems. So DFBS are not of-

ten used but it does not mean that they are useless.

If a DFBS can be used, we should specify the re-

quirements as transformations of input data into out-

put data. It is not equal to the way we specify the

data and data operations in data-driven system and

object-oriented system described below. DFBS use

data-ﬂow diagrams as a main system visualization

tool and structured analysis and design as a system

development tool (Yourdon, 1988). If a DFBS can be

used, it can save a lot of effort and it can simplify the

maintenance and increase the reusability of the sys-

tem. DFBS has the architecture of a network of au-

tonomous services – it is a property that has recently

returned in a modiﬁed form in software confedera-

tions.

DFBS are still usually written in COBOL. The

classical COBOL thinking is not obsolete here. The

thinking oriented towards a network of autonomous

services partly applicable during the implementation

of DFBS substantially simpliﬁes the task, provided

that the network based architecture is possible. It is

the case of DFBS being formed by a virtual network

of autonomous programs (a predecessor of services).

The autonomous programs can be autonomously de-

veloped using different methodologies and/or pro-

gramming languages if necessary. The programs can

be reused or they can be third party products. It is

a great advantage having its counterpart in software

confederations. It need not therefore be a good idea

of some CIO’s to avoid ‘COBOL thinking’ (com-

pare (Sneed, 2002)) and to require every DFBS to be

reengineered to be an object-oriented system.

Batch systems are usually very stable, well main-

tenable and have good software engineering proper-

ties. Such systems can be applied in confederations in

the cases of massive data reconstructions, data repli-

cations and even in the time consuming cases of data

analysis. In these cases the batch-oriented attitude is

more or less a practical necessity. We know banks

performing due to safety reasons ﬁnancial transac-

tions in two steps. In on-line mode the transaction

data are stored in a temporal database. The transac-

tions are completed in batch mode by DFBS.

The use of batch system can impose some limita-

tions on the system performance as some operations

cannot be done on-line. The importance of such lim-

itations is often overestimated and advantages of the

application of batch system underestimated. The con-

sequence is that the batch philosophy is wrongly con-

sidered to be obsolete and useless. Due to this prej-

udice some opportunities are missed as the analysis

does not include the question whether some applica-

tions should not be implemented via a batch subsys-

tem.

DFBS attitude can be an optimal solution in mas-

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

108

sive data ﬁltering, presentation (report generation)

and other task performable in batch mode.

The modeling of batch systems is possible via data-

ﬂow diagrams known from structured analysis and de-

sign (Yourdon, 1988) or by the tools of functional de-

sign.

5 DATA DRIVEN SYSTEM (DDS)

Data driven systems appeared after the success of

modern database systems. The aim at that time was

usually to computerize operative level of an enterprise

(warehouses, bookkeeping, business data). Data types

were known and various operations could be deﬁned

over the same data. Moreover properly designed data

structures can be used for many other potential oper-

ations – i.e. the data enable many further operations

not speciﬁed yet. It was and still is supported by the

power of the SQL language.

The substantial properties of the architecture of the

developed system was the data model expressed by

ER-diagrams often accompanied by data-ﬂow model

(Donnay Software Designs, 1999). The condition for

the application of such a strategy was a proper qual-

ity of hardware (servers, client workplaces, data net-

works).

Data driven systems are still a good solution in the

situations when the kernel of the problem is in the

data area, i.e.:

• The main problem is to deﬁne data and data struc-

tures and to collect data in an electronic form.

• The operations can be easily derived from data and

data concepts, there are many possible operations

over the same data (i.e. a value can be used by many

different operations in different ways).

• The properties of the system depend heavily on the

optimality of the operations on data.

• There is a need to work with and analyze massive

data (statistics, OLAP, etc.).

The requirements speciﬁcation starts from the data

speciﬁcations and/or data model and from basic op-

erations. As data enables a broad set of operations the

system is open in this sense.

Data oriented philosophy is appropriate in the case

when a system is built from scratch starting from data

tier.

The existence of data orientation in modern sys-

tems is conﬁrmed by the existence of resource deﬁ-

nition framework (RDF (W3 Consortium, 1999)) and

(meta)data oriented research. Data orientation is typ-

ical for management information systems. Such sys-

tems assume a ﬂexible open system of operations over

massive data.

The fact that the collection of operations is open

can be felt sometimes disadvantageous (optimality

issues, some important operations need not be de-

tected). The practice indicates that DDS are usually

not felt as a system of collaborating autonomous ser-

vices. Note, however, that common database with

triggers can be quite easily adapted to serve as mid-

dleware. The message transfer can be implemented as

a storing some data including an activation of a trigger

causing proper activation of the addressee of the mes-

sage. The integration of software pieces is in this case

via a common data tier. The used tools are SQL, ER-

diagrams, RDF, data-ﬂow-diagrams. A strong point

of DDS is their openness and support for data analy-

sis. Weak points are:

• the problems with deﬁnition of common data struc-

ture/database,

• issues connected with data replication and uniﬁca-

tion (common format/structure),

• large systems are difﬁcult to reconstruct,

• inﬂexibility of “middleware” services (data rout-

ing) compared with the middleware implementa-

tion and message passing via e.g. Internet.

Elements of DDS must be often applied in the

parts performing on-line (interactive) data analysis

(e.g. OLAP/ROLAP

) and generally the management

tier of information systems. Elements of data ori-

entation can appear on quite low level. In (Kr

and

Zemli

cka, 2003b; Kr

al and

Zemli

cka, 2004b)

a practical implementation of the interface between

Scheduler and an automated machine tool workshop

is described. The interface was based on a common

database and its presentation tool having features of

data analysis. The implementation facilitated the suc-

cess of several projects of several ﬂexible manufac-

turing systems.

6 IMPLEMENTATION OF

SOFTWARE

CONFEDERATIONS

Technically a legacy system AC is integrated into a

confederation via adding a gate G to AC (Fig. 3). G

connects AC to a middleware. AC is also redesigned

to be a permanent process (if not already one). The

software confederation has then the structure from

Fig. 3.

AC can be implemented using object-oriented phi-

losophy. Sometimes it can happen that a system can

(seemingly) be designed as a confederation or as a

OLAP = on-line analytical processing, ROLAP = rela-

tional OLAP.

TOWARDS DESIGN RATIONALES OF SOFTWARE CONFEDERATIONS

109

monolithic system in which all autonomous compo-

nents should be completely rewritten and “dissolved”

in the system.

-¾

Middleware

-¾

Figure 3: Software confederation with gates

Although the choice between the two alternatives

seems to be a quite technical one, it should be in-

cluded into requirements speciﬁcation. The require-

ments speciﬁcation should be adapted to the fact

whether the monolithic or confederated philosophy is

to be used as it inﬂuences substantially user proper-

ties of the system and the set of feasible solutions. If

a particular autonomous component AC “belongs” to

some department/division (being e.g. its local infor-

mation system), the department is satisﬁed with AC,

and AC can provide all required information/services

to other collaborating autonomous components, then

AC can and often should be integrated. Note that

it reduces development effort as substantial parts of

code are reused. The department people feel that

they still (mentally) ‘own’ AC. It is well known that

of such ownership feeling is advantageous and often

necessary.

Confederative architecture can make feasible re-

quirement types raised by CEO like the transfor-

mation of the enterprise organization structure into

a decentralized form, selective outsourcing of some

parts of the information system, selling out some di-

visions/departments, integration of newly purchased

ﬁrms/divisions, support for supply chain manage-

ment, and forming various business coordination

groups (Kr

al and

Zemli

cka, 2002). Autonomous

components can be developed as a “black boxes” us-

ing any of the developing strategies mentioned above.

7 BUSINESS PROCESSES IN

CONFEDERATIONS; USERS AS

SERVICES

The business processes in confederations can be quite

complex, they can be a complex networks of activities

(variants of workﬂow). There can be various levels of

automation of business processes and their particular

steps. It is highly desirable that the processes can be

(in principle) supervised by users. Users can:

• deﬁne or modify the deﬁnition of processes,

• can start processes, supervise/inﬂuence/perform

their steps, on-line redeﬁne and reschedule process

steps,

• change the run of the running (active) processes

(change the sequence of the steps, etc.),

• replace some services intended to be provided by

software by ‘manual activities’.

The last requirement is especially important dur-

ing the system development as it can serve as the pro-

totyping tool and even substitution of not yet devel-

oped (implemented) services. It is a very useful tool

for run-time of the system as it can happen that some

services will be always provided by human beings or

that users will have to simulate or provide services not

available due a failure at the given moment. The con-

dition is that user interface components (UC, portals)

are able to accept the messages for the missing ser-

vices, present it to the users and to produce answers

deﬁned by users. It is often a quite simple task to

implement it (Kr

al et al., 1987) – provided that the in-

terfaces of gates are user-oriented in the above sense.

More complicated business processes should use

(should be controlled) by some process deﬁning data.

There is a problem where to store business process’

states and data. The most promising seems the strat-

egy to include the data into the data of the associated

user ‘owning’ (responsible for) the process. It is also

possible to generate a new service S associated with

UC. The purpose of S is then to serve as an agent

controlling business processes owned by some user.

8 SOFTWARE ENGINEERING

ISSUES

The user-oriented interfaces of components enhance

the following software engineering properties of the

service-oriented systems:

1. User involvement. The governance of business pro-

cesses by users is easier than in classical systems.

2. Modiﬁability

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

110

• implementation changes in services can be hid-

den, it simpliﬁes maintenability as well;

• some autonomous components can be pur-

chased, insourced or outsourced.

3. Incremental development as well as iterative devel-

opment.

4. Prototyping and temporal replacement of the ser-

vices that are currently not available.

5. Short milestones (autonomous services can be not

too large software units).

6. Solution/refactoring of many antipatterns (Brown

et al., 1998), see above.

7. New turns, e.g. testing the response time of real-

time control systems (Kr

al, 1998).

8. Reduction of development effort due:

• integration of legacy systems,

• purchasing autonomous component from ven-

dors,

• decomposition the system into small units that

due to dependency between the system size

and the development effort reduces the effort

(Eﬀort

= c · Size

1+a

, a > 0), see COCOMO

II,

• shorter feedback between developers and users.

The are open issues:

1. It is not clear what services should be good to be

provided as a central (infrastructure) ones. Cen-

tral services can be a bottleneck (access trafﬁc, too

strong inﬂuence of big vendors, data correctness

checking, service modiﬁcation, etc.).

2. Confederative architecture can make customers

less dependent on large vendors. The vendors are

not happy with it and try to resist it.

3. As a new paradigm the confederations need the de-

velopers to precisely understand the user knowl-

edge and needs. This opposes the strong computer-

oriented feeling and interests of software experts.

To avoid it they should understand and accept the

thinking and philosophy of experimental sciences

(e.g. physics, to some degree economy) and math-

ematical statistics. It is quite difﬁcult to achieve it.

4. Data intensive functions (for management and

DDS in general) can beneﬁt from service orienta-

tion but there is no good methodology available for

it now.

5. In some parts of confederations some seem-

ingly obsolete techniques (COBOL) can be used.

The traditional integration (into object-oriented or

database applications/systems) of such services

need not be a simple matter.

6. There are problems with security and effectiveness.

Note, however, that the user-oriented interfaces im-

ply reduction of the number of messages and there-

fore can enhance system performance and can limit

threats due to misuse of RPC.

9 MAIN POINTS OF DESIGN OF

SERVICE-ORIENTED

SYSTEMS

As there is no common agreement what service ori-

entation and service-oriented architecture are about

(Barry and Associates, 2003), it is necessary to de-

cide ﬁrst whether the architecture of the system will

be a virtual peer-to-peer network. We believe that the

choice of peer-to-peer is the best one and we shall dis-

cuss this case. The components (peers of the network)

should be quite large applications behaving like ser-

vices in human society. The services should be spec-

iﬁed via their interfaces and integrated therefore as

black boxes.

The services (their interfaces) should mirror the

real-world services provided by the organizational

units of enterprises or by people. Their interfaces

should be (and due to the above conditions can be)

user-oriented, i.e. understandable to system users.

The system then behaves like the human society being

also a network of autonomous services.

Users should be deeply involved in the speciﬁca-

tion and design of the interfaces.

The development process of SOA system depends

on the variants of decomposition and integration. The

implementation of interfaces can be different in con-

federations (known collection of services) and al-

liances (e-commerce).

There can be problems with the acceptance of the

philosophy in the above sense, as service orientation

is a new paradigm for many people especially for the

strongly object-oriented beings. The acceptance and

governing of a new paradigm need many years.

It is preferable for the development, debugging

and use of service-oriented system to design ser-

vices/programs so that they can be substituted by dis-

cussion with human bodies via user interface. It is

good to support the human involvement as much pos-

sible (i.e. automate as little as possible). The develop-

ment process should be incremental using Pareto 80-

20 law as much as possible. It is against the strategy

computerize as much as possible promoted by soft-

ware vendors and accepted by some users.

TOWARDS DESIGN RATIONALES OF SOFTWARE CONFEDERATIONS

111

10 CONCLUSIONS

The service-oriented architecture is a very powerful

and in many areas a quite new paradigm. There are,

however, several issues to be solved yet:

1. Education of people to be able to use service orien-

tation properly. Service orientation is not any sim-

ple and straightforward modiﬁcation of the object-

oriented techniques and object-oriented philoso-

phy.

2. Design patterns as well as new tools of modeling

are not available yet.

3. The SOA inﬂuences the speciﬁcation of require-

ments more substantially than other architectures

do.

4. The collaboration of users (including their top

management) with developers as well as users in-

volvement should be tighter than before.

5. The developers should have a deeper knowledge of

the user problem and knowledge domain.

Important issues are the prejudices of software devel-

opers like insisting on full computerization, belief that

users are too stupid to take part in requirements spec-

iﬁcations, etc.

Service orientation is, however, today already an

attitude promising to develop software of the quality

known from the other branches of industry.

Supported by the Czech Science Foundation, grant

No. 201/02/1456.

REFERENCES

Barry and Associates (2003). http://www.service-

architecture.com.

Brown, W. J., Malveau, R. C., Hays W. ”Skip” McCormick,

I., and Mowbray, T. J. (1998). AntiPatterns: Refac-

toring Software, Architectures, and Projects in Crisis.

John Wiley & Sons, New York.

Donnay Software Designs (1999). Mature, portable, data-

driven systems. http://www.dclip.com/datadr.htm.

Jablonski, S. and Petrov, I. (2003). Web services, workﬂow

and metadata management as the integration means

in the electronic collaboration era. Tutorial at the

ICEIS’03 conference.

Jacobson, I. and et all (1995). Object Oriented Software

Engineering: A Use Case Driven Approach. Addison

Wesley.

Kope

cek, P. (2003). Private communication.

al, J. (1998). Informa

ı Syst

emy, (Information Systems,

in Czech). Science, Veletiny, Czech Republic.

al, J. and Demner, J. (1979). Towards reliable real time

software. In Proceedings of IFIP Conference Con-

struction of Quality Software, pages 1–12, North Hol-

land.

al, J.,

Cern

y, J., and Dvo

ak, P. (1987). Technology of

FMS control software development. In Menga, G. and

Kempe, V., editors, Proceedings of the Workshop on

Information in Manufacturing Automation, Dresden.

al, J. and

Zemli

cka, M. (2002). Autonomous compo-

nents. In Hamza, M. H., editor, Applied Informatics,

pages 125–130, Anaheim. ACTA Press.

al, J. and

Zemli

cka, M. (2003a). Software confedera-

tions and alliances. In CAiSE’03 Forum: Information

Systems for a Connected Society, Maribor, Slovenia.

University of Maribor Press.

al, J. and

Zemli

cka, M. (2003b). Software confederations

and manufacturing. In Camp, O., Filipe, J., Ham-

moudi, S., and Piattini, M., editors, ICEIS 2003: Pro-

ceedings of the Fifth International Conference on En-

terprise Information Systems, volume 3, pages 650–

653, Set

ubal. EST Set

ubal.

al, J. and

Zemli

cka, M. (2004a). Architecture, speciﬁ-

cation, and design of service-oriented systems. In re-

viewing process.

al, J. and

Zemli

cka, M. (2004b). Service orientation and

the quality indicators for software services. Accepted

for EMCSR’04 in Vienna.

al, J. and

Zemli

cka, M. (2004c). Systemic of human

involvement in information systems. Technical Re-

port 2, Charles Univerity, Faculty of Mathematics

and Physics, Department of Software Engineering,

Prague, Czech Republic.

Object Management Group (2001).

Uniﬁed modeling language.

http://www.omg.org/technology/documents/formal/uml.htm.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and

Lorensen, W. (1991). Object-Oriented Modeling and

Design. Prentice-Hall, Englewood Cliffs, New Jersey

07632.

Skula, J. (2001). Private communication.

Sneed, H. (2002). Position statement at panel discussion at

CSMR 2002, Budapest, Hungary.

uma, P. (2003). Modern software architectures: Novel

solutions or old hats? In Popel

ınsk

y, L., editor,

DATAKON 2003, pages 151–162, Brno, Czech Re-

public. Masaryk University.

W3 Consortium (1999). Resource description

framework. A proposal of W3C Consortium.

http://www.w3.org/RDF/.

W3 Consortium (2002). Web services activity.

http://www.w3.org/2002/ws/ – as visited on 31st

October 2003.

Yourdon, E. (1988). Modern Structured Analysis. Prentice-

Hall, 2nd edition.

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

112