SOA-based Integration of Service Management Applications Integrated IT Service Management

Transcription

1 SOA-based Integration of Management Applications Integrated IT Management Christian Mayerl, Tobias Vogel, Sebastian Abeck Cooperation & Management Faculty of Computer Science Universität Karlsruhe (TH) [vogel Abstract As well as other organizations IT service providers use applications to support their internal business processes. So-called management applications support monitoring and controlling of networks, systems, applications, operational processes and IT services. Today a multitude and diversity of management applications can be recognized in one provider scenario. Reasons often are the need for specialized management functionality and information depending on IT components and IT services which have to be managed. To run IT and to provide IT services efficiently management applications have to be integrated. Thereby it has to be kept in mind that processes can be changed over time and management applications have to be adapted flexibly. Because available management architectures do not meet all providers requirements, this article describes an approach to integrate management applications using a service-oriented architecture. The main contribution of this approach is a method defining how to integrate management applications loosely according to business processes. A prerequisite is a sufficient understanding of IT service provider s processes and cooperative roles by a formalized modeling approach on which SOA-based integration can be established. Keywords Business Process, Management Application, Application Integration, -oriented Architecture, Web, Business Process Execution Language 1 INTRODUCTION IT service providers have defined their business processes for running IT and providing IT services according to standards like IT Infrastructure Library (ITIL) [ITIL]. Examples for provider s business processes are configuration management, change management, problem management, service level management etc. Executing these processes effectively and efficiently IT provider s employees use different management applications. Today management applications can be classified depending on their main functionality [HA+99] to monitor and control networks, systems or applications, to support operational processes or to manage IT services and service level agreements (SLAs). Because of dependencies between provider s business processes and because of an efficient use management applications have to be integrated. For example after installing and configuring a new IT component whose functionality should be offered to provider s customers, necessary configuration management information of this IT has to be stored in a Configuration Management Database (CMDB). This information about available IT is the starting point designing and defining IT-based and ITrelated services which are documented in a service catalog. Again a service catalog implements the base to negotiate with customers about IT services and service level agreements using a SLA editor etc. Figure 1 shows an overview of the scenario and examples of used management applications. INTRODUCTION Page 1 from 16

2 Customer Business Process IT IT IT Configuration Management Design Level Management IT Infrastructure Application System Network Config. Database Catalog IT Management Portal Process-oriented Integration Integrated Management Architecture (SOA-based) SLA Editor SLA Monitor IT Provider new IT Config. Database Catalog SLA Editor SLA Monitor Figure 1: Scenario of Integrated IT Management Existing management architectures basically focus on IT like network and system resources or application components. Solutions for service, customer and business management are not sufficient or are not integrated with other management applications according to providers management processes [RH04]. Approaches like management platforms focus on homogenous views on heterogeneous IT components but not on process-oriented integration of management applications. They are not flexible enough to cope with challenges of dynamic customer requirements and changing management processes. Such changes can be caused for example by changed demands on IT services or after installing new IT which has to be managed using additional management applications. Instead of integrating applications on information or function layer preferred by existing management architectures and platforms this article presents a process-oriented integration approach following service-oriented architecture (SOA) principles. The SOA integrates management applications according to requirements derived from IT service management (ITSM) processes. In the following section the background of the presented approach is detailed and existing work in the area of IT service management (ITSM) and service-oriented architectures (SOA) is related to our approach. As a prerequisite for process-oriented integration ITSM processes and the use of management applications have to be understood. Therefore section 3 presents models to provide an insight into ITSM processes and service management applications. Section 4 details a SOA for integrated IT service management following a process-oriented integration of management applications. Section 5 mirrors experiences implementing the architecture using BEA technologies in an IT service provider scenario. The article finishes with a conclusion and an outlook on further work. 2 BACKGROUND AND RELATED WORK To integrate management applications using a SOA requires understanding the business of IT service providers and the management applications supporting ITSM processes. A provider s business contains processes from infrastructure and application management, service delivery and service support up to business perspective activities. From a historic point of view its main challenges as IT administrator was the installation of networks and systems and the configuration of applications according to users needs. For an efficient administration of distributed and heterogeneous IT components management standards were defined to monitor BACKGROUND AND RELATED WORK Page 2 from 16

3 and control IT. Different management applications were integrated using management platforms which implement management architectures with standardized management information and protocols. Analyzing demands on management applications an IT administrator s view were focused on IT components. Today the main challenge of IT service providers is to offer IT functionality as services with defined quality without burdening customers with the complexity of IT and the operation of IT. In addition to IT administration operational processes of distributed and cooperative roles have to be defined. Not only IT management applications have to be implemented but also applications supporting providers business processes and management of IT services. A prerequisite to develop provider accepted management applications is to understand ITSM processes. The following section gives an short overview about existing approaches related to our work. To use management applications effectively and efficiently means to integrate innovative service management applications together with existing IT management applications. Also it s useful to support the interaction between users and the management environment and to guide cooperation between distributed users according to ITSM processes. For these purposes a service-oriented architecture approach will be followed. 2.1 IT Management To support ITSM processes with management applications an ITSM framework is necessary defining terminology, tasks, roles and processes of IT service providers. The IT Infrastructure Library (ITIL) represents a de facto standard for IT service management offering best-practice solutions applied in IT organizations [ITIL]. ITIL carries out strong commitment to meet customer s service and quality demands. Two aspects outlined by ITIL are related to our work: delivery and service support. delivery contains capacity, availability, service level, IT service continuity and financial management whereas service support includes incident, problem, configuration, change and release management. Three major processes have been regarded as relevant to our case study: Configuration management, service design and service level management (see also Figure 1). Initially as part of configuration management new network, system or applications have to be installed and configured by administrators. In doing so, management relevant information about resource properties have to be inserted in a so-called Configuration Management Database (CMDB). As ITIL does not address the IT service definition process in detail, but regards it to be part of service level management, a service design method has been conceived for that purpose as a necessary ITSM process [ML+05]. The service design method implies guidelines for defining and describing services in a modular and SLA-conform manner. A management application supporting the service design method is the service catalog manager which implements functions to define and to catalog IT services. By extracting the process of service design from service level management, the importance of that activity is taken into account as subsequent steps such as SLA negotiations and concluding directly rely on these service s. level management is the third aspect to be considered. Once a customer orders a service with certain quality levels, customer and IT provider conclude service level agreements. With regard to these service level agreements service delivery has to be carried out. Finally, the status of service delivery is monitored and reported to customers. To execute these activities efficiently a SLA editor and a SLA monitor could be used. As a very pragmatic approach to IT service management, ITIL lacks a systematic formal of processes and particularly a framework for management applications. But this is presumed for conducting SOA-based integration of management applications according to ITSM processes. BACKGROUND AND RELATED WORK Page 3 from 16

4 2.2 -oriented Architecture A -oriented Architecture (SOA) can be considered as a universal integration platform leveraging existing software functionality. Thereby process-oriented integration logic is separated from user interaction and business logic. Connectivity is accomplished by adapters. The integration layer provides high-level functionality for modeling, execution and analysis of business use cases. A message broker contributes message-level mechanisms for data validation, transformation and filtering to SOA. User interaction layer A Business integration layer Message Broker Adapter layer presentation business logic data business logic data presentation business logic data Application 1 Application 2 Application 3 Figure 2: Blueprint for -oriented Architecture (SOA) Along with these features SOA paradigm focuses on loosely-coupled and process-oriented integration. Loose coupling is a vague yet often used term lacking precise definition. In short, loosely-coupled environments aim at reducing dependencies between applications by means of asynchronous messaging-style interactions based on coarse-grained, business-level interfaces and dynamic binding patterns [Ka04]. As done by other existing middleware approaches before [REF], implementation and technology-specific system details are concealed behind abstract interface definition yielding to stronger autonomy of systems to be integrated. Finally one may wonder what distinguishes SOA from middleware for Enterprise Application Integration or Workflow Management. According to [AC+04] these middleware approaches were lacking both standards and interoperability. Due to these facts, its implementation was considered to be expensive and complex. SOA overcomes these short-comings when combined with Web service technology Process-oriented Integration The Business Process Execution Language (BPEL) [BPEL04] specifies a formal XML-based of automated business processes that can be composed of Web service invocations. Enjoying a great support from industry such as Microsoft, BEA Systems, IBM, Siebel and SAP BPEL is considered to be the most ambitious standard among other competing approaches for Web service composition. Recently, BPEL has been submitted to the Organization for the Advancement of Structured Information Standards (OASIS) for further enhancements [OASIS]. In terms of portability standardization is required, so that BPEL artifacts can be executed on any system complying with the BPEL specification. BPEL is suitable for both horizontal and vertical integration: The former allows sequential orchestration of Web service invocations along business process or use case s. The latter allows aggregation of concurrent Web service calls to form coarse-grained Web services while relying on fine-grained Web BACKGROUND AND RELATED WORK Page 4 from 16

5 services. Executable process s themselves can be exposed as Web services enabling interaction between client applications (e.g. portal applications) and process instances. In summary, BPEL together with Web services being leveraged in service-oriented architectures provides necessary mechanisms for enabling process-oriented integration Adapter Construction Web services are well-suited for adapter construction, they aren t the only way for establishing SOA-conform adapters, as CORBA IIOP,.Net Remoting, Java RMI/IIOP or message-oriented middleware approaches are possible as well. But what distinguishes them from other middleware approaches is to be an interface technology, granting interoperability and loose coupling in heterogeneous environments by platform independent communication formats and protocols. To deepen the understanding of Web service technology, the following Web service definition by the W3C Consortium [W3C04] may be helpful: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its using SOAPmessages, typically conveyed using HTTP with a XML serialization in conjunction with other Web-related standards. The foundation of Web services is the specification of standards, namely SOAP [SOAP03], Web Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI). Mapping operations, parameters and metadata of Web service invocations to XML-based messages SOAP relies on internet protocols such as HTTP for message transmission. WSDL provides a syntactical and technical service containing information about operations, message structures, URL service address and transport protocol while UDDI serves as a repository for Web service providers enabling dynamic discovery at runtime. With these three standards only rudimentary interaction is accomplished still lacking features fundamental to conventional middleware platforms. That s why plenty of so called Second-generation Web service specification has been coming up addressing transaction, conversation, orchestration and security issues. In [WS-Spec] an overview of pending Web service specifications can be found. 3 ITSM PROCESSES AND SYSTEM FRAMEWORK As pointed out above, before a SOA for ITSM can be implemented IT service provider s business processes and management applications have to be understood. Modeling as a conceptual approach for capturing essential properties of complex entities on a higher abstraction level while neglecting irrelevant facts can be applied either for of existing systems or for specification of systems, that have yet to be constructed [Lu04]. To be understandable by human beings, graphical notation syntax is preferred. The Unified Modeling Language (UML) [UML03], which is issued by the OMG, has been well-established in modeling software systems by the means of visual notation. In different stages of software development lifecycle, mainly in the analysis and conceptual design phase, UML provides various diagram types expressing static and dynamic system properties. Concerning modeling business or workflow processes event-driven process chains used in ARIS (IDS Prof. Scheer) or SAP R/3 Business Workflow (SAP AG) are adopted in industry while in academia Petri Nets enjoy popularity because of their profound mathematical and formal background. Recently, UML activity diagrams are gaining in importance for modeling business processes adopting some Petri Nets concepts. Using UML activity diagrams facilitates establishing a common approach to understand business processes and systems. It is for that reason, why the method introduced in this article makes use of UML activity diagrams. ITSM PROCESSES AND SYSTEM FRAMEWORK Page 5 from 16

