Towards Rationales of Software Confederations

1
Towards Rationales of Software Confederations

• Jaroslav Král, Michal Žemlicka
• Department of Software engineering
• Faculty of Mathematics and Physics
• Charles University, Prague

2
Service Orientation

• Old habits in a new coat
• Buzzword

?

• Holy grail
• New paradigm

3
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
4
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.

5
Batch Systems
Batch 1
App2
App1
App3
Batch 2
6
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

7
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

8
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

9
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

10
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

11
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 services
• Similar properties can be found also in IS
  supporting e-government and in many other systems

12
Types of Service Orientation

• Alliances
• e-commerce supported by web services
• Software confederations
• e-government
• IS of (international) enterprises
• control systems

13
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

14
Software Confederation
Middleware
. . .
. . .
front-end gate
User Gate
primary gate
Application
. . .
. . .
front-end gate
15
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.

16
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

17
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

18
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

19
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

20
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.)

21
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

22
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

23
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

24
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

25
ConclusionsService 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

26
ConclusionsService Orientation

• requires new type of IT education
• requires tighter cooperation between users and
  developers
• developers should understand user problem and
  knowledge domain

27
ConclusionsSoftware 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

28
Software Confederation
Middleware
. . .
. . .
front-end gate
User Gate
primary gate
Application
. . .
. . .
front-end gate
29
Control Systems
Level-crossing gate
commands
Train detector