Business Transformation to SOA: Aspects of the Migration
and Performance and QoS Issues
Liam OBrien Paul Brebner
NICTA NICTA
Building A, 7 London Circuit, Building A, 7 London Circuit,
Canberra, ACT 2601, Australia Canberra, ACT 2601, Australia
+61 2 62676276 +61 2 62676277
Liam.OBrien@nicta.com.au Paul.Brebner@nicta.com.au
ABSTRACT
Organizations face challenges to be more adaptable and transform to
meet new customer demands with fewer resources and streamlining
of its business activities. There is a growing move to introduce
SOAs with their promise of cost-efficiency, agility, adaptability and
legacy leverage. However there are many aspects of transforming an
organization to use SOA and many obstacles and issues that the
organization has to address when introducing SOAs. In this paper
we outline some of the major aspects of SOA introduction and focus
on some of the open issues that still need to be tackled. In the
discussion on the various aspects of SOA introduction we focus in
on performance and QoS which are major pieces to get right if the
SOA implementation is to be successful. We outline some of the
work that we are doing in this area and some problem areas where
further research is needed.
Categories and Subject Descriptors
K.6.4 [System Management]: Quality Assunance.
General Terms
Management, Performance
Keywords
Service Oriented Architecture, SOA, Performance. Quality-of-
Service, Service Level Agreements, Migration.
1. INTRODUCTION
As organizations adapt and transform their business process and IT
business systems to meet new challenges and respond to customer
demands many of them are deciding to implement SOA-based
systems. The promise of cost-efficiency, agility, adaptability and
legacy leverage has attracted many organizations to try out SOA
and in may cases make substantial investments in new systems that
are based on SOA.
In order to move to transform their business processes and IT
business system many organizations are undertaking rationalization
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SDSOA08, May 11, 2008, Leipzig, Germany.
Copyright 2008 ACM 978-1-60558-029-6/08/05...$5.00.
35
Jon Gray
NICTA
Building A, 7 London Circuit,
Canberra, ACT 2601, Australia
+61 2 62676275
Jon.Gray@nicta.com.au
programs to determine what strategies they will pursue in the future,
what business processes will support those strategies and determine
what IT systems are needed. As part of this rationalization many
organizations are moving to SOA based systems. There are various
aspects to the introduction of SOA from mining and reusing legacy
components as services in an SOA-based environment to acquisition
and development of an SOA infrastructure. In section 2 we will
outline several aspects of introducing SOA into an organization and
outline some of the open issues where further research still needs to
be done.
One of the main concerns for organizations building SOA-based
systems should be whether or not those systems can meet Quality-
of-Service (QoS) requirements. The use of an SOA can have a
positive impact on some quality attributes and a negative impact on
others [14]. Some of the main issues for organizations are dealing
with security, performance, availability and interoperability of their
SOA-based systems. Determining exactly what the QoS
requirements are, building their systems to conform to these
requirements, analyzing the systems to make sure that they conform
and determining what their QoS is and managing all of this through
specifying and negotiating service level agreements (SLAs), can be
quite burdensome on an organization. We have been working on
building performance and QoS modeling and simulation tools and
we outline our current work in this area in Section 3 and outline
some open issues where further research is needed.
The paper is structured as follow. Section 2 outlines various aspects
of the migration to SOA. Section 3 outlines some of the work we are
doing the areas of performance and QoS and outlines some of the
open issues that we are tackling. Section 4 concludes the paper.
2. ASPECTS OF SOA MIGRATION
When an organization wants to introduce the use of SOA there are
various aspects that it needs to consider. These include:
The identification and mining of services from its
existing/legacy systems
The integration of common/shared (e.g. Whole-of-
Government (WofG) services provided by one
government agency and used by other agencies) services
with existing/legacy systems
The acquisition and development of an SOA
infrastructure (including middleware)
The development of services and development of
applications from services
 The development of governance policies and procedures
