The Third International Conference on Software Engineering Advances
Standardization and Agile Business Processes
Jaroslav Král and Michal Žemlička
Charles University, Faculty of Mathematics and Physics
Malostranské nám. 25, 118 00 Praha 1, Czech Republic
kral@ksi.mff.cuni.cz, zemlicka@ksi.mff.cuni.cz
Abstract
We show that it is crucial for the support of business
processes and intelligence as well as for the technical ad-
vantages that the peers (services) in service-oriented sys-
tems have user-oriented interfaces. Such a requirement is
at present difficult to implement if we require that the inter-
faces must be completely implemented according to world-
wide standards – i.e. no proprietary (ad hoc) solutions are
allowed. The reason is that the user-oriented interfaces
must be implemented as semi-formal interfaces inspired by
the interfaces of real-world services and therefore must be
ultimatively based on the knowledge domains, domain lan-
guages, and even of the domain habits and local cultures of
users. We further show that there are at least for the time
being technical reasons why it is not feasible to standardize
such interfaces fully as there is a danger that the hurried
standardization of the interfaces can lead to many prema-
ture cumbersome standards not to be well usable. We pro-
pose a solution of this problem. Our proposal is supported
by the observed tendency of modern service-oriented sys-
tems to use XML-based proprietary interface languages and
SOAP-message encoding instead of the SOAP-RPC one.
1. Introduction
It is often assumed that all (business) processes sup-
ported by an information system should be fully comput-
erized. It is sometimes acceptable for information systems
providing information only, i.e. for systems having no (di-
rect) process control abilities (compare [25]). It is nowa-
days rather an exception than a rule. The decision and
actions of the system able to control business processes
or their parts must be supervised/committed and on-line
changed by authorized users – process owners. The rea-
son is that for many business actions/operations caused by
the software there must be a person responsible for them
– i.e. the authorized person (process owner) should be able
to influence the process execution. Even more: the owner
must be often able to change the process ”on the fly” – it is,
978-0-7695-3372-8/08 $25.00 © 2008 IEEE
DOI 10.1109/ICSEA.2008.40
so called business agility is to be enabled.
We will discuss the implementations of business pro-
cesses as service-oriented systems. Service-oriented sys-
tems are virtual peer-to-peer networks of permanently ac-
tive processes provided by autonomous software compo-
nents – peers of the network. The peers are called (soft-
ware) services. They have a lot of common with real-world
services.
We discuss the most practically important implementa-
tion when the ”atomic” steps of business processes are pro-
vided by the services. Every service has an interface accept-
ing messages – service requests – from users or other ser-
vices. The service can generate answers or requests requir-
ing capabilities of other services. The properties of service
interfaces determine the substantial properties of service-
oriented systems.
The requirement that business processes should be agile
have substantial impacts on the standardization of service
interfaces:
1. The interfaces of the services must be user oriented
(usable), i.e. understandable for (some) users – at least
for process owners. As such they must use coarse-
grained interfaces reflecting user knowledge domain
and also user domain languages and local habits1 must
be applied. All that implies that the interfaces tend to
be rather proprietary.
2. The used standards and agreements must be often de-
veloped iteratively in the close cooperation of users
and developers, i.e. many principles of agile develop-
ment [3] should be applied2 .
Under these circumstances it can be more important that
the used message formats are user-oriented than that they
1 Note that SOAP [28] is now often used as an envelope of semanti-
cally rich user-oriented XML messages. The solution is known as SOAP-
document encoding or SOAP-document literal [6]. The reasons can be
technical (effectiveness [6, chap. 14]). But the most important effect is
that user domain languages in XML formatting can be used.
2 We must therefore implement tools for agile business using agile de-
velopment principles.
184
are standardized using open formats. The two require-
ments are therefore difficult to meet in the systems like
e-commerce (often B2C) where communication partners
should be potentially looked for all over the world at the
start of their communication. It is obvious that the search-
ing process must be based on open world-wide accepted
standards. We call such systems alliances. Fortunately,
there is a broad collection of systems where constituent ser-
vices ”know each other” for ever as the services must be
e.g. trusted or support divisions of an enterprise. In such
cases the communication partners need not be looked for.
The communication protocols can be then agreed locally, if
it is appropriate. We call such systems confederations [16].
2. Flood of Standards and How Not To Sink
Standards are used for different purposes. Some fix best
practices, some are interoperability agreements. The prob-
lem with standards on web and with SOA-related standards
is that there are too many standards and that they grow and
change quickly. The standards explosion is enabled by the
use of XML framework as XML makes it easy to define new
languages and new formats. One of the unpleasant conse-
quences is that many standards try to fix practices being still
immature and even to address problems that are not impor-
tant enough (yet).
Service-oriented techniques and patterns discussed be-
low open the ways of software development and use without
excessive use of the newest standards. Such standards are
sometimes quickly obsoleting and often cumbersome. The
service-oriented techniques make it possible to invent, use,
and perfect best practices before fixing them in an (interna-
tional) standard. The techniques enable saving/retaining of
the experience and data collected in the form required by
long time used standards considered now not to be used any
more.
Service orientation also provides not only the opportu-
nity to develop software incrementally but also to modern-
ize it incrementally together with the progress of business
practices and enhancements of software engineering prac-
tices. We therefore can modernize incrementally the entire
collection of needed software standards.
We think that standardization process should take into
account such issues like easy user involvement and agility
and gradually collected experience and knowledge.
3. Confederations and Alliances
Services in service-oriented systems can be newly de-
veloped applications, encapsulated legacy systems, or third
party products.
Examples of service-oriented systems are:
185
1. Information system of an international global enter-
prise having the structure of a network of autonomous
organizational units (divisions). The information sys-
tem of the enterprise is formed by a peer-to-peer net-
work of the information systems of the divisions and
by some additional units serving the whole system of
the enterprise (e.g. system portals or support of busi-
ness processes). In other words the system has the
service-oriented architecture (SOA) [8, 18]. The mes-
sages can have the format defined as an XML dialect.
Note that such an architecture simplifies the integra-
tion of new divisions and/or of newly acquired enter-
prises as well as the selling out (outsourcing) some di-
visions or some parts of IS or splitting the enterprise
into smaller units.
2. Information systems of e-government ([14]). Such in-
formation systems must be built as a network of the
information systems of particular offices3 with addi-
tional services. We shall discuss this case in details
below.
3. The collaboration between the information system(s)
of the given enterprise and the information systems of
its business partners supporting advanced variants of
supply chain management (SCM, [23]) and customer
relationship management (CRM, [7]).
4. The information system supporting a purchase coali-
tion of car vendors. The aim of the coalition is to bet-
ter the position of the coalition members with respect
to the suppliers of the automobile parts and to cumu-
late the member orders.
5. An information system for a highly open association
of health organizations (physicians, hospitals, labora-
tories, health database services, etc.) intended to sim-
plify, enhance, and speed up health care.
6. Open dynamically changing network of cooperating
software systems (typically web services) necessary
for supporting of e-commerce.
As noted above (see also [17]), we call the systems support-
ing e-commerce alliances whereas the cases 1 through 5
confederations. Let us repeat that the distinguishing feature
is that in confederations communicating partners are mutu-
ally known and can therefore agree (semi)proprietary mes-
sage formats and protocols, whereas in alliances the part-
ners must be looked for.
Our list indicates that confederations occur rather as a
rule than as an exception, especially in the cases when very
large software systems must be built.
3 Other solutions are not feasible for technical as well as for practical
and political reasons ([16, 14, 26]).
 Note that in business, especially in the case of B2B, the
