Views on Service Oriented Architectures in the Context ... - IEEE Xplore

Views on Service Oriented Architectures in the Context of Smart Grids Matthias Postina∗ , Sebastian Rohjans∗ , Ulrike Steffens∗ and Mathias Uslar∗ ∗ OFFIS

Institute for Information Technology, 26121 Oldenburg, Germany Email: [first name].[last name]@offis.de

Abstract—The transfer from the current power grid to the power grid of the future implicates major changes for all stakeholders participating in the smart grid. Hence, utilities have to face several novel problems in terms of service provision. In this contribution, we examine two complementary views in the overall context of smart grids. We argue for a combination of those two views, based on ontology mappings. We explain a generic top-down and EA-related view, focused on intra-enterprise communication as well as a very domain-specific, technical bottomup view, focused on inter-enterprise communication. The topdown view supports architects in reorganizing and developing enterprise SOA, whereas the bottom-up view takes into account the CIM (IEC 61970/61968), OPC UA (IEC 62541) and semantic web services to cope with technical interoperability in an utility domain-specific SOA. The combination of those two views results in the capability for smart grid stakeholders to realize seamless information exchange among field and IT.

I. I NTRODUCTION The National Institute of Standards and Technology (NIST) in the US defines the transformation of the current power grid to the power grid of the future in form of a process, which is called smart grid. Monitoring, protection and automatic optimization of the operations of its interconnected elements are key issues of the future grid. Those elements include central and distributed generation through the highvoltage network and distribution system, industrial users and building automation systems, energy storage installations and to end-use consumers and their thermostats, electric vehicles, appliances and other household devices [1]. The different domains (customers, markets, service providers, operations, bulk generation, transmission and distribution) can expect benefit in the fields of finances, safety and cyber security, energy efficiency, and environment/conservation [1]. A lot of challenges will result from this transition process. One of those challenges is concerned with communication (data exchange). Both, the communication among different stakeholders as well as the communication within the context of a single stakeholder has to be taken into account. Related to the first case, several studies and reports [2], [1] and [3] argue for the use of standards from the International Electrotechnical Commission (IEC) and similar organizations. In this contribution, we follow this advice and use the IEC 61970/61968 standards series, which were unanimously exposed as core standards, as syntactic and semantic basis

for a service oriented architecture (SOA) coping with layercomprehensive data exchange between different stakeholders. The mentioned standard series’ define the Common Information Model (CIM) which is a widespread domain-specific data model and could be seen as a domain ontology for the utility domain [4]. Also the IEC 62541 (OPC Unified Architecture (UA)) and the concept of semantic web services (SWS) are part of the developed SOA [5]. Regarding the inside perspective of utilities, the smart grid transformation process stipulates architectural changes on the entire enterprise architecture (EA), affecting all layers from business down to IT infrastructure [1]. We follow the IEC roadmap [3] and consider services to be the atomic building blocks of the emerging smart grid architecture and show based on The Open Group Architecture Framework (TOGAF) [6] - how EA can contribute to architectural change management and efficient service management inside an organization. The remainder of our contribution is structured as follows. Section 2 introduces EA as intra-utility viewpoint in the context of smart grid and shows how TOGAF concepts can contribute to architectural change management. In section 3, we consider a more technical view on smart grid and focus on inter-enterprise communication based on a standard-compliant architecture. We elaborate on common concepts in section 4 and propose ontology alignment to establish a joint view. Section 5 regards related work before we conclude the paper and outline future work. II. I NTRA -E NTERPRISE V IEW According to the Enterprise Architecture Research Forum, EA can be characterized as ’[...] the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change’1 . A sociotechnical organization could be a governmental agency, an enterprise, a part of an enterprise, an enterprise with customers and suppliers or an entire industry sector, for example. So, EA is able to describe the current state of a sociotechnical organization and also to plan envisioned states. EA as a discipline has developed tools, methodologies, and frameworks 1 http://hufee.meraka.org.za/Hufeesite/collaborations/earf/definition-for-eaas-defined-by-the-group

978-1-4244-6511-8/10/$26.00 ©2010 IEEE

25

Fig. 1.

Enterprise Architecture Overview