6 3.1 Business Processes of IT Providers As a first step the scope of business domain to be supported and modeled should be determined. According to the introduction we will focus on IT service provider s business. Its business objectives can be seen in enabling and supporting customer s IT usage processes. It provides quality-based network, system and application services [HA+99]. Thereby effectivity and efficiency of provider s ITSM processes have a significant impact on productivity and quality of IT service. Customer triggered business use cases Secondary business use cases Customer <<informs>> <<orders>> Processing service information request Manager <<include>> <<include>> Installing IT component <<uses>> Negotiating & concluding SLA <<include>> Administrating config. information <<controls>> Delivering service Administrating service (module) Reporting SLA status Monitoring SLA status IT Provider Figure 3: Business Use Cases in an IT Provider Scenario In a second step stakeholders involved in ITSM processes should be regarded. The term stakeholder subsumes persons participating in IT service management, namely IT provider s staff members, customers, suppliers and business partners. IT providers have to satisfy consumer demands by offering appropriate services in different service levels. Suppliers and business partners support IT provider in service provisioning by offering external IT services or human resources. In a third step business use cases initiated by external partners have to be analyzed precisely. This includes business use cases such as processing service information requests, negotiating & concluding SLAs, delivering services as well as reporting of SLA status. These business use cases have in common that they are directly triggered by customers and rely on internal, supporting use cases, namely administrating service (module) s, monitoring SLA status etc. Figure 3 provides an overview of business use cases which have been identified in an IT service provider scenario. ITSM PROCESSES AND SYSTEM FRAMEWORK Page 6 from 16

