Flexible Business-oriented Service Interfaces in Information Systems

Michal

Zemli

cka

1,2

and Jaroslav Kr

2,3

Department of Software Engineering, Faculty of Information Technology, Czech Technical University in Prague,

Praha, Czech Republic

Network and Labs Management Center, Faculty of Mathematics and Physics, Charles University, Praha, Czech Republic

Department of Computer Systems and Communications, Faculty of Informatics, Masaryk University, Brno, Czech Republic

Keywords:

Flexible User-driven Integration, Architectural Services, Large Software System in SME, User-oriented

Service interfaces, Flexible SOA.

Abstract:

Information systems supporting ﬂexible business in small-to-medium enterprises must be easily modiﬁable

under the supervision of their users. The users (business people) must take active part in agile system devel-

opment and maintenance. The systems must be able to integrate large legacy systems and to communicate

with the systems of independent business partners. Business processes need not be executed by a single ERP.

We discuss a variant of SOA able to meet these requirements. The discussed SOA uses communication pro-

tocols based on problem-oriented languages. We propose a concept of organizational (architectural) services

generalizing the concept of connectors and routers. The power and usefulness of the proposal is demonstrated

on the examples of service composition, business-oriented interfaces, agile business processes, portals, and

gateways. The proposal is based on experience from practical SOA projects.

1 INTRODUCTION

Information systems are permanently becoming more

complex. They must support agile business processes,

must have a proper architecture, and cannot be de-

veloped and maintained using classic software engi-

neering attitudes (Royce, 1970; Yourdon, 1988; Som-

merville, 2010). The crucial reasons are:

• Large information systems cannot be developed

and maintained within reasonable costs and dead-

lines if a single-step process is used. The system

must enable agile changes of business processes

and agile maintenance.

• System users must often take part in the sys-

tem supervision, development, and maintenance.

They must therefore understand the communica-

tion among system components.

• It is necessary to integrate large legacy systems

and third-party products to reduce expenses, meet

terms, and to preserve business knowledge.

We will show that the requirements can be met

if the developed systems have the following key fea-

tures:

1. The systems have a service-oriented architecture

with coarse-grained components having coarse-

grained business-oriented interfaces.

2. The services are connected by a virtual commu-

nication network of active elements being again

services. We call them architectural services and

the systems using them confederations (Kr

al and

Zemli

cka, 2013).

The concept reﬂects the needs of small-to-medium

business. We will discuss the structure, features, and

implementation principles of some architectural ser-

vice types that have proven their quality in practice.

We will summarize the reasons why confederation is

a very powerful generally applicable concept.

Structure of the paper: Section 2 gives an

overview of the critical issues faced by current busi-

ness information systems. Section 3 deals with archi-

tecture patterns solving the issues. The last section

summarizes the results and gives recommendations.

2 BUSINESS-ORIENTATION AND

INTEGRATION

A proper architecture enables almost independent de-

velopment of system components. It is not the only

164

Žemli

cka M. and Král J..

Flexible Business-oriented Service Interfaces in Information Systems.

DOI: 10.5220/0004888901640171

In Proceedings of the 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2014), pages 164-171

ISBN: 978-989-758-030-7

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

advantage. Below proposed architectures:

• allow easy integration and replacement of legacy

systems and third party products,

• simplify insourcing and outsourcing,

• cheapen, fasten, and uprate the development,

• enable agile business processes and agile develop-

ment,

• make the system development and maintenance

more efﬁcient; users could take part in system

development, maintenance, and operation; some

task can be solved by users alone.

2.1 Small-to-medium Business

Small or medium-sized enterprises and organizations

(SME) form a signiﬁcant part of contemporary econ-

omy. SME must do their business processes (BP) in a

globalized market and global social environment. BP

of SME must promptly react on the dynamic changes

in business environment.

The dynamics of the business processes in SME

requires almost always a direct active participation of

business people and managers. They must have the

possibility to utilize their business knowledge, experi-

ence, abilities, and skills. Smaller companies usually

do not have enough IT people having necessary busi-

ness knowledge. There can be budget issues. Last but

not least, the business culture in SME is different from

the culture in big companies (Robbes et al., 2013).

It follows that the modiﬁcation of the processes