like TOGAF to manage such changes and offers models and a common vocabulary to formalize the essential elements and their relationships to each other and to the environment. NIST [1] predicts significant changes to the energy sector, provides a conceptual model for discussing the electric smart grid and describes application areas and early use cases for arising challenges. Utilities as important stakeholders of the smart grid are confronted with drastic changes in business and IT, so change management on enterprise level or even beyond will be essential for succeeding in enterprise adoption and interaction with a changing environment. We will show that EA can play an important role in managing changes arising from the smart grid initiative by providing a formal description of the current state, providing an architecture development method for the envisioned state and planning the transformation process. We consider services as atomic building blocks of the new architecture and regard them in context of EA. It is important to notice, that we consider EA from the internal perspective of an utility to reorganize changes to the enterprise architecture arising from new challenges triggered by smart grid initiatives. Even though EA techniques may also be applicable to describe the entire smart grid including all stakeholders of the entire sector and further research seems to be of high relevance, we focus on the internal view on EA in this chapter. A. Enterprise Architecture (EA) Each sociotechnical organization of certain size and complexity - like an enterprise - needs techniques for the design and realization of the organizational structure, business processes, information systems, and infrastructure. EA ’is the coherent whole of principles, methods and models [...]’ [7] to do so. EA considers various architectures of a sociotechnical organization and provides adequate views to different stakeholders. The center of figure 1 shows typical architectures of a sociotechnical organization as well as other EA aspects like project management, organizational aspects, security etc. Each entity of figure 1 stands for an abstraction of a sphere of interest of different stakeholders. A business analyst for ex-

ample, is interested in the optimization of business processes. He has specific concerns like decomposition of workflows, runtime of tasks or costs associated to business processes. A business analyst is used to specific notations like Event-driven Process Chains (EPC) or Business Process Modelling Notation (BPMN) diagrams and performs a specific set of analysis on a stakeholder-specific information model. Obviously, the business analyst is interested in the business architecture of an organization. A top manager may also be interested in the business architecture, but has different concerns and is used to certain reports and visualizations. To provide a coherent picture of the business architecture, helping stakeholders to understand complexity and manage change, EA has to model the essential business elements, their relationships to each other and to the environment - an abstraction of the business sphere of interest. Besides business architecture, EA provides abstractions to other spheres of interest like technology architecture and service architecture and considers organizational structures and projects of a sociotechnical organization and interconnects these partial models to a coherent content model. Such model weaving fosters the real value of EA, since it leads to a consistent and comprehensive representation of a sociotechnical organization and allows complex analysis over all spheres of interest. The entire model is typically stored inside a centralized EA repository to enable access to all relevant stakeholders. The model stored inside a repository is organization-specific and depends on stakeholder concerns. However, patterns for typical concerns exist (see [8], [9]) as well as generic content models appropriate for a number of enterprises from different sectors. Such content model templates comprehend EA best practices and ease the development of a tailored and organization-specific model. A generic content model for EA is provided by TOGAF as Content Metamodel (CMM) for instance. Another important aspect of using content models and standardized EA frameworks lies in the common language of enterprise architects. A common understanding of things, a clear taxonomy describing essential entities and a model showing the relationships of entities to each other enables a semantic description of the EA discipline and moreover, allows consideration of EA in context of other disciplines. B. Architecture Development Enterprise architecture development is the planned and intended process of evolution of the enterprise architecture. Typically triggered by events like the decision for new product placement, a shift of the business strategy, mergers or acquisitions, the current state of the enterprise architecture is critically checked on being sufficient to cope with the new requirements. If the new situation enforces changes to the enterprise architecture, the process of architecture development takes place. A well known architecture development method in the field of EA is the Architecture Development Method (ADM) of TOGAF [6].

26

The ADM is an iterative method for architecture development separated in 9 phases. The preliminary phase is setting the scope of the architecture development and the architecture vision phase outlines the envisioned state of architecture. The following phases (B to D) consider the enterprise architecture on different layers corresponding to the spheres of interests described in section II-A. Performed on different architecture layers, the activities inside these phases follow the same pattern: • • •

Determine the current architecture. Outline the envisioned architecture. Perform gap analysis on these architectures and identify measures for a roadmap ([10] consider the task of gap analysis in detail).

Phases E and F determine the project roadmap as a plan for the implementation of changes on the current enterprise architecture. The actual implementation takes place in phase G and phase H assures that the initial requirements are met by the outcome of the ADM cycle. C. Services in Enterprise Architecture SOA is recommended to be the leading paradigm for the smart grid architecture [3] - for inter-stakeholder communication as well as for intra-stakeholder communication. Considering the architecture of utilities, service orientation has already begun to find its way into the enterprises as an efficient way to integrate legacy systems as reusable building blocks into a flexible enterprise architecture [11]. Process engines have been installed on the top of this legacy layer and build up a flexible framework for service orchestration and process development. Content (services and processes) is growing fast in such environments, so evolution and maintenance of SOAs will be the challenge of the near future. EA can contribute to solve this challenge in two ways: •