7 Customer Processing service information request Retrieve service data Manager Catalog Manager Retrieve service module data Manager module Catalog Manager Retrieve configuration data Manager Configuration data Config. Manag. Database [for each module] Merge and publish Manager Detailed service Portal Figure 4: Activity Diagram of Automated Business Use Case When applying process-oriented integration it is essential to understand business use cases and their activity sequences. Therefore all necessary activities of for example processing service information requests are outlined. Four different entities are modeled and shown in Figure 4: Business use case, activities and roles, information objects and involved systems, which are adumbrated on the right hand-side. For being able to process information requests by customers, corresponding service information has to be retrieved from the Catalog Manager. Additionally, associated service module s are read as well. Finally, suitable entries are retrieved provided by Configuration Management Database (CMDB). Before being published, the distinct elements are merged. 3.2 System Framework for Management Applications After understanding ITSM business sufficiently business processes have to be mapped onto system use cases. Developing an integrated IT service management environment requires understanding which role will use what kind of functionalities offered by integrated management applications. The analysis of users demands leads to business objects which will be processed using GUI-elements. Furthermore system component and class diagrams are of essence when adapter functionality is subsequently added. Being relevant to an integrated IT service management principles and components of a service-oriented architecture (SOA) must be part of the system model. Following these SOA principles a predefined framework has to be recognized. Modeling business and system aspects has to fill up the framework dependant on scenarios to be supported. ITSM PROCESSES AND SYSTEM FRAMEWORK Page 7 from 16

