M2M Interface: a Web Services-based Framework for

M2M Interface: a Web Services-based Framework for Federated Enterprise Management Lei Liu Institute of Telematics University of Karlsruhe Germany [email protected]

Martin Gaedke Institute of Telematics University of Karlsruhe Germany [email protected]

Abstract Managing a highly connected and heterogeneous computing environment requires the federation of various management systems (managers) across different platforms, technologies and systems. This research work is focusing on a generic manager-tomanager (M2M) Interface, which enables a seamless cooperation between autonomous managers on the basis of Web services. Next to the standard Web services protocol stack, further emerging Web Services specifications are reviewed in depth for the usability in this case study.

Andreas Koeppel SAP AG Germany [email protected]

enterprise management and so that reach a market share as high as possible [2]. • Poor interoperability between managers: To enable cooperation between two managers, certain interfaces are required on both participating managers to export/import management data/functionalities. Furthermore, the exchanged capabilities have also to be interpreted by the participating managers in the same way. Unfortunately in the most cases this precondition can only be fulfilled in an insufficient way.

1. Introduction and Motivation The continuing evolution of the IT landscape towards distributed and heterogeneous environments and the increasing rate of outsourcing IT services to extern IT service provider [1], increases the need for cooperated supplying of management services without regard to the existing boundaries. But currently there are several factors that prevent such a cooperated management: • Heterogeneity in enterprise IT landscape: A typical enterprise computing environment consists of a multitude of client devices, systems, platforms, network protocols and topologies of various types. It prevents using a unified management concept for all the participating managers. • Insufficient support from software industry: Although the interoperability problem between various managers has been defined for a long time, but the support from the industry to solve this problem remains insufficient so far. This situation can be partially traced back to the increasing number of standardization organizations and software vendors, who try to establish their products as standards for the

Figure 1. M2M Interface Motivation Our approach is to eliminate the heterogeneity in the operating environments as well as in the managers by fully utilizing the ability of Web services to operate in a platform-, system- and technology independent manner. In the project Everest [3], we develop a framework to solve the heterogeneity problem successively in two levels: using a dedicated Web services-based messaging infrastructure to solve operating environment’s heterogeneity and using a generic adapter infrastructure to eliminate managerlevel’s heterogeneity, as illustrated in Figure 1. In this paper, we focus on the first aspect and determine how emerging Web services specifications can be adopted

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

in the messaging infrastructure. After a state-of-the-art analysis of emerging Web services specifications in section 2, we present the design of the messaging infrastructure in section 3. Section 4 illustrates how the M2M Interface can help in the cooperated enterprise management of a real world and section 5 concludes the paper and provides an outlook to the project.

2. Web Services for Management In traditional distributed enterprise management, a network protocol is required as an integral part of the management architecture for exchanging management information, such as SNMP. Due to the similar nature that both Web services and distributed enterprise management have, Web services are well suited to be used as the underlying interoperable network protocol. It eliminates the needs for a dedicated network protocol so that the management architecture can put more focus on the management-level protocol. But the basic Web services stack introduced in WSA is insufficient to meet the high demand that distributed management has on the network protocol. Emerging Web services protocols should be used to enhance the usability of Web services for distributed management.

2.1. Emerging Web Services Specifications A distinct characteristic of Web services protocol design is the Focus on Composition and Reuse: due to the extreme cost for developing an entire protocol for each vertical domain [4], the Web service protocol suite is designed as a family of composable protocols. Each protocol defines a fine-grained unit of functionality and can be flexibly reused and combined on demand. This section provides a state-of-the-art analysis of such specifications in the context of the M2M Interface. • Messaging: For a message-based technology with SOAP messages as the atomic unit of communication, Web Services place a significant emphasis on how messages are formed and transferred. – Addressing: as a distributed application, each M2M Interface represents a network end point to other M2M Interfaces. To reference uniquely and independently of the underlying transport a particular M2M Interface and its corresponding manager(s), an addressing mechanism is required. Currently there are two Web services specifications that address these issues: WSAddressing and WS-MessageDelivery. Both of them provide the addressing capabilities with possible customization by applying different approaches. – Reliable Messaging: As a Web service, the M2M Interface uses the underlying transport protocols to

