Requirements Specification and Software Engineering Properties of Service Oriented Systems Jaroslav Kral, Michal Zemlicka Department of Software Engineering.

Requirements Specification and Software Engineering Properties

of Service Oriented Systems

Jaroslav Kral, Michal Zemlicka

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

IRMA2004 2

Service Orientation Software Systems

A virtual p2p network of (quite large) autonomous software

components interconnected by an appropriate middleware and

working like the real world services of mass services

systems

zemlicka:

asi by bylo dobré buď SO: SS, nebo service-oriented ss …

zemlicka:

asi by bylo dobré buď SO: SS, nebo service-oriented ss …

IRMA2004 3

Main Issues

• How depends the structure of requirements specification on the type of service orientation

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

• Consequences of SOSS for users (user top management inclusive)

• Obstacles of the proper use of SOSS

IRMA2004 4

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 substantially different user and engineering properties.

IRMA2004 5

Software paradigmA 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. The acceptance is a long term process (compare the experience with object-oriented paradigm)

zemlicka:

Místo „Acceptance“ by se možná hodilo „Even their acceptance“…

zemlicka:

Místo „Acceptance“ by se možná hodilo „Even their acceptance“…

Paradigm Shift• Service orientation is becoming the leading paradigm of software development. The reasons are

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

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

IRMA2004 7

Attributes of service orientation in our sense

• 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 autonomously)– Asynchronous cooperation

• The „application“ services integrated as black boxes, i.e. not developed, their interfaces only are known – The service interfaces can be data or message oriented

• There can be „infrastructure“services integrated as white boxes (developed)

IRMA2004 8

Consequences of p2p Architecture

• No central service from the technical point of view• Problems should be expected with the services

playing central logical role (e.g. coordination like UDDI, central databases, process control)– Effectiveness– Timeliness

– Concepts (Partial) decentralization of „central“ services desirable

(e.g. distributed databases with different task specific interfaces)

IRMA2004 9

SOSS Types

• Alliances– The communication partners must be looked

for in principle all over the world– Typical application – e-commerce

• Confederations– The communication partners are almost

always known– Typical applications: large decentralized

companies, health systems, CRM, SCM, e-government, soft real-time systems, etc.

IRMA2004 10

Properties of Alliances

• Appropriate/necessary for e-commerce• Future communicating partners are not known –

dialogs cannot be tuned• Internet must be used to achieve world-wide

accessibility • The interfaces must be based on general-

purpose standards and low-level/universal programming tools (e.g. SOAP)

IRMA2004 11

Properties of Confederations

• Appropriate for large organizations and some real-time systems

• Future partners are usually known – dialogs can be tuned

• Various techniques can be applied• Predecessors of such systems are known from history• Middleware and communication techniques and

philosophies can be adapted to particular needsWe shall discuss mainly the case of confederations

IRMA2004 12

Structure of a Confederation

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

IRMA2004 13

The Crucial Properties of Interfaces

• Stability – Does not imply the changes of partners if

implementation of the given service varies

– The need to rewrite of services is reduced• Effective (not too much messages)• Simple for use

Understandable for partners/usersSimple protocols (semantically rich messages

and/or data)

IRMA2004 14

Fulfilled by User-Oriented Interfaces

• Stable – based on principles used often for centuries

• Coarse grained and effective – human beings are otherwise unable to respond to too many messages

• Simple in use – based on the intuition and knowledge of the user domain knowledge area

• User-oriented interface must be used if we want to have legal responsibilities – users and experts must understand the communication log in the case of law suits or complex failures

IRMA2004 15

Variants of User Orientation

The implementation of interfaces should mirror message formats as well as the communication protocols and

autonomy of receivers• Operational level – performing commands (message

passing)• Management level – intelligent communication via a

(common) database (data oriented interface)Enterprise

Scheduler FMS

FMS manager

Database

IRMA2004 16

Data-Oriented Interface

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

IRMA2004 17