8 Internal IT service provider s staff External partner module manager manager Customer ITSM business processes Manage service module Design service Catalog service request service Roles Business processes Business activities ITSM Portal with role-specific desktops Desktops GUI elements System activities Process management (Workflows with user collaboration) Workflows CMDB (internal) Catalog composition (BPEL) (external) Catalog Higher-value services Automated processes Business logic Business objects Functions CMDB s module s Basic core services Data elements Architecture System use cases Figure 5: SOA Framework with System Use Cases Figure 5 shows relationships between process and system components. In the middle of the figure the architecture specifies a set of default components: A portal implements functions differing roles and providing role-specific desktops gathering GUI elements derived from ITSM use cases. Supporting collaboration of distributed roles according to business processes a process management component implements workflow management functions. These functions will not be detailed in the following. But to integrate management applications according automated ITSM processes a service composition component is of special interest. This component supports a process-oriented composition of basic core services up to higher-value services which can be integrated into the portal. Thus it s possible to extract basic services from business logic and to couple these services loosely. Management applications needed must be implemented behind services interfaces. In the following application examples are detailed which are relevant for ITSM. Figure 5 also outlines some use cases (see red lines) how services could be used and integrated according to business processes. A large set of possible management applications has been established and widely adopted by industry for supporting activities of IT service management [Ma01]. For instance Configuration Management Database (CMDB) provides comprehensive information about managed Configuration Items (CIs) which are installed in an IT service provider s scenario. Each change has to be propagated to CMDB for guaranteeing consistent and up-to-date view of IT assets. SLA editor supports IT service provider staff in negotiating and concluding service level agreements with their customers, whereas controlling of service level agreements is accomplished by SLA monitors. A Catalog Manager (SCM) supports IT service manager in creating, retrieving, updating and deleting service (module) s. Hence, IT resources such as software, hardware or organizational resources provide the undermost building blocks in service hierarchy. module s directly rely on these resources but adding further service attributes for defining SLA parameters. Single service module s can be aggregated to a service published in the service catalog. Both service and service module s have to be indexed in catalog structures. While the service module catalog is an internal catalog supporting the service manager for aggregating single modules to a service, the service catalog is intended to be published to customers. ITSM PROCESSES AND SYSTEM FRAMEWORK Page 8 from 16