deliver messages, whose capabilities vary from one to another. Unreliable transport protocols such as HTTP do not guarantee a delivery of messages, which is definitely unacceptable for a stable and at all reliable cooperation between managers. Currently there are two specifications being proposed, WS-Reliability and WSReliableMessaging. Both specifications provide the capabilities for at-least-once, at-most-once and inorder delivery of messages, even in the presence of failures in software components, system, or network. – Notification: From the point-of-view of topology, M2M Interfaces are distributed across the enterprise. An M2M Interface may be interested in events occurring on particular remote M2M Interfaces and would like to be notified if such events occur. WSEventing and WS-Notification provides the necessary capabilities to enable an event-driven functional model between various M2M Interfaces. Although WSEventing presents only a subset of WS-Notification, it gains gradually more acceptance and support from the industry [5] due to its flexibility. – Attachment: SOAP is designed to transfer text-based content, which is already sufficient in ordinary operation of M2M Interfaces. But in case that binary data or other complex data types need to be sent over the wire using SOAP, it is not suitable anymore, since serializing binary data to text increases significantly the size of SOAP message and makes great demands on the computing power, which is demonstrated by Ying’s evaluation of SOAP messaging [6]. There are several specifications addressing this problem by encapsulating binary data or XML document/fragment as attachment in a SOAP message: SOAP Messages with Attachments (SwA), WS-Attachments and SOAP Message Transmission Optimization Mechanism (SOAP MTOM). SwA and WS-Attachments have recently lost their momentum and are therefore superseded by MTOM. • Security: As one of the fundamental requirements for exchanging messages, Web services provide several specifications targeting security: – Messaging Security: To secure exchanging messages between M2M Interfaces, a secure transport is required between the communicating Web services of the M2M Interface. The security mechanisms of the underlying transport layers like SSL are not a perfect solution, since they are limited to point-to-point messaging and become problematic if intermediaries are used for messages transport. To maximize the usage of the M2M Interfaces, a higher-level security protocol is required to ensure end-to-end message security and it is WS-Security. It provides the messagelevel security in three aspects: Message Integrity, Confidentiality and Authentication. As a useful complement to WS-Security, WS-SecurityPolicy

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

defines how to exchange metadata about messaging security with communicating partners and therefore is rather a specification on the metadata layer. – Secure Session: WS-Security depends partly heavily on the computational expensive mechanisms like asymmetric en-/decryption, which becomes critical to resource-constrained systems. WS-SecureConversation aims to reduce the security overload by eliminating unnecessary operations after initial authentication. It defines a security session concept and specifies how security contexts, which are based on shared secrets, are established and amended during the lifetime of the session. • Discovery: Web services discovery is the key enabler for automating connection to M2M Interfaces without intervention of administrators or operators. For occasionally connected M2M Interfaces caused by operational condition, discovery mechanism provides an easy way to include the newly connected peer into the existing management landscape. Depending on the art of the discovery process, it can be classified into two groups: – Static discovery: Static discovery means for the M2M Interface to look for the potential cooperation partner in a well-known location. The UDDI registries apply this approach and serve as the directory for registering and querying M2M Interfaces. – Dynamic discovery: In dynamic discovery, there is no well-known location for querying M2M Interfaces. To discover an appropriate M2M Interface, the requester broadcasts a request to all available listeners. WS-Discovery defines this approach and specifies procedures to announce and discover Web services through multicast messages. • Metadata: In general, information about a Web service is collectively referred to as Metadata. Web services use a lot of metadata, such as WSDL, XML Schema, to describe a particular Web service. – Metadata exchange: Discovery is not enough for automated connection. After a target M2M Interface end point has been retrieved by discovery, the requesting M2M Interface needs more information about the target M2M Interface to enable bootstrap communication with it. A new Web services specification, WS-MetadataExchange, allows an M2M Interface to provide metadata to other interfaces through a Web services interface, both at design time and at runtime. • Summary: In general, all the emerging Web services specifications introduced above can be broadly categorized into two groups: the first one contains specifications that have a self-contained application model. Such specification defines a set of services that must be present to achieve the desired

