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. IRMA20042 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 zemlicka: asi by bylo dobré buď SO: SS, nebo service- oriented ss … zemlicka: asi by bylo dobré buď SO: SS, nebo service- oriented ss …

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

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

5. IRMA20045 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) zemlicka: Místo „Acceptance“ by se možná hodilo „Even their acceptance“… zemlicka: Místo „Acceptance“ by se možná hodilo „Even their acceptance“…

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

8. IRMA20048 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)

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

10. IRMA200410 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)

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

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

13. IRMA200413 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)

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

15. IRMA200415 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)

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

17. IRMA200417 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 G Service FEG Partners, first type Partners, second type FEG

18. IRMA200418 The Use of Front-End Gates Front 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.

19. IRMA200419 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 based use 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 standards can be tuned and formally standardized later

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

21. IRMA200421 Advantages 1: Screen prototypes

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

23. IRMA200423 Main Points of Specifications 1.The decision (after an analysis) that a confederation can be used (i.e. there is almost fixed set of services) 2.User involvement 3.Incremental development (not all at once) Start from the most useful services (apply Pareto 80-20 rule) 4.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)

24. IRMA200424 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!!

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

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

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.