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

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 e-service Technology Development end Application in High-performance Computing Platforms“ (No. VP1-3.1-ŠMM-08-K-01-010) funded by the European Social Fund.

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

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

SoEA Concept

BSC 2013, Rīga

SOA

EA SOEA

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

SoEA Concept

BSC 2013, Rīga

Internal Consumer

External Consumer

Enterprise Service Bus Intranet/Extranet

EBS A

EBS B

EBS C

EBS D

Enterprise Business Service (EBS) Consumers

Infrastructure

EBS Interface

EBS Implementation

ERP CRM External Systems

Examples: SAP Enterprise SOA, IBM WebSphere

Other Internal Systems

SOA vs. SoEASOA 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.

BSC 2013, Rīga* Normalisation means that each EBS should be designed with the intent to avoid functional overlaps and to reduce the redundancies in EBSs.

SOA vs. SoEASOA 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

SOA vs. SoEASOA 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

QoS Concept

BSC 2013, Rīga

• 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.

• There is no generic quality model proposed to evaluate quality of services.

Elephant Problem

BSC 2013, Rīga

How does the elephant really look?

QoS Problem

BSC 2013, Rīga

What is the QoS indeed?

QoS

Application perspective

Designer’s viewpoint

Value-based viewpoint

Infrastructure perspective

Web-service perspective

Transportation perspective

Presentation perspective

Data perspective

Socio-economic perspective

Domain perspective

QoS

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 Internet-wide 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

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

Conclusions• At present, QoS modeling techniques are too much technology-

oriented.• 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

Thank you for your attention!Questions?

BSC 2013, Rīga