The successful development of complex systems cannot be achieved without a thorough investigation of the requirements that the system should meet and the available tools, technologies and implementation models that can be used to support those requirements.
It is also important to have a good understanding of the advantages that particular archi-tectural styles provide and for this reason we make a quick overview of the fundamental architectural styles that we use as foundations. During the design phase, quality at-tributes mentioned further in this section are used to motivate and support the decision to use a particular architectural style.
As defined by Garlan and Shaw [102], a software architecture represents a collection of
computational components that interact through connectors. A more recent definition states that ’The software architecture of a program or computing system is the struc-ture or strucstruc-tures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them’ [46]. In software engi-neering, an architectural style ’defines a family of such systems in terms of a pattern of structural organization.’ [102]
The overall structure of a software system and its components has to be driven by effi-ciency characteristics that ensure that initial requirements are fulfilled. One of the first assessments on quality attributes and their role for software systems was done by McCall et al [132]. Of particular importance for research related software systems are implemen-tation attributes and runtime attributes because they consider aspects closely related to the development and execution of such systems. Business attributes such as implemen-tation cost and delivery time related attributes are of less concern and therefore they will not be considered in our analysis.
Some of the most important implementation attributes are [154]:
• Interoperability - the ability of a software component to be universally accessible to other components for the purpose of exchanging data. As we shall see later in this chapter, this ability is particularly important for establishing an infrastructure for symbolic computations;
• Maintainability and extensibility - the ease of altering the existing software imple-mentation in order to correct or to extend the system’s functionality;
• Reusability - the effort to adapt existing components so they can be re-used in more than one context;
• Testability - the ability to test and verify the correctness of the implementation;
• Portability - the ability of the implemented software to be deployed and used in conjuction with different hardware profiles and software infrastructures;
• Scalability - the ability of the system to handle increased number of requests.
Usually scalability is attained by replicating subcomponents that interoperate for solving the incoming requests;
• Flexibility - measures the effort required to adapt the system for use case scenarios for which the system was not originally designed;
The most relevant run-time attributes of the software systems are:
• Efficiency - the volume of resources required by a software system to fulfil its function
• Availability - the property of the system to be up and running for long periods of time
• Security - the system property to enforce the required security requirements such as proper authentication and authorized access, the ability to handle malicious attacks, etc . . .
• Performance - the ability of the system to respond effectively to high loads
• Usability - the degree to which the systems respond to users’ expectations and to their level of expertise
• Reliability - the level of confidence based on the frequency of execution problems that arise during run-time
• Maintainability - the level of difficulty to which a running system may be modified, reconfigured or extended
Most large software packages combine pure architectural styles to achieve the desired functional characteristics. Different levels of abstraction of a software system may reveal different architectural styles. Most of modern architectural styles evolved from several fundamental architectural styles: pipes and filters, data abstraction and object oriented
organization, event-based implicit invocation, layered systems, data repositories, main program - subroutine styles to name only the most important ones. A more extended list of architectural styles and a more thorough description may be found in [102, 163]. In the following we present a short overview of the most important ones that inspired our design.
The pipe and filter is a software architectural style well known especially for its use in Unix systems. Computational components of the architecture, called filters, transform data received as input and feed the resulting data to the output. Internal state of filter components is not shared with other components and therefore the result of their pro-cessing is only based on the input values they receive and their internal implementation.
To achieve interoperability filter components share the same model of data representa-tion. In addition, reusability of components, maintainability at both design and run-time and the possibility to link components in parallel are also favoured by this design.
Sharing a common data representation may induce poor efficiency if significant pro-cessing has to be applied to data to transform it in order to accommodate the one used internally by the component. Because filters are tied to a common model for represent-ing data, parsrepresent-ing from the common format to the one required internally and from the internal format to the common one may reduce the efficiency of the system.
The precursors of the Data abstraction and Object Oriented Organization architectural styles were Main-Program-Subroutine and Remote Procedure Call (RPC). The latter is an implementation variant of the former, tailored for network environments. The main idea that drives these styles is to partition the implementation based on the functionality they provide. As a result of this separation, maintainability and reusability of software components is improved. The RPC model was developed to allow parts of the software system to be executed on separate processors or machines.
Data Abstraction and Object Oriented Organization have several advantages in addition to the ones inherited from their predecessors. The components of the system are objects with a well described interface that encapsulate internal details, provide internal data
integrity and preserve invariants. The interface may be advertised separately from the implementation, allowing decoupling of the two in favour of maintainability and exten-sibility of the system. Interoperability is also easier to achieve because the client has a clear representation of object’s interface. The main drawback of this approach is that the potential client must know in advance the identity of the objects it wants to access. Most of the systems implementing the Data Abstraction architectural style offer discovery mechanism that allow clients to find the object they require.
The Event-Based with Implicit Invocation architectural style defines two types of compo-nents: processing components and message managers. During execution, the processing components produce messages that notify interested third party components that a cer-tain state was reached in the system. Interested processing components may register to be notified when events of a certain type of topic are reported. The role of the mes-sage managers is to receive produced mesmes-sages and to notify interested subscribers that a certain event has occurred. These architectures offer the advantage of scalability and flexibility since new components versions and even new components can be easily added to the system.
The trade-off of the model described above is the lack of control over the order in which subroutines of the system are executed in the case of complicated execution scenarios.
More than one subscriber may exist for the same event and the order in which they are notified is arbitrary. Therefore it is not possible to foresee the order in which processing steps are executed system wide after the occurrence of an event. Another important topic to consider is related to data exchange capabilities. The messages have the sole purpose of notifying that a certain event has occurred. Usually, in these circumstances additional data that describe the state of the system may be required, too large to be sent together with the notification messages. There are also situations when components waiting for the same events require different sets of data or representations of it. The solution is to add mechanisms through which components gather on their own the data they require. We also have to note that interested components must be alive and listening at the moment when the event occurs, otherwise they are not able to respond effectively
to the notified event.
Layered Systems represent an architectural style in which components are organised in layers. Each layer groups components that address problems of a certain type so that a certain layer offers functionality to the layer of components situated one level higher in the architecture and use functionality offered by the layer of components below. This type of organization favours separation of concerns for each layer of components, exten-sibility and maintainability because enhancements may be done at a certain level without affecting components at other levels and reusability of components. This model allows better communication between components and offers support for multiple message ex-changes when a stronger coupling is needed between components.
The architectural styles described above represent only a small part of the ones that exist today. They are the foundation of modern architectural styles and offer important guidelines for further implementations. Architectural styles that are able to respond better to specialized architectures and functional requirements were created. A special category of such architectural styles is the one tailored for distributed computing.