Service Orientation and the Quality Indicators for Software Services

1. Service Orientation and the Quality Indicators for Software Services Jaroslav Kral, Michal Zemlicka Department of Software Engineering Faculty of Mathematics and Physics, Charles University Prague

2. Main issues • What specification design principles imply good user and engineering properties of service-oriented software systems (SOSS). • Consequences of SOSS for users (user top management inclusive), IT management, IT marketing, and software development • Consequences for the education of software experts

3. 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 different user and engineering properties..

4. 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. Acceptance is a long term process

5. Attributes of service orientation • System architecture is 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 autonomly) • The services are integrated as black boxes, i.e. their interfaces only are known • The interfaces can be data or message oriented

6. Variants of service oriented systems Alliances. The comunication partners must be at the beginning of the communication looked for. E-commerce Confederations. The services know each other. The communication parners need not be looked for. E-government IS of decentralized enterprises Support of SCM, and CRM Manufacuring support systems, ….

7. Properties of Confederations • Appropriate for large organizations • Partners are known – dialogs can be tuned • Many techniques can be applied • Predecessors are known from history • Middleware can be adapted to particular needs We shall discuss mainly the case of confederations

8. Batch predecessors of SOSS COBOL systems were the first systems having the structure of the network of autonomous applications communicating via datastores

9. Experience • The case Y2K has shown that there were COBOL systems used for years without any maintenance (enterprises had no COBOL programmers able to modify applications routinely in use) • Incremental development • Many generally usable applications, e.g. report generators, data filters, …

10. Online systems, firstly in soft real-time systems • Autonomous permanently active application • Equipped by sockets connecting them to a middleware • Crucial role of the application interfaces • Middleware can use quite different technologies (message passing or common data, Internet or local networks)

11. Structure of a modern SOSS log Physical (black) and logical (yellow, blue) views UC – service providing user interface

12. User oriented interfaces – quality drivers SOSS is stable if service interfaces are not varying. User oriented interfaces tend to be • Declarative • Not changing • Coarse grained – not too many messages per action • Understandable for users – they can be easy involved into system development Such interfaces enhances engineering quality They are not easy to achieve, need not be SOAP based. Sometimes message passing, sometimes data oriented

13. Data oriented interface Data orientation is typical for „intelligent“ collaborations (management level)

14. Middleware via a database Enterprise FMS manager Scheduler FMS Database

15. Message passing is dominant in operation level of service oriented systemsMessages can be easily redirected.It can be used as a powerful development tool (prototyping, requirements specification,definition of business processes).

16. Engineering advantages • Easy integration of legacy systems and third party product • Incremental development, Pareto 80-20 rule applicable - usable system early available • Implemetation details hidden and localized • Modifiability, reusability, etc • Agile development can be used in large systems

17. Virtual prototyping in a soft real-time system User interface Redirected 1 Middleware Drivers Control logic Redirected 2 Controlled system Simulator log Prototyping via user interface providedthere are not too many messages

18. Virtual prototyping in SOSS User interface Implemented service Redirected Implemented service Service not implemeted yet Middleware Implemented service log

19. 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 systems 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 all SOSS the authors and their friends have took part in Achievable generally via service orientation!!

20. 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 Service orientation is not generally understood and accepted. This issue will take years to be resolved (compare the the history of object orientation). The process of the acceptance of SO can be fastened by involving people having experience with soft real-time (e.g. manufacturing) systems

21. Service orientation and education of software experts Not only a deep and narrow computer knowledge User-oriented interfaces  developers must understand user knowledge IT graduates underrate users IT gradutes dislike non computer (empirical) knowledge IT graduates dislike SW engineering (e.g. Reusability) Can be called as hacker syndrome Difficult to cure (real-life projects cannot be developed in lectures)

22. How to prevent hacker syndrome • Enough noncomputer lessons from very beginning of the study • The noncomputer lessons should include the exercises on empirical inference (data analysis) • The empirical evaluation using very elementary statistical tools should be included in early computer science, software engineering, or programming lectures (when to stop testing, error prone components, quality of programmers, …) to prevent the development of the hacker syndrome

23. Software technique Area of application Service orientation (possibly partly) Manufacturing control level: CIM components, real time systems Object orientation (possibly supported by e.g. UML, MDA) Monolithic enterprise level: middle management, divisions of an international enterprise, highly centralized organizations Service orientation desirable, necessary Global (world-wide) enterprise level: international enterprises, state administration ... Service-orientation necessary, B2B World-wide business: some health network services, coalition of car vendors, e-business, etc Variants of software architectures

24. Quality indicators • Crucial quality indicators • p2p, peers – large black boxes, • User oriented interfaces • User services as peers • White boxes – services –message routers and tranformers • Desirable properties, crucial for some systems • Internet and web-services • XML

25. Conclusions Service orientation has the potential to convert software into a true hi-tech engineering product (no Warranty Disclaimer). As a paradigm being new for the majority of software developers it must overcome thinking barriers and prejudicesces. It will be a long-term process. Good practices, specification, modeling, and development tools must be developed yet. An example is the development starting from service interfaces Service orientation implies changes in the education