effect. WS-MetadataExchange or WS-Discovery belongs to this group. The other group contains specifications that contribute only auxiliary work to the basic Web service protocol stack, such as WSAddressing or WS-Security. And another issue that must be figured out is the diverse status of the specifications. While some of them are only proposals on the paper, some other have already grown to industry-proved standards.

2.2. Management using Web Services The factors that make Web services suitable for distributed systems also make them an attractive choice for exchanging management information. Web Service Distributed Management (WSDM) [7] and WSManagement [8], are the two newly proposed Web services specification for distributed management. WSDM is currently hosted by the OASIS WSDM TC and focuses on two distinct problem domains in the distributed system management: Management Using Web Services (MUWS) and Management of Web Services (MOWS). In this paper, we only focus on MUWS since it is best comparable with an M2M Interface. The core component of the concept is the Web Services End Point. It interprets Web services messages and provides access to a backend manageable resource. A manageable resource can have a number of capabilities, each of which has distinct semantics, and provide these capabilities via the Web Services End Points outwards. The definition of MUWS’s manageability capability is extensible. And depending on the type of the management capabilities, they can be broadly classified into three categories: Resource-Specific Management Capabilities, Common Management Capabilities and Management Capabilities from Web Services. Another approach to use Web services for distributed management is Web Services for Management (WS-Management, former Web Service for Management Extension [8]), which is a joint publication of AMD, Microsoft and Sun etc [9]. It specifies a general SOAP-based protocol for managing IT resources by fully utilizing the strong foundation of Web services for building robust and interoperable system management solutions. In the WS-Management concept, a System is a top-level managed entity composed of one or more Resource Instances, where a Resource Instance is a single manageable item, such as a disk drive or a running process. A Resource Service is a Web service that provides access to a single category of Resource Instances, such as disk drives or running processes, which share the same operations and representation schema. An Agent is a hosting

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

application and provides management services for a System by exposing a set of Resource Services. Although both specifications address the same problem domain, they are extremely different, both in design and in their capabilities. WS-Management is designed as a lightweight management specification that can scale down to all types of devices. Its core only defines how to identify a resource and how to communicate with it. WSDM addresses essentially more problems in the domain than WS-Management. WS-Management overlaps with MUWS completely in the problem domain “management using Web services”. From the point-of-view of capabilities, WSManagement defines only the basic ones, while MUWS also specifies further approaches like relationship management and state management. In this regard, WS-Management can be thought of as a subset of MUWS.

3. Design a Solid Messaging Infrastructure The previous state-of-the-art analysis concerning enterprise management provides an informative basis for the design of M2M Interface’s messaging infrastructure. In the following section, we illustrate the design process including all the possible design decisions.

3.1. Design Guidelines The main objective of the infrastructure design is to identify the necessary software components of a generic messaging infrastructure for connecting managers, in spite of the heterogeneity in the computing environment. In order to make a compact but reusable design of the infrastructure, the following guidelines are necessary during the design process: • Generic Architecture: the goal of the work is to design a generic messaging infrastructure, which is suitable for all kinds of managers. Then, any vendoror manager-specific component should not be built into the design of M2M Interface. • Compatibility: the M2M Interface should be compatible to the existing/emerging Web services specifications. Therefore the design of the M2M Interface on one hand should leverage the existing and emerging Web services standards and on the other hand should be flexible enough to adopt any coming specification. • Composability: the design of the M2M Interface should follow the principles for Composition and Reuse from the Web services specification design. In other words, the architecture of the M2M Interface should be based on the “LEGO principle”, which