9 4 INTEGRATED ITSM ARCHITECTURE Instead of using different systems separately, our approach claims to establish a SOA-based system for an integrated service management. As part of the SOA an ITSM portal grants access for stakeholders in the service provider scenario to the integrated service management environment. Compared to user interaction with one application, portal s value added is personalization, role-based access control and single-sign-on authentification to more than one integrated applications. Furthermore, a portal provides access via different channels and enduser devices like browser, PDA etc. Though a portal implements access to the SOA of which functionality itself is implemented by integrated applications. ITSM Portal User interaction logic Integration logic ITSM <<BPEL>> Integrat. Use Cases Control Adapter logic Business logic CMDB Adapter Catalog <<Web >> Adapter SLA Editor Adapter CMDB facade Use Case Control Catalog facade Use Case Control SLA Editor facade Use Case Control BO BO BO BO BO BO Data management Database Database Database Figure 6: Integrated Architecture for IT Management Because some functionality is implemented by several management applications, they have to be orchestrated to provide the expected behavior. In the following sections orchestration is accomplished by the means of Web service composition using BPEL after having prepared existing management applications for participating in orchestration. As a prerequisite management applications involved have to be enabled by adding adapter functionality. These adapters are wired to provide functionality for integrated IT service management solutions. In summary it can be ascertained, that the proposed integrated architecture for IT service management contains building blocks as shown in Figure Process-oriented Integration Logic Involved management applications have to be wired along to activity sequences of business processes. Currently one possibility for process-oriented integration is limited to well-known process structures that can be completely automated. Processing service information requested by service providers customers is considered to be such a use case. Each customer request looking for service information initiates an automated process to gather information from different management applications: In a first step the Catalog Manager designed as Web service is invoked delivering service and service module s. In a next step further information is obtained from a Configuration Management Database (CMDB), also designed as Web service, delivering additional more technical information. Subsequently the information results have to be merged before being published to customers via the ITSM portal. INTEGRATED ITSM ARCHITECTURE Page 9 from 16

10 When orchestrating Web services communication issues have to be addressed, namely the question whether to use synchronous or asynchronous calls. Synchronous service calls imply that service requestor is blocked until a reply is received. This is a common and well-understood paradigm for RPC-based interaction. Preventing senders from being blocked asynchronous interaction provides greater efficiency by means of queues or method callbacks. As asynchronous Web service calls haven t been standardized yet, a decision, whether to use synchronous and asynchronous invocation is deferred until underlying SOA middleware has been chosen. GUI : request for service <receive> <invoke> Get service s <while> 1 [Ok] Get service module <invoke> 2 [Ok] Get configuration data <invoke> module Configuration data module s Configurations data 4 [for each module] 3 [Ok] <reply> Merge information detailed service GUI : Detailled 5 [Ok] Figure 7: Mapping Activity Sequence of Use Case to BPEL To perform the technical wiring, the activity sequence has to be mapped to a business process and execution language. As mentioned before, BPEL is used to achieve processoriented integration. For structuring processes using BPEL, the following syntactical elements are available: <sequence>, <switch>, <while> and <flow>. For invocations <invoke>, <receive> and <reply> elements are to be used. Even more sophisticated aspects can be expressed in BPEL such as variable assignments, event and fault handling or compensation activities. For further information see [BPEL]. Figure 7 shows examples to map activity sequences to BPEL elements. After mapping activity sequences to BPEL interactions between users and BPEL artifacts have to be implemented by programming portal applications. Details of portal development are beyond the scope of this article. Instead of that the design of adapter logic is shown in the following section. 4.2 Adapter Logic for Management Applications After introducing example applications of IT service management in the scenario, the Catalog Manager (SCM) is given more attention for demonstrating integration efforts. In order to enable the SCM to participate in integration following the activity sequences of ITSM business processes, adapters have to be added afterwards. Adapter construction is supposed to be a crucial factor as many decisions have to be taken with great impact on performance and quality. Choosing an appropriate adapter technology is the first step which all subsequent decisions in this context rely on. In our scenario Web services are chosen for implementing adapters because of their platform and vendor independence. Following open standards of Web technology, wide-spread applicability can be granted meeting future requirements and crossplatform interoperability. Another important design issue is the interface granularity, where a trade-off between re-use and communication overhead has to be found. While fine-grained INTEGRATED ITSM ARCHITECTURE Page 10 from 16