must be cheap and transparent for business people.

It also means that legacy systems and open software

must be often used.

Business processes in SME are usually open. It

is, they often cross company borders. Some parts of

the processes must then be done by independent orga-

nizations using classic business procedures based on

the rules and documents of commercial cooperation.

Business partners can be changed dynamically. It is

then desirable to allow direct cooperation between in-

formation systems of the business partners.

The information systems of cooperating business

partners behave like (composite) SOA services using

a document-oriented communication. We point out

that the documents are for us coarse-grained pieces of

communication well understandable by users. They

can eventually have the form of documents in the

sense of electronic data interchange (EDI) if appro-

priate. XML-based formats are often preferred now.

The SOA uses organization services acting as

wrappers, routers, gateways, orchestrators, and user

interface. The message paths can be inﬂuenced by

business process owners. The individual ERP can

use for the steps of the processes the same approach.

2.2 Business-oriented Systems

Human aspects are crucial for the formulation of the

aims and requirement speciﬁcations of information

systems as well as their development and use. Infor-

mation systems inﬂuence real world processes. These

aspects are especially important in the case of infor-

mation systems supporting business processes.

The dynamic character of modern economy im-

plies that the business processes ought to be agile, i.e.,

easily modiﬁable by users. The business partners

can be changed dynamically. It, together with the

growing complexity of software, implies that the sys-

tem must be able to integrate/use existing large legacy

applications and to utilize already existing informal

personal knowledge and social business contacts. It

avoids risky business process restructuring.

Taken together the communication should have

the form of an exchange of legible messages and

the system as a whole has a speciﬁc service-oriented

architecture (confederation). It uses coarse-grained

business-oriented communication between coarse-

grained software components.

The documents used for service to service com-

munication inside an information system and between

information systems should be intuitively understood

by users. It can be digital variants of the (business)

documents. Their form can be agreed by communi-

cating parties. The standards like EDI can be used but

there are reasons why EDI has not been generally ac-

cepted. The transparency of communication and the

agile choice of business partners are otherwise hard to

achieve. It allows agile on-line modiﬁcations of busi-

ness processes. It is necessary to support agile choice

of message addressees – of business partners.

We will discuss technologies enabling encapsula-

tion of software artifacts using proxy services solv-

ing the above mentioned requirements. The technolo-

gies further enable easy implementation of general-

ized capabilities of Business Process Model and No-

tation (BPMN, (Object Management Group, 2011)) –

understandability, openness, gateways, etc.

The proposed solutions are good to support busi-

ness processes in back ofﬁce as they use business-

oriented interfaces. It solves issues from (Boyd et al.,

2012a; Boyd et al., 2012b).

FlexibleBusiness-orientedServiceInterfacesinInformationSystems

165

3 SOFTWARE

CONFEDERATIONS

Software confederations are service oriented systems

with loosely coupled coarse-grained services being in

principle of three types:

1. Business Application Services: encapsulated

business applications and business systems sup-

porting basic software operations (example: ac-

counting service);

2. Architectural Services: allowing creation and

changes of the architecture of the built system

(example: proxy/generalized application wrapper

implemented as a service – front-end gate; see be-

low);

3. SLA Services: organizational business services at

the SLA level (e.g., identity management imple-

mented as a service) where service requester must

wait for the response of service provider, i.e. the

services communicate synchronously.

3.1 Basic Service Types

We will describe service types most frequently used

in confederative systems. The descriptions take into

account both development and maintenance point of

view.

3.1.1 Business Application Service

Confederations have a two-tier structure. The basic

tier is the collection of services providing basic busi-

ness capabilities. A typical variant of such services

is a properly wrapped business application or even

entire information systems of business partners. The

wrapped entities usually have a legacy interface sup-

porting a direct communication with users and with

other applications (Fig. 1).

A

partner services

AKA

? 





Primary

gate

Legacy

interface

APPLICATION

a) built-in primary gate

A

partner services

AKA

? 





Primary

gate

Legacy interface

APPLICATION

b) primary gate wrapping

legacy interface

Figure 1: (Business) application service with primary gate

and legacy interface.

The services must be by deﬁnition capable to take

part in peer-to-peer communication. It is preferable to

implement this capability using a component called