makes the resulted M2M Interface more flexible and the administration easier. • Data Integrity: In M2M Interfaces, the management data exists only in the particular backend managers. The M2M Interface’s job is to make these data remotely accessible. To ensure the data integrity, M2M Interfaces should not hold a second copy of the management data anywhere in the architecture. An important design decision regarding the messaging infrastructure is the way, how an M2M Interface can invoke functionalities exposed by remote M2M Interfaces. Currently there are two available approaches. The first one is the Remote Procedure Call (RPC), which applies the principle of encapsulation and lets a manager invoke functionalities of remote managed objects as if they were local managed objects. A set of technologies, such as .NET Remoting, CORBA, Java RMI, implement RPC. An RPC-enabled remote managed object is location transparent for an M2M Interface, which reduces the complexity of development and increases the usability of managed objects, but it also makes all the M2M Interfaces tightly coupled to one another. And the encapsulation increases the complexity of the whole solution and therefore makes it more likely to fail at runtime. The largest problem of an RPC-based M2M Interface is its platform- and technology-dependency, because RPCenabled managed objects are tightly associated with the underlying RPC platform. The other approach is to transfer management data and control information in well-formatted XML documents between participating M2M Interfaces, called Messaging. Messaging is platform- and technology independent and focuses on the message formats rather than on the remote object interface. The most significant difference of Messaging to RPC is that M2M Interfaces are loosely coupled. Another benefit is the asynchronous behavior in messaging, which is especially expedient for occasionally connected M2M Interface as well as for long-lasting operations. Comparing both approaches, it can be concluded that although the messaging-based M2M Interface requires obviously more implementation than the RPC, but its comparability to the loosely coupled nature of distributed managers makes it more suitable to provide a platform-independent connection between managers. Another important design decision is to decide the topology of the messaging system, namely either a point-to-point approach with decentralized components or centralized middleware, such as Message Bus [84]. From the point-of-view of functionalities, both approaches accomplish the same fundamental functionalities for transmitting messages. Additional

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

functionalities, such as aggregating messages, can be realized or at least emulated by both topologies. From the point-of-view of implementation complexity, both of them have similar implementation complexity in the respect of number of components to develop and the reusability of such components. From the point-of-view of deployment and administration, the centralized approach shows a better simplicity since no centralized component needs to be deployed and maintained. This benefit becomes even more important when the participating M2M Interfaces reside in separate enterprises. Combining all the analysis, it can be concluded that the decentralized approach is more suitable to M2M Interface than the centralized approach, namely each M2M Interface maintains its own messaging part and no centralized messaging system is deployed.

3.2. Applying EAI in Messaging Infrastructure As discussed before, the strict adoption of M2M Interfaces enables the managers to share their data and functionalities within the enterprise or even across enterprises. This objective conforms with the one of Enterprise Application Integration (EAI [10]). As a well-defined technology, there are a number of praxisproved integration concepts in EAI [11] that are applicable to the messaging infrastructure. • Point-to-Point Connection: A Point-to-Point connection ensures that only the desired target M2M Interface can receive the messages. In M2M Interfaces, a Point-to-Point connection is the physical Web service connection between the end points. • Publish/Subscribe: The Publish/Subscribe pattern gives the messaging infrastructure the ability to realize a 1-to-n connection. At a higher level, it helps separate processing message from addressing message. The message will only be addressed if it is about to leave the M2M Interface. [12]. • Pipe and Filter: The design guidelines Composability and Compatibility require that the M2M Interface should be able to perform complex processing on messages while maintaining independence and flexibility. The solution from EAI is Pipe/Filter that divides the message processing task into a sequence of smaller, independent processing steps. The adoption of Pipe/Filter in M2M Interfaces decouples the different processing components from each other, which can be combined on demand by given capabilities. • Message Dispatcher: From the top down, the M2M Interface applies a hierarchical 1-to-n relationship to the backend managers. Hence an incoming message targeting a particular manager has to be distributed