software services enhancing communication protocols can
wrap information systems of business partners. The busi-
ness properties of the business partners (trustability, eco-
nomical health, etc) must be as a rule verified by a long
term human driven evaluation process. A business partner
is then acceptable only if it is on a (virtual) list of trustable
business partners or it is acceptable for process owner. In
this situation the requirement that the information systems
of business partners ”are known” is not too limiting.
4. Agility and Agile Business Processes
The business processes must be based on the user needs
and requirements. Users – as we pointed above – must have
at least in principle a possibility to supervise business pro-
cesses and to modify them on-line. The reasons are:
• Every business process should have its owner respon-
sible for the run of the process, for the correctness,
feasibility and profitability of the process, as well as
for accidental losses and emergency responses. There
must therefore be a tool allowing post-mortem analy-
sis of the business processes – eventually using a log
file.
• Inherent property of business processes in B2B busi-
ness is the possibility of the agility of the businessmen
of business partners. To be more specific: the initia-
tor of a business action can (but need not) look for a
business partner using e.g. UDDI/WSDL. The initiator
must take into account not only the information ob-
tained via e.g. UDDI or even by a web search engine
but also the information from other sources (knowl-
edge on the business quality of the potential partner).
It follows that the start of a business contact cannot be
in many cases fully computerized and that users must
have the possibility to switch to manual mode. On
the provider side there must be someone able to evalu-
ate the quality of the business initiator and to have the
right to start the business and to conclude agreements.
Both business partners must have the possibility to for-
mulate the conditions of the agreement using personal
contacts. Under such conditions the full computeriza-
tion of the business action is acceptable for repeated
business actions covered by a long-term general agree-
ment. Even in this case it must always be possible to
influence the business process manually.
The implementation of the cooperation should therefore be
based on schema from Fig. 1. It is obvious that the mes-
sages must be understandable to the businessmen (users).
So the messages should have the format, syntax and seman-
tics near to the syntax and semantics of user knowledge do-
main languages and should reflect local culture and/or local
186
language features. In confederations such requirements can
be implemented in a seamless way.
The dialog between web services can be in a SOAP-
based language format or we can use attitudes based on
REST philosophy [9]. It is important to choose a format
easily understandable by users. An example is the use of
SOAP such that the messages contain user-oriented parts. It
has implied the use of SOAP-document encoding protocol
[28].
 