primary gate (Fig. 1). Primary gate can eventually

utilize (a part of) the legacy interface (Fig. 1b).

The communication with partner services pro-

vided by the primary gate is as a rule due many rea-

sons ﬁne grained and remote procedure call oriented.

We have, however, seen that the interfaces should

be (like their real-world counterparts) document and

user knowledge domain oriented. We therefore need

a tool able to transform these different communica-

tion protocols. It can be achieved using a speciﬁc

organizational service type called front-end gates de-

scribed below, see also Fig. 2. These services pro-

vide the capability of adapters (compare (Newcomer

and Lomow, 2005; Krafzig et al., 2004; Reynolds and

Antony, 2010). Their construction as services signiﬁ-

cantly increases system variability and ﬂexibility.

Application services can communicate using in-

telligent coarse-grained communication protocols.

The communication is provided by network of orga-

nizational (architectural) services forming the second

tier of the system.

The use (integration) of existing applications sim-

pliﬁes and shortens the development and reduces the

risk that the newly developed system will not do what

is required. On the other hand there is a risk that the

application can be changed by a third party or that it

cannot be used for other reasons.

In such a case it is possible to replace it by an-

other properly encapsulated application. The replac-

ing application can be newly developed. If business-

oriented service interfaces are used, it is likely that

change propagation can stop at the front-end gates.

If the interface changes are not requested or needed

by the partners, the business-oriented service inter-

face available for them usually need not change.

This service interface stability signiﬁcantly im-

proves stability of the system and simpliﬁes and de-

composes system maintenance.

Throughout this paper the communication is men-

tioned generally (typically without restriction of type

or means). If necessary, the restrictions are included

into the ﬁgures.

3.1.2 Basic Architectural Services

Architectural services are organizational services that

can be viewed as a generalization of connectors in the

sense of (Mikic-Rakic and Medvidovic, 2002). Long

term experience with the use of architectural services

in manufacturing control systems (Kr

al et al., 1987;

al et al., 1979) and elsewhere, see, e.g., systems

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

166

produced by ICOS Praha and logistics systems pro-

duced by ICZ, proved the usefulness of the concept.

We currently study applicability of our approach in

e-government using virtual ﬁlling rooms.

The transition from classic connectors to architec-

tural services looks conceptually simple: it is just an

implementation of the connector as a service (CaaS).

The issue is that the communication with the connec-

tor as a service must be sometimes asynchronous and

must use multipoint protocols. It may imply limita-

tions for the use of synchronous communication pro-

tocols. Our experience from practical and educational

projects shows that mastering this paradigm is often

very tough. Some people doubt that such an approach

can work – although the cases of its successful appli-

cation (industrial projects inclusive) were described

many years ago, see e.g. (Kr

al and

Zemli

cka, 2004;

al et al., 1979). In comparison to classic connec-

tors CaaS have the following advantages:

1. higher independence of protocols enabling vari-

ous use policies;

2. better opportunities to interconnect almost inde-

pendent components;

3. possibility of agile supervision of system opera-

tion by users and managers;

4. new incremental development methods and espe-

cially agile variants of maintenance.

We present here architectural service types we have

already used or that support especially interesting ca-

pabilities. Connectors as services play in confeder-

ations the role of the Petri net ”places” used in par-

allel automata models (Petri, 1962; Jensen, 1997).

It could be an issue for the developers used to use

object-oriented paradigm. There are many situations

(like broadcasting or message composition) where the

asynchronous communication is necessary.

Front-end Gate

Front-end gates are special services translating in-

terface from the form requested for the integration

(matching partner needs) to the form supported by

the application service primary gate and vice versa.

It is possible to use techniques originally developed

for transducers or compilers ((Aho and Ullman, 1973;

Grune and Jacobs, 2008;

Zemli

cka, 2006)). XSLT

(W3 Consortium, 1999) can be applied in the case of

quite simple transformations of XML-based message

formats. Front-end gates can be equipped by capabil-

ities enabling business process owners to redirect the

communication and to log it (Fig. 2). For the sake

of simplicity these capabilities are not shown in most

ﬁgures.

admin

A









 

log







partner services

AKA

? 





Front-end gate

Primary gate

APPLICATION

Problem-(user-)oriented interface

Application-oriented interface

Figure 2: Application service and its front-end gate.

Front-end gate in Fig. 2 wraps the application ser-

vice to hide peculiarities of application service inter-

face. It is a very powerful implementation of Par-

nas’s recommendation on information hiding (Parnas,

1979).

An application service can be easily replaced by

another one. It greatly simpliﬁes the integration of

legacy systems, third-party products, and open source

artifacts and also almost independent development of

the services.

The transparency of log records is preferable for

the business management and for solving business is-

sues and enhancement of business intelligence. So the

proposal enables the implementation of all the capa-

bilities mentioned in Section 2. The capabilities are

generally applicable. The pattern from Fig. 2 offers

further interesting generalizations, see e.g. Fig. 3.

partner services

(e.g. operation functions)



partner services

(e.g. management functions)



Front-end gate 1 Front-end gate 2

HYH

Hj 



*





Primary gate

APPLICATION

Figure 3: Application service and with multiple front-end

gates.

The communication between partners and a front-

end gate can be supported by other means than the

communication between the front-end gate and the

supported service if necessary. The front-end gates

can serve also as service connectors for various com-

munication means or as middleware gateways. The

basic principles of the concept of FEG was introduced

in (Kr

al and

Zemli

cka, 2002). The wrapper in (Erl,

2009) has similar but less general abilities.

FlexibleBusiness-orientedServiceInterfacesinInformationSystems

167

Portal

For a signiﬁcant group of users the access point to the

system is provided by a special service called portal.

It helps the users to specify what they need and how

to tell it to the system. It also presents the users the

reactions of the system.

In more detail: The portal usually presents the

user an overview of available activities. If the user

selects one of them, the portal should lead him/her

through the speciﬁcation of necessary and optional

parameters. The portal then gives the collected re-

quest to the services that are assigned and able to pro-

cess such requests. If the request is incomplete or im-

precise, the portal should lead the user through the ad-

ditional requirements. In some cases it is reasonable

to pass the non-standard request to individual process-

ing (emergency, rare cases).

From the more technical point of view a portal is

a service providing usually web-based user interface

allowing users to check all their service requests and

responses. From the system side it is a service sending

and receiving messages with various access rights.

Client

portal

-

Intranet

portal

-

SYSTEM

KERNEL

Business process

management portal

Figure 4: Example of a system with multiple portals.

It is often reasonable to equip confederative infor-

mation system with multiple portals. Typically there

will be speciﬁc portals for employees (intranet) and

for customers (extranet) and there can be various spe-

cial portals for special user groups (e.g. process own-

ers).

It is also possible to encapsulate various portals

into composed ones. The composed ones can dele-

gate handling of particular user interfaces to particular

portal services and handle only integration of the user

interface into a single access point (Fig. 5). Data and

computation intensive interfaces should be provided

by specialized portals. The separation of concerns re-

duces demand on their throughput and simpliﬁes their

development, maintenance, and use.

From the maintenance point of view the separa-

tion of complicated user interface agendas into sep-

arate services signiﬁcantly simpliﬁes the localization

of errors and their correction.

The solution is logically similar to portlets (OA-

SIS, 2008). The encapsulation of subportals into spe-

cial services allows a better load balancing and a

higher overall throughput.

A

-

Uniﬁed

access

portal









Basic

agenda

portal

-

Special

agenda

portal

-

Service

network

(system

kernel)

Figure 5: Grouped multiple portals.

3.1.3 Advanced Architectural Services

Head of Composite Service

Larger systems tend to an integration of logically

closed smaller parts. Such integrations are usually

layered or hierarchical. Real-world services tend to be

integrated hierarchically, for systems supporting them

we decided to use also hierarchical integration.

We call logically closed groups of services that

can behave as logically single service composite ser-

vices. The group is equipped by a special service rep-

resenting the group and providing communication of

the group with ”the rest of the world”. All the com-

munication of any of the services in the group to and

from any service outside the group must go through

this service. This policy can be weakened (modiﬁed)

easily if necessary. We call this service head of com-

posite service. It can be again equipped by front-end

gates to match the needs of various partner service

groups (Fig. 6).

Interface for

partner group 1

Interface for

partner group 2

Front-end

gate 1

Front-end

gate 2

H 



Head of

composite

service



 H

Service 1

Service 2



Service 3

Figure 6: Composite service with head and front-end gates.

The group encapsulation simpliﬁes error localiza-

tion and system testing. The most important advan-

tage is that the services in Fig. 6 can be again indepen-

dent systems like ERP systems of business partners

wrapped by their own architectural services. The ar-

chitectural services are therefore a very powerful tool

of the information systems integration. The organi-

zational services together with other services form a

network. The organizational services there play the

role of routers.

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

168

Datastore

In structured analysis and design (Yourdon, 1988) the

systems are composed from processes and data stores.

The data acquisition and modiﬁcation is done by pro-

cesses, the data accumulation and persistence by data

stores. There is a limitation that the data can get into

and from data store only using some process.

If we want to integrate subsystems built using this

methodology, or if we need to apply batch processing,

we should equip our system with services playing the

role of data stores. They substantially differ from the

classic data store in maintenance and security aspects.

The data stores could be also equipped with tools en-

abling batch as well as on-line (interactive) process-

ing. The data stores could be used to integrate batch

and interactive subsystems together (Fig. 7).

The use of batch subsystems can substantially

simplify maintenance and stabilize the system.

Interactive subsystem

Record-oriented communication

Datastore service

Collection-oriented

communication

Batch subsystem

Figure 7: Composition of batch and interactive part of a

system.

General Architectural Service

An architectural service can have various communi-

cation partners using various languages and protocols,

a local store, supervision capabilities, and a logging

ability – see Fig. 8. Architectural services described

above are specialized cases of the general one.

A

admin

-

Console

-

Inputs

AU ?









General

architectural

service







 ?

Outputs



1

)









 

