CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE
Susanne Patig
University of Bern, IWI, Engehaldenstrasse 8, CH-3012 Bern, Switzerland
Keywords: SOA design approaches, Service design, Case study.
Abstract: During the last years, several approaches for the design of software services in service-oriented architectures
(SOA) have been proposed. Often these approaches are too rough or too academic to provide guidance for
real world SOA projects. Moreover, since the existing SOA design approaches are often not sufficiently
validated, their successfulness in practice can be doubted. The research presented here aims at learning from
successful SOA projects. Two cases of such projects are described. In the cases similarities show up that are
distinct from existing SOA design approaches (mainly the purely academic ones) and, thus, point to
necessary enhancements of these approaches.
1 MOTIVATION
Since the initiation of service-oriented architecture
(SOA) in the 1990s, several guidelines for SOA
design have been published (see Section 2). For
companies intending to implement SOA, the mere
diversity of design directions is confusing.
Moreover, it is often not really clear whether some
published design approach results from an academic
effort, and, thus, does not necessarily work outside
the scientific clean room, or whether the approach
represents “best practices” of some number of SOA
projects. Even in the latter case it can be questioned
whether domain-independent best practices of
application software service design exist at all.
Additionally, most SOA design approaches are not
validated (e.g., Arsanjani et al., 2008; Papazoglou &
Yang, 2002) or only by small examples (e.g., Zhang,
Liu, & Yang, 2005; Erradi, Anand& Kulkarni,
2006), and usually validation is not reliable because
it was done by the authors themselves. So, sound
methodical support for the design of software
services in ‘real world’ application scenarios is hard
to find.
Finally, probably none of the proposed SOA
design approaches is complete and universally
correct. Improving these approaches requires
knowledge about facets of real SOA projects that are
currently not covered or insufficiently solved.
In response to these doubts and questions, a case
study was conducted to investigate how companies
design the service-oriented architecture underlying
their application systems; first results are presented
here. Roughly, the case study tries to find out, (1)
which services have been designed and implemented
for a particular application system or systems
landscape (descriptive research objective), and (2)
why have the services been designed in a particular
way (exploratory research objective)? Exploratory
means that practically relevant software service
design criteria and processes should be discovered to
possibly adapt the existing SOA design approaches.
From the research objectives listed above,
Section 3 derives the research design, i.e., the plan
for the investigation that links the data to be
collected to the research objectives (Yin, 2009). The
collected data currently consists of two cases that are
presented and compared in Section 4. The overall
conclusion and the next steps in our research can be
found in Section 5.
2 CURRENT SOFTWARE
SERVICE DESIGN
APPROACHES
Basically, approaches to design software services for
SOA fall into two groups (see Figure 1): principles-
driven approaches and hierarchical ones.
Occasionally, strategies of these groups are
combined (e.g., Erradi et al., 2006; Kohlmann, 2007;
Klose, Knackstedt, & Beverungen, 2007).
376
Patig S. (2009).
CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE.
In Proceedings of the 4th International Conference on Software and Data Technologies, pages 376-383
DOI: 10.5220/0002286703760383
Copyright
c
 SciTePress