11 interfaces promote better re-use but imply high communication overhead, coarse-grained interfaces are preferred in distributed computing environments like SOAs. If a façade design pattern [GH+95] is applied, interface design can be derived from façade objects ensuring the right level of granularity. Designing the Web service interface, a decision has to be taken, whether the interface granularity of the façade is directly adopted or further consolidated. Figure 8 shows the Web service enhancements to Catalog Manager where the operations of the façade are directly mapped to the web service. WSDL Catalog Adapter logic Business logic Web Catalog facade Use Case Control Business Object modul Business Object Resources Business Object Data management Database Figure 8: Mapping Façade Interface to Web Creating a corresponding interface enabling clients to interact with the SCM Web service completes adapter construction. In the case of Web services the Web Definition Language (WSDL) is used. A WSDL document contains necessary information required by clients to invoke the Web service. Therefore WSDL documents specify type definitions for data elements expressed in XML schema, message definitions built up with these data elements and operation definitions for input, output and fault messages. With composition of several operation definitions towards port types a so-called abstract definition is finished. Subsequently, WSDL definitions contain protocol binding specifications such as SOAP over HTTP, HTTP- GET / POST, SOAP-JMS etc. for abstract port types. Furthermore binding specifications include invocation style (RPC / Document) and encoding style (encoded / literal). At last service definitions denotes an URL address, under which the Web service can be reached. As WSDL writing manually is supposed to be tedious and error-prone, it is recommended to generate WSDL documents by an Integrated Development Environment (IDE). With completion of these steps, the SCM is enabled to participate in process-oriented integration. 5 IMPLEMENTATION EXPERIENCES To implement a SOA-based integrated IT service management environment a SOA middleware platform is required. Selecting an appropriate SOA platform is a crucial decision, because in spite of standardization efforts some vendor lock-in cannot be avoided. Big players such as IBM, BEA, Oracle, SAP and established middleware developers like Seebeyond, Vitria, Tibco or Sonic are offering SOA solutions. We have chosen the BEA WebLogic Platform [BEA04], because of its complete integration suite and free availability for evaluation purpose. Another reason is that BEA is one of the major players contributing to standards for SOA and processoriented integration. IMPLEMENTATION EXPERIENCES Page 11 from 16

12 BEA WebLogic Portal User Integration BEA WebLogic Liquid Data Data Integration BEA WebLogic Integration Application, Process and B2B Integration Beehive Application Framework XMLBeans, Java Page Flow Java Controls, WS-Metadata BEA WebLogic Server Application Server BEA WebLogic JRockit JVM BEA WebLogic Workshop Integrated Development Enviroment Figure 9: Overview of BEA WebLogic Platform Figure 9 outlines the different components of the BEA WebLogic Platform. In our case study we focused on application server, application framework and the process-oriented integration solution. The BEA WebLogic Workshop serves as an Integrated Development Environment (IDE). Higher-level components utilize and benefit from an application server which is fully J2EE-compliant. To develop for example an ITSM service portal and to integrate management applications the application server must be configured properly. In spite of the wide scope of the J2EE standard specifications there are still missing pieces. Therefore BEA offers some proprietary, but open-sourced programming concepts compensating J2EE short-comings: For integration scenarios there are XML beans to ease mapping of object oriented Java data types and XML schema. Java controls provide unified access to J2EE resources. For rapid Web service development programming mechanisms based on annotations are available. For conducting process-oriented integration the BEA WebLogic Integration component enables definitions of processes by a drag and drop user interface provided by the BEA Workshop development environment. 5.1 Implementing a Process with BEA BEA WebLogic Integration offers developer s support for design and run-time support. During design time all kind of resources can be applied to build up an automated business process definition by graphical drag and drop Java controls and Web services (see Figure 10). Behind the scenes Process Definition for Java (PD4J) is automatically generated [JSR207], that is a precursor of BPEL and Java-enhanced BPELJ. Events and client requests can trigger business process execution. Furthermore process variables enable the definition of stateful processes. Finally a mapping tool makes it easy to define data mappings between service calls by using XML technologies such as XML Schema, XQuery and XPath. BEA enables asynchronous Web service or Java Control invocations by callback mechanisms and achieves loosely coupling by buffering input and output messages. IMPLEMENTATION EXPERIENCES Page 12 from 16

