1. A View-Based Approach to Quality of
Service Modelling
in Service-Oriented Enterprise Systems
Audronė Lupeikienė
Jolanta Miliauskaitė
Albertas Čaplinskas
Vilnius University
Institute of Mathematics and Informatics
BSC 2013, Rīga

2. Outline
•
•
•
•
•
•
Research objective
Service Oriented Enterprise Architecture (SoEA) concept
SOA vs SoEA
Quality of Service (QoS) concept
Problem
Conclusions
 The research has been supported by the project „Theoretical and Engineering Aspects of eservice Technology Development end Application in High-performance Computing
Platforms“ (No. VP1-3.1-ŠMM-08-K-01-010) funded by the European Social Fund.

3. Research Objective
• To propose a conceptual view-based framework
which describes and relates to each other the
different viewpoints and perspectives of QoS in
web-based Service-Oriented Enterprise System
(SoES).
BSC 2013, Rīga

4. SOA Service
Source: Phil Bianco, Rick Kotermanski, Paulo Merson, Evaluating a Service-Oriented Architecture; TECHNICAL
REPORT CMU/SEI-2007-TR-015 ESC-TR-2007-015, September 2007
BSC 2013, Rīga

5. SOA
SOEA
EA
SoEA Concept
A service-oriented architecture (SOA) “is
a framework for integrating business
processes and supporting IT
infrastructure as secure, standardized
components – services – that can be
reused and combined to address
changing business priorities.”*
Enterprise architecture (EA) “an
aggregated, holistic view of all systems,
people, and internal and external
constructs that have relationships within
the enterprise.”**
* Bieberstein, N., Bose, S., Fiammante, M., Jones, K., Shah, R. (2005): Service-Oriented Architecture (SOA) Compass - BusinessValue,
Planning, and Enterprise Roadmap. IBM Press.
** Allega, Ph. EA and SOA: Balancing Project Implementation and Top Down Guidance, 2005, EACommunity.com
BSC 2013, Rīga

6. SoEA Concept
Internal
Consumer
External
Consumer
Intranet/
Extranet
Enterprise Service Bus
Enterprise
Business Service
(EBS) Consumers
Infrastructure
EBS
EBS
EBS
A
EBS
B
C
D
EBS Interface
ERP
CRM
Other Internal
Systems
External
Systems
EBS
Implementation
Examples: SAP Enterprise SOA, IBM WebSphere
BSC 2013, Rīga

7. SOA vs. SoEA
SOA
SoEA
Open Internet-wide system. Developed in a
bottom-up manner.
Relatively closed enterprise-wide system
controlled on an enterprise-wide level.
Developed in a top-down manner.
Enterprise service inventory.
Deals with any business services. No ability
either to define global data types or
normalize business services (i.e., to avoid
similar or duplicate bodies of service logic).
Deals with normalized* enterprise business
services (EBS) aligned with the enterprise
business functions and working with global
data types.
Is not purported either to support a
particular business strategy or to implement
predefined business processes.
Is a set of interacting EBSs coordinated
by an enterprise business process. Supports
enterprise’s business strategy and
objectives.
No ability to guide what services are built
how they are built and deployed. No control
over changes of services.
Designed, developed and deployed in
compliance with an enterprise-wide
standards. All changes are under control.
* Normalisation means that each EBS should be designed with the intent to avoid functional overlaps and to reduce the redundancies
in EBSs.
BSC 2013, Rīga

8. SOA vs. SoEA
SOA
SoEA
The structure of messages is standardized
(e.g. by SOAP) but not unified. Interfaces
standardized (by WSDL), but are not clearly
defined and not stable. No ability to use
global data types in the interfaces.
The structures of messages is unified.
EBS interfaces are clearly defined, stable,
and make use of global data types
SLA is negotiated between provider and
consumer at the run time.
Mostly, mandated at the enterprise-wide
level at the design time.
Direct pear-to-pear communication
between consumer and provider. UDDI for
service registration and discovery.
Enterprise Service Bus acts as a mediator
between consumers and providers.
Neither service provides nor consumers
control SOA infrastructure and
communication networks.
Intranet, extranet, and the whole
infrastructure, including Enterprise Service
Bus, servers and so on are controlled by the
enterprise.
BSC 2013, Rīga

9. SOA vs. SoEA
SOA
SoEA
Recommended security and safety
standards.
Mandatory security and safety standards.
Some services are situation-aware but only
in rare cases are context-aware because the
context usually is ill-defined.
All services are context-aware because they
run in the well-defined enterprise context.
BSC 2013, Rīga

10. QoS Concept
•
•
•
•
•
In SOA, includes most of non-functional properties and even characteristics that are
hardly related to quality such as service requestor’s satisfaction or service cost.
Still remains ill-defined and frequently misused concept, but is an important issue
because SOA usefulness depends not only on the results of the executed services, but
also on the properties related to their execution.
In different contexts, refers to different things (software component, web service,
middleware, network, etc.).
In service engineering literature usually emphasizes the technology-oriented issues;
in service science literature mostly emphasizes the quality perceived by users.
BSC 2013, Rīga
There is no generic quality model proposed to evaluate quality of services.

11. Elephant Problem
How does the elephant really look?
BSC 2013, Rīga

12. QoS Problem
What is the QoS indeed?
Domain
perspective
Socio-economic perspective
Presentation
perspective
Designer’s
viewpoint
QoS
Data
perspective
QoS
Transportation
perspective
Infrastructure
perspective
Web-service
perspective
Value-based
viewpoint
Application
perspective
BSC 2013, Rīga

13. QoS Problem
• At present, the technology-oriented attitude (a developer’s
point of view) prevails when considering QoS of SOA
services. Other points of view are mostly ignored.
• It is difficult to solve the QoS problem for an open Internetwide SOA system.
• It is possible to solve this problem for SoES in which all
perspectives, at least partly, are under control of an enterprise.
Proposed approach
• To adapt the view reconciliation methodology.
• Motivation: QoS properties to some extent are akin to
software quality requirements.
BSC 2013, Rīga

14. Proposed Solution
• View construction: For each point of view to integrate
perspectives.
• Modeling approach: To represent each view as a set of
interacting each with others (in conflict or in synergy)
weighted quality goals (qualities).
• View balancing: To use weights and kinds of interactions, to
balance different views,
– i.e. to find such the configuration of qualities that the level of
achievement of each quality would be as much as possible acceptable
to each point of view under consideration.
– to adapt i* techniques in combination with an interactive conflict
resolution procedure to balance different views.
BSC 2013, Rīga

15. Conclusions
• At present, QoS modeling techniques are too much technologyoriented.
• It is necessary to balance technology-oriented viewpoint and
the other viewpoints.
• View reconciliation methodology should be adapted to model QoS.
• i* star methodology (in combination with interactive conflict
resolution procedures) should be applied to balance different
viewpoints.
BSC 2013, Rīga

16. Thank you for your attention!
Questions?
BSC 2013, Rīga