g - g
Log
 

A 6
A
BM BM
 B  B
 BN    BN
AC G - Middleware - G AC
 
Figure 1. Semi-automated contract dialog
scheme: Users should be able to supervise
communication and to analyse Log datas-
tore. Log can be inspected by third parties
(e.g. by experts at court trial)
5. Business Processes in SOA
Business processes are usually designed such that they
are the internal matters of the communicating business par-
ties. The coordination of the business processes of sev-
eral partners can be a quite complicated task. Require-
ments specifications on the supervising activities of indi-
vidual steps of business processes are an important part of a
service-oriented system.
The main advantage of alliances is their flexibility, gen-
erality, and standardized solutions. The disadvantage is the
problems with timeliness, efficiency, quality, and the size of
standards, their quick changes and quick getting obsolete,
and problems with integration of legacy systems and third
party products. A deeper problem is caused by the fact that
the tools used in alliances are not very user friendly as they
are based on tools that are rather programmers’ knowledge
domain oriented and not user knowledge domain oriented.
It complicates requirements specification and business pro-
cess agility.
Alliances are better suited to business operations than
to business process analysis. The important business deci-
sions should be, however, often preceded by the analysis of
the market, references, and the history of cooperation with
a given business partner. The analysis must often be per-
formed by human beings.
Communication of software parties can be in alliances
designed in the framework of the web services quite indi-
vidually. It is a substantial advantage.
 Some business cases (processes or process steps) can
