UCSOA: User-Centric Service-Oriented Architecture
Mark Chang, Jackson He, W.T. Tsai*, Bingnan Xiao*, Yinong Chen*
Intel Incorporation, USA
*Arizona State University, Tempe, AZ 85287-8809, USA
Abstract
This paper introduces a new user-centric service-
oriented architecture (UCSOA) that allows end users
to compose applications. UCSOA is an extension of
consumer-centric service-oriented architecture
(CCSOA), which is an extension of conventional SOA.
The conventional SOA is producer-centric because
service providers publish their services and service
consumers must search available services to compose
their applications. CCSOA is different as it allows
consumers publish their needs including workflows
and services, and let producers to produce services to
meet the requirements. Based on CCSOA, UCSOA
provides support for end users. An application builder
is an engineer who has both domain and programming
knowledge, while an end user has little knowledge on
programming and thus UCSOA needs to allow non-
technical persons to compose their applications. This
paper presents the concepts, architecture, enabling
techniques, and illustrative examples.
1. Introduction
Service-Oriented Computing (SOC) including
service-oriented architecture (SOA) and Web Services
(WS) emerges as a new computing paradigm. Major
computing corporations and government agencies are
adopting this paradigm. The idea that a program as a
service that can be discovered, matched, composed,
executed, verified, and monitored at runtime forms the
new paradigm. In SOA, service providers register the
services at a service broker and the service consumers
(application builders) search and discover required
services through the broker. Once a required service is
found, the service consumer can bind the service into
its application. Service collaboration is essential in
SOA because a complex service is normally composed
of several services.
Consumer-Centric SOA (CCSOA) [16] is an
architecture designed to support collaboration-oriented
service composition. In addition to publishing service
The research reported here is supported in part by the NSF under Grant Number 03-26606 (ITR).
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
specifications in SOA, workflows and application
collaboration specifications are also published in
CCSOA for discovery, matching, and subscription.
The CCSOA is different from the conventional SOA
framework [2][13], in which service providers develop
and publish their services, and service consumers
(application builders) are responsible to discover the
right services published as well as use the services in
their applications. This is essentially a producer-
centric. Specifically, the majority of the current
support in SOA is for producers, e.g., the service
broker will list registered services, the specification
techniques and standards are designed so that service
providers may produce the right software for a given
specification. There is no corresponding broker for
consumers, nor is the corresponding application
specification publisher. In CCSOA, consumers publish
their application requirements together with associated
service specifications including the workflow. Once
these are published as application templates, any
service provider can submit their software or services
to meet the application requirements. This way of
computing is consumer-centric because now the
service providers will look for application needs from
service customers.
Even though CCSOA provides a framework for
service consumers, there is rarely any support for end
users who have little programming background and
who are the ultimate customers of services. User-
Centric SOA (UCSOA) is a new framework to support
end users. Most of the current SOA focuses are
centered on providing platform independent services
for developers and / or application builders. With web
technologies becoming ubiquitous and service-
orientation technologies maturing, a new breed of user-
centric services is emerging, e.g., Web 2.0 [11]. The
era of user-orientation is dawning on us. Future
computing environment and development
methodologies will pay more attention to end users and
design services directly for them. UCSOA assumes the
following facts:
• Numerous application services will be made
readily available to end users. Examples of such
 services include calendars service, weather
