Service Oriented Architecture as an Integration Approach
A number of integration approaches and concepts already exist. They can be differentiated by integration level (for example data, functions or process integration) and integration architecture (for example point-to-point, hub & spoke, SOA) (Aier & Schönherr, 2006). This paper presents an approach to integrating enterprise systems by way of building up service oriented architectures. This integration approach is of special interest and will be described in more detail.
The concept of service orientation is currently being intensively discussed. It can be differentiated from component orientation by its composition and index service (repository). Additionally, SOA is suitable for a process oriented, distributed integration (Aier & Schönherr, 2006). However, the addressed goals of component orientation and SOA are similar: different enterprise systems are connected through one interface, and a cross-system data transfer and the re-usage of objects or components is enabled. Thereby a service represents a well defined function which is generated in reaction to an electronic request (Burbeck, 2000). The SOA approach offers a relatively easy way to connect, add and exchange single services, which highly simplifies the integration of similar systems (e.g. enterprise take-over). Moreover, SOA offers a high degree of interoperability and modularity, which increases the adaptability of enterprise systems (Andresen et. al., 2008), (Lämmer et.al. 2008).
The SOA approach is based on the concept of service. The sender wants to use a service and in doing so he wants to achieve a specific result. Thereby the sender is not interested in how the request is processed or which further requests are necessary. This is the idea of SOA, where services are defined in a specific language and referenced in a service index. Service request and data exchange occur via use of pre-defined protocols (Erl, 2008), (Papazoglou, 2007).
This service orientation can be used on different levels of architecture. The grid architecture is a common example of infrastructure level (Bermann et. al., 2003), (Bry et. al., 2004). On the application level an implementation usually takes place in terms of web services.
The use of web services offers the possibility of re-using raw source code, which is merely transferred to another environment (Sneed, 2000). The benefit of this transfer is the re-usage of perfected (old) algorithms. The main disadvantage is the necessity of revising the raw source code in order to find possible dependencies (Sneed, 2000). This is also true for enterprise systems. It isn’t efficient to re-use the entire old system, but rather only significant parts of it. To accomplish this it is necessary to deconstruct the old enterprise system and to locate the source code parts which can effectively be re-used. Our approach uses self-diagnosis for finding these source code locations. This analysis will be considered in the third integration step.