Principle-Driven Approaches Hierarchical Approaches
⎯
(no steps)
Design to:
Abstraction, standardized contract,
loose coupling, cohesion,
reusability, autonomy,
statelessness, discoverability
Service Identification
Top-Down Bottom-Up
Goals Functional Areas Processes Existing Applications
Service Refinement
Service Grouping
Service Verification
Asset Analysis Requirements Analysis
Service Specification
Figure 1: Design Steps in Current Software Service Design Approaches.
Principle-driven software service design
approaches are directly linked to the heart of SOA:
There is a common understanding that service-
orientation is not primarily tied to specific
technologies, but to a set of principles that must be
obeyed in designing such architectures (Erl, 2008a;
Papazoglou & van den Heuvel, 2006). The main
principles are abstraction (services hide information
on technology and logic from the outside world),
standardized contract (services provide technical
interfaces by which they can be accessed and which
keep to some contract definition standard), loose
coupling (a service contract is independent of the
implementation of the service, and services are
independent of each other), cohesion (the
functionality provided by a service is strongly
related), reusability (the logic encapsulated by a
service is sufficiently generic for numerous usage
scenarios and consumers), autonomy (service
exercise as much control as possible over their
runtime execution environment), statelessness
(between consecutive service calls, no information
must be kept within the service) and discoverability
(service contracts contain meta data by which the
services can be found and assessed). Principle-
driven approaches, e.g., (Erl, 2008a) provide
guidelines (sometimes bundled in patterns; (Erl,
2008b)) how to realize the SOA design principles –
without defining and ordering the necessary steps.
Also hierarchical service design approaches in parts
involve SOA design principles (see below).
Hierarchical software service design approaches
prescribe a series of steps from some level of
abstraction to a set of software services. Either they
end at the design stage (e.g., Kohlmann, 2007;
Quartel, Dijkman, & van Sinderen, 2004; Zhang et
al., 2005) or they include further stages of the
service life cycle such as deployment, billing,
execution and monitoring (e.g., Papazoglou & van
den Heuvel, 2006; Arsanjani et al., 2008). It can be
distinguished between top-down approaches, which
proceed from abstract information at the business
level to service design and implementation, and
bottom-up approaches that increase the level of
abstraction during design.
Common starting points for top-down software
service design approaches are business goals (e.g.,
Kaabi, Souveyet & Rolland, 2005), functional
business areas (e.g., Levi & Arsanjani, 2002) or
business processes (e.g., Papazoglou & Yang, 2002;
Kohlmann, 2007; Quartel et al., 2004; Klose et al.,
2007). Goals describe what should be achieved by a
software service, functional areas are sets of related
tasks referring to, e.g., departments or products, and
business processes additionally consider the roles
that perform these tasks as well as the order of tasks
(Arsanjani et al., 2008; Papazoglou & van den
Heuvel, 2006). Some of the top-down approaches
rely on several types of business information or even
link, e.g., goals to functional areas and then to
business processes (Arsanjani et al., 2008).
Current bottom-up software service design
approaches (e.g., Zhang et al., 2005) try to achieve
service-orientation by wrapping existing application
systems. They use reverse engineering techniques
such as clustering to identify cohesive components,
which form service candidates.
The direction top-down vs. bottom-up mainly
refers to the identification of
service candidates.
Often these initial candidates are refined before they
are specified. The following refinement steps can be
found in both top-down and bottom-up approaches:
• Grouping: Fine-grained services that have some
kind of logical affinity (in terms of, e.g., functions
or communication; (Papazoglou & van den
Heuvel, 2006)) are grouped into more coarse-
grained services. Grouping is unavoidable for
bottom-up approaches. In top-down approaches,
it guarantees high cohesion, loose coupling and
the autonomy of services (e.g., Arsanjani et al.,
2008; Quartel et al., 2004; Erradi et al., 2006).
• Verification: Software services are checked for
their conformance to the SOA design principles
CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE
377