service, and appointmentBooks service.
• End users have limited computer knowledge, and
they can use web browsers to read news online
and use sample applications on the web. Yet they
certainly may not have sufficient training in
composing applications.
• Each end user has his/her own background and
interests, and will need different applications
accessible from the web browser.
Web 2.0 can be considered an important step
towards user-oriented computing [11] as it emphasizes
on user interaction and data syndication. Some notable
Web 2.0 principles include:
• Software as operational services: Software will
not only be treated as services but also the values
of software remain only if it is maintained on a
daily basis.
• Users treated as co-developers: As software is
being constantly updated, user feedback and
evaluation will be continuous that users are
essentially co-developers of the software.
Specifically, new features will be tested by end
users at limited sites, and if they are used and liked
by users, they will be deployed to all the sites.
• Harnessing collective intelligence: Data and
services can be created in a collaborative manner
via the web.
• Lightweight user interface and programming
models: Develop software services that are loosely
coupled with the rest of applications so that they
are easy for reuse and support data syndication.
These principles encourage user interaction and
allow software services to be used and evaluated by
end users. While they also support software reuse by
using lightweight programming models, programming
is still done by programmers.
This paper introduces UCSOA to support end-user
oriented application development. Table 1 compares
SOA, CCSOA, and UCSOA. Figure 1 illustrates the
current situation in which the end users struggle to find
services that meet their needs.
Enterprise Service Providers
Publish
Broker
Public/Private
Networks
Public Service Providers Publish
Discover &
Subscribe
Programmers
Figure 1: Needs of User-Oriented Services
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
With the advances of SOA specification
technologies, it is possible to incorporate the needs of
end users into the service specification so that end
users can know what service to use and how to use
them.
2. SOA Evolution
Several generations of SOA techniques have been
developed in the last few years [16]:
• Initial stage or input/output stage;
• Process description stage;
• Service collaboration specification stage; and
• Consumer-centric specification stage.
UCSOA introduces a new service specification
stage to the SOA specification evolution, i.e., a user-
centric specification stage. In previous stages,
application builders are engineers who have
programming knowledge and expertise. On the other
hand, end users may not have programming expertise,
but they know what functions the software must have
and how it should be used. In this user-centric
specification stage, techniques are needed to support
end-users with little programming knowledge to
specify applications and services they want to use. The
remainder of the paper will focus on the user-centric
service specification.
3. UCSOA Framework
3.1 UCSOA Hierarchy
The overall UCSOA architecture is a four-layered
architecture as shown in Figure 2:
How to
Where use the
to find Services
Services ?
?
Publish my
needs and
get services
directly ?
Figure 2: UCSOA Architecture
End Users
• Conventional SOA Layer: This layer provides
Re-Package
w/ GUI
conventional SOA services such as publishing,
discovery, and broker services.
• CCSOA Layer: CCSOA publishes not only
service specifications, but also application templates
and collaboration patterns. In CCSOA, all kinds of
 solutions are provided for both end users and service
providers.
• COI (Community of Interests) layer: This is a
layer where common solutions related to a specific
domain are stored and classified.
• End user profiling Layer: Each individual end
user has his /her own preferences and behaviors, and
thus will result in different applications.

Table 1: Comparison of SOA, CCSOA, and UCSOA

SOA
Descriptions Service descriptions include
to be method calls, parameters
published (input and output), and
internal process specification how a typical customer can use this what types of services they
in WSDL or OWL-S.
Publishing Service descriptions in
service directories such as
UDDI or ebXML.
Discovery Service consumers
and (application builders) match
Matching their services needs with
existing services in WSDL or can offer. Furthermore, they can
OWL-S in the service
directories or service
repositories.
Composition Use available services to
compose new services or
applications. Composition is
mostly manual at this time,
even though several
approaches are being pursued
for automated composition.
Brokers Allow service providers to
publish service description
and, and allow application
builders to perform various
search to locate the most
suitable services for their
applications.
CCSOA UCSOA
In addition to input/output and In addition to the
internal process specification, specifications in SOA and
service description also includes CCSOA, users can specify
service in various applications or want, service quality
missions. It also includes use cases criteria, personal profile and
and collaboration patterns. interests, and workflow for
service collaboration.
Service descriptions and In addition to publishing
application templates in the services, collections of
application builders’ directory. related applications are
published in Community of
Interests (COI) directory.
Service providers discover the Application builder and
services in need and match them service providers discover
with what they have and what they the needs of end users and
provider solutions,
test their services using the use including application
cases and the collaboration patterns template and services to
given in the application template. match the end users' needs.
In addition to service composition, End users can compose their
CCSOA offers to use application user interfaces using drag-
templates to facilitate application and-drop tools and
composition. application builders must
match or compose their
interfaces to meet the end
users' requirements.
In addition to publishing and In addition to the tasks done
matching services, a broker also by a CCSOA broker, a
allows application builders to UCSOA broker allows end
publish their service requirements users to publish their
and application templates. Store application requirements.
not only service descriptions, but
also collaboration descriptions and
use cases.

UCSOA provides a framework for end-user-