•

TOGAF considers services as building blocks provided by applications and sets them into enterprise context. Such overarching classification of services allows for a better context awareness of services than simple Universal Description, Discovery and Integration (UDDI) registries could offer. Context analysis like service graphs showing hierarchies of service calls can provide end-toend information, from business goals down to supporting servers for instance. TOGAF provides a detailed architecture development method to manage architectural changes (see Section II-B) on enterprise level and smart grid will affect entire utilities. Even though TOGAF in its current version 9, was not intended to support SOA environments, TOGAF - being a generic framework - is able to support service orientation and The Open Group is also working on enhancements to improve SOA support (SOA Ontology, SOA Governance Framework)2 .

2 The SOA Ontology and the SOA Governance Framework are under development by the SOA Workgroup of The Open Group Architecture Forum

III. I NTER -E NTERPRISE V IEW In this section we want to provide a technical and very specific view on the future smart grid. Smart equipment, communication systems, data management, cyber security, information and data privacy and new software applications are just some parts where major changes are expected [1]. To cope with these challenges, the use of standards is a good option. However, it is not possible just to use existing standards. Established standards have to be extended, combined and specializied. The following sub-sections will focus on different IEC standards like IEC 61970/61968 and IEC 62541 and on standards for SWS as well as on a SOA combining them [5]. A. Common Information Model (CIM) The CIM is standardized in the IEC standard series 61970 and 61968 and it is also provided and developed by the CIM User Group, using Unified Modeling Language (UML), the lingua franca for modelling in software engineering. The information model consists of about 53 packages, 800 classes, 9.000 attributes and 780 associations, which provide an opportunity to model different utility-domain-specific problems and cases [12]. Both, abstract objects and documents like market operations, and physical objects like devices can be modeled. CIM is a platform-independent data model which is also published as an Web Ontology Language (OWL) ontology, formalizing almost the whole syntax and semantics for the electric utility domain. The CIM is used for the following three use cases in the overall context of standardizing a set of guidelines to support the integration of applications in the control center (CC) environment, independent of suppliers and to support the information exchange with systems external to the control center environment: • Building and exchanging custom messages between systems in the utility based on CIM semantics and syntax, e.g. curve schedules based on eXtensible Markup Language (XML) serializations. • Exchanging instance data of the distribution and transmission grid (grid topology), whereas profiles are used to define which objects from the CIM should be used to model distribution grids or transmission grids and how to serialize them using the Resource Description Framework (RDF) standard from the World Wide Web Consortium (W3C). • Standardizing interfaces between systems and interface descriptions. Another large part of the standard family defines the Component Interface Specification (CIS). In these parts, interfaces which could be implemented by components or applications to exchange data in a standard way are specified. Apart from the framework and the common services, the following data access methods are taken into account: Generic Data Access (GDA), High Speed Data Access (HSDA), Generic Eventing and Subscription (GES) and Time Series Data Access (TSDA). The specifications for these interfaces are based on several OPC standards (OPC DA (Data Access), OPC AE (Alarms

27

and Events) and OPC HDA (Historical Data Access)) which are predecessors of the new UA which is described in the next sub-section. B. OPC Unified Architecture (UA) The OPC UA is a server-client-architecture which is developed by the OPC foundation and standardized in the IEC 62541. The UA is the successor of the well known and widespread OPC specifications DA, HDA and AE for automation systems [13]. They are used for the exchange of real-time plant data among control devices. The two major improvements of the UA are platform independence and capability to exchange data beyond local networks. The UA should be a platform for interoperability between the existing OPC specifications using web services or a binary format. In the context of the OPC standards, the UA is the top level standard used to provide platform independent and service-based communication. The UA provides a generic information model which is a basis for domain specific information models. In this contribution, we take the CIM as an utility domain specific model to be set on top of the generic UA model [14] and use the UA for integrated automation purposes. C. Semantic Web Services (SWS) What is known as SWS is an improvement of the common web services which are extended by semantic content. Amongst others, SWS are specified by the W3C and could be seen as a new approach in the course of the Semantic Web. Their intention is to exploit the full potential of the Semantic Web [15]. To facilitate automation in cases of service discovery and execution it is important to have descriptions - written in formal machine-readable languages - as specific as possible of the provided and desired services. The discovery could fail even if there are fitting web services within the repository. For this purpose the client/provider should describe the desired/provided functionalities in a much more specific way in terms of semantics. The descriptions of the services reside on a functional and behavioral layer, concerning interfaces and non-functional requirements [16]. Standards like Web Service Modeling Language (WSML) and Web Service Modeling Ontology (WSMO) can be used to solve this annotation and meta data problem. The clients describe the desired functionality and the server - deploying the CIM - can offer the matching web service. However, their weak maturity has to be mentioned and considered during the application of the architecture. D. Merged Technical View Figure 2 shows our approach to join the three aforementioned components. The CIM is the common semantic basis for the UA and the SWS. Furthermore, an extended technology mapping combines the UA and the SWS [5]. New requirements for Information and Communications Technology (ICT) in the context of smart grid arise and can be faced in an appropriate way by combining the platformindependent components UA and CIM. Among others, legal