and adapted if necessary (e.g., Kohlmann, 2007;
Erradi et al., 2006).
In contrast to these common steps, only top-down
approaches require asset analysis: It maps the
identified and refined services either to existing
application systems that can provide these services
or to service implementation projects (Erradi et al.,
2006; Arsanjani et al., 2008; Kohlmann, 2007;
Papazoglou & van den Heuvel, 2006). Bottom-up
approaches, on the other hand, require an analysis of
business requirements and a corresponding align-
ment between business and IT (Lämmer, Eggert &
Gronau 2008).
Hybrid approaches use both top-down and
bottom-up strategies, but usually they emphasize one
strategy or the other. For example, the SOMA
method proposed by IBM predominately is a top-
down approach, but includes bottom-up asset
analysis (Arsanjani et al., 2008).
The final step of service specification is always
necessary. It defines the service interface (operations
and their signatures, given by message types for
inbound and outbound messages) and the
conversations between services (Arsanjani et al.,
2008; Erradi et al., 2006; Levi & Arsanjani, 2002;
Papazoglou & van den Heuvel, 2006). Service
specification aims, once more, for loose coupling,
high cohesion, reusability and standardization.
Figure 1 summarizes the existing approaches to
software service design. For the hierarchical
approaches, the superset of proposed steps is shown.
3 RESEARCH DESIGN
Since the challenges of software service design
result from the complexity of the underlying
application context, the research design must
consider real-life scenarios where companies have
developed services-oriented solutions (application
systems or system landscapes). When the boundaries
between the phenomenon to be observed and its
context are not evident, case studies are an
appropriate research strategy (Yin, 1981). A case
study is a qualitative empirical investigation of
contemporary phenomena within their real-life
context without the possibility to control the
situation (Yin, 2009).
To increase the external validity (generaliz-
ability) of this research, a multiple-case study is
conducted where conclusions are drawn from a
group of cases, which represent a variety of
situations (Yin, 2009). Once a phenomenon has been
shown to occur in two to three cases, it can be
generalized to develop some general explanation
(Yin, 1981). Then, further cases can be selected that
either lead to contrasting results for predictable
reasons or that state more precisely the conditions
under which the observed phenomenon occurs (Yin,
1981). This paper presents the first part of the
research, namely two cases that form the basis for a
generalization of software service design in practice.
The research objectives directly lead to the data
to be collected: A case in the sense of this
investigation is any project where an at least mid-
size company realizes SOA for some application
software by implementing a set of software services
(service inventory; (Erl 2008a)). This case definition
excludes pure SOA middleware projects from the
investigation as well as projects where services are
not yet implemented or only composed out of
existing ones. To count as ‘service-oriented’, a
system’s architecture must consist of physically
independent software packages that (1) provide
well-defined functions by standardized interfaces in
a discoverable way and (2) that primarily
communicate via message exchange (Erl, 2008a).
Though not presupposed by the definition of service-
orientation (Erl, 2008a), web services are currently
the predominant implementation technology. For
that reason the comparability of the cases is
guaranteed by requiring that at least some of the
service interfaces are specified by the Web Services
Description Language (WSDL).
The phenomena to be observed within each case
are the software services and the process of their
design. A software service is defined by its interface,
which groups operations. Each operation has a
signature consisting of the types of the inbound and
outbound messages as well as optional information
on conversations. A service design process usually
comprises phases in some chronology and criteria
for service design.
The context of the phenomena to be investigated
includes all information that potentially influences
SOA design, namely:
• General context: the company, its branch,
organization, IT department (size and experience)
and existing systems landscape
• Project context: SOA motivation, project size and
duration
• Requirements context: needed functionality,
quality characteristics as well as technical or
organizational constraints
• Development context: degrees of freedom
(descendent from green-field development over
reengineering and migration to wrapping), service
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies
378

