Transcript

Towards Rationales of Software Confederations

Jaroslav Král, Michal ŽemličkaDepartment of Software engineering

Faculty of Mathematics and Physics

Charles University, Prague

Service Orientation:

Holy grail

New paradigm

Old habits in a new coat

Buzzword

?

Service Orientation:

Holy grail

New paradigm

Old habits in a new coat

Buzzword

?

Paradigm using many existing techniques new for many people applied in new areas

Service orientation - history

• Some of the SO features can be found in batch systems written in COBOL in 70-ies (the activities were performed by cooperating applications) and especially in (soft) real/time systems applications cooperating by complex human-readable messages.

Batch Systems

App2

App3

App1

Batch 1

Batch 2

Batch Systems• Batches are composed from simple

specialized applications

• Applications are simple enough not to be error prone

• Applications are typically used for many years, sometimes even decades

• Y2K has shown that in many companies such systems were working without any maintenance for a very long time

Batch Systems

• Used from 60-ies

• cooperation can be provided off-line

• communication between software entities is typically provided by files

• Individual steps can be restarted when failed

Control Systems

• Control units of individual machines behave like black boxes – only interface is known

• Communication between control units is based on commands

• Different control units may use different languages translation of the messages is necessary

Control Systems (2)

• Used from 70-ies

• No UNDO or REDO possible

• It is possible to run more control units/applications on one computer working virtual peer-to-peer network of software entities

Terminology

• Enterprise Information System – information system supporting all activities of given enterprise (inclusive manufacturing, sales, management functions, resource management, warehousing, etc.)

• Paradigm – a generally accepted perspective of a particular discipline at a given time

Decentralized Enterprise IS: Tendencies

• can be designed known and almost fixed collection of services

• presence of user interface to whole system• known set of multi-step business processes

involving the servicesSimilar properties can be found also in IS

supporting e-government and in many other systems

Types of Service Orientation

Alliances:

• e-commerce supported by web services

Software confederations:

• e-government

• IS of (international) enterprises

• control systems

• …

Software Confederation

• (Virtual) peer-to-peer network of autonomous services/components/applications

• High-level architecture/paradigm• Can be combined with other software

development paradigms• Composed from almost fixed set of applications

used as black boxes and additional components (portals, front-end gates) used as white boxes

Software Confederation

primary gate

Application

front-end gate

front-end gate

Middleware

User

Gate

.

.

.

.

.

.

.

.

.

.

.

.

Experience: Several paradigms must be applied in SOSS

• Middleware can be implemented as message-passing or data-oriented (DO). DO is often necessary to support management.

• Middleware need not be Internet-based.

• Object orientation is good for development of individual services.

Service Interface Properties

• Problem-oriented (based on terminology used for solving such problems)

• Declarative (high-level commands)• Can/should be set by negotiation of

cooperating service developers• User readable and understandable (i.e. user-

oriented) Long-term stability can be expected

Advantages of Problem-Oriented Interfaces

• Users understand the interface; can report possible errors in early development stages

• Users can be involved in design• Problems exist longer time than applications

– such interfaces can be very stable• Service with problem-oriented interface can

be simulated manually

Advantages of Problem-Oriented Interfaces

• Changes in an application need not to be reflected in cooperating applications communicating via such interface

• Log of such communication can be easily analyzed and used at court when needed

• Such communication is very effective

Software Confederations: User Involvement

• complex workflows over services need supervision– responsibility issues

• user activities:– definition and modification of processes

– starting and rescheduling processes

– supervision/influence/performance of steps

– replacement of computerized services by manual ones

Users as Services

• some services can be performed manually

• good for prototyping and emergency situations

• often advantageous when users control the service or take part in its work (business decisions, work assignment, scheduling, etc.)

Software Engineering Advantages

• user involvement• modifiability• incremental and iterative development• prototyping and replacement of non

available services• short milestones• solution/refactoring of many antipatterns• new development turns• reduction of development effort

Open Issues

• whose services should be centralized• vendors try to keep customs dependent• new paradigm needs other knowledge• data intensive function can benefit from SO

but there is no support for it now• confederations can use some seemingly

obsolete techniques• security and effectiveness

Design of Service-Oriented Systems

• services should work as peer-to-peer

• services (their interface) should mirror real-world services

• users should be deeply involved in specification and design of interfaces

• development process and interfaces depend on SO type

Design of Service-Oriented Systems

• services should be replaceable by human activities (at least in emergency)

• use incremental development; start from most valuable services (80-20 law)

• automate as little as possible – involve users also in the system run

• Carefully select developers – object-oriented ones may have problems with SO acceptance

Conclusions:Service Orientation

• is a new paradigm• needs time to be generally accepted, to

develop methodologies, best practices, and tools

• necessity when building large or complex applications

• substantially influences requirements specification

Conclusions:Service Orientation

• requires new type of IT education

• requires tighter cooperation between users and developers

• developers should understand user problem and knowledge domain

Conclusions:Software Confederations

• Communication by high-level human-oriented commands

• Services may and should have front-end gates transforming the high-level commands into application interface

• May use (can be based on) legacy and third party systems

Software Confederation

primary gate

Application

front-end gate

front-end gate

Middleware

User

Gate

.

.

.

.

.

.

.

.

.

.

.

.

Control Systems

Level-crossing gate

Train detector

commands