(including establishing and monitoring of Service Level
Agreements)
Analysis of architectural alternatives performance,
scalability and other QoS requirements for SOA-based
systems
For each of these aspects we will explore some of the current
research in each area and outline some of the work that we are doing
and outline some of the open issues that are still important in each
area.
2.1 Identification and Mining of Services
When an organization moves to using SOA it does not want to
throw away its investment in its existing systems and has to deal
with them. Therefore there is a need to determine what services are
needed and what components from existing system can be migrated
to fill these service needs. There are several activities that an
organization will need to undertake:
Identify what services are to be used within its SOA. An
organization can do this by developing an overall
Enterprise Architecture, required business processes and
identifying services that are needed (top-down) or it can
examine each of its existing systems, identify common
processes/functions and identify services from these
(bottom-up). Either way identification of services is a
major issue.
Determine what legacy/existing components can satisfy
the service needs, determine what needs to be done with
those components and migrate and reuse them as services.
In doing this there is a need to determine the cost and
effort of such a migration so as to make informed
decisions about the feasibility of mining and reusing. A
method to help support determination of the cost and
effort is SMART [1]
No matter which approach is chosen (bottom-up or top-down), if
legacy components are used to satisfy service needs it is important
to identify services that meet performance and QoS requirements.
Approaches to identification and mining of services are needed that
take these requirements into account and carry out a detailed
analysis of whether or not these services will satisfy current and
future QoS requirements.
2.2 Integration of Services
As an organization moves forward with its SOA strategy services
will be identified, either internal or external, that will need to be
integrated with the organizations existing systems. Organizations
will need to be able to determine what systems the services will
integrate with, the scope of the work involved and estimate the cost
and effort of doing the work. The organization will also have to
determine what the impact of different architecture alternatives will
be on various quality attributes and QoS concerns for the system. As
well as this it will have to determine SLAs for its applications and
system as well as what QoS requirements are need for the services
that it consumes and be able to negotiate these with the service
providers.
We are currently developing a method to tackle these issues and are
calling it SMAT-AUS. The method consists of several activities for
36
determining the scope, size, effort and cost of the integration and
several activities for detailed modeling and simulation of
performance and QoS concerns with the ability to be able to
generate alternative architecture solutions to satisfy different QoS
requirements. An organization can choose a particular architecture
alternative based on their specific requirements.
One of the main open issues in integration of services is how so size
an integration effort and what are the various parts that make up the
cost. Items such as number of data elements, systems complexity,
service complexity, process complexity, applicable standards,
potential risks, etc all have an impact on cost [16]. Development of
methods and techniques that tackle determination of cost in SOA
projects (individual activities as well as the total cost) have still to
be fully develop, tested and used across the industry.
2.3 Development of an SOA Infrastructure
To run and manage SOA applications, an organization needs an
SOA infrastructure. An SOA infrastructure consists of several
pieces that support the main aspects of SOA including security,
governance, management, orchestration and resourcing (e.g.
virtualization). Gartner lists the following as major technical errors
in SOA [18]:
Bad selection of application infrastructure components,
Insufficient validation of the SOA enabling infrastructure
implementation,
SOA infrastructure, service and consumer application are
insufficiently instrumented for security, management and
troubleshooting.
Many vendors IBM, Microsoft, SAP, Oracle, BEA, and many
others are advocating the use of their SOA infrastructure
technology. Open issues in this area are how do organizations
choose which SOA infrastructure to acquire and what pieces they
will need to build themselves? How des an organization test the
infrastructure sufficiently to guarantee the level of security,
governance and management provided meets their requirements?
How is interoperability between different vendor infrastructure
handled?
2.4 Service Development and Application
Development from Services
As an organization moves forward with its SOA strategy it will need
to develop services as well as develop applications using either its
home-grown services and/or services provided by external
organizations. Different approaches to developing services and
applications can be used such as the traditional spiral development
models to more agile approaches. The approach used can also be
top-down which is driven by business processes or Model Driven
Architecture or bottom-up which is driven by existing legacy and
componentization of legacy [15].
When dealing with the development of services and applications
from services one of the main concerns is dealing with the quality of
service of the services and the quality of service of the application
(which is dependent on the QoS of the services used). One of the
main issues is the problem of time-boxed development of services
versus designing for QoS. If a set of services have to be developed
in a particular timeframe especially in more agile approaches how is
QoS for the services handled (which may endure through the entire
development process).
When developing services and applications an organization will
have specific QoS requirements which the services and applications
will have to meet. These requirements can guide the development of
the services and applications but there are few development
methods that can guarantee that the resultant services or applications
will meet their QoS needs. Detailed testing of the services and
applications will need to be done to determine if in fact they
actually meets their QoS requirements.
If external services are used in the development of an application
then service level agreements with the service providers will have to
be negotiated and be in place in order to make any guarantees about
the QoS level of the application. A further complication on QoS is
that an application may identify what services to use dynamically so
it is not possible at design time to know what services will actually
be used. In this case it may be difficult to do QoS analysis of an
application. In Section 3 we discuss our current work in the
performance and QoS area and outline areas where further research
is needed.
In order to undertake a project to develop a service or an application
from services there is a need to know the scope and size of the work
involved. This will help in determining the cost and effort for such a
project. There are few methods that assist in determining the scope,
size, cost and effort of SOA projects. Some guidelines as to what is
involved in determining the cost have been developed [16] but there
are few methods that do a complete scoping, sizing, cost, and effort
estimation. More is needed in this area as having methods to
determine the scope and reasonably accurate cost and effort figures
will help organizations to better budget and plan for their major
SOA efforts.
2.5 SOA Governance
SOA governance is an essential activity to manage many levels of
SOA decisions correctly. There are various requirements to the
governance problem including the following [17]:
Strategy and Goals what is governed and why?
Funding, Ownership and Approvals who owns what?
What gets funded and by whom?
Organization what structures, processes and governance
mechanisms are in place?
Processes what are the roles, responsibilities and
procedures for managing SOA activities?
Policies what are the enforcement issues including
standards, security, release and re-use?
Metrics what are the business outcomes and how are
they measured and by what metrics?
Behavior what is the behavioral model, incentives,
penalties and rewards for appropriate SOA Behavior?
Work still needs to be done in various areas of governance and clear
paths through all of the issues in governance have to be developed
that will lead an organization to success with its SOA initiative.
What governance issues are core to the success of an SOA initiative
and need to be tackled early in the SOA lifecycle and which can be
37
left to later? What areas can be automated and what tools are there
to help automate governance? One of the areas of SOA governance
that we are working on is on Service Level Agreements and the use
of methods and tools to determine the performance and QoS of
services and applications that can be used in developing and
negotiating SLAs.
3. PERFORMANCE AND QOS
Since 2006 we have been researching, developing, and trialing
methods and tools for the performance modeling of SOAs. It is vital
to consider performance while architecting and developing SOA for
both services and applications. Some example issues with SOA
performance are as follows. The performance (response time) of
web services is typically worse than the bare underlying
functionality. This is due to and compounded by the overheads of
XML (e.g. delivery, parsing, validation, serialization), the
implementation of composite services (e.g. use of other services
including 3rd party services and legacy applications), service
orchestration (infrastructure and protocols), service invocation (e.g.
security, transports), resources (physical or software resources, e.g.
CPUs, threads), and resource models (e.g. virtualization). Optimally
allocating resources to services is also difficult, as resources may
not be correctly distributed, and individual services in a workflow
for which there is high demand, may become bottlenecks due to
resource constraints. The consumers expectations of performance
may be higher than what can actually be delivered. For example, we
have observed SLAs which promise a sub-second response time,
whereas in practice response time ranged from 1 to 48 seconds.
Response time is often unpredictable, and varies depending on
service operation, binding, parameters, and payloads. If a call to a
service times out unexpectedly the consumer is unsure of the
success or failure of the call (e.g. if side-effects are possible).
Perhaps the most severe issue is scalability for Open services i.e.
services that are exposed publicly. The maximum number of
consumers, and the arrival rate and distribution are unknown in
advance, and extremely high peak demands are possible which may
saturate one or more resources for the service resulting in increasing
response times, or more likely, the service being unavailable due to
failure or the imposition of access restrictions to limit demand (load
shedding). For example, Open services may be used to construct
3rd party mash-ups, resulting in unexpected increases and
distributions of demand for the consumed services.
In the e-Government area we observe that there is increased
dependency between whole-of-government services, as
compositions of services are offered and reused across all level of
government, non-government organizations, and business and
private citizens. The ability to architect applications with well
known performance characteristics is critical, but becomes harder
because of the dependencies between services, and the possibility of
large numbers of users accessing applications during periods of peak
demand (e.g. to meet deadlines for submission of information to
government agencies).
Given that performance is a well known issue with SOAs, it is vital
to architect SOAs with performance in mind. To do this it is
necessary to be able to understand the performance characteristics
of the architecture and investigate alternatives early on in the
development lifecycle. To this end we are developing a method and
tool support for early lifecycle performance modeling of SOAs [3].
The tool supports performance modeling in terms of SOA concepts
(services, workflows, and composite services), and automatically
transforms the SOA model into a performance model which is
simulated producing performance metrics for the SOA components.
Significant performance modeling issues that we encountered and
have made initial progress with are in the areas of service
orchestration (e.g. workflows and engines), resource virtualization
(e.g. virtual servers), and Service Level Agreements (SLAs). We
believe that research in these areas is important but so far
incomplete, and we address each briefly in turn.
3.1 Service Orchestration
Composite services may be orchestrated in a variety of ways. For
example, hardwired workflows over an Enterprise Service Bus, or
using a workflow language executed by a workflow engine. Each
approach has different performance and scalability characteristics,
which depend on the workflows executed on them, their deployment
and configuration, and the resources available.
There are some academic studies of workflow performance [5, 6],
but little public empirical performance data is available from real
SOA workflow deployments. However, anecdotal information
suggests that workflow performance is a critical issue for SOAs.
Workflow engines in Grid computing must discover and utilize
large numbers of resources dynamically in order to support high
concurrency on-demand computations, and may need to be
distributed for scalability. In Enterprise environments, the impact of
rules evaluated in a rule engine for the workflow steps may be
substantial. Configuring workflow engines for different levels of
reliability and failover can have a large performance impact (e.g. if
every step is persisted to a database, or if the state of replicated
workflow engines is synchronized to enable warm failover).
Understanding the performance characteristics and performance
tuning of workflow technology is vital for the architecting and
operation of production systems, and requires expert knowledge.
Due to the architectural mismatches across services [4] and the
resulting difficulty of integrating services that were not originally
designed to work together, XML data must be transformed,
serialized, and/or validated between services (i.e. from the output of
one service to the input of another service). Transformation may be
done in the workflow engine itself (e.g. by XSLT), or by specialized
integration infrastructure (e.g. Composite Application Frameworks).
It is often resource (computationally and memory) intensive.
Our SOA performance modeling method models service
compositions as a series of workflow steps (a step is a service and a
time, either measured, or the default time of the invoked service, or
computed by the simulation model for composite services). We do
not currently model the orchestration technology directly, as the
overhead of orchestration is included in the measured performance
times. In theory the orchestration overhead could be modeled
explicitly as time spent in a workflow service. However, these
times need to be measured for the target system, and a suitable
model of the performance characteristics of the workflow service
need to be developed for different orchestration solutions. Also the
impact of other resource limitations may need to be modeled. For
example, memory usage due to large payloads held in memory for
the duration for each workflow instance may severely limit the
number of concurrent workflow instances. We are currently
exploring options to extend our tool to allow resources such as
memory to be allocated, held, and de-allocated across multiple
service boundaries.
38
3.2 Virtualization
Our SOA performance modeling method and tool support models
services as first-order components. This makes the modeling easier
and more transparent for architects, and allows metrics to be
produced for services. Our tool was initially designed to model
resourcing of services on fixed resources. Simple service resourcing
options are services deployed to non-shared servers (i.e. 1 service
per server, a possible resource model for compositions using
services from different 3rd party providers), and services sharing
resources (i.e. multiple services per server, a typical resource model
for compositions using services provided within the same
organization and hosted on common enterprise servers). However,
one of the government SOAs we trialed the method with intended to
use resource virtualization in the form of virtual servers (e.g.
VMWare, [7]), which requires modeling of services sharing
resources dynamically (i.e. depending on maximum resources
available, current resources available, contention for resources, and
resource sharing policies).
Virtualization makes performance modeling more complex, but is
becoming an increasingly common foundation for SOA
environments, so there will be a need to model increasingly
complex virtualization scenarios. One of the significant issues is
gaining an adequate understanding of the performance impacts of
the VMware (for example) and various deployment, replication and
configuration options available. For example, there is a fixed per
VMware instance overhead, but scalability is harder to predict when
replicating VMware instances, or increasing the number of physical
CPUs per VMware instance (there are indications of non-linear
overheads [8, 9]). There is a lack of benchmarks showing the impact
on application performance of VMware configurations, as the
VMware-specific benchmark is designed to show benefits of
VMware for increased utilization of servers.
We have developed tool support for modeling one example of
server virtualization. This is done by weighting the deployment of
services to physical servers, the weights representing virtual CPUs,
allowing the resource simulation model to allocate more resources
to services with higher weights. However, more flexible modeling
of virtual servers is needed to model various scenarios of services
deployed to software servers or containers (e.g. web servers,
application servers), software servers hosted on virtual servers with
virtual resource allocations (e.g. virtual CPUs), and virtual servers
resourced by physical servers.
The scope of virtualization is increasing in enterprises. Resources
other than servers are now being virtualized, for example networks,
SANs, etc. This will make performance modeling of SOAs
deployed to completely virtualized environments more challenging.
The relevance of virtualization to SOAs has been documented
previously (e.g. for remote deployment of services across
organizational boundaries, [10]), and recently Amazon has
introduced a virtual server based on-demand cluster computer
service (Amazon EC2, [11]), which is web service-based and uses
Xen, another virtualization technology. Another application of
virtualization is to isolate consumers from each other to ensure
SLAs can be met. This is a logical extension of the Amazon
approach where each user has one or more exclusive virtual
environments (and is only charged for the physical resources used).
See below for further discussion.
3.3 Service Level Agreements
This brings us to the final issue, how can SOAs deliver what they
promise to different user communities (with possibly virtualized
resources) [12]? As part of the trials we have assisted government
agencies understand the connection between the modeled
performance of SOAs and SLAs. Because composite services can
consume external 3rd party services, service providers function in
the roles of both service consumers and providers, and therefore
need to understand SLAs in both contexts. If services are consumed,
the performance model can be used to understand the demand for
external services. If there is a SLA associated with the use of these
services, it is possible to determine if the demand will be exceeded,
and the SLA renegotiated, costs or other penalties for exceeding the
demands estimated, decrease in response time expected taken into
account, or measures put in place to limit the demand (e.g. by
limiting the concurrency in a wrapper service for invoking 3rd party
services).
From the perspective of service providers, it is possible to use the
performance predictions to negotiate SLAs for consumers, or
determine the resources required to meet previously agreed SLAs.
Once the maximum throughput of each service is known, by using
the maximum predicted throughput as the average arrival rate for a
Poisson distributed workload, it is possible to find the maximum
permissible average arrival rate to ensure that the system is not
saturated for some maximum period of time per day (or other unit of
time) with a given probability (e.g. less than 1 chance in 100 of
service having excessive response time due to resource saturation
for more than 10 seconds in 24 hours). For different classes of users
(e.g. different organizations) it is also possible to determine SLAs to
split the available capacity between them by imposing limits on
their arrival rate for the service, along with expected response times
(e.g. max average arrival rate of 1 every 5 seconds to ensure
response times below 3 seconds). Of course, this is based on
independent and uniform distribution of arrivals. If the arrivals are
dependent or non-uniform (e.g. DoS attacks, burst of arrivals to
meet deadline, etc), then all bets are off and the services may be
saturated for significantly longer than estimated for all users (e.g.
record stock trading volumes caused a meltdown resulting in
services being unavailable for 30 minutes, [13]).
It would be desirable to automate further the process of deriving
SLAs from the performance metrics, and allow various tradeoffs to
be made for different SLAs depending on the needs of the different
user communities. The other requirement is to determine the
resources required to meet a set of SLAs.
A significant problem remaining however is the inability to isolate
the SLAs for each user community to ensure that overuse by one
community doesnt degrade the agreed QoS for the others. One
approach that could be pursued is to use virtualization to isolate
services for different user communities from each other. This would
allow a SLA to be specified for each virtualized service. While there
are spare resources, SLAs will be met, and even exceeded, as with
virtualization spare resources are distributed to active processes, so
even if a user community is exceeding the agreed demand for a
service they will receive the agreed QoS. Concurrently other user
communities will continue to receive the agreed share of resources
required to ensure that their SLAs are still met.
However, once overall demand exceeds supply, resources are
strictly allocated according to the virtualization resource policies,
39
and performance will start to degrade. Strategies to guarantee QoS
include preventing SLAs being violated (e.g. by limiting the number
of concurrent connections per user community), or increasing
resources dynamically (e.g. by using autonomic resource allocation
in conjunction with virtualization).
It is unclear how practical it is to deploy a service for each SLA to a
virtual server, as it is not just the externally visible service that
needs to be deployed to the virtual server, but also all dependent
services. Finally, if SLAs are in place then they must be monitored
for enforcement, to locate the origin and cause of potential SLA
violations (e.g. is the problem on the consumer, network, or
provider side) to allow for future capacity planning, renegotiation of
SLAs, and possibly for dynamic allocation of resources (e.g.
resources can be easily increased in Amazon EC2).
4. CONCLUSION
As organizations move to introduce SOA and develop SOA
applications there are many aspects that they may encounter. In this
paper we have outlined some of those aspects and outlined some of
the problems and issues that organization will face when tackling
the various aspects. We have also outlined some open issues in these
areas where further research needs to be done.
No matter which aspect of SOA migration that an organization is
involved with one of the main areas of concern for SOAs is that of
performance and QoS. We have outlined some of the work that we
are doing in this area and in particular what are still some of the
main open issues related to performance and QoS. This work can
especially be used in the SOA governance area when determining
and negotiating SLA both for services (internal and external) and
applications developed using services.
The research areas in performance and QoS areas that we are
working on; service orchestration, virtualization and service level
agreements are areas that are important to get right for an SOA
system. The results of our research should lead to improved
modeling capabilities, better modeling and simulation tools and
better use of the data produced by these tools.
5. REFERENCES
[1] Lewis, G., Morris, E., OBrien, L., Smith, D., and Wrage, L.,
SMART: The Service-Oriented Migration and Reuse
Technique, G, CMU/SEI-2005-TN-029, Software Engineering
Institute, USA.
[2] Zhang, Z. and Yang, H., Incubating Services in Legacy
Systems for Architectural Migration, 11th Asia Pacific
Conference on Software Engineering, Nov 20 Dec 3, 2004,
pp: 196-203.
[3] Brebner, P., OBrien, L., Gray, J., Performance Modeling for
Service Oriented Architectures, research demonstration track,
ICSE 2008.
[4] Bierhoff, K., Grechanik, M., and Liongosari, E. S. 2007.
Architectural Mismatch in Service-Oriented Architectures. In
Proceedings of the international Workshop on Systems
Development in SOA Environments (May 20 - 26, 2007).
International Conference on Software Engineering. IEEE
Computer Society, Washington, DC, 4. DOI=
http://dx.doi.org/10.1109/SDSOA.2007.2.
[5] Aiello, R., Workflow Performance Evaluation, March 2004,
PhD, Universita di Salerno.
[6] Kim, K. and Ellis, C. A. 2001. Workflow performance and
scalability analysis using the layered queuing modeling
methodology. In Proceedings of the 2001 International ACM
SIGGROUP Conference on Supporting Group Work (Boulder,
Colorado, USA, September 30 - October 03, 2001). (Ellis, C.
and Zigurs, I., Eds. GROUP '01. ACM, New York, NY, 135-
143. DOI= http://doi.acm.org/10.1145/500286.500308.
[7] VMware, www.vmware.com.
[8] VMware ESX Server 2: Performance and Scalability
Evaluation, 2004. URL:
ftp://ftp.software.ibm.com/software/dw/wes/hipods/esxserver_
evaluation.pdf.
[9] Improving Scalability for Citrix Presentation Server. URL:
http://www.vmware.com/pdf/esx_citrix_scalability.pdf.
[10] Brebner, P. and Emmerich, W., Deployment of Infrastructure
and Services in the Open Grid Services Architecture (OGSA),
Third International Component Deployment Conference, CD
2005, Grenoble, France, Dearle, A, Eisenback, S. (Eds.),
LNCS Volume 3798/2005, pp. 181-195.
[11] Amazon EC2 (Elastic Computing Cloud). URL:
http://www.amazon.com/gp/browse.html?node=201590011.
[12] Ludwig, H., Web services QoS: external SLAs and internal
policies or: how do we deliver what we promise?, Fourth
International Conference on Web Information Systems
Engineering Workshop, 2003, p. 115-120, Digital Object
Identifier: 10.1109/WISEW.2003.1286793
[13] SMH, Share panic leaves online traders in the lurch, January
24, 2008. URL:
http://www.smh.com.au/articles/2008/01/24/1201025051004.h
tml.
40
[14] OBrien, L., Moreno, P. and Bass L., Quality Attributes for
Service-Oriented Architectures, International Workshop on
Systems Development in SOA Environments (SDSOA) 2007
at the International Conference on Software Engineering,
Minneapolis, USA, May 20th 26th, 2007
[15] Arsanjani, A., Toward a pattern language for Service-Oriented
Architecture and Integration, Part 1: Building a service eco-
system, IBM, 2005, URL:
http://www.ibm.com/developerworks/webservices/library/ws-
soa-soi/
[16] Linthicum, D., How Much Will Your SOA Cost? Here are
Some Guidelines, Info World November 2006.
[17] Marks, E. A., Perspectives on SOA Governance, URL:
http://colab.cim3.net/file/work/SOACoP/2006_05_2324/EMar
ks05242006.pdf
[18] Gartner Inc., Bad Technical Implementations and Lack of
Governance Increase Risk of Failure in SOA Projects, Media
Release, June 2006. URL:
http://www.gartner.com/it/page.jsp?id=508397
[19] Liu, Y., Zhu, L., and Gorton, I., Performance Assessment for e-
Government Services: An Experience Report, the 10th
International ACM SIGSOFT Symposium on Component-
Based Software Engineering (CBSE), Lecture Notes in
Computer Science, Boston, USA, 2007.
Acknowledgements
NICTA is funded by the Australian Government as represented by
the Department of Broadband, Communications and the Digital
Economy and the Australian Research Council through the ICT
Centre of Excellence program.