oriented service specification, registration, discovery,
matching, verification, validation, and composition. An
operational sequence in UCSOA is shown in Figure 3.
The numbers in the diagram shows a scenario of
how an end user uses UCSOA:
1. An end user (solution builder) describes a solution
specification which includes information on
workflow specification, COI specification, and
Figure 3: A UCSOA Operation Sequence policies.

IEEE International Conference on e-Business Engineering (ICEBE'06)

0-7695-2645-4/06 $20.00 © 2006
 2. The solution specification is submitted to a
UCSOA service broker. If an existing solution
specification associated with registered application
is available, the broker will return the application to
the end user. Otherwise, the solution specification
will be published in the solution specification
registry.
3. A service provider subscribed to the solution
specification registry is informed the availability of
a new solution specification. The service provider
can request to support this solution specification.
4. The ontology and standard taxonomy in the COI
specification help automatic matching between the
solution specification and registered application
specification from the service provider.
5. Once the service broker matches the solution
specification in its registry with the application
specification from service provider, it returns the
solution specification details to the service
provider.
6. The service provider customizes its service or
application according to the detailed solution
specification and submits it to the broker.
7. Once an application matches the solution
specification is available, the service broker will
notify the user (solution builder) that an application
is available.
8. Using the binding information from the service
broker, the end user can test and evaluate the
application based on the solution specification.
9. If the application passes the solution acceptance
test, the end user can accept the application, which
will make the application to be bound into the end
user's solution specification.
Once the end user's application is completed, new
services can still arrive. For example, as a software
service will be maintained and updated on a daily basis
according to the principles of Web 2.0, a new service
with better performance, functionality, user interface,
lower cost may be available after the application is
completed. The users can still take advantage of these
new services by going through the evaluation process
again from time to time. In this way, the cost of
owning the application keeps on going down and
performance going up as new services become
available.
3.2 Publishing Solution Specification in COI
In a COI, solutions will be published and classified.
An end user can publish, search, and discover a
solution specification in a COI. If the related
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
application is available, the user can simply use it. If
the solution specification is not available, but a similar
template solution is available, the user can customize
the template solution. If nothing similar is available,
the user can outline a solution specification, publish the
specification, and ask service providers to supply the
services or applications needed. The entire process can
be assisted by the COI supporting services, either
manually or automatically. For example, searching an
application in a COI can be supported by a powerful
search engine that can find the needed application even
though the user supplies only a few keywords and/or
attributes. Currently, many websites already provide
this kind of facilities powered by, for example Google
and Yahoo. Composing a solution template can be
assisted by drag-and-drop GUI and associated tools so
that an end user can compose simple solutions. If an
end user wants to specify a specific application, the
COI may provide similar specification as a reference to
guide the end user to input the proper application
specification.
4. Key Techniques in UCSOA
4.1 Communities of Interest (COI)
A COI [10] is a place where interested parties can
get related information, and each party can contribute
to the discussion and share information with each
other. In this way, an end user can receive information
he/she needs and participate in the dynamic service
composition. A COI can provide the following
additional services:
• Membership management;
• Policy specification;
• Situation awareness;
• Dynamic reconfiguration;
• Service mining; and
• Data classification.
In UCSOA, common applications together with
associated services will be represented in solution
specifications, and these solution specifications can be
stored in ontology so that both users and service
providers can search, navigate, and discover
applications and their associated services. Applications
can be grouped into various COIs according to various
trades or professions. The applications and data in
COIs can be constantly upgraded and updated.
A sports COI example is shown in Figure 4.
Basketball COI may contain various applications
associated with professional basketball and college
basketball so that both users and service providers of
basketball can have easy access. When an end user
wants to build a new basketball related application,
 he/she first submits the request to the COI register to
look up appropriate COI that best fits his/her needs.
There are different solution specifications stored for a
COI and these solution specifications are linked to the
application templates registered in CCSOA. End users
communicate with COIs only to get the applications
they need, and they do not need to know the
application details in CCSOA. The solution
specifications stored in the COI layer are also ranked
according to different criteria, such as:
• Ranked by the number of usages;
• Ranked by metrics such as reliability, security,
fault-tolerance, and performance;
• Ranked by user feedback and evaluation; and
• Ranked by service availability.
Figure 4: Sport COI Example
4.2 User Personal Profile Specification
User personal profile specification provides
information of user identification information as well
as the preferences on using different services. User
personal profile includes following information:
• User identity information;
• User general profile;
• Recent activities records;
• User interests information;
• User preference information; and
• User solution specification.
User personal profiles provide user information to
the UCSOA framework to better serve the users’
specific needs. With user personal profiles specified
for an end user, the UCSOA framework knows what
the areas of interest and what preferences are for this
end user. Thus, the UCSOA framework can always
return most related information to this end user
according to the areas of interest and service
preference information collected from the user’s
personal profile. Different users have different
preferences and different behaviors. As a result, even
in the same application domain, different users may
request different applications. Furthermore, user’s
personal profile can be updated after he/she requests
and uses a new application. The information will be
collected as feedbacks for service providers to improve
the services.
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
4.3 Discovery and Matching
In addition to the service discovery and matching in
conventional SOA and application template discovery
and matching in CCSOA, UCSOA also has discovery
and matching for COIs and user customized solution
specifications.
UCSOA discovery and matching is a two-steps
process based on COI ontology and collaboration
ontology. COI ontology defines an ontology for
creating different COIs including domain
categorization information. Collaboration ontology is
similar to service ontology except the information is
about service collaboration rather than service.
When a user submits a solution specification
request to the UCSOA, the area of interest
specification will be matched to the domain
categorization information of different COIs based on
the COI ontology specification first. After a matching
COI is identified, the UCSOA framework will match
user specified solution specification to the solution
specification stored in that COI. The user defined
solution specification will be matched to the solution
specifications defined based on the collaboration
ontology in the COI layer. Only if the solution
specification matches both the COI and collaboration
specification of an existing solution specification
stored in the COI layer of UCSOA, the applications
associated with this solution specification will be
returned to the user as he/she requested.
4.4 Verification and Validation in UCSOA
Before a service provider or application builder can
register an application to support a solution
specification published by a user (solution builder), the
application needs to be verified and validated by the
service broker against the service acceptance criteria.
Basically, this evaluates the application against the
policies that end user specified in the solution
specification.
Each UCSOA service broker has a Service
Verification and Validation Agent (SVVA) that can
verify and validate applications and services. When
one service provider or application builder wants to
subscribe to a solution specification, the SVVA
retrieves the test cases provided by the solution builder
or other parties from the repository. Then it needs to
perform unit testing on the service being registered. In
addition to the testing for functional validation, test
agent may need to perform other property-specific
testing according to different requirements from the
end user (solution builder). Once the unit testing and
 property-specific testing are done, a test agent needs to
perform the interoperability testing to validate the
collaboration capabilities of this service against the
policies specified in the user solution specification.
Only if the subscribing application passes all the tests,
it can be linked to the solution specification. The
service providers are still going to maintain those
registered services and keep updating their services
after the registration. Whenever changes are made to
the services, regression testing needs to be performed
to validate the revised services. .
4.5 Push-Driven Service Evolution
In UCSOA, when a service implementation is
accepted to be an acceptable member of a solution
specification, the UCSOA infrastructure can maintain
the link between the solution specification and the
implementations. Because multiple implementations
can serve the same specification, the UCSOA
infrastructure maintains this one-to-many links from
the solution specification to multiple implementations.
Similarly, a service implementation may be able to
contribute to multiple applications, and the UCSOA
infrastructure can also maintain this one-to-many links
from a service implementation to applications. If there
is a new version or new updates to the service
implementations that a solution is linked to, the push-
driven service publication or data syndication can be
used to push the new updates to the user solution. The
updates are pushed from the bottom layer of the
UCSOA framework through CCSOA and COI layers
to the end user applications.
4.6 Rapid Application Generation in UCSOA
With UCSOA, if sufficient number of COIs,
applications, and their associated services are
available, together with associated SOSE (Service-
Oriented System Engineering) [15] tools, it is possible
for an end user to create a large application rapidly.
The process for composing a simple application which
involved one COI can be outlined as follows:
1. The user submits his/her interest and solution
specification to the COIs register to look for an
existing COI application that fits the interest;
2. If a COI has existing application template fits the
needs of user’s solution specification, the user can
simply use the application template to request
services in the CCSOA;
3. If an application template largely fits but some
customization is needed, the user needs to
customize the application template for the new
applications;
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
4. The newly submitted services by service providers
will be evaluated by the COI/broker using SOSE
techniques including simulation, model checking,
C&C checking, and testing;
5. As only a few implementations in each application
template will be needed, the COI layer can save the
implementations in its repository;
6. Once all the service implementations for a new
application are available, the new application can
be evaluated using SOSE technologies rapidly
before deployment.
It is possible that an end user needs to compose an
application using applications from more than one
COIs. The user can first compose applications from
individual COIs, and then combine these applications
into the final application. The final application will
have an overall workflow to specify the coordination
of individual applications. The process for composing
a complex application can be outlined as follows:
1. List all required simple applications needed for the
complex application;
2. For each simple application in the list, compose
the application following the previous composition
process including evaluation;
3. Specify the overall workflow of the complex
application, and link the simple applications to the
overall workflow;
4. Once the verified simple applications are linked
together to compose the complex application, the
new application can be evaluated using SOSE
technologies before deployment.
5. UCSOA Example
This section uses an online sports trip planning
application as an example to illustrate the complex user
solution fulfillment in UCSOA. An NBA (National
Basketball Association) fans club wants to set up an
online trip plan application for registered club
members to buy team souvenirs and/or plan their trips
to watch away games. The leader of the fans club has
no background of programming but she decides to use
existing online services to build a new application for
this club. With this application, club members can shop
online to buy souvenirs such as player jerseys or other
accessories of the team they support. They can also use
this application to book air tickets, reserve hotels,
reserve rental cars, and book game tickets. The overall
workflow of this online fans club trip planning
application is shown in Figure 5.

Figure 5: Travel Planning Workflow
She starts from searching for online shopping
services to be included into the application. To be more
specific, she wants to search for an online NBA
souvenir shopping service. Thus, she composes an
online shopping application as described below:
First, she registers in the UCSOA framework and
fills in her user identity information such as user ID
and password. She also needs to provide her general
profile to the registration service such as name,
address, and telephone number. For a new user, the
recent activities record is initiated as empty and this
will be updated after she uses the services. For areas of
interest, she fills in NBA and Souvenir as her interest
preference. Also, she specifies some policies as her
personalized user solution so that the services will
always return the merchandise with lowest prices first.
She submits her interest profile to the COI server as
shown in Figure 6.
Figure 6: User Submits Request to COI Server
The COI framework queries its registry to look for a
COI according to the information submitted by the
user. Since the areas of interest are NBA and Souvenir,
the COI server returns the Souvenir COI to the user.
Figure 7: Online Shopping Application Template
There are many different application templates
defined in the Souvenir COI including online shopping
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
application template. By browsing the returned COI
description, she chooses one online shopping
application template for her use, as shown in Figure 7.
The COI server submits an application request to
the CCSOA layer with the selected online shopping
application template. Since there are many existing
online shopping applications for the selected
application template registered in the CCSOA layer
application registry, she can select a vendor according
to the policies she specified in the solution
specification. For this example, she may specify the
following policies as her vendor selection criteria:
• Lowest total price;
• Reputation of service provider;
• Secure authentication;
• Graphic catalog browsing capability;
• Merchandise availability;
• Payment method; and
• Shipping speed.
As a result, the online shopping service showing in
Figure 8 will be returned to the user for purchasing
NBA souvenirs.
Figure 8: Final Online Shopping Service
After the online shopping application is available,
she continues to compose a travel planning application.
Following the similar process introduced above, she
finds a travel package application in the COI and this
application provides a series of services including air
ticket reservation, hotel reservation, rental car
reservation, and activity ticket booking. The travel
planning application as shown in Figure 9 will be
returned to the user.
Figure 9: Final Travel Planning Service
 Once these two online applications are composed,
the UCSOA framework will evaluate the application
using SOSE verification and validation technologies
including testing, model checking and simulation. If
the applications pass the evaluation, the simple
applications will be linked to the overall workflow
specification as shown in
Figure 5 for the complex travel plan application for
a NBA fans club. Then the complex application will be
evaluated by the UCSOA framework to verify these
two applications can collaborate with each other.
Finally, the complex application will be deployed for
the NBA fans club to serve the club members.
Furthermore, user’s selection of this online shopping
application and travel planning application will be
recorded in her personal service preference. The
activities of using these services will be monitored and
updated in the user personal profile. These data will be
collected as feedbacks to the online shopping service
and travel planning service for service improvement.
5. Summary
This paper presented, compared, and contrasted the
concept, architecture, and techniques of SOA, CCSOA,
and UCSOA. An example is used to illustrate the new
UCSOA concepts. This paper also presented
techniques that support the new architecture, including
user profile description, discovery and matching
techniques, verification and validation of the
specifications and implementations, and rapid and
dynamic application generation through automated
code generation. Among the key concepts in UCSOA,
COI can greatly improve the service categorization and
classification for easy service matching. User's
personal profile can facilitate the user-specific
customization of the applications. Thus, the quality of
applications can be greatly improved in UCSOA.
6. References
[1] DARPA: OWL-S: www.daml.org/services/owl-s/
[2] IBM Developer Works, Service Component
Architecture, http://www-128.ibm.com/developerworks/
library/specification/ws-sca/
[3] IBM Developer works, Service Data Objects,
http://www-128.ibm.com/developerworks/webservices/
library/specification/ws-sdo/
[4] Intel: Service-Oriented Enterprise, The Technology Path
IEEE International Conference on e-Business Engineering (ICEBE'06)
0-7695-2645-4/06 $20.00 © 2006
to Business Transformation. http://www.intel.com/
business/bss/technologies/soe/soe_backgrounder.pdf
[5] N. Kavantzas, D. Burdett, T. Fletcher, Y. Lafon, “Web
Services Choreography Description Language (WS-CDL)”,
Version 1.0, W3C Working Draft 17 December 2004.
http://www.w3.org/TR/ws-cdl-10/.
[6] F. Leymann, Web Services Flow Language, Version
1.0, May 2001. http://www-306.ibm.com/software/
solutions/webservices/pdf/WSFL.pdf
[7] OASIS: ebSOA proposal: http://www.oasis-open.org/
committees/ebsoa
[8] OASIS: Business Process Execution Language for Web
Services (BPEL4WS), 2003. http://
xml.coverpages.org/bpel4ws.html
[9] Object Management Group, Unified Modeling
Language (UML), version 2.0. http://
www.omg.org/technology/documents/formal/uml.htm.
[10] Object Management Group, Meta Object Facility
(MOF) 2.0 Core Specification.
http://www.omg.org/docs/ptc/04-10-15.pdf.
[11] T. O’Reilly, “What is Web 2.0: Design Patterns and
Business Models for the Next Generation of Software”, Sept.
2005, available at
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/3
0/what-is-web-20.html?page=1.
[12] R. Paul and W.T. Tsai, “A Real-Time Community-of-
Interest Framework for Command-and-Control
Applications”, 9th International Command and Control
Research and Technology Symposium (ICCRTS), 2004.
[13] M. P. Singh and M. N. Huhns, Service-Oriented
Computing, John Wiley & Sons, 2005.
[14] W.T. Tsai, R. A. Paul, B. Xiao, Z. Cao, Y. Chen,
"PSML-S: A Process Specification and Modeling Language
for Service Oriented Computing", The 9th IASTED
International Conference on Software Engineering and
Applications (SEA), Phoenix, November 2005, pp. 160-167.
[15] W.T. Tsai, "Service-Oriented System Engineering: A
New Paradigm," Proc. of IEEE International Workshop on
Service-Oriented System Engineering (SOSE), Beijing
October 2005, pp. 3 - 8.
[16] W.T. Tsai, B. Xiao, R. A. Paul, Y. Chen, “Consumer-
Centric Service-Oriented Architecture: A New Approach”,
Proc. of IEEE 2006 International Workshop on Collaborative
Computing, Integration, and Assurance (WCCIA), April
2006, pp. 175-180.
[17] O. Zimmermann, Sven Milinski, M. Craes, F.
Oellermann, "Second Generation Web Services-Oriented
Architecture in Production in the Finance Industry",
OOPSLA’04, Oct. Vancouver, 2004