twice: at first from messaging infrastructure to the appropriate manager and then from the manager to the corresponding processing component. This process can be done by a Message Dispatcher, which coordinates the various consumers of the messages. • Message Gateway: One of the design guidelines for M2M Interfaces is the Generality. But part of the M2M Interfaces needs to be manager-specific to suit the heterogeneous management environment. Hence the generic messaging infrastructure must be decoupled from the backend managers. A Message Gateway is applicable in this context for loose coupling between the messaging infrastructure and the manager(s). Connecting all the components discussed above, we get a rough messaging infrastructure that accomplishes the basic message exchanging task. An incoming message from the Point-to-Point connection goes first through the inbound Pipe/Filter pipeline to verify the messaging headers in the message. Then it is delivered to the targeting processing component through the Message Dispatcher as discussed before. The Message Gateway converts the message to a strongly-typed object for the backend manager. An outgoing data is at first converted to a message by the Message Gateway. Then the Publish/Subscribe component addresses the message with remote M2M Interfaces’ addresses that have subscribed to this message. Before the message is sent by the Point-to-Point connection, it goes through the outbound Pipe/Filter pipeline, which equips the message with necessary messaging headers.

3.3. Adopting Emerging Web Services In the following, the rough infrastructure design of the last section is further refined by applying emerging Web services specifications. We identify at first the problem to solve and then specify how the Web services specifications can help to solve the problem. • Addressing: the M2M Interface has a hierarchical constitution as mentioned before, therefore a reasonable addressing must contains both information about the network end point and the target backend manager. The WS-Addressing specification does not meet these requirements directly. The element from WS-Addressing is a URI, which means WS-Addressing can only specify the network transport address. Hence, An additional addressing element is required in the SOAP messages to figure out the target manager. Accordingly, an Addressing-Filter component is required in the inbound/outbound pipeline to process this specific SOAP addressing header. • Security: Another fundamental design issue for M2M Interface is security. Messages being exchanged

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

must be protected against attacks like in-flight modification, interception, replay and so on. – Authentication: before accepting any requests from an M2M Interface, the M2M Interface being requested must authenticate the sender of the message prior to performing the desired action. WS-Security defines sufficient mechanisms for authentication, such as credential-, certificateor Kerberos-based authentication. To handle authentication information in the SOAP messages, an Authentication-Filter conforming WS-Security is required in both inboundand outbound-pipelines. – Authorization: The only security issue that is not addressed by WS-Security is authorization. Authorization determines if a requesting M2M Interface is granted to perform the desired action on the target M2M Interface. From the management application integration perspective, authorization can occur at four levels: 1. M2M Interface: Authorization at this level determines if the requesting M2M Interface can contact the target M2M Interface at all. 2. Manager and its adapter: This level authorization controls access request to particular backend manager. 3. Managed object: In some case, not all the managed objects that are available on a manager are valid for external access. This level authorization examines if the requesting M2M Interface has access to the desired managed objects. 4. Management functionality: This level authorization determines if the requesting M2M Interface can execute the desired management functionality. All the four authorization levels together span the whole M2M Interface. As the result, the Authorization component is not built into the inbound/outbound pipes. It acts as a stand-alone component outside the messaging infrastructure and provides authorization services to functional components. As a representative for the authorization in the inbound/outbound pipes, an Authorization-Filter component is required. – Confidentiality: While working with M2M Interfaces, sensitive information transferred over the Internet should not be available to unauthorized user. WS-Security addresses this problem by using XML Encryption. Accordingly, a Confidentiality-Filter component is build into both inbound and outbound pipe. This filter can be omitted if an underlying secure transport protocol like HTTPS is used. – Integrity: The transferred messages between two M2M Interfaces have also to be protected from modification on the way, since a message may need to pass several intermediaries until it reaches the destination. WS-Security addresses this problem by using XML Signature. The implementation of XML