fail for some reason. In this case the reasons of the fail-
ure and the businessmen responsible for it can be detected
via the analysis of the relevant logged messages. The anal-
ysis could be used as evidence at a court, if necessary. It
follows that the messages stored in the log memory must be
understandable (possibly using appropriate trustable soft-
ware tools) for users as well as for experts in economy and
even for lawyers taking part in business-related trials. The
best solution is, if possible, if the messages themselves are
legible. Such a solution is needed for system flexibility, ap-
plication of agile methods in development, and for agility in
business.
6. Specific Cases of Human Involvement
Humans must take part in business processes:
1. Many business processes must use data of a poor qual-
ity (e.g. incomplete or not trustable). It is true espe-
cially in the case of small and medium enterprises. It
is quite common that some data are missing or their
quality is not known. There can be problems with sup-
pliers, etc. The data like the duration of operations
needed in scheduling need not be exact. Let us con-
sider, for example, the management of machine tools
floor workshop. If the manager of the workshop has
an appropriate tool displaying manufacturing schedule
and the situation on the floor, he/she can – using his/her
experience and the support of the information system
– find a (semi)optimal solution. It can happen that the
scheduling system cannot find a good solution due to
poor data quality. The scheduling can be so time con-
suming that the scheduler must work in batch mode.
In this case the communication between the scheduler
and the machine tool floor control must be via data
store implemented as a specific infrastructure service
[18]. Such a service enables the integration of batch
systems into service-oriented systems. It can be fur-
ther used to implement proprietary multipoint commu-
nication protocols.
2. Some parts of the business processes can be influenced
by a fallout. It is very desirable that the activity of
the not yet available part of the system being not yet
available can be replaced by human activities.
3. If the system is service-oriented, the above point is
implementable quite easily. The idea is that the mes-
sages can be redirected to people. They must, how-
ever, understand them. Such an implementation offers
desirable software engineering properties like stabil-
ity, openness, incremental development, software pro-
totyping of not yet existing services, etc. [16, 19].
187
Human involvement should be based on the following prin-
ciples:
• The system interface and the interfaces of components
should support the intuition of the users and employ
their experience. There are no very strong reasons
against if the interfaces simulate existing business pro-
cesses. It has the advantage that it reduces the risks of
business process reengineering mentioned in [22].
• So long as the non-computerized version of an ac-
tivity is not substantially worse than its computerized
version, the non-computerized version should be pre-
ferred. The business process reengineering and soft-
ware development costs and the expenses connected
with hardware purchasing and the system run are very
high and often not taken into account. There can be yet
another loses connected with the loss of staff knowl-
edge related to the traditional processes and with the
expenses of staff training.
The experience of the authors with SOA indicates that the
above points are in SOA quite easily implemented. Incom-
plete computerization is therefore no drawback, it can be an
important advantage.
We stress out that the user-oriented interfaces are a con-
cept to a high degree independent on the tools and tech-
niques used to transfer the messages between the services.
Typical solutions of message transfers can be:
1. Direct transferring of a user-oriented message M
(e.g. an invoice possibly coded in XML) via a mid-
dleware.
2. SOAP-document encoding protocol.
3. Other transport means transporting M (e.g. in REST
[9] manner).
Note that the use of SOAP-RPC based on remote pro-
cedure call leads to talkative procedural (implementation-
oriented) interfaces. It often leads to SOA antipattern
Chatty Service [2].
The solution 1 tends not to obey public standards but it
implies the need that the format of M must be agreed by
communicating partners as a proprietary solution. It has
[21] obvious drawbacks. The drawbacks in confederations
are, however, quite bearable whereas the drawbacks of the
use of the cumbersome quickly changing and obsoleting
standards can be unacceptable.
7. Towards User-Oriented Interfaces (Service
Adapters)
Confederations have the structure from Fig. 2. Any con-
federation should have its global interface – one or more
 AC AC
G G
6 S
7 o
? /
 S
w
FEG FEG

   
UC - Middleware - G AC UC - FEG Middleware FEG - G AC
   

6 6
? ?
G G
AC AC

Figure 2. Software confederation with gates Figure 3. The structure of a confederation

