Service Orientation and Software-Intensive Systems

Service Orientation and Software-Intensive Systems

Jaroslav Král (Charles University, Czech Republic) and Michal Žemlicka (Charles University, Czech Republic)
Copyright: © 2009 |Pages: 21
DOI: 10.4018/978-1-59904-699-0.ch003
OnDemand PDF Download:


Software intensive systems are systems strongly depending on supporting software. The software is typically large, complex, and it as a rule interacts with human users. The failure of the software implies failure of the system usually causing substantial losses. Such systems are critical. The prospective redevelopment all at once of the software is no feasible solution. It is shown that such software should usually be service-oriented. The interfaces of services should be user-oriented (well understood by users and the users can use it easily). The services should be of two basic types: application services and architecture (enabling to develop an architecture) services. We present the most important infrastructure services as basic service-oriented design patterns.
Chapter Preview


We understand as software intensive systems the systems strongly depend on supporting software. The software is typically large and the design of the systems should take into account the activities of people, the users of the system. To be more specific, the dependency of the system on its software implies that the system cannot work properly if the supporting software does not work (fails). The software is moreover so complex that its redevelopment effort is so high and its development duration so large that the redevelopment of the entire system in “Big Bang” manner is no feasible solution. A very important but often neglected dimension of the software intensiveness is the degree of user involvement (agility) in the system and software actions and the degree of interaction of the system with real world.

All the aspects imply that the software supporting software intensive systems is a very complex high-tech engineering artifact. As such the software must be properly structured in the large. It must have a proper architecture.

The architecture should meet the following requirements:

  • 1.

    The all at once (re)development of the system is too costly and time consuming so the architecture should enable a cheap seamless integration of existing (large) software artifacts like legacy systems, third party products, or newly developed artifacts.

  • 2.

    The integration of the artifacts usually must not influence existing capabilities of the artifacts and their availability (but it can enhance them). It implies that the local (existing) user interfaces must be preserved, and eventually extended. These conditions enable that the exiting users of the “old” artifacts capabilities need not be aware that the integration just takes place or that the artifact has already been integrated.

  • 3.

    The integrated software artifacts should be integrated with minor changes, if any, of its code to save the integration investments, to reduce the errors caused by the changes, and to reduce other undesirable effects affecting the users.

  • 4.

    The integration of artifacts can be gradual (incremental). No “Big Bang” is necessary.

  • 5.

    The resulting system should be easily maintainable (enhanced, extended, per partes modified).

  • 6.

    It is desirable that the architecture is good for the application of modern development and integration methods (prototyping, incremental development, agile development, and the support for the overall improving software engineeringsoftware engineering quality of the new product).

  • 7.

    The architecture should enable the effective implementation of the requirements of business people. An example is the support, supervision, and use of business processes offered by the system. The processes must be understood by human process users to enable online modification of the processes and commitment of business steps.

We must be aware that architecture in general means integration in the large. A change of an architecture type implies changes of the development processes. Let us remember the following analogy: Being able to lay bricks (objects or small programs) does not directly imply the ability to build good houses (large artifacts). The ability to build good houses need not imply the ability to develop good towns (large software-intensive systems).

Large technical artifacts, large software systems inclusive, cannot be reasonably developed as logical monoliths (compare power plants). Such systems must be built as compositions of quite large components and complex autonomous units. The compositions can be again composed into larger compositions, if appropriate. In software it implies that we must start with entities providing basic capabilities. In software systems the entities are usually called applications. We must have also software entities enabling communication, collaboration and orchestration of collaborating applications as well as the users and maybe real-world entities. The main, if not one and only, feasible way to implement such software systems is service orientation. Service orientation assumes that the system has a specific structure (architecture), that it has service-oriented architecture (SOA). Service-oriented (SO) paradigm and SOA are the proper solution for the majority (if not almost all) of large software (intensive) systems (Král & ·Žemlička, 2002).

Complete Chapter List