store









 

log

Figure 8: Generalized architectural service.

General architectural service is a very powerful

generalization of the concept of connector (Taylor

et al., 2009; Mikic-Rakic and Medvidovic, 2002; Bu-

res and Plasil, 2004). It can use coarse-grained pro-

tocols, supervise and redirect messages, and powerful

logging. The logs can be used by users in various situ-

ations. Examples are: business intelligence enhance-

ments, system optimization, or business court trials.

General architectural services can further use var-

ious middleware, various message formats, and var-

ious (dynamic) possibly multipoint communication

protocols.

Process Manager

Business process management can be supported by a

special service – business process manager service or

process manager for short – that controls execution of

the business process and allows a responsible person

(business process owner) to supervise and optionally

modify the run of the business process.

As information system can support business pro-

cesses of various types, it is reasonable to have mul-

tiple business process manager types. During a busi-

ness process enactment it is possible to select a proper

business process deﬁnition template that ﬁts best the

character of the business process as well as the abili-

ties and skills of its owner.

It is crucial for emergency situations whether the

process owner understands the used process deﬁnition

and whether the process interface does not compli-

cate the situation too much. The process owners must

be able to use proper supervision tools. The process

owners must understand the business process itself

(they should be domain experts).

Encapsulation of business process supervi-

sion/control/development into dedicated services