Changes of InterfacesReasons why not user oriented interfaces are not used:

– Interface is implementation oriented to enable access to all functions of corresponding services

– The need to have different interfaces for different groups of users

– An interface is a part of a software component that cannot be modified (legacy, third party products)

Solution:– Implement a service FEG providing transformation,

combination and routing of services

G Service

FEGPartners, first type

Partners, second type

FEG

IRMA2004 18

The Use of Front-End GatesFront end gate (FEG) is a service transforming, combining and routing messages (compare XSLT engines). Implemented as a

white box (developed).FEG can implement some properties of gates places in colored

Petri nets.

Service G G Service

Service G

UC

UC

Old service interface

System interface 1

System interface 2

FEG

FEG

FEG

FEG middleware

IRMA2004 19

Standards• User-oriented interfaces tend to be declarative.

– it follows that the direct use of rather procedural and low level tools like SOAP is not the best choice. User oriented interfaces have, however, no formal standards

• Solution: – If the basic language of an application services is or must be

SOAP based use front-end gates (FEG) to translate sequences of SOAP messages into user oriented high level messages.

– FEG behaves like a compiler translating high level messages into sequences of SOAP messages and vice versa. Similar turn can be used in the case of data oriented communication.

– User oriented standards can be tuned and formally standardized later

IRMA2004 20

Challenges and Opportunities for Users

• Flexible outsourcing and insourcing• Organizational changes (reorganization,

decentralization) easier• Support of long term collaborations even in

e-commerce – CRM (loose cooperation with regular customers)– SCM (loose cooperation with regular suppliers)

• Warning. Top and middle management of the users should be involved into the requirements specification

IRMA2004 21

Advantages 1: Screen prototypes

Implemented service

Service not implemented yet

log

User interface

Redirected

MiddlewareImplemented service

Implemented service

IRMA2004 22

Advantages 2: SW Engineering Properties

• Supports incremental development• Easy user involvement and application of agile

forms of development• Modifiability• Reduction of development effort due to

– Decomposition and independent development of services– Powerful debugging tools– Integration of legacy systems and third-party products,

reuse– Easy outsourcing– Modifiability (changes tend to be local) – Stability – etc.

IRMA2004 23

Main Points of Specifications

1. The decision (after an analysis) that a confederation can be used (i.e. there is almost fixed set of services)

2. User involvement3. Incremental development (not all at once)

• Start from the most useful services (apply Pareto 80-20 rule)

4. Specification of services and their interfaces. • Use existing services as much as possible. • Newly developed services should mirror the real world

services.• The service interfaces should be user oriented, coarse

grained, declarative. Interfaces are the corner stone of the developed system.

• Reduce the use of central services, decentralize them (it is usually possible)

IRMA2004 24

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 system was 25 years used without maintenance• Is about to be retired, the reason is that the production type

(gearwheels) is not needed anymore

Similar observations for SOSS the authors and their friends have taken part in

Achievable generally via service orientation!!

IRMA2004 25

Quality Indicators• Crucial quality indicators

– p2p, peers – large black boxes services and possibly infrastructure white box services,

– User-oriented interfaces– User understandable services as peers– White boxes – services – message routers and transformers– Limited use of central services, decentralization of central

services, if possible }it is often the case• Desirable properties, crucial for some systems

– Internet and web-services– XML

IRMA2004 26

Related Areas

• Grid computing – networks of autonomous applications

• Intelligent agents – autonomous cooperating peers

• Petri nets • Networks administration• Symmetric multiprocessing

Conclusions

Service orientation has the potential to convert software artifacts into a true hi-tech engineering product having preferable engineering attributes.

As a paradigm being new for the majority of software developers the service orientation must overcome thinking barriers and prejudices, intensify user involvement, update education of developers and change business strategies. It will be a long-term process.

Many good practices, specification, modeling, and development tools must be developed yet. A important good practice is the user orientation of interfaces

The structure requirements specification must reflect the fact that a service-oriented system is to be developed.