provisioning (only within some controllable
service inventory vs. to unknown consumers)
In the investigation presented here, the information
on phenomena and context was gathered by
interviews (both face-to-face and by phone) with
several persons representing distinct roles (e.g.,
software architect, software developer, project
manager), by document analysis (design guidelines,
service specifications, models) as well as by systems
analysis (sample services). The final case report was
checked for correctness by the contact persons of the
companies. Very condensed versions of the case
reports are contained in the following Section.
4 CASE STUDY
4.1 Case 1: Mail Order Company
Context. The case stems from a leading trading and
services corporation; its 123 companies employ
around 50,000 persons in nearly 20 countries. The
IT department has circa 230 employees for
development. The application systems landscape
consists of 200 application systems and includes a
central mainframe application that is responsible for,
e.g., customer data management, invoicing and order
picking. Since the mainframe application was
written in assembly language (current in-house
software development uses Java and J2EE), it should
be replaced by a new application system.
In 2002/2003 it was decided to conduct SOA-
directed reengineering of the mainframe application
for two reasons: First, SOA is able to cope with the
unavoidable heterogeneity (in terms of functionality,
technology, life cycle and controllability) of the
corporation’s systems landscape, which is a
consequence of continuous acquisitions of
companies. Secondly, SOA increases the flexibility
to react to new requirements such as seasonal
business (Christmas etc.), promotions and changing
legal regulations.
The new service-oriented application system
should cover the functionality to manage customer
orders (i.e., order management in the narrow sense
of the word, stock management, customer data
management, invoicing and order picking), which is
currently covered by several application systems
including the mainframe. The consumers of the
intended services are several types of clients (e.g.,
call center clients, web shop clients ‘business to
consumer’ (B2C) and ‘business to business’ (B2B))
that are mostly under the control of the corporation.
Especially the management of customer data is
subject to strict security restrictions, and the web
shop client for consumers (B2C) is performance-
sensitive.
The service design process, summarized in
Figure 2 using the Business Process Modeling
Notation (BPMN), is hybrid: Top-down, business
processes and their sub-processes are identified. A
business process is defined as a set of logically
related activities that are chronologically ordered,
started by events and lead to results. For IT-
supported business (sub-) processes, use cases are
derived. A use case (e.g., ‘create order’) is an
interaction sequence between a role and a software
system to solve some business task. Use cases are
modeled as UML activity diagrams. Indivisible
(atomic) interaction sequences within a use case that
have a business goal are called application functions
(e.g., ‘find shipment with items’). Application
functions are candidate application services.
Simultaneously, object-oriented analysis is
performed bottom-up: First, domain classes are
identified, i.e., application-independent objects of
the real world with attributes and functionality (e.g.,
‘article’ or ‘order’). Then, from the domain classes,
analysis classes are derived that specialize the
domain class within the context of a particular
application system. For example, ‘stocked article’
and ‘orderable article’ are analysis classes of the
domain class ‘article’. Each method of an analysis
class (e.g., ‘create’, ‘release’, ‘cancel’) corresponds
to an application function, and an application
function can be realized by one or more methods of
an analysis class.
Application services (e.g.,
GetShipmentWith-
Items
or DeliveryConditionOperations; the
latter one changes the type of some delivery to
‘urgent’ or specifies the delivery address) are the
interfaces of software components that provide
methods to realize application functions. They result
from candidate application services by applying
design rules. These rules comprise the SOA design
principles ‘abstraction’ and ‘statelessness’ as well as
the requirement that an application service should
correspond to the smallest application function. The
last requirement leads, for example, to a separation
between the application services
CreateCustomer,
which, among others, includes name and address,
and
ChangeCustomerAddress.
Subsequently, the designed services are
evaluated by the SOA design principle ‘reusability’
and the criteria ‘similarity’ and ‘stability’. Similarity
means that existing services must be extended if
they provide at least 50 % of the functionality of
some new application service. Stability calls for the
CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE
379