simpliﬁes their agile deﬁnition, modiﬁcation, and

enhancement by users. It is a more ﬂexible concept

than the one recommended in (Erl, 2009, Chap. 8).

The business orientation of service interfaces is

advantageous for the description of business pro-

cesses in problem domain oriented languages. Under-

standable description of individual steps can directly

correspond to the service requests. It can be useful

for system design as well as for potential system de-

bugging – many of the activities could be in such case

easily consulted with domain experts what simpliﬁes

debugging at the problem domain level.

Screen Prototype

Screen prototype is a service of a slightly different na-

ture. It is able to send and receive messages. The

received messages are recorded and displayed to the

user. The user reacts on them (either by process-

ing/performing some activities or by writing an an-

swer).

Screen (mock up) prototype is useful especially in

the following cases:

1. It can be used to simulate the communication part-

ners of a just developed service – it can mimic (or

even replace) its communication partners.

FlexibleBusiness-orientedServiceInterfacesinInformationSystems

169

2. It can serve as a ”manual” version of failed ser-

vices.

3. It can enable manual processing of rare service

requests.

4. It simpliﬁes the integration, use, and management

of batch applications.

Any standard client of our communication system

(Fig. 9) can serve as a screen prototype. Otherwise it

could be enhanced by supporting tools (Fig. 10) avail-