13 Process flow Process configuration Process state Process activities Integration controls Figure 10: Graphical Process Definition in BEA WebLogic Workshop 8.1 Concerning run-time support automated execution of business processes as well as sophisticated analysis and reporting for process monitoring is provided. Even basic service level agreement functionality for process instances can be applied to ensure quality-based process executions. 5.2 Integrating an Application with BEA Attaining SOA conformity to the Catalog Manage (SCM) the BEA WebLogic Platform offers two different approaches for adapter construction: First Java controls provide high-level access to all kind of J2EE resources for example EJB, JMS, JBDC, Java Mail concealing complex access logic. Recently submitted to the Apache Foundation within the Beehive project [REF], Java controls allow establishing of native, high performance Java-based SOAs but being intrinsically restricted to Java environments. Regardless Java controls play an important role for establishing Web services in BEA. In doing so, BEA Workshop supports automatic derivation of Web services from Java controls. Web service communication comes at certain costs, but ensures interoperability inside SOAs based on Web services by leveraging well-established Internet communication protocols. That s the reason why the Catalog Manager is enhanced by Java control and Web service to cope with both requirements like high efficiency in Java-based SOAs and highest possible degree of interoperability in Web service based SOAs. While Java control is directly derived form SCMs EJB session bean façade, the corresponding Web service interface can map several Java Control operations on one Web service method for efficiency reasons. IMPLEMENTATION EXPERIENCES Page 13 from 16

14 WSDL Catalog Web Catalog Adapter logic Business logic Java control Catalog facade Use Case Control Business Object modul Business Object Resources Business Object Data management Database Figure 11: Adapter Construction in BEA WebLogic 8.1 Figure 11 shows adapter construction for the Catalog Manager (SCM) using BEA WebLogic Integration and Workshop. 6 CONCLUSION AND OUTLOOK Implementing a service-oriented architecture (SOA) brings different software engineering approaches together: algorithm development as programming in the small and integration as programming in the large [Le04]. Developing software functionality will increasingly rely on existing software assets, integration will have a strong impact on software development. Furthermore the key benefit of SOA lies in process-oriented integration of involved applications in a loosely coupled manner. SOA as a paradigm does not represent revolutionary concepts but rather an evolution of existing middleware approaches. Greatly influenced by EAI middleware but combining it with standards (for example Web service, BPEL etc.), it comes with the promise to be more cost-effective and interoperable than other middleware concepts before. Though SOA is not limited to Web services they seem to be a natural fit for establishing SOAs as they ease adapter construction. Web services allow application integration based on open standardized Internet technologies whereas service-oriented architectures provide sophisticated environments for process-oriented integration. This combination of features makes a SOA-based approach predestined to be evaluated in IT service management. In doing so, modeling considerably helps implementing SOA-based integration. Business modeling is a prerequisite to understand business processes, their activities and involved applications. System use cases and activity diagrams drives service wiring in integration layer, while adapter construction and interface design can be derived out of UML component and class diagram respectively. When UML graphical notation is used in both business and system modeling, the gap between these two domains can be bridged. As proof of concept this method has been successfully applied in BEA WebLogic Platform 8.1. Relying on comprehensive SOA middleware platforms, tedious and error-prone work is handled by tools. Furthermore, proprietary elements facilitate establishing of service-oriented architectures compensating current Web service drawbacks. When applying service-oriented architectures in productive environments some restrictions have to be taken into account. For instance combining sophisticated user interaction with process instances is hard to achieve. Concepts being well-established in conventional workflow management environments such as assigning tasks to roles for enabling people to collaborate have to be advanced. Leveraging Web service standards for adapter construction overcomes CONCLUSION AND OUTLOOK Page 14 from 16