Business Process Modeling
Object-oriented Analysis
Identify
Business
Processes
Identify
Sub-
processes
Subprocess
IT supported?
no
Define
Use Case
Identify
Domain
Classes
Identify
Analysis
Classes
Identify
Service
Candidates
Design
Services
Evaluate
Services
OK?
no
yes
Design
Rules
Evaluation
Criteria
Application
Function
yes
End event
Sequence
flow
Message
flow
Start event
Activity
XOR
gateway
Figure 2: Software Service Design Process in Case 1.
separation of unstable application functions (e.g.,
country-specific ones, known from domain
experience) from stable ones.
So far, around 250 web services have been
designed and implemented within a custom-made
J2EE framework; execution partly relies on an
adapted Oracle BEA WebLogic Application Server.
The interfaces of many web services comprise 1 or 3
operations; the largest interface consists of 9
operations. According to their type, 80 % of the web
services are application services, 20 % are technical
ones supporting software development (e.g., testing
web services) or technical process execution (e.g.,
starting batches). Many application services refer to
analysis classes, e.g.,
CreateOrder or Credit-
Operations (all methods related to order items
locked after credit analysis). Additionally, separate
application services have been defined for
application functions that cannot uniquely be
assigned to a particular analysis class. For example,
the application service
OrderDetailOperations
groups all the heterogeneous functions that are
possible for constituents of an order, e.g.,
cancellations or substitution of order items, priority
adjustments or stock allocations.
4.2 Case 2: Oil- and Gas-Producing
Company
Context. The company, headquartered in Norway, is
one of the world’s largest crude oil and gas suppliers
with about 29,500 employees in 40 countries and
more than 30 years domain experience. Its IT
department has circa 800 employees. The data-
intensive application systems for the oil and gas core
business (e.g., planning of lifting and cargo, trading,
managing contractual documents) have been
developed in-house in PL/SQL. Current software
development relies on JAVA/J2EE for service
providing and on .NET for clients. In addition to the
custom-made application systems, the company also
uses standard software (SAP R/3) for domain-
independent business tasks such as accounting,
invoicing and human resources. Moreover, the
systems landscape integrates external information
providers (e.g., Reuters and pricing agencies),
information systems of business partners (e.g., ocean
carriers) and the quite independent partner
application systems at the offshore field sites.
The SOA project was initiated in conjunction
with reengineering: The oil and gas core application
systems, 20 years old, were to be replaced, since the
old PL/SQL code became increasingly difficult to
maintain. Service-orientation was chosen as
architecture because of its openness and scalability,
which makes it appropriate to cope with the
developments on the oil and gas market (e.g.,
increased activities in new markets including China
and India, more and smaller trades by private
investors). Hence, some of the later service
consumers cannot be anticipated.
Functionally, the intended service-oriented solu-
tion should cover the core of the oil and supplies
‘wet’ supply chain (transport by ship). Later the
functional coverage was extended to the gas core.
Technological constraints resulted only from the
systems landscape. Software qualities (e.g., security,
performance) were not an issue.
The first web services were implemented around
2001 in the gas domain. Before (since around 1997),
service-orientation had been realized in redesigning
the PL/SQL functions and their interfaces. The
following explanations refer to software service
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies
380

Business
Process
Modeling
Information
Modeling
Identify
Business
Processes
Group
Business
Processes
Events
Refine
Candidate Services
Create
Service
Specification
Business
Rules
Identify
Information
Objects
Group
Information
Objects
Function
Modeling
IT
Realization
Existing
Application
Systems
Similar
activities
Common
Operations
Provided
Functions
Context
Events
Identify
Candidate
Services
End event
Sequence
flow
Message
flow
Start event
Activity
XOR
gateway
Figure 3: Software Service Design Process in Case 2.
design principles and steps common to both
situations.
Service Design Process (see Figure 3).
‘Application services’ have been identified both top-
down and bottom up. Top-down development started
from high-level business processes that are
collections of activities to achieve a business goal
(e.g., ‘plan transport’, ‘forecast replenishment’).
These business processes were already available due
to governance requirements. In contrast to
workflows, the activities in business processes are
ordered in strict sequence, and events only exist at
the start or end of the business process. Both
business processes and workflows are modeled by
BPMN.
Business processes within a function area (e.g.,
‘shipping’, ‘trading’) are grouped and analyzed to
find similar activities, e.g., ‘update cargo’, ‘calculate
price’ and ‘calculate volume’. Abstractions of
similar activities form candidate application
services.
Perceiving similarities between activities is
relieved by simultaneous bottom-up service design
starting from information concepts. An information
concept, e.g., ‘line item’ (a position of a deal),
‘cargo’ or ‘pricing formula’ (describes how the price
for an oil deal should be set), is strongly
interdependent information with similar life cycle.
Information concepts reside on the logical level of
system design, but may correspond to business
objects, which are input or output of activities.
Common operations on information concepts (often
CRUD - create, retrieve, update, delete) form a type
of bottom-up candidate application service; another
type are functions provided by existing application
systems and gathered by reverse engineering.
Information concepts are modeled by UML class
diagrams.
Application services such as
UpdateCargo or
CalculationEngineService (for price and
volume calculations) express the contribution of a
software system to a business process on a logical
level. They represent functions with so high
interdependencies (in terms of data usage, user
interaction or business rules) that they are normally
implemented together.
After their identification, the candidate
application services are refined (grouped or split) by
using additional information and the following
heuristics:
• Application services are often required to handle
start or end events of business processes (e.g.,
‘lifting program published’).
• An application service must refer to the same
information concept in the same context. For
example, distinct loading operations and facilities
are needed to handle the information object
‘cargo’ in the context ‘ship’ or ‘dock’,
respectively. Hence, separate services must be
defined.
• An application service must stick to the same
business rules (for example, calculations and
derivations).
Refinement leads to (grouped) functions (and their
consumption of information) that form the base of
service specification. In the beginning of the SOA
project, there were no service specification
guidelines - except for the principle that a service
interface should be small and contain only stable
CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE
381