able to operator(s).

Partner

service(s)

-

Messaging

client

-

A

Operator

screen prototype

Figure 9: Simple screen prototype.

Partner

service(s)

-

Messaging

client

-

A

Operator

-

Legacy

application

screen prototype

Figure 10: Screen prototype with application support.

Combined Use of Front-end Gate and Screen

Prototype

If a service interface allow frequent as well as rare or

unexpected requests, it is reasonable to combine ad-

vantages of front-end gate allowing efﬁcient process-

ing of frequent requests whereas the ones that could

not be processed by the front-end gate are left for

manual processing using a screen prototype and a di-

rect interface of the application service (Fig. 11). It

could be reasonable to let a human operator eventu-

ally handle some service requests that could be pro-

cessed using the front-end gate. An example is the

situation when standard processing could fail or lead

to unwanted results. It could, for example, happen

when some hot business information is available to

the operator and is not encoded in the system.

Partner

services

-

Proxy







Screen

prototype

@R@

Front-end

gate

-

Application

service

legacy interface

primary gate

Figure 11: Application service with front-end gate and

screen prototype support.

4 CONCLUSIONS

We have discussed a speciﬁc architecture – business-

oriented software confederations – having very in-

teresting and desirable properties for system devel-

opment, use, and modiﬁcation. It enables, if used

properly, that both the development and maintenance

could be based on almost identical principles and

techniques. It further enables an easy involvement of

managers and end-users (business people).

The architecture of software confederations en-

ables gradual (incremental) integration and activation

of services and agile modiﬁcation of their collabora-

tion. Such a development enables application of cru-

cial elements of agile development of very large sys-

tems. It enables agility in the large with emphasis on

the incremental variant of the development.

From the maintenance point of view the most im-

portant technical properties are:

• simple error or failure localization;

• the changes in different components of the sys-

tem can be done using principally different tools

and attitudes (changes in communication proto-

cols, the use of logs);

• powerful information hiding in the sense of Par-

nas (Parnas, 1979).

The main business advantages are:

• Many operations can be effectively done by busi-

ness people.

• The maintenance process is cheaper, more ﬂexi-

ble, and can be felt as a continuation of system

development.

• Collaboration between developers and business

people is smooth.

A potential disadvantage could be the fact that our

recommendations are not always in full agreement

with current standards and design patterns from the

service orientation and web service domain. One

of the reasons is that the message formats should

promptly reﬂect current user needs whereas changes

of standards requires usually years. We know from

our pedagogical activities and industrial projects that

for people trained in object-oriented attitude it is com-

plicated if not impossible to accept the proposal.

It is open how to combine optimally synchronous

(call) and asynchronous (message passing) commu-

nication protocols. There are open security prob-

lems and the use of principles of confederations based

on the virtual ﬁlling rooms being in fact generalized

mailboxes accepting forms.

Our long-time experience with confederations in

practical projects has shown that the confederations

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

170

are as a rule very well maintainable and reliable.

Some of our confederations were used for decades.

They were, however, very easy modiﬁed to match

changing needs. Confederations could be very useful

in the framework of SOA ecosystems (OASIS, 2012).

It is open how they can be used in the frameworks like

ITIL, COBIT, or ISO 20000.

REFERENCES

Aho, A. V. and Ullman, J. D. (1973). The Theory of Parsing,

Translation and Compiling, volume II.: Compiling.

Prentice-Hall, Englewood Cliffs, N.J.

Boyd, A., Pucciarelli, J., and Webster, M. (2012a).

It’s worse than you think: Poor document pro-

cesses lead to signiﬁcant business risk. [Online:]

http://mds.ricoh.com/ﬁles/knowledge center/IDC

Risk WP Ricoh Eng.pdf.

Boyd, A., Pucciarelli, J., and Webster, M. (2012b). Organi-

zational blind spot: The role of document-driven busi-

ness processes in driving top-line growth. [Online:]

http://mds.ricoh.com/ﬁles/knowledge center/IDC

Revenue WP Ricoh FINAL.pdf.

Bures, T. and Plasil, F. (2004). Communication style driven

