Towards Rationales of Software Confederations Jaroslav Král, Michal Žemlička Department 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 services Similar 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 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 Middleware User Gate

Control Systems Level- crossing gate Train detector commands