operations. However, identification and refinement
brought about three types of software services: (1)
entity services (e.g.,
TradeService; mainly
CRUD on information concepts corresponding to
business objects), (2) task services (execution of
process activities; related to none or several
information concepts; e.g.,
CalculationEngine-
Service) and (3) technology services that are not
related to business (and, thus, no application
services), but needed for the systems to operate (e.g.,
SmXDataService that provides a system with data
from a data base). Currently, specification guidelines
for these service types are prepared in the form of
patterns.
At the time of writing, more than 70 web
services exist; each one has 3-5 operations. The web
services run on IBM WebSphere Application Server
6.0 and communicate either through this platform or
via Microsoft BizTalk. Non-web services exchange
messages via data base read/write or the Oracle
Messaging Gateway.
4.3 Comparison of the Cases
Both cases have a common context: (C1) They relate
to SOA-based reengineering of existing application
systems in non-IT companies, which have
comprehensive domain experience. (C2) Both
projects started nearly at the same time. (C3) Web
services have been designed, implemented and
deployed. (C4) Not all of the potential consumers of
these web services can be anticipated or controlled.
Concerning software services design, the
following commonalities can be stated: (D1) The
service design processes were hybrid, i.e., both top-
down and bottom-up. (D2) Top-town design started
from ‘business processes’, bottom-up design from
information objects. (D2a) Closer examination of the
‘business processes’ shows that the most distinctive
process characteristic, the control flow between
activities, was not considered. Instead, both
companies used processes for a functional
decomposition of their domains. Hence, top-down
service design actually started from functional areas
(see Section 2). (D2b) The information objects
underlying bottom-up service design express main
concepts of the domain (domain ontology) and were
gathered from the domain knowledge of experienced
employees. (D2c) The predominant way of thinking
was bottom-up, i.e., increasing abstraction by
grouping functions that refer to information objects
or business tasks. (D3) Distinct types of services
have been designed whose functionality is related to
either business (objects or cross object tasks) or
technology. (D4) The SOA design principles
‘reusability’, ‘cohesion’, ‘loose coupling’ and
‘abstraction’ were involved in either design process;
additionally, stability (of the operations that form an
interface) was used as a criterion for service design.
5 CONCLUSIONS AND FUTURE
WORK
This case study has shown that, in contrast to most
of the proposed approaches, software service design
in practice is always hybrid, i.e., it proceeds both
top-down (decreasing abstraction) and bottom-up
(increasing abstraction). None of the existing
hierarchical approaches (see Section 2) explicitly
considered bottom-up service design starting from
information objects, which is, however, common
practice; some of the recently presented service
design patterns (e.g., ‘utility abstraction’, ‘entity
abstraction’, ‘process abstraction’; (Erl, 2008b))
follow this tack. As opposed to the academic top-
down approaches, strict top-down derivation of
software services from business processes was not
observed; instead, processes were used for a
functional decomposition of the domain (alike Levi
& Arsanjani, 2002) - the control flow within
processes was ignored. Thus, functions and not
processes drive service design. Functionality and
software quality are the only ‘goals’ considered
during service design.
Finally, service design in practice ultimately
leads to service layers, i.e., services that can be
grouped according to the type of functionality they
provide (business object services, business task
services, technical services). Service layering as a
special form of grouping is neglected in purely
academic approaches, but mentioned in hierarchical
service design approaches that originate from
practice (e.g., Kohlmann, 2007; Klose et al., 2007)
and in principle-driven service design approaches
(Erl, 2008a). Altogether, focusing on functions and
information objects as well as layering services point
to required extensions of existing SOA design
approaches.
Since both cases considered here stem from
distinct branches, and the SOA projects were
conducted independently of each other, the results
are generalizable. To increase the validity of the
results, additional cases will be analyzed that differ
slightly in context (e.g., green-field development,
development by IT companies). Differences in
context can lead to contradicting results, which are
needed to specialize the conditions for particular
service design processes and steps.
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies
382

