Upload
matilda-parker
View
212
Download
0
Tags:
Embed Size (px)
Citation preview
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