The SOA's Layers

In this paper we introduce a reference model for the layering of service-oriented architecture (SOA). Opinions on how this architecture appears are often disjunctive or contradictory within the SOA community a standardized layering has not as yet been established. Therefore, it is our objective to provide a definition and better understanding of the layers encountered within an SOA as well as the relationships between them, thus aiming at the provisioning of common understanding and nomenclature for SOA. Basically SOA aims at the provisioning of abstract software functionality through services that can be flexibly composed to implement business processes. Through the deployment of reusable services a processoriented alignment of business and IT is achieved, allowing fast adaptations on changes in business processes [EW+06]. Furthermore, SOA enables the integration of existing applications by exposing their functionality as services improving the value of existing software assets and avoiding redundancy in IT infrastructure. To yield these benefits and to support the service-oriented paradigm, SOA adds further layers to the conventional architecture responsible for application integration and service orchestration hence making the underlying systems transparent for business analysts. The bottom layer of the reference model comprises the existing systems, called operational systems [Ar04] or legacy systems. It holds detached systems that are traditionally developed and therefore usually per se not service-oriented. From the SOA perspective, it does not matter if these legacy systems are internally monolithic or of multi-tier architectures. It is the task of an SOA to leverage these systems by exposing their functionality as reusable services that build the foundation for the alignment of IT and business processes. Up to the point of time when SOA principles are directly applied in application development, most of the scenarios will have the migration character described before. At the core services border the wrapping of existing functionality to services is achieved with a common interface description and communication protocol that can be used by potential consumers. The act of exposing this functionality as services to gain reusability is done by software developers and involves changes in the applications’ source code or proxy-style wrapping. Such services are described by providing service descriptions held in a service registry that gives information about the syntax (e.g. through Web Service Description Language WSDL [KL04]) and semantics (e.g. using Ontology Web Language Services OWL-S) [MP+04]) of the service interfaces. Business Process Business Process Business Process Busines Process Mapping of the IT-supported Parts Business Process Business Process Service-Oriented Architecture Service-Oriented Architecture Process Layer