Fig. 2.

Combined architecture of SWS and OPC UA.

unbundling and distributed generation are the reasons for those new requirements which include novel services and new processes to combine old and new systems and components. The new requirements can mostly be covered by SOA using web services. However, it still lacks some essential features as UA and CIM both cover syntax and semantics but the semantics is usually omitted when it comes to the point of finding and discovering appropriate services form different systems or parties. Based on that fact, annotating meta data like costs, location information and availability would provide the possibility to choose the best service based on the current context. This merged technical view covers both the important issues of being compliant to standards as well as finding the right services in a SOA. IV. J OINT V IEW Smart grid leads to major changes for all stakeholders and key players like utilities are mainly affected by these changes. They have to take intra-enterprise (all interfaces that are used for data exchange within the enterprises) and inter-enterprise (all interfaces that are used for data exchange with other enterprises) communication into account and have to adapt existing architectures in order to participate in smart grids. As shown in section 2, EA allows for the documentation of current architectures and provides methods to plan and reach envisioned architectures. Services are the essential building blocks of emerging architectures in context of smart grids but only a limited number of services lies in intra-enterprise control and thus can be managed by EA. A standard-conform description of services is of special importance when it comes to inter-enterprise (inter-stakeholder) communication. In terms of service discovery inside an organization, EA provides

28

Fig. 3.

Ontology alignment between EA and IEC-Standards

adequate classification concepts (architectural layers, business context of usage etc.) and can significantly be improved by standard compliant annotation of meta data (CIM conform). For inter-enterprise service discovery a standardized data architecture (service description) becomes indispensable. Figure 3 shows the mapping of concepts between the TOGAF CMM and the extended CIM ontology. The EA stack (left) comprises the intra-enterprise view and important entities of the TOGAF CMM are highlighted. Besides covering the inter-enterprise view, the right stack is more technical than the EA architecture layers - as indicated by the offset between them. The information layer includes SWS which allows smart grid stakeholders to communicate among each other through the internet. In this special case the connection to the automation layer is shown. The UA concept - on the automation layer - is extended by a technology mapping for SWS. Thus, field devices, which are connected via UA can be monitored and invoked by UA services via the internet. Both, SWS and the UA model are based on CIM syntax and semantics, hence a seamless ontology based commuication is facilitated. To realize an ontology mapping between the CIM based ontology and the TOGAF CMM based ontology, the CIM based ontology has to be extended by a set of services. Both, energy specific SWS and UA services have to be considered. Being the bottom layer of EA, the technology architecture consists of technical artifacts like server or platform technology for instance. Thus, the technology architecture comprises ’[...] assets that are used to implement and realize information system solutions.’ [6]. We introduced the service architecture - in TOGAF defined as information systems architecture composed of data and application architecture to describe the extract of EA entities relevant in the SOA context. We group building blocks used by workflow engines like applications and simple wrapped application services or orchestrated higher order services as service architecture. The business architecture describing business entities and the coherent model comprising all three architectures allows for

