SOA
Introduction
There is no single definition of a SOA but most definitions agree on the following aspects: It is some kind of distributed information system architecture which cannot be reduced to its technical aspects because of a high degree of interrelation to the business and its processes [BIE05][ERL05][LEG07].
Information system architecture is defined by the IEEE Standard Glossary of Software Engineering Terminology as ‘the organizational structure of a system’ [IEE90].
Combining these two definitions obviously leads to the conclusion that a SOA defines the organizational structure of an information system with particular focus on the business aspects.
SOA in the context of information system architecture
Early information systems showed a monolithic design without any consideration of the whole architectural concept. These systems were often designed as a solution to one specific problem which led to high complexity and a high degree of coupling within these silo applications.
With the introduction of database systems and their acceptance because of advantages during the backup and transaction process a new architecture style evolved with the 2-tier or client/server architecture. This architecture mainly formed monoliths with an application layer tightly coupled to a database layer as shown in [1].
When graphical user interfaces evolved, the need for a 3rd layer was given. This enabled the development of the 3-tier architecture consisting of a data layer, a logical layer, and a presentation layer, all tightly coupled. These layers were mainly representing the database, the application, and the graphical user interface, respectively.
With the emergence of the Internet the content of the presentation layer changed from an application’s front-end to the web browser. Therefore, the connection between the logical layer and the presentation layer shifted to a more loose degree of coupling. Depending on the level of granularity a layered architecture with five layers is also possible. These would be a presentation layer managing the representation of information to the user interface followed by a process layer responsible for managing the process flow (i.e. a workflow system). One layer deeper the application layer is situated. The lowest layer is the database layer which represents the physical storage of data which is in practice mostly implemented using a relational database [MAS07].
The next step of evolution was the component based software architecture which added a vertical layer to the existing horizontal layers. One of the main ideas of component based architectures is to achieve a high reusability of components [ERL05]. According to [MAS07], reusability in the context of component based software systems is of limited importance in practice whereas the ability to better structure software is the real advantage.
Components are encapsulating data and logic and can be combined at runtime to an application by using their interfaces. Each component has three parts which are an interface describing the functionality, its exchangeable implementation, and the deployment.
Although a SOA is the evolution of earlier architecture concepts fundamental differences exist. Architectures used to be universally applicable, paying little attention to the organization and structure of the business process and the overall context. In a SOA all processes have to follow the service-oriented paradigm and the organization has to become a SOE in order to be able to leverage the full benefit [CHE05]. It consists of loosely coupled services and operates on a higher level of abstraction paying less attention to detailed technical processes but focusing on providing a service to the business [NAT03]. [1] shows the evolution of the different layers from a monolithic design to a SOA.
Parts of a SOA
Important parts of a SOA are:
- the involved entities
Technical SOA benefits
Out of the SOA concepts described in this chapter many technical benefits of a SOA can be derived. Therefore the benefits mentioned in [AHL07] are listed and justified very briefly.
- StandardizationA SOA is based on open standards. Using these standards should assure consistency and compatibility far across a company’s borders [KRA07]. It can also enable the consolidation of the application portfolios.
- InteroperabilityA SOA can mitigate the diffusion of many different proprietary standards leading to a higher degree of interoperability and a lower degree of vendor dependence [AHL07].
- Reduced complexity
- Fault tolerance
- FlexibilityLoose coupling and stateless communication between services based on interfaces without direct point-to-point connections enhance the overall flexibility [PAO08].
- OrchestrationOrchestration makes the flexible definition and redefinition of business processes without technical skills possible [KRA07].
- Application abstractionAll kinds of applications can be abstracted and easier integrated by representing them as a service [PAO08].
- Granularity
- Service compositionA service can be a part of other services and can be composed out of other services [KRA07].
- ReusabilityThe ease of orchestration and the right granularity enhance reusability by reuse of services [PAO08].
- Infrastructure virtualizationIn a SOA application and infrastructure logic can be kept separately by using services. While functional developers can concentrate on the functionality of their solutions, infrastructure can be leveraged by using basic services. Virtualization techniques in general allow merging and sharing of IT resources [HUZ03]. This can lead to a reduced hardware demand with a higher utilization rate which is desirable from an economic point of view.
These benefits represent a list of possible SOA benefits. It should be noted that the number of realized benefits as well as the degree in which these benefits are realized varies because of the benefits’ dependence on the respective SOA adoption. The process of adopting a SOA is known to be a critical task which needs to be well prepared in advance in order to reveal as much benefit as possible [HOP06]. The most reasonable way to SOA adoption is a gradual and consecutive process [ARS08]. Because Maturity Models can support gradual, consecutive processes and can be applied to different domains (e.g. SOA) they are further examined in the following chapter.
Letzte Änderung: 11.05.2009, 16:33 | 1086 Worte