Towards Rationales of Software Confederations

  • View
    25

  • Download
    2

Embed Size (px)

DESCRIPTION

Towards Rationales of Software Confederations. Jaroslav Král, Michal Žemlička Department of Software engineering Faculty of Mathematics and Physics Charles University, Prague. Holy grail New paradigm. Old habits in a new coat Buzzword. Service Orientation:. ?. Holy grail New paradigm. - PowerPoint PPT Presentation

Text of Towards Rationales of Software Confederations

  • Towards Rationales of Software ConfederationsJaroslav Krl, Michal emlikaDepartment of Software engineeringFaculty of Mathematics and PhysicsCharles University, Prague

  • Service Orientation:Holy grail

    New paradigmOld habits in a new coat

    Buzzword?

  • Service Orientation:Holy grail

    New paradigmOld habits in a new coat

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

  • Service orientation - historySome 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 SystemsApp2App3App1Batch 1Batch 2

  • Batch SystemsBatches are composed from simple specialized applicationsApplications are simple enough not to be error proneApplications are typically used for many years, sometimes even decadesY2K has shown that in many companies such systems were working without any maintenance for a very long time

  • Batch SystemsUsed from 60-iescooperation can be provided off-linecommunication between software entities is typically provided by filesIndividual steps can be restarted when failed

  • Control SystemsControl units of individual machines behave like black boxes only interface is knownCommunication between control units is based on commandsDifferent control units may use different languages translation of the messages is necessary

  • Control Systems (2)Used from 70-iesNo UNDO or REDO possibleIt is possible to run more control units/applications on one computer working virtual peer-to-peer network of software entities

  • TerminologyEnterprise 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: Tendenciescan be designed known and almost fixed collection of servicespresence of user interface to whole systemknown 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 OrientationAlliances:e-commerce supported by web servicesSoftware confederations:e-governmentIS of (international) enterprisescontrol systems

  • Software Confederation(Virtual) peer-to-peer network of autonomous services/components/applicationsHigh-level architecture/paradigmCan be combined with other software development paradigmsComposed from almost fixed set of applications used as black boxes and additional components (portals, front-end gates) used as white boxes

  • Software Confederationprimary gateApplicationfront-end gatefront-end gateMiddlewareUserGate............

  • Experience: Several paradigms must be applied in SOSSMiddleware 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 PropertiesProblem-oriented (based on terminology used for solving such problems)Declarative (high-level commands)Can/should be set by negotiation of cooperating service developersUser readable and understandable (i.e. user-oriented) Long-term stability can be expected

  • Advantages of Problem-Oriented InterfacesUsers understand the interface; can report possible errors in early development stagesUsers can be involved in designProblems exist longer time than applications such interfaces can be very stableService with problem-oriented interface can be simulated manually

  • Advantages of Problem-Oriented InterfacesChanges in an application need not to be reflected in cooperating applications communicating via such interfaceLog of such communication can be easily analyzed and used at court when neededSuch communication is very effective

  • Software Confederations: User Involvementcomplex workflows over services need supervisionresponsibility issuesuser activities:definition and modification of processesstarting and rescheduling processessupervision/influence/performance of stepsreplacement of computerized services by manual ones

  • Users as Servicessome services can be performed manuallygood for prototyping and emergency situationsoften advantageous when users control the service or take part in its work (business decisions, work assignment, scheduling, etc.)

  • Software Engineering Advantagesuser involvementmodifiabilityincremental and iterative developmentprototyping and replacement of non available servicesshort milestonessolution/refactoring of many antipatternsnew development turnsreduction of development effort

  • Open Issueswhose services should be centralizedvendors try to keep customs dependentnew paradigm needs other knowledgedata intensive function can benefit from SO but there is no support for it nowconfederations can use some seemingly obsolete techniquessecurity and effectiveness

  • Design of Service-Oriented Systemsservices should work as peer-to-peerservices (their interface) should mirror real-world servicesusers should be deeply involved in specification and design of interfacesdevelopment process and interfaces depend on SO type

  • Design of Service-Oriented Systemsservices 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 runCarefully select developers object-oriented ones may have problems with SO acceptance

  • Conclusions:Service Orientationis a new paradigmneeds time to be generally accepted, to develop methodologies, best practices, and toolsnecessity when building large or complex applicationssubstantially influences requirements specification

  • Conclusions:Service Orientationrequires new type of IT educationrequires tighter cooperation between users and developersdevelopers should understand user problem and knowledge domain

  • Conclusions:Software ConfederationsCommunication by high-level human-oriented commandsServices may and should have front-end gates transforming the high-level commands into application interfaceMay use (can be based on) legacy and third party systems

  • Software Confederationprimary gateApplicationfront-end gatefront-end gateMiddlewareUserGate............

  • Control SystemsLevel-crossing gateTrain detectorcommands