portals. The services must be connected to a middleware,
usually via gates (sockets) G. The services need not be web
services in the sense of W3C or OASIS.
The services are implemented as autonomous pieces of
software (components) that can be usually developed au-
tonomously4 . We therefore call them autonomous compo-
nents (AC) [13].
The development and maintenance of service-oriented
systems is substantially simplified if the interfaces of the
AC’s are stable (not varying) and independent on the im-
plementation details of the components. It is quite easily
achievable if it is the case when the interface is based on
user knowledge domain languages.
If it is required that the gate G from Fig. 2 should offer
an access to all functionality of the corresponding compo-
nent, the gate must usually disclose the main features of the
component’s implementation. Under such a condition the
‘language’ of G must be to some degree implementation
oriented. As such it is not stable enough neither optimal
for the communication partners of the given autonomous
component. The main problem is that it discloses imple-
mentation details. It is known as a very dangerous feature
[27].
It follows that there must be a tool transforming mes-
sage formats. We can use for that a yet another type of
autonomous components (services) – front-end gate (FEG)
[15]. FEG is again an autonomous component (peer) with
the external properties similar to user gates: from the devel-
oper’s point of view it is a white box and a node (service) of
the peer-to-peer network of components forming the con-
federation.
4 It is possible and often desirable to implement (pack) several related
services into one software component. If designed properly, it can increase
the autonomy of the component and reduce development, administration,
and maintenance costs. To use analogy: the car services are not provided
in the form of one service type per one service provider but one service
with front-end gates. One AC can have none,
one, or more front-end gate(s).
Front-end gates play several roles5 :
• They stabilize and generalize the interfaces of compo-
nents – the interface based on a problem-oriented lan-
guage.
• They can provide different interfaces of given AC for
different groups of users/partners.
• In some situations one FEG can provide access to more
than one autonomous component. This feature can be
used to implement composite services [24].
The interface of a FEG can be specified by a language L
based on the knowledge domain and languages of the users
of the autonomous component.
There is a good chance that L will be able to specify se-
mantics of an AC in the form required by its partners. As
FEG is used as a ”white box”, the properties of L (if not
L itself) must be specified during the development of the
entire system. This task is similar to the task of the speci-
fication and design of user interface components (portals),
compare [16]. The specification of gates and front-end gates
can simplify the system specification and documentation. If
the interfaces are user oriented, it can happen that the only
documentation of the system is the description of the inter-
faces.
FEG can be also felt and used as an enhancement of mid-
dleware services (Fig. 3). The specification of its properties
can be therefore felt as a specification of middleware func-
tions. In other words, the developers develop in this case
rather the infrastructure than the applications (see [12]). It
opens the opportunity to use proprietary standards in this
area instead of the international ones if appropriate.
5 FEG is a generalization of Object Adapter from object-oriented

provider for a set of auto repair and maintenance activities (services). methodology. FEG can be viewed as an Service Adapter – compare [10].

188
 In confederations the formats of messages between large
