Service Orientation and the Quality Indicators for Software

Services

Jaroslav Kral, Michal Zemlicka

Department of Software Engineering Faculty of Mathematics and Physics, Charles University Prague

Main issues

• What specification design principles imply good user and engineering properties of service-oriented software systems (SOSS).

• Consequences of SOSS for users (user top management inclusive), IT management, IT marketing, and software development

• Consequences for the education of software experts

The concept of Service-orientation

Service orientation is a crucial software engineering paradigm. It is a challenge as well as an issue.Service orientation is not limited to web services and Internet.There are service-oriented software systems having different user and engineering properties..

Software paradigm

A generally applicable philosophy, tools, methodology, best practices, experiences, and success stories

enabling effective solutions of tasks/projects in some

area of software development.

Observation. Paradigms are difficult not only to develop, but also to accept. Acceptance is a long term process

Attributes of service orientation

• System architecture is a virtual p2p network of autonomous components behaving like services in a mass service systems– Autonomy – a component/service works properly as

a stand alone application if its inputs are filled (it can de developed autonomly)

• The services are integrated as black boxes, i.e. their interfaces only are known – The interfaces can be data or message oriented

Variants of service oriented systems

1. Alliances. The comunication partners must be at the beginning of the communication looked for.

– E-commerce

2. Confederations. The services know each other. The communication parners need not be looked for.

– E-government– IS of decentralized enterprises– Support of SCM, and CRM – Manufacuring support systems, ….

Properties of Confederations

• Appropriate for large organizations• Partners are known – dialogs can be tuned• Many techniques can be applied• Predecessors are known from history• Middleware can be adapted to particular needs

We shall discuss mainly the case of confederations

Batch predecessors of SOSS

COBOL systems were the first systems having the structure of the network of autonomous applications

communicating via datastores

Experience

• The case Y2K has shown that there were COBOL systems used for years without any maintenance (enterprises had no COBOL programmers able to modify applications routinely in use)

• Incremental development• Many generally usable applications, e.g.

report generators, data filters, …

Online systems, firstly in soft real-time systems

• Autonomous permanently active application

• Equipped by sockets connecting them to a middleware

• Crucial role of the application interfaces• Middleware can use quite different

technologies (message passing or common data, Internet or local networks)

Structure of a modern SOSS

Middleware Service G G Service

Service G

UC

UC

Old service interface

System interface 1

System interface 2

Physical (black) and logical (yellow, blue) views

UC – service providing user interface

log

User oriented interfaces – quality drivers

SOSS is stable if service interfaces are not varying.User oriented interfaces tend to be

– Declarative – Not changing– Coarse grained – not too many messages per action– Understandable for users – they can be easy involved into system

development

Such interfaces enhances engineering qualityThey are not easy to achieve, need not be SOAP based.

Sometimes message passing, sometimes data oriented

Data oriented interface

Data orientation is typical for „intelligent“ collaborations (management level)

Middleware via a database

Enterprise

Scheduler FMS

FMS manager

Database

Message passing is dominant in operation level

of service oriented systems

Messages can be easily redirected.It can be used as a powerful development

tool (prototyping, requirements specification,definition of business

processes).

Engineering advantages

• Easy integration of legacy systems and third party product

• Incremental development, Pareto 80-20 rule applicable - usable system early available

• Implemetation details hidden and localized• Modifiability, reusability, etc• Agile development can be used in large

systems

Virtual prototyping in a soft real-time system

Control logic Middleware Drivers

Controlled system

log

User interface

Redirected 1

Simulator

Redirected 2

Prototyping via user interface provided there are not too many messages

Virtual prototyping in SOSS

Implemented service

Service not implemeted yet

log

User interface

Redirected

MiddlewareImplemented service

Implemented service

Practical experiences with a flexible manufacturing system designed as

SOSS• Results over expectations at low as well as at management

level, general satisfaction• Although an island of automation it survived several ERP

systems• The systems was 25 years used without maintenance• Is about to be retired, the reason is that the production type

(gearwheels) is not needed anymoreSimilar observations for all SOSS the authors

and their friends have took part in

Achievable generally via service orientation!!

Paradigm shiftService orientation is becoming the leading paradigm of software development. The reasons are

– global systems needed and technically feasible– progress of development techniques

Service orientation is not generally understood and accepted. This issue will take years to be resolved (compare the the history of object orientation).The process of the acceptance of SO can be fastened by involving people having experience with soft real-time (e.g. manufacturing) systems

Service orientation and education of software

expertsNot only a deep and narrow computer knowledge

– User-oriented interfaces developers must understand user knowledge– IT graduates underrate users– IT gradutes dislike non computer (empirical) knowledge– IT graduates dislike SW engineering (e.g. Reusability)

Can be called as hacker syndrome

Difficult to cure (real-life projects cannot be developed in lectures)

How to prevent hacker syndrome• Enough noncomputer lessons from very

beginning of the study• The noncomputer lessons should include the

exercises on empirical inference (data analysis)

• The empirical evaluation using very elementary statistical tools should be included in early computer science, software engineering, or programming lectures (when to stop testing, error prone components, quality of programmers, …) to prevent the development of the hacker syndrome

 

Variants of software architectures

Software technique Area of application

Service orientation (possibly partly)

Manufacturing control level: CIM components, real time

systems

Object orientation (possibly supported by e.g. UML, MDA)

Monolithic enterprise level: middle management, divisions of an international enterprise, highly centralized organizations

Service orientation desirable, necessary

Global (world-wide) enterprise level: international

enterprises, state administration ...

Service-orientation necessary, B2B

World-wide business: some health network services, coalition of car vendors, e-business, etc

 

Quality indicators

• Crucial quality indicators– p2p, peers – large black boxes, – User oriented interfaces– User services as peers– White boxes – services –message routers and

tranformers• Desirable properties, crucial for some systems

– Internet and web-services– XML

Conclusions

Service orientation has the potential to convert software into a true hi-tech engineering product (no Warranty Disclaimer).

As a paradigm being new for the majority of software developers it must overcome thinking barriers and prejudicesces. It will be a long-term process.

Good practices, specification, modeling, and development tools must be developed yet. An example is the development starting from service interfaces

Service orientation implies changes in the education