Signature in the M2M Interface requires an IntegrityFilter component in the inbound/outbound pipe, which signs a message before sending it and verifies the message after having received it. – Secure Session: To reduce the security overload caused by unnecessary and expensive security operations in a long lasting conversation between M2M Interfaces, WS-SecureConversation can be adopted in the messaging infrastructure, which establishes a stable authentication state after the initial authentication at both sides. The implementation of WS-SecureConversation in the M2M Interface requires a SecureConversation-Filter conforming WSSecureConversation in both inbound/outbound pipes that handles the messages. • Discovery: The discovery of managed resources on particular M2M Interfaces is carried out successively, just like its hierarchical constitution: at first the M2M Interface end point, then the managers that the requesting M2M Interface have access to, and finally the capabilities available of a particular manager. The successive discovery process spans the whole M2M Interface. Hence, the implementation is also divided into two parts: the first part is normal Web service discovery that can be done by using UDDI or WSDiscovery; and the second part is the application-level discovery, which is out of scope of this paper. The other topic associated with discovery is metadata exchange, after an M2M Interface end point has been discovered. In general, a metadata exchange process is not required in the M2M Interface, since all the metadata about the M2M Interface’s Web service is predefined and already known at design time. But it is not excluded that a Web services client that is not necessary to be an M2M Interface also consumes the services provided by the requested M2M Interface. In this case, a MetadataExchange-Filter is required to enable the bootstrap communication between all the parties. The implementation of Discovery- or MetadataExchange-filter requires a dedicated pipe, since both specifications have defined their own application models that have nothing to do with the backend manager. • Attachment: For some managers like configuration management systems, it is possible that binary data has to be sent over the wire. Web services attachments specifications, especially SOAP MTOM, must be adopted here to supply an effective and efficient transport of data. The Message Gateway, which converts data between the strongly typed objects and the text-based messages as part of its responsibility, is most suitable component to host this implementation. • Multiple Messages: In some case, M2M Interface has to transmit large amount of data, whose size is too

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

large for transport even after compressing. Although most of the SOAP implementations do not specify an absolute limit on how big a SOAP message can be, there are practical limits for the message size that ensures properly processing of SOAP messages. The common way to transfer all the data in a single SOAP message may fail or at least causes performance problems at the sending/receiving M2M Interface. To work around this problem, data will be split into several parts that are sent in a message sequence. After an M2M Interface has received all the parts of the message sequence, the original data can be reconstructed from these parts. To ensure the proper transport of the message sequence, WSReliableMessaging or WS-Reliability must be applied. Similar to the dedicated inbound pipe for discovery, for reliable messaging is also a dedicated inbound pipe necessary that can autonomously interpret reliable messaging information in the received messages and send corresponding messages according to the procedures defined in the specification.

Figure 2: Messaging Infrastructure Design • Summary: Figure 2 depicts the refined messaging infrastructure. Comparing to the basic one defined in section 3.2, this infrastructure can accomplish more complex task than the simple message exchanging, such as discovery, metadata exchange, reliable message etc. Generally there are two message ways that a two-way message may take across the M2M Interface. 1. A Messaging-Related Way: a messaging-related way is marked as dotted line in the figure. This message way is designed for Web services specifications with a self-contained application model. Such SOAP messages are directly distributed by the Message Dispatcher to the dedicated inbound Pipe/Filter. The dedicated filter acts as a stand-alone building block that is used in conjunction with other Web services auxiliary specifications and performs autonomously actions according to the procedures defined in the specification. 2. A Management-Related Way: a managementrelated way is marked as dashed line in the figure. This

message way is designed for messages, which contain requests that can only be answered by the backend manager. The inbound- and outbound Pipe/Filter have a 1-to-1 relationship to the remote M2M Interface and contains only Filters for messaging level specifications, such as addressing or messaging security. The key components for the flexible capabilities of the messaging infrastructure are the inbound/outbound Pipe/Filter components. Any changes in the messaging capabilities can be done by adjusting the corresponding inbound/outbound Pipe/Filter, namely adding/ removing the processing Filter component to/from the pipe. Among all the components identified in this section, the Addressing-Filter is indispensable and must be available in both inbound/outbound pipes. Other filter components can be used depending on the capabilities being required.

4. M2M Applied – Lessons Learnt The M2M Interface is designed to enable a seamless cooperation between all types of managers. To prove the concept, we used the implemented M2M Interface in a real industry case study to manage SAP systems on the Microsoft platform. A first prototype of the M2M Interface has been fully implemented and successfully used for connecting Microsoft Operations Manager (MOM) to The SAP Computing Center Monitoring System (CCMS). The biggest problem that we faced during implementation is the lack of appropriate implementation of the emerging Web services specifications. Although there are also some implementations from the industry like Emerging Technologies Toolkit (ETTK) from IBM and Web Services Enhancements (WSE) from Microsoft, these implementations have less than expected in common due to the different objectives and purposes. In terms of implemented Web services specifications, we could therefore and so far only implement the minimal set of components that are required for the operation of M2M Interface and necessary for its proof-of-concept.