autonomous components can be based (as we have seen)
on proprietary XML formats or XML-based standards like
RDF, SOAP, etc. The issue is when to use standard formats
and when an ad-hoc customer-oriented solution.
The first choice can benefit from the know-how of a stan-
dardization committee. It leads to formats generally known
and usable. But the standards can be, however, obsolete,
changing, not well suited to the particular needs and – what
is the most important issue – overly cumbersome (hundreds
of pages of a text difficult to read, compare UDDI and also
the design antipattern Designed by a Committee, see [4]).
The national or international standards are often too
dependent on object-oriented philosophy or vendor inter-
ests. Many users prefer message formats that would cor-
respond/reflect the syntax (and semantics) of their profes-
sional user-oriented languages and/or intuition. There is a
good chance that the interfaces based on professional (user
related) languages will be stable as they benefit from a long
term experience. Such languages need not disclose the way
the program is designed/structured.
The proprietary solutions can easily result into Babel of
formats. If, however, the message formats reflect (describe)
properly the notions of some well established knowledge
domain, the Babel need not arise. It can be expected in
the confederations having quite stable partnerships between
components.
8. Standards and Business Processes
Business processes are crucial for the software systems
supporting business activities. Let us summarize (obvious)
facts important for the design and use of business processes.
A business process can cause substantial losses if
1. it involves untrustable business partners;
2. it is not flexible enough to respond ”on the fly” prop-
erly on emergency situations like supply failures, er-
rors/deficiencies in process definition (design) due the
fact that the data used in the definition were not of a
satisfactory quality, there can be sudden changes in
business plan (e.g. parts suddenly needed to respond
to sudden crashes or failures), etc.
It is clear that the second reason is more common in small
economies, in small firms, and for business involving prod-
ucts produced in short series (e.g. specialized machine tools,
rare chemicals, etc.). The processes are often designed us-
ing statistical analysis of data bodies being as large as pos-
sible. Small factories are, however, unable to collect data
collections large enough to be able to support optimization.
Flexibility of business processes is more and more desir-
able for large firms, car producing factories inclusive.
189
A business process P is typically generated (enacted) on
a request of a user (process owner) responsible for the busi-
ness consequences of the process. It is desirable to have
some model (template) M of the process. M is during the
process enactment parameterized and modified. The result
is a process control structure C. C can be a data structure
describing the process structure and process state. C can be
again in different languages. BPEL [1] is recommended to
be used for C now. M is a part of business intelligence of
an enterprise often based on a long-term experience. M can
therefore be based on various process modeling/definition
standards. BPML [5] or BPEL can be used here.
P is ”executed”, i.e. C is used to control the actions re-
quired by P . It follows that C must store the state of the pro-
cess. This note is important as in e-commerce (and there-
fore in alliances) the communication of services tend to be
stateless and specific turns are therefore necessary. Dur-
ing the execution of the process P the structure C can be
modified to respond to unexpected problems and situations
(rejects, failures, temporarily not available resources, and
snags in process models).
C can be in some situations generated directly, without
the model M .
9. Implementation of Business Processes Al-
lowing Business Agility
If we implement business processes in service-oriented
systems, we must decide how to represent the model M and
the control structure C and how to implement the above
issues. We propose the following solution ([20]; compare
Fig. 4):
1. The model M of a business process can be stored in
database(s) of models and can be generated from con-
trol data of already performed processes.
2. During the process enactment a new service (peer)
PM called process manager is created. PM uses the
control structure C generated (possibly) from M . PM
communicates with the process owner. The process
owner usually starts and supervises the enactment of
his/her processes.
3. P can be on-line modified and its actions can be su-
pervised and committed by its process owner. P com-
municates with services providing the steps of the pro-
cess. The communication is based on messages having
user-oriented declarative formats. The services can re-
turn the information about the results of their actions
(e.g. OK, some problems occurred, failure) to P .
As the process control service C of P can be hidden in its
process manager PM , PM can use any appropriate process
control standards (e.g. BPEL [1], workflow [29], or Aris
[11]; even text descriptions can be used here).
 g process
enactment
Portal  etary) variants. The variants can be sometimes too
request
A owner
6parameters
interactions
modifications
? ?
datastore C service - service C:
of models generation process control
 B @
commands for services performing  B @
business process steps  B @ not provide exactly what is needed (see point 1) and
 B @ can lead to the antipattern Vendor Lock-In [4].