15 interoperability problems, but to reach functionality used in conventional middleware approaches a lot of specification effort has to be done. In the meantime relying on proprietary mechanisms may be suitable, but it means certain vendor lock-in and interoperability problems between competing platforms. Ultimately, coping with the challenge of operating Web service based SOAs quality-assured stays an open issue. Due to the preceding discussions this article revealed that IT service management can benefit from SOA-based integration on the basis of ITSM processes but it is recommended to be sensible for current SOA shortcomings. 7 REFERENCES [AC+04] G. Alonso, F. Casati, H. Kuno, V. Machiraju: Web s Concepts, Architectures and Applications, Berlin, Heidelberg, Springer-Verlag [BEA04] BEA WebLogic Platform 8.1 Pack 3, product documentation, [BPEL04] [Er04] [GH+95] [HA+99] Business Process Execution Language for Web s, BEA, IBM, Microsoft, SAP, Siebel, Thomas Erl: -Oriented Architecture: A Field Guide to Integrating XML and Web s, Prentice Hall, E. Gamma, R. Helm, R. Johnson and J. Vlissides: Design Patterns : Elements of Reusing Object-oriented Software, Addison-Wesley Publising, Heinz-Gerd Hegering, Sebastian Abeck, Bernhard Neumair Integrated management of networked systems: concepts, architectures, and their operational application, Morgan Kaufmann, [ITIL02] Office of Government Commerce (OCG): IT Infrastructure Library (ITIL) Support (ISBN ), 2000; Delivery (ISBN ), 2001; Planning to Implement Management (ISBN ), 2002; Application Management (ISBN ), [JSR207] JSR 207: Process Definition for Java, [Ka04] [Le04] [Lu03] [Ma01] [ML+05] Doug Kaye: Loosely Coupled: The Missing Pieces of Web s, RDS Press, California, Frank Leymann: The Influence of Web s on Software: Potentials and Tasks, Proc. of INFORMATIK 34th Annual Conference of the Gesellschaft für Informatik e.v., (Ulm, Germany, September 2004). Jochen Ludewig: Models in software engineering an introduction, Software and Systems Modeling, Issue: Volume 2, Springer, March Christian Mayerl: Eine integrierte Dienstmanagement-Architektur für die qualitätsgesicherte Bereitstellung von Netz- und Systemdiensten. Dissertation, Shaker-Verlag, Christian Mayerl, Stefan Link, Matthias Racke, Stefan Popescu, Tobias Vogel, REFERENCES Page 15 from 16

16 Oliver Mehl, Sebastian Abeck: Methode für das Design von SLA-fähigen IT- s, GI-Fachtagung KIVS, Kaiserslautern, [Ra04] [RH04] [SOAP03] [UML03] [WSDL03] [WSG04] Matthias Racke: Catalog Manager, product documentation, University Karlsruhe (TH), C&M (Prof. Abeck), G. Dreo Rodosek, H.-G. Hegering: IT-Dienstmanagement: Herausforderungen und Lösungsansätze, Praxis der Informationsverarbeitung und Kommunikation, 2/04, K. G. Saur, M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau and H. F. Nielsen: Simple Object Access Protocol (SOAP) 1.2, OMG Unified Modeling Language Specification Version 1.5, UML Resource Page, R. Chinnici, M. Gudgin, J.-J. Moreau, S. Weerawarana: Web s Description Language (WSDL) Version 1.2 Part 1: Core Language, June W3C Web s Architecture Working Group: Web Glossary, [WSS04] Second-Generation Web Specifications, Tomas Erl, [OASIS04] Organization for the Advancement of Structured Information Standards (OASIS): Web s Business Process Execution Language Technical Committee (WSBPEL) REFERENCES Page 16 from 16