Requirements Specification and Software Engineering Properties of Service Oriented Systems

1. Requirements Specification and Software Engineering Properties of Service Oriented Systems Jaroslav Kral, Michal Zemlicka Department of Software Engineering Faculty of Mathematics and Physics, Charles University Prague

2. zemlicka: asi by bylo dobré buď SO: SS, nebo service-oriented ss … Service Orientation Software Systems A virtual p2p network of (quite large) autonomous software components interconnected by an appropriate middleware and working like the real world services of mass services systems IRMA2004

3. Main Issues • How depends the structure of requirements specification on the type of service orientation • What specification principles imply good user and engineering properties of service-oriented software systems (SOSS). • Consequences of SOSS for users (user top management inclusive) • Obstacles of the proper use of SOSS IRMA2004

4. The Concept of Service-Orientation • Service orientation is a crucial software engineering paradigm. It is a challenge as well as an issue. • Service orientation is not limited to web services and Internet. • There are service-oriented software systems having substantially different user and engineering properties. IRMA2004

5. zemlicka: Místo „Acceptance“ by se možná hodilo „Even their acceptance“… Software paradigm • A generally applicable philosophy, tools, methodology, best practices, experiences, and success stories enabling effective solutions of tasks/projects in some area of software development. • Observation:Paradigms are difficult not only to develop, but also to accept. The acceptance is a long term process (compare the experience with object-oriented paradigm) IRMA2004

6. Paradigm Shift Service orientation is becoming the leading paradigm of software development. The reasons are global systems needed and technically feasible progress of development techniques and communications Service orientation is not generally understood and accepted. This issue will take years to be solved (compare the the history of object orientation). The process of the acceptance of service orientation can be fastened by involving people having experience with soft real-time (e.g. manufacturing) systems

7. Attributes of service orientation in our sense • A virtual p2p network of autonomous components behaving like services in a mass service systems • Autonomy – a component/service works properly as a stand alone application if its inputs are filled (it can de developed autonomously) • Asynchronous cooperation • The „application“ services integrated as black boxes, i.e. not developed, their interfaces only are known • The service interfaces can be data or message oriented • There can be „infrastructure“services integrated as white boxes (developed) IRMA2004

8. Consequences of p2p Architecture • No central service from the technical point of view • Problems should be expected with the services playing central logical role (e.g. coordination like UDDI, central databases, process control) • Effectiveness • Timeliness • Concepts (Partial) decentralization of „central“ services desirable (e.g. distributed databases with different task specific interfaces) IRMA2004

9. SOSS Types • Alliances • The communication partners must be looked for in principle all over the world • Typical application – e-commerce • Confederations • The communication partners are almost always known • Typical applications: large decentralized companies, health systems, CRM, SCM, e-government, soft real-time systems, etc. IRMA2004

10. Properties of Alliances • Appropriate/necessary for e-commerce • Future communicating partners are not known – dialogs cannot be tuned • Internet must be used to achieve world-wide accessibility • The interfaces must be based on general-purpose standards and low-level/universal programming tools (e.g. SOAP) IRMA2004

11. Properties of Confederations • Appropriate for large organizations and some real-time systems • Future partners are usually known – dialogs can be tuned • Various techniques can be applied • Predecessors of such systems are known from history • Middleware and communication techniques and philosophies can be adapted to particular needs We shall discuss mainly the case of confederations IRMA2004

12. Structure of a Confederation log Physical (black) and logical (yellow, blue) views UC – service providing user interface IRMA2004

13. The Crucial Properties of Interfaces • Stability • Does not imply the changes of partners if implementation of the given service varies • The need to rewrite of services is reduced • Effective (not too much messages) • Simple for use • Understandable for partners/users • Simple protocols (semantically rich messages and/or data) IRMA2004

14. Fulfilled by User-Oriented Interfaces • Stable – based on principles used often for centuries • Coarse grained and effective – human beings are otherwise unable to respond to too many messages • Simple in use – based on the intuition and knowledge of the user domain knowledge area • User-oriented interface must be used if we want to have legal responsibilities –users and experts must understand the communication log in the case of law suits or complex failures IRMA2004