services performing the actions
Figure 4. Implementation of business pro-
cesses in SOA. Note that C can be edited
from scratch (without datastore of models)
The model M of P can be in different languages like
XML dialects or formalized natural languages (plain text)
and stored in different repositories. The communication be-
tween process manager and the software components pro-
viding process operations can be in different protocols in-
dependently on the choice of the standard for C, if appro-
priate. It is also possible under some arrangements to enable
FEG to provide security functions like encoding/decoding,
e.g. to apply new WS-* standards for C. It is reasonable
and often necessary to hide the channels between appli-
cation services and their front-end gates into a protected
area. So we must cope with the explosion of standards, re-
tain business intelligence and data depending on ”obsolete”
standards – we must avoid the standardization paralysis.
We think that the complains saying that SOA is based on
too quickly developing technologies should be rather com-
plains against quickly developed standards often designed
such that the enterprises using them are induced to use
the support of large software vendors (the situation is also
known as vendor lock-in antipattern). Our proposal has a
further advantage: Process manager can in fact orchestrate
all service types. It can therefore orchestrate process man-
ager services as well. So we need no process orchestration
standards for the near future.
10. Data Store Services
Many standards to be applied in service-oriented systems
implicitly assume or work well only if the point-to-point
communication is used. It is known as a SOA antipattern
[2]. Various variants of multipoint communication in SOA
need not be provided by middleware for the following is-
sues:
190
1. Multipoint communication has many specific (propri-
specific – so it is then doubtful whether to standardize
them. An example is a network of real-world services
that can replace each other under some conditions only
(e.g. some operations on A can be performed by an op-
eration of B but not vice versa; it can depend on the
preferences of the requesters).
2. If the communication is performed by a middleware,
the middleware must be as a rule bought from a vendor.
It can be costly and sometimes the middleware need
A good alternative is to generalize front-end gates so that
they can maintain/contain a data store of messages (service
requests) so that proprietary needs are met. The full (non-
proprietary) standardization of multipoint communication
then can be postponed till enough experience and best prac-
tices can be used – or can be postponed for ever.
Similar turn can be used if we want to integrate batch
applications into a service-oriented system [20].
11. Conclusions
It is often forgotten that it is necessary for service-
oriented systems supporting business processes to be com-
posed as tools enabling symbiosis of software and its users.
The users bring to the system their own dialects, habits,
and culture. If the users should give their best to achieve
the complex goal, it is necessary for the software part of
the system to communicate with the users with their lan-
guage. Many different tasks can be supported by user aware
service-oriented systems – software confederations. As
people are used to use their own dialects (that is typically
used for decades), it is reasonable to support these dialects.
Such dialects tend to be stable (not changing), understand-
able by users, and imply coarse-grained interfaces.
Every such a language leads to a proprietary standard. It
is not reasonable to design another incompatible standard –
even if it is intended for world-wide use, as such a standard
cannot fulfill the needs of so wide spectrum of existing user
domain languages. Applying an artificial world-wide stan-
dard would worse the reactions of the people involved into
the systems as they will be forced to use language different
from their long time tuned one.
Many complains on service orientation can be charac-
terized as consequences of the antipattern Standardization
Paralysis (overuse of latest standards). We have shown that
it can be in practically important cases avoided by imple-
mentations based on proper use of the service-oriented phi-
losophy and techniques. It is a good message for interna-
tional standardization effort as it can benefit from the long
term experience with best practices and de-facto standards.
Acknowledgement This research was partially supported by
the Program ”Information Society” under project 1ET100300517.
References
[1] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein,
F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trick-
ovic, and S. Weerawarana. Specification: Business pro-
cess execution language for web services version 1.1, 2003.
http://www-106.ibm.com/developerworks/library/ws-bpel/;
[2] J. Ang, L. Cherbakov, and M. Ibrahim. SOA antipat-
terns, Nov. 2005. http://www-128.ibm.com/developerworks
/webservices/library/ws-antipatterns/.
[3] K. Beck, M. Beedle, A. van Bennekum, A. Cock-
burn, W. Cunningham, M. Fowler, J. Grenning, J. High-
smith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C.
Martin, S. Mellor, K. Schwaber, J. Sutherland, and
D. Thomas. Agile programming manifesto, 2001.
http://www.agilemanifesto.org/.
[4] W. J. Brown, R. C. Malveau, H. W. S. McCormick, III, and
T. J. Mowbray. AntiPatterns: Refactoring Software, Archi-
tectures, and Projects in Crisis. John Wiley & Sons, New
York, 1998.
[5] Business Process Management Initiative. Business process
modeling language, 2004. http://www.bpmi.org/downloads
/BPML-BPEL4WS.pdf.
[6] F. Cohen. Java Testing and Design: From Unit Testing To
Automated Web Tests. Prentice Hall Publishing, 2003.
[7] J. Dyché. The CRM Handbook: A Business Guide to Cus-
tomer Relationship Management. Addison Wesley Profes-
sional, Boston, 2002.
[8] T. Erl. Service-Oriented Architecture: Concepts. Technol-
ogy, and Design. Prentice Hall PTR, 2005.
[9] R. T. Fielding and R. N. Taylor. Principled design of the
modern web architecture. ACM Trans. Internet Techn.,
2(2):115–150, 2002.
[10] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
Patterns. Elements of Reusable Object-Orieneted Software.
Addison-Wesley, Boston, MA, 1993.
[11] IDS Scheer. Aris process platform. http://www.ids-
scheer.com/international/english/products/31207.
[12] J. Král. Middleware orientation: Inverse software devel-
opment strategy. In W. Wojtkovski, W. G. Wojtkowski,
S. Wrycza, and J. Župančič, editors, Systems Development
Methods for Databases, Enterprise Modeling, and Work-
flow Management, pages 385–396, New York, 1999. Kluwer
Academic/Plenum Publishers.
[13] J. Král and M. Žemlička. Autonomous components. In
V. Hlaváč, K. G. Jeffery, and J. Wiedermann, editors, SOF-
SEM’2000: Theory and Practice of Informatics, volume
1963 of LNCS, pages 375–383, Berlin, 2000. Springer.
[14] J. Král and M. Žemlička. Electronic government and soft-
ware confederations. In A. M. Tjoa and R. R. Wagner,
editors, Twelfth International Workshop on Database and
Experts System Application, pages 125–130, Los Alamitos,
CA, USA, 2001. IEEE Computer Society.
191
[15] J. Král and M. Žemlička. Component types in software con-
federations. In M. H. Hamza, editor, Applied Informatics,
pages 125–130, Anaheim, 2002. ACTA Press.
[16] J. Král and M. Žemlička. Software confederations – an ar-
chitecture for global systems and global management. In
S. Kamel, editor, Managing Globally with Information Tech-
nology, pages 57–81, Hershey, PA, USA, 2003. Idea Group
Publishing.
[17] J. Král and M. Žemlička. Software confederations and al-
liances. In CAiSE’03 Forum: Information Systems for a
Connected Society, Maribor, Slovenia, 2003. University of
Maribor Press.
[18] J. Král and M. Žemlička. Service orientation and the quality
indicators for software services. In R. Trappl, editor, Cy-
bernetics and Systems, volume 2, pages 434–439, Vienna,
Austria, 2004. Austrian Society for Cybernetic Studies.
[19] J. Král and M. Žemlička. Architecture, specification, and
design of service-oriented systems. In Z. Stojanovic and
A. Dahanayake, editors, Service-Oriented Software System
Engineering: Challenges and Practices, pages 182–200,
Hershey, PA, USA, 2005. Idea Group Publishing.
[20] J. Král and M. Žemlička. Implementation of business pro-
cesses in service-oriented systems. In Proceedings of 2005
IEEE International Conference on Services Computing, vol-
ume II, pages 115–122, Los Alamitos, CA, USA, 2005.
IEEE Computer Society.
[21] J. Král and M. Žemlička. Software architecture for evolv-
ing environment. In K. Kontogiannis, Y. Zou, and M. D.
Penta, editors, Software Technology and Engineering Prac-
tice, pages 49–58, Los Alamitos, CA, USA, 2006. IEEE
Computer Society.
[22] T. K. Landauer. The Trouble with Computers. MIT Press,
1995.
[23] B. Lowson, R. King, and A. Hunter. Quick Response: Man-
aging the Supply Chain to Meet Consumer Demand. John
Wiley & Sons, New York, 1999.
[24] Z. Maamar, D. Benslimane, C. Ghedira, and M. Mrissa.
Views in composite web services. IEEE Internet Comput-
ing, 9(4):79–84, 2005.
[25] C. M. MacKenzie, K. Laskey, F. McCabe, P. F.
Brown, and R. Metz. Reference model for service-
oriented architecture 1.0, commitee specification 1, 19
july 2006, 2006. http://www.oasis-open.org/committees
/download.php/19361/soa-rm-cs.pdf.
[26] D. Rowe. e-government motives & organisational frame-
work. In J. Pour and J. Vořı́šek, editors, Systems Integra-
tion 2002, Conference Presentations, pages 93–99, Prague,
Czech Republic, 2002. Prague University of Economics.
[27] I. Sommerville. Software Engineering. Number 42765 in
International Computer Science. Addison-Wesley, Reading,
MA, 5th edition, 1996.
[28] W3 Consortium. Simple object access protocol, 2000. A
proposal of W3C consortium. http://www.w3.org/TR/SOAP.
[29] Workflow Management Coalition. Workflow specification,
2004. available at http://www.wfmc.org/standards/docs/Wf-
XML-11.pdf.