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

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

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..

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

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

Variants of service oriented systems 1.Alliances. The comunication partners must be at the beginning of the communication looked for. – E-commerce 2.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, ….

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

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

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, …

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)

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

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

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

Middleware via a database Enterprise SchedulerFMS FMS manager Database

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

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

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

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

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!!

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

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)

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

Variants of software architectures Software techniqueArea 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

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

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