connector conﬁgurations. In Ramamoorthy, C. V.,

Lee, R., and Lee, K. W., editors, Software Engineering

Research and Applications, volume 3026 of Lecture

Notes in Computer Science, pages 102–116. Springer.

Erl, T. (2009). SOA Design Patterns. The Prentice Hall

Service-oriented Computing Series From Thomas Erl.

Prentice Hall Pearson Education.

Grune, D. and Jacobs, C. J. H. (2008). Parsing Tech-

niques. Monograps in Computer Science. Springer,

New York, USA, second edition.

Jensen, K. (1997). Coloured Petri Nets. Basic Concepts,

Analysis Methods and Practical Use. Monographs

in Theoretical Computer Science. Springer, 2nd cor-

rected printing edition.

Krafzig, D., Slama, D., and Blanke, K. (2004). Enter-

prise SOA: Service-Oriented Architecture Best Prac-

tices. Prentice Hall Ptr.

al, J., Demner, J., and Koste

cka, V. (1979). Synchroniza-

tion primitives for mass service like control software.

Polytechnica 7 (IV,1), pages 11–21. also in Proceed-

ings of IFIP-IFAC 3rd SOCOCO Conference, Praha,

1979.

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). Component types in soft-

ware conferations. In Hamza, M. H., editor, Applied

Informatics, pages 125–130, Anaheim. ACTA Press.

al, J. and

Zemli

cka, M. (2004). Service orientation and

the quality indicators for software services. In Trappl,

R., editor, Cybernetics and Systems, volume 2, pages

434–439, Vienna, Austria. Austrian Society for Cy-

bernetic Studies.

al, J. and

Zemli

cka, M. (2013). Support of service sys-

tems by advanced SOA. In Lytras, M., Ruan, D., Ten-

nyson, R., Ordonez De Pablos, P., Garc

ıa Penalvo,

F., and Rusu, L., editors, Information Systems, E-

learning, and Knowledge Management Research, vol-

ume 278 of Communications in Computer and Infor-

mation Science, pages 78–88. Springer.

Mikic-Rakic, M. and Medvidovic, N. (2002). Architecture-

level support for software component deployment in

resource constrained environments. In Proceedings

of the IFIP/ACM Working Conference on Component

Deployment, pages 31–50, London, UK. Springer-

Verlag.

Newcomer, E. and Lomow, G. (2005). Understanding SOA

with Web services. Addison-Wesley, Upper Saddle

River, NJ.

OASIS (2008). Web services for remote portlets speciﬁ-

cation v2.0. http://docs.oasis-open.org/wsrp/v2/wsrp-

2.0-spec.html.

OASIS (2012). Reference architecture foundation for ser-

vice oriented architecture version 1.0.

Object Management Group (2011). Business process model

and notation (BPMN).

Parnas, D. L. (1979). Designing software for ease of exten-

sion and contraction. IEEE Transactions on Software

Engineering, 5(2):128–138.

Petri, C. A. (1962). Kommunikationen mit automaten.

Schriften der IIM, (2).

Reynolds, W. and Antony, M. (2010). Oracle SOA Suite 11g

R1 Developer’s Guide. Packt Publishing, 2nd edition.

Robbes, R., Vidal, R., and Bastarrica, M. (2013). Are soft-

ware analytics efforts worthwhile for small compa-

nies? The case of Amisoft. IEEE Software, 30(5):46–

53.

Royce, W. W. (1970). Managing the development of large

software systems. In IEEE WESCON Proceedings,

pages 328–338. Institute of Electrical and Electronics

Engineers.

Sommerville, I. (2010). Software Engineering. Pearson

Education, 9th international edition.

Taylor, R. N., Medvidovic, N., and Dashofy, E. (2009).

Software Architecture: Foundations, Theory, and

Practice. Wiley.

W3 Consortium (1999). XSL transformations (XSLT).

http://www.w3c.org/TR/xslt.

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

Hall, 2nd edition.

Zemli

cka, M. (2006). Principles of Kind Parsing. PhD the-

sis, Charles University, Faculty of Mathematics and

Physics, Prague, Czech Republic.

FlexibleBusiness-orientedServiceInterfacesinInformationSystems

171