end-to-end consideration of the entire enterprise architecture. For the actual concept mapping we designed an ontology based on the TOGAF CMM and aligned this ontology with the CIM ontology (indicated by arrows in Figure 3). There are several OWL-classes within the CIM ontology that describe different field devices. For example, a generating unit which is a part of a field device, can be aligned to a physical technology component in the TOGAF CMM ontology. Furthermore, the new energy specific SWS within the CIM based ontology can be aligned to the information system services as well as the UA services can be aligned to platform services. Joining the aforementioned views via ontology alignment leads to various benefits for smart grid stakeholders. For an utility - for example - as part of a smart grid, the approach offers a methodology to control upcoming massive changes on the enterprise architecture (TOGAF ADM). Further, EA offers a classification system (e.g. CMM ontology) to classify services as central building blocks of the service-oriented enterprise architecture and thus, puts a service into an enterprise context. The CIM world refines this enterprise service classification and adds energy specific attributes as meta data to services on a more technical level. Such comprehensive service classification considering both contexts, the enterprise context as well as the technical domain specific context enables semantic service discovery inside an organization. The emerging smart grid will consist of various stakeholders offering large amounts of services, so utilities will increasingly have to consume external services offered by other stakeholders of the smart grid. The aforementioned intra-enterprise service classification system is not limited to internal service classification. Beyond, the same concept should be used to describe service queries for external services. A standardized classification of all services inside the smart grid fosters external communication and enables the smard grid vision of public service marketplaces. The main innovation of the contribution is to integrate the two vertical perspectives, bottom-up and top-down, from the IT to the field with the third perspective dealing with horizontal communication on the different layers of the two vertical views to achieve a holistic system. Thus, it is possible to cope with use cases regarding typical Distributed Management System (DMS) functionalities like frequency stabilization and load control each consisting of many single services needing both communication within and among enterprises. V. R ELATED W ORK In terms of related work concerning the technical view, the use of SWS and the use of the UA have to be considered. The CIM is transitively included. Various SWS technologies have been developed in the last year. They can be classified as topdown and bottom-up approaches. The top-down approaches use an ontology language to model services in a technologyindependent way, during the first step. After this, an appropriate description language has to be identified (e.g. WSMO and Web Ontology Language for Services (OWL-S)). Bottomup approaches base on existing technologies, which are en-

29

riched with semantic information (e.g. Web Service Semantics (WSDL-S), Semantic Annotations for WSDL (SAWSDL) and DARPA Agent Markup Language/Ontology Inference Layer (DAML+OIL)). In this project, top-down approaches are the choice. Outside the utility domain the UA is already used as basis for domain-specific information models. For example, Production Markup Language (PRODML) for the vertical integration of oil values, Machinery Information Management Open System Alliance (MIMOSA) for plant operations and maintenance, Open Modular Architecture Control (OMAC) for the integration of different packing line functions and PLCopen for standard PowerLine Communication (PLC) programming languages. Furthermore, the IEC Technical Committee (TC) 57 is currently specifing CIM-interfaces for the UA in the IEC 61970-502-8 (Web Services Profile for 61970-4 Abstract Services) in an abstract way. Those specifications are a good starting point for our approach. In the second edition of the IEC 61968-9 (Interfaces for meter reading and control), the IEC starts annotating semantic data, thus, its importance becomes apparent. Contrary to our approach they use bottomup technologies. Considering service classification, Quasar Enterprise [17] introduces the concepts of domains and service classes (Interaction, Process, Function and Data) and argues for a functional rather than a technical view on SOAs. The authors put Quasar Enterprise into the wider context of Capgeminis Integrated Architecture Framework (IAF) but touch EA just marginally. Inside the Open Group the SOA work group is working on TOGAF enhancements toward service orientation. A SOA ontology and a SOA government framework are under development. The DoD Architecture Framework (DoDAF) follows already the concept of SOA in its recent Version 2.0 and provides corresponding views as well as a DoDAF Meta-Model (DM2) but lacks a comprehensive architecture development method. This was also the reason for choosing TOGAF as a starting point for our work. A combination of both, the DoDAF Meta-Model and the ADM of TOGAF might be an adequate solution for the future. For architecture development especially for SOA Quasar Enterprise should also be considered as well as IBMs Service Oriented Modeling and Architecture (SOMA) [18]. Inspired by both, SOA could be regarded inside a framing ADM. VI. C ONCLUSIONS AND F UTURE W ORK In section IV we introduced our approach concerning the combination of the two views explained in sections II and III. The approach describes a layer comprehensive functional model, which provides an opportunity for enterprises to take an active part in the future smart grid without serious problems in terms of interoperability and integration. To realize the approach the following work is already in progress. First steps for the implementation of the technical view can be found in [5] and [14]. The development of a CIM based UA model is shown as well as the design of a CIM based WSMO ontology being the basis for energy specific SWS.