15. Variants of User Orientation The implementation of interfaces should mirror message formats as well as the communication protocols and autonomy of receivers • Operational level – performing commands (message passing) • Management level – intelligent communication via a (common) database (data oriented interface) IRMA2004

16. Data-Oriented Interface Data orientation is typical for „intelligent“ collaborations (management level) IRMA2004

17. Changes of Interfaces Reasons why not user oriented interfaces are not used: • Interface is implementation oriented to enable access to all functions of corresponding services • The need to have different interfaces for different groups of users • An interface is a part of a software component that cannot be modified (legacy, third party products) Solution: • Implement a service FEG providing transformation, combination and routing of services Partners, first type FEG G Service Partners, second type FEG IRMA2004

18. The Use of Front-End GatesFront end gate (FEG) is a service transforming, combining and routing messages (compare XSLT engines). Implemented as a white box (developed).FEG can implement some properties of gates places in colored Petri nets. IRMA2004

19. Standards • User-oriented interfaces tend to be declarative. • it follows that the direct use of rather procedural and low level tools like SOAP is not the best choice. User oriented interfaces have, however, no formal standards • Solution: • If the basic language of an application services is or must be SOAP baseduse front-end gates (FEG) to translate sequences of SOAP messages into user oriented high level messages. • FEG behaves like a compiler translating high level messages into sequences of SOAP messages and vice versa. Similar turn can be used in the case of data oriented communication. • User oriented standardscan be tuned and formally standardizedlater IRMA2004

20. Challenges and Opportunities for Users • Flexible outsourcing and insourcing • Organizational changes (reorganization, decentralization) easier • Support of long term collaborations even in e-commerce • CRM (loose cooperation with regular customers) • SCM (loose cooperation with regular suppliers) • Warning. Top and middle management of the users should be involved into the requirements specification IRMA2004

21. Advantages 1: Screen prototypes IRMA2004

22. Advantages 2: SW Engineering Properties • Supports incremental development • Easy user involvement and application of agile forms of development • Modifiability • Reduction of development effort due to • Decomposition and independent development of services • Powerful debugging tools • Integration of legacy systems and third-party products, reuse • Easy outsourcing • Modifiability (changes tend to be local) • Stability • etc. IRMA2004

23. Main Points of Specifications • The decision (after an analysis) that a confederation can be used (i.e. there is almost fixed set of services) • User involvement • Incremental development (not all at once) • Start from the most useful services (apply Pareto 80-20rule) • Specification of services and their interfaces. • Use existing services as much as possible. • Newly developed services should mirror the real world services. • The service interfaces should be user oriented, coarse grained, declarative. Interfaces are the corner stone of the developed system. • Reduce the use of central services, decentralize them (it is usually possible) IRMA2004

24. Practical Experiences with a Flexible Manufacturing System Designed as SOSS • Results over expectations at low as well as at management level, general satisfaction • Although an island of automation it survived several ERP systems • The system was 25 years used without maintenance • Is about to be retired, the reason is that the production type (gearwheels) is not needed anymore Similar observations for SOSS the authors and their friends have taken part in Achievable generally via service orientation!! IRMA2004

25. Quality Indicators • Crucial quality indicators • p2p, peers – large black boxes services and possibly infrastructure white box services, • User-oriented interfaces • User understandable services as peers • White boxes – services –message routers and transformers • Limited use of central services, decentralization of central services, if possible }it is often the case • Desirable properties, crucial for some systems • Internet and web-services • XML IRMA2004

26. Related Areas • Grid computing – networks of autonomous applications • Intelligent agents – autonomous cooperating peers • Petri nets • Networks administration • Symmetric multiprocessing IRMA2004

27. Conclusions Service orientation has the potential to convert software artifacts into a true hi-tech engineering product having preferable engineering attributes. As a paradigm being new for the majority of software developers the service orientation must overcome thinking barriers and prejudices, intensify user involvement, update education of developers and change business strategies. It will be a long-term process. Many good practices, specification, modeling, and development tools must be developed yet. A important good practice is the user orientation of interfaces The structure requirements specification must reflect the fact that a service-oriented system is to be developed.