Search this Book:
Table of Contents
Pierre F. Tiako
Chapter 1
Alf Inge Wang, Carl-Fredrik Sørensen
This chapter presents a framework for differentiated process support in large software projects. Process support can be differentiated in different... Sample PDF
Differentiated Process Support for Large Software Projects
Chapter 2
Holger Giese, Stefan Henkler, Martin Hirsch, Vladimir Rubin, Matthias Tichy
Software has become the driving force in the evolution of many systems, such as embedded systems (especially automotive applications)... Sample PDF
Modeling Techniques for Software-Intensive Systems
Chapter 3
Jaroslav Král, Michal Žemlicka
Software intensive systems are systems strongly depending on supporting software. The software is typically large, complex, and it as a rule... Sample PDF
Service Orientation and Software-Intensive Systems
Chapter 4
Alf Inge Wang, Carl-Fredrik Sørensen, Hien Nam Le, Heri Ramampiaro, Mads Nygård, Reidar Conradi
This chapter describes a requirement analysis framework that may be used as a tool for developing client-server systems for mobile workers. The... Sample PDF
From Scenarios to Requirements in Mobile Client-Server Systems
Chapter 5
Gan Deng, Douglas C. Schmidt, Aniruddha Gokhale, Jeff Gray, Yuehua Lin, Gunther Lenz
This chapter describes our approach to model-driven engineering (MDE)-based product line architectures (PLAs) and presents a solution to address the... Sample PDF
Evolution in Model-Driven Software Product-Line Architectures
Chapter 6
Ståle Walderhaug, Erlend Stav, Ulrik Johansen, Gøran K. Olsen
This chapter introduces a tracability solution for use in a model-driven software development approach. It argues that a trace model based on a... Sample PDF
Traceability in Model-Driven Software Development
Chapter 7
Gerhard Chroust, Erwin Schoitsch
When designing a complex software-intensive system it is unavoidable to make some a-priori basic assumptions about its architecture. We introduce... Sample PDF
Choosing Basic Architectural Alternatives
Chapter 8
Rafael Capilla, Margarita Martínez, Francisco Nava, Cristina Muñoz
Virtual reality systems are a kind of complex software systems that need a lot of effort and resources during its development phase. Because rigid... Sample PDF
Architecting Virtual Reality Systems
Chapter 9
Kendra M.L. Cooper, Lirong Dai, Renee Steiner, Rym Zalila Mili
This chapter presents a survey of software architecture approaches. It is intended for a broad audience of students, practitioners, and researchers... Sample PDF
A Survey of Software Architecture Approaches
Chapter 10
Daniel G. Waddington, Nilabja Roy, Douglas C. Schmidt
As software-intensive systems become larger, more parallel, and more unpredictable the ability to analyze their behavior is increasingly important.... Sample PDF
Dynamic Analysis and Profiling of Multithreaded Systems
Chapter 11
James H. Hill, Douglas C. Schmidt, John M. Slaby
This chapter introduces the next generation of system execution modeling tools designed around modeldriven engineering (MDE) coupled with... Sample PDF
Evaluating Quality of Service for Enterprise Distributed Systems
Chapter 12
Jules White, Douglas C. Schmidt, Andrey Nechypurenko, Egon Wuchner
Model-driven development is one approach to combating the complexity of designing software intensive systems. A model-driven approach allows... Sample PDF
Reducing the Complexity of Modeling Large Software Systems
Chapter 13
Enis Afgan, Purushotham Bangalore, Jeff Gray
Grid computing environments are dynamic and heterogeneous in nature. In order to realize applicationspecific Quality of Service agreements within a... Sample PDF
A Domain-Specific Language for Describing Grid Applications
Chapter 14
Jeff Elpern, Sergiu Dascalu
Traditional software engineering methodologies have mostly evolved from the environment of proprietary, large-scale software systems. Here, software... Sample PDF
A Framework for Understanding the Open Source Revolution
Chapter 15
Syed Ahsan, Abad Shah
With the proliferation of Web, a tremendous amount of data is available to researchers and scientists in computational sciences, business... Sample PDF
Quality Metrics for Evaluating Data Provenance
Chapter 16
Krishnakumar Balasubramanian, Douglas C. Schmidt, Zoltán Molnár, Ákos Lédeczi
With the emergence of commercial-off-the-shelf (COTS) component middleware technologies software system integrators are increasing faced with the... Sample PDF
System Integration Using Model-Driven Engineering
About the Contributors