Starting from existing enhancements on TOGAF to support service orientation, we extracted 45 concerns of various SOA stakeholders leading to a SOA specific EA meta-model [19]. We design an ontology able to satisfy these concerns based on our TOGAF CMM ontology extended by concepts taken from Quasar Enterprise and The Open Group SOA Ontology. This meta model is able to describe SOAs in both, enterprise context and sector independently but lacks energy specific meta data. This paper presents work in progress and outlines the direction for future work - the improvement of our idea to align EA and CIM to manage a complex system of systems like smart grid. R EFERENCES [1] “NIST Special Publication 1108 NIST Framework and Roadmap for Smart Grid Interoperability Standards”, 2010. [2] OFFIS, SCC Consulting, and MPC management coaching, “Untersuchung des Normungsumfeldes zum BMWi-Foerderschwerpunkt ”EEnergy - IKT-basiertes Energiesystem der Zukunft””, 2009. [3] SMB Smart Grid Strategic Group (SG3), “IEC Smart Grid Standardization Roadmap”, June 2010. [4] P. Hitzler, R. Sebastian, and M. Kr¨otzsch, Foundations of Semantic Web Technologies. London: Chapman & Hall/CRC, 2009. [5] S. Rohjans, M. Uslar, and H. J. Appelrath, “OPC UA and CIM: Semantics for the smart grid”, in Transmission and Distribution Conference and Exposition, 2010 IEEE PES, 2010, pp. 1–8. [6] TOGAF Version 9, The Open Group Std., 2009. [7] M. Lankhorst, Enterprise Architecture at Work: Modelling, Communication and Analysis. Springer, 2005. [8] S. Buckl, A. Ernst, J. Lankes, and F. Matthes, “Enterprise Architecture Management Pattern Catalog (Version 1.0, February 2008)”, Chair for Informatics 19, Technische Universit¨at M¨unchen, Tech. Rep., February 2008. [9] P. Gringel and M. Postina, “I-Pattern for Gap Analysis”, in Software Engineering (Workshops), ser. LNI, G. Engels, M. Luckey, A. Pretschner, and R. Reussner, Eds., vol. 160. GI, 2010, pp. 281–292. [10] M. Postina, I. Sechyn, and U. Steffens, “Gap analysis of application landscapes”, in Enterprise Distributed Object Computing Conference Workshops, 2009. EDOCW 2009. 13th, 1-4 2009, pp. 274 –281. [11] T. Schmedes, “Serviceorientierte Architekturen fuer dezentrales Energiemanagement”, Ph.D. dissertation, 2009. [12] M. Uslar, F. Gruening, and S. Rohjans, Cases on Semantic Interoperability for Information Systems Integration: Practices and Applications. IGI Global, 2009, ch. A Use Case for Ontology Evolution and Interoperability: The IEC Utility Standards Reference Framework 62357, pp. 187–209. [13] W. Mahnke, S.-H. Leitner, and M. Damm, OPC Unified Architecture, 1st ed. Springer Verlag, 3 2009. [14] M. Uslar, S. Rohjans, P. Beenken, and M. Specht, “Towards a standard compliant smart grid through semantic web technologies concerning interoperability, security and soa”, in POWERGRID Europe 2010, 2010. [15] D. Fensel, M. Kerrigan, and M. Zaremba, Implementing Semantic Web Services, The SESA Framework. Berlin, Heidelberg: Springer-Verlag, 2008. [16] J. de Bruijn, D. Fensel, M. Kerrigan, U. Keller, H. Lausen, and J. Scicluna, Modeling Semantic Web Services: The Web Service Modeling Language. Berlin: Springer, 2008. [17] G. Engels, A. Hess, B. Humm, O. Juwig, M. Lohmann, J.-P. Richter, M. Vo, and J. Willkomm, Quasar Enterprise - Anwendungslandschaften serviceorientiert gestalten. Heidelberg: dpunkt.verlag, 2008. [18] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Gariapathy, and K. Holley, “SOMA: a method for developing service-oriented solutions”, IBM Syst. J., vol. 47, no. 3, pp. 377–396, 2008. [19] M. Postina, J. Trefke, and U. Steffens, “An EA-Approach to Develop SOA Viewpoints”, in Proceedings of the 14th IEEE International Enterprise Distributed Object Computing Conference, EDOC 2010, 2529 October 2010, Vitria, ES, Brasil, 2010.

30