5. Summary and Future Work In this paper we have presented a generic messaging infrastructure based on Web services to enable a unified cooperated management concept for various managers. The resulted M2M Interface aims to solve the problem domains identified in the cooperation of two management systems.

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE

The first contribution of this paper is a concrete analysis of the emerging Web services specifications towards cooperated enterprise management. On one hand we reviewed the set of feasible Web services specifications in the context of using Web services as the carrier for the management protocol. On the other hand we focused on the problem domains in the heterogeneous operating environment of M2M Interface and discussed the usage of the emerging Web services specifications in different aspects, such as messaging, security etc. The second contribution is the design of a solid messaging infrastructure based on Web services. Besides the design guidelines discussed in section 3.1, we concentrated on the extensibility, transparency and security during the design process. • Extensibility: The messaging infrastructure has a flexible architecture. Regarding the Web services protocol, any new Web services specification can be implemented by adding a new filter to the inbound/outbound message pipeline. And similarly, a new manager can be dynamically included into the enterprise management environment by add a new entry to the message dispatcher. • Transparency: for the backend manager, the messaging infrastructure is transparent for its operation due to the message gateway. The manager adapter can communicate with any remote M2M Interface despite of possibly different operating environment. • Security: as an enterprise application, the messaging infrastructure proves also an active support for security. Besides the standard mechanisms defined in WS-Security, the messaging infrastructure provides also the possibility to adopt a self-contained security model, which makes sense if the underlying security infrastructure is not available at runtime. Future work on the M2M Interface will be on one hand to apply further Web services specifications to refine the messaging infrastructure, such as applying the automating approach with discovery and the subsequently metadata exchange, and on the other hand to investigate the interoperability of M2M Interface to other management specifications, with or without Web services, such as WBEM, WSDM MUWS or WS-Management.

[3] Project Everest: Concept of a Generic Manager-toManager Interface based on Web Services, Institute of Telematics, University of Karlsruhe, 2005. [4] L. F. Cabrera, et al.: An Introduction to the Web Services Architecture and Its Specifications, 2004. [5] P. Krill: IBM, Sun join Microsoft on Web services event specification, InfoWorld, 2004. [6] Y. Ying: An Evaluation of SOAP with Attachment in eScience, 2002. [7] OASIS: OASIS Web Services Distributed Management (WSDM) Technical Committee, 2005. [8] S. Akhil Arora, et al.: Web Services for Management (WS-Management) Specification, 2005 [9] AMD, et al.: AMD, Dell, Intel, Microsoft and Sun Drive New Management Web Services Specification, 2004. [10] D. S. Linthicum: Enterprise Application Integration, Addison Wesley, 1999. [11] G. Hohpe and B. Woolf: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addison Wesley, 2003. [12] D. Trowbridge, et al.: Integration Patterns, Microsoft Press, 2004. Acknowledgement:

This work is executed in the context of Project Everest [3], which is the diploma thesis of Lei Liu as a graduate student at the University of Karlsruhe, Germany. The project is supported by both SAP AG and Microsoft EMEA SAP Competence Center located in Walldorf, Germany. Especially, we would like to thank Mr. Rolf Mueller from SAP, Mr. Juergen Grebe from Microsoft as well as Mr. Johannes Meinecke, who contributed a lot organizational work to this project.

6. References [1] E. Frauenheim: Gartner: Outsourcing drives IT services' growth, News.com (CNet), 2004. [2] T. Grieser: MARKET ANALYSIS: Worldwide Distributed Performance and Availability Management Software 20042008 Forecast Summary and 2003 Vendor Shares, IDC, 2004.

Proceedings of the IEEE International Conference on Web Services (ICWS’05) 0-7695-2409-5/05 $20.00 IEEE