REMARKS AND
ACKNOWLEDGEMENTS
Even if not explicitly stated, all trademarks
mentioned in this article are registered trademarks of
the respective companies.
I would like to thank the anonymous reviewers
for their interest, support and comments. A more
detailed report is in preparation.
REFERENCES
Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T.,
Ganapathy, S., & Holley, K. (2008): SOMA: A
method for developing service-oriented solutions. IBM
Systems Journal, 47(3), 377 -396.
Erradi, A., Anand, S., & Kulkarni, N. (2006): SOAF: An
Architectural Framework for Service Definition and
Realization. In IEEE (ed.): Proceedings IEEE
International Conf. on Service Oriented
Computing - SCC 2006 (pp. 308-315) Los Alamitos:
IEEE.
Erl, T. (2008a): SOA Principles of Service Design. Upper
Saddle River et al.: Prentice Hall.
Erl, T. (2008b): SOA Design Patterns. Upper Saddle River
et al.: Prentice Hall.
Kaabi, R.S., Souveyet, C., & Rolland, C. (2004): Eliciting
service composition in a goal driven manner. In
Aiello, M. et al. (Eds.), Proceedings of the Second
International Conf. on Service Oriented
Computing - ICSOC 2004 (pp. 308-305). New York:
ACM Press.
Klose, K., Knackstedt, R., & Beverungen, D. (2007):
Identification of Services - A Stakeholder-based
Approach to SOA development and its application in
the area of production planning. In Österle, H. et al.
(Eds.), Proceedings of the 15th European Conf. on
Information Systems - ECIS 2007 (pp. 1802-1814). St.
Gallen.
Kohlmann, F. (2007): Service identification and design -
A Hybrid approach in decomposed financial value
chains. In Reichert, M., Strecker, S., & Turowski, K.
(Eds): Proceedings of the 2nd International Workshop
on Enterprise Modeling and Information Systems
Architecture – EMISA ’07 (pp. 205-218). Bonn:
Koellen-Verlag.
Lämmer, A., Eggert, S., Gronau, N. (2008): A Procedure
Model for SOA-Based Integration of Enterprise
Systems. International Journal of Enterprise
Information Systems, 4 (2), 1-12.
Papazoglou, M.P., & van den Heuvel, W.-J. (2006):
Service-oriented design and development methodo-
logy. International Journal of Web Engineering and
Technology, 2(4), 412-442.
Papazoglou, M.P., & Yang, J. (2002): Design
Methodology for Web Services and Business
Processes. In Buchmann, A. et al. (Eds.), Third
International Workshop on Technologies for E-
Services - TES 2002 (pp. 175-233). Berlin: Springer.
Quartel, D., Dijkman, R., & van Sinderen, M. (2004):
Methodological support for service-oriented design
with ISDL. In Aiello, M. et al. (Eds.), Proceedings of
the Second International Conf. on Service Oriented
Computing - ICSOC 2004 (pp. 1-10). New York:
ACM Press.
Yin, R.K. (1981): The Case Study as a Serious Research
Strategy. Knowledge: Creation, Diffusion, Utilization.
3(1), 97 – 114.
Yin, R.K. (2009): Case Study Research: design and
Methods. 4rd ed. Thousand Oaks: SAGE Publications
Zhang, Z., Liu, R., & Yang, H. (2005): Service
Identification and Packaging in Service Oriented
Reengineering. In Chu, W.C., Juristo Juzgado, N., &
Wong, W.E. (Eds.), Proceedings of the 17th
International Conf. on Software Engineering and
Knowledge Engineering - SEKE '2005 (pp. 620-625).
Skokie.
Levi, K., & Arsanjani, A. (2002): A Goal-driven
Approach to Enterprise Component Identification and
Specification. Communications of the ACM, 45(10),
45-52.
CASES OF SOFTWARE SERVICE DESIGN IN PRACTICE
383