By using the remote functions of a modern IT service management system infrastructure, it is possible to analyze huge amounts of logfile data from complex technical equipment. This enables a service provider to predict failures of connected equipment before they happen. The problem most providers face in this context is finding a needle in a haystack - the obtained amount of data turns out to be too large to be analyzed manually. This report describes a process to find suitable predictive patterns in log files for the detection of upcoming critical situations. The identification process may serve as a hands-on guide. It describes how to connect statistical means, data mining algorithms and expert domain knowledge in the domain of service management. The process was developed in a research project which is currently being carried out within the Siemens Healthcare service organization. The project deals with two main aspects: First, the identification of predictive patterns in existing service data and second, the architecture of an autonomous agent which is able to correlate such patterns. This paper summarizes the results of the first project challenge. The identification process was tested successfully in a proof of concept for several Siemens Healthcare products.
Im Servicegeschäft werden Eventkorrelationssysteme verwendet, um bevorstehende Systemzustände vorherzusagen und damit Anlagenausfälle zu vermeiden. Aus strategischer Sicht kann dies zu höherer Anlagenverfügbarkeit und bessere Planbarkeit beitragen. Unternehmen, die von diesem Wettbewerbsvorteil profitieren wollen, begegnen dabei häufig zwei grundlegenden Problemen: die Komplexität im Service steigt mit der Anzahl der Korrelationen. Gleichzeitig geht die Kostentransparenz für den Gesamtprozess verloren. Die vorliegende Arbeit zeigt, warum diese beiden Probleme entstehen und wie sie weitgehend vermieden werden können.
Offering services anonymously on the Internet using so-called location-hidden services requires complex protocols with many different nodes involved. These properties result in performance problems, e.g. a simple website request taking tens of seconds. This work describes a setup to measure the performance of hidden services using the worldwide Tor network. It analyzes the results and proposes changes to the protocol to improve the performance without losing anonymity.
Ever fiercer competition has forced enterprises not only to optimize their own operations but also to cooperate with their suppliers and customers along their supply chains. Thus, competition today usually takes place between supply chains and not between individual enterprises. Business-To-Business integration (B2Bi) is a major task of supply chain management (SCM), and although it already has been researched for years, B2Bi is still an area of active research with a plethora of research questions and according approaches. Hence, management of B2Bi projects necessitates the identification of relevant requirements which is a far from trivial task. This paper identifies a core set of B2Bi challenges and deduces a comprehensive set of B2Bi requirements that are particularly useful for tackling the challenges identified. The derivation of B2Bi requirements follows an inductive approach that is based on the analysis of integration standards, reference architectures and related literature. In order to operationalize the B2Bi requirements for further analysis and concrete B2Bi projects, the requirements are classified according to the abstraction layers of a B2Bi schema. Thus, this report not only offers a requirements check list for B2Bi projects but also helps in deciding when to address which requirements during the course of a B2Bi project.
The way business processes are organised heavily influences the flexibility and the expenses of enterprises. The capability to address changing market needs in a timely manner and to provide appropriate pricing is indispensable in a world of internationalisation and growing competition. Optimising processes that cross enterprise boundaries potentially is a key success factor in achieving this goal but it requires the information systems of the participating enterprises to be consistently integrated. This gives rise to some challenging tasks. The personnel involved in building up business collaborations comes from different enterprises with different business vocabulary and background which requires extensive communication support. The lack of central technical infrastructure, typically prohibited by business politics, often calls for a distributed and computer-aided collaboration structure, so that the resulting complexity must be handled somehow. Nevertheless robustness is an important factor in building business collaborations as these may exchange goods of considerable value. This technical report proposes the use of a two step modelling approach that separates business logic, modelled in the so-called centralised perspective (CP), from its distributed implementation, modelled in the so-called distributed perspective (DP). The separation of these perspectives enables business people to concentrate on business issues and to solve communication problems in the CP whereas technical staff can concentrate on distribution issues. The use of stringent modelling rules is advised in order to provide the basis for formal analysis techniques as one means to achieve robustness. Considering the choreography of RosettaNet Partner Interface Processes (PIPs) as the subject of my analysis, UML activity diagrams for modelling the CP and WSBPEL for modelling the DP are described as enabling techniques for implementing the proposed two step modelling approach. Further, model checking is applied to validate the CP and DP models in order to detect errors in early design phases. As the adequacy of model checking tools highly depends on the detailed modelling techniques as well as the properties to be checked, a major part of our discussion covers relevant properties and requirements for a model checker.
Since their invention as lightweight integration technology about a decade ago, Web Services have matured significantly. Today, major middleware solution vendors as well as industry communities like RosettaNet are propagating Web services even for exchanging business-critical data and implementing inter-organizational business processes. Core enablers for using Web services in this domain are stateful interactions using the Web Services Business Process Execution Language (WS-BPEL) as well as advanced communication features like security and reliability using the WS-Security and WS-ReliableMessaging standard specifications. However, advanced communication features come at the price of complexity which challenges interoperability across different Web services stack implementations. Interoperability, in turn, is a predominant requirement for an integration technology such as Web services, in particular if inter-organizational business processes are supposed to be implemented on top of that technology. This paper approaches the problem of testing the interoperability of the so-called WS-* standards, advanced Web services communication features that are typically defined as SOAP extensions and configured using WS-Policy. Being essential to business process integration, WS-Security and WS-ReliableMessaging are selected as representatives of this group and the two major Java-based Web services stack implementations Metro and Axis2 are tested for interoperability. We operationalize the notion of interoperability for testing WS-* standards, suppose an approach for deriving test cases from WS-* specifications as well as a method for performing the test cases, and we provide a comprehensive interoperability review of the two selected Web services stack implementations.
Business Process Management Systems (BPMS) aim to support the Business Process Management paradigm and to ease legacy application integration. Often, they rely on Service-oriented Architecture (SoA). However, do such systems really meet real-world requirements? This paper introduces and discusses a set of criteria which are important for BPMS and applies these criteria in comparing tools from three important vendors, namely IDS Scheer, Oracle and Intalio based on a case study.
Recently, service orientation has strongly influenced the way enterprise applications are built. Service ecosystems, which provide means to trade services between companies like goods, are an evaluation of service orientation. To allow service ordering, discovering, selection, and consumption, a common way to describe services is a necessity. This paper discusses existing approaches to describe certain service aspects. Finally, a Service Description Framework for service ecosystems is proposed and exemplified.
Despite the popularity of BPEL engines to orchestrate complex and executable processes, there are still only few approaches available to help find the most appropriate engine for individual requirements.
One of the more crucial factors for such a middleware product in industry are the performance characteristics of a BPEL engine.
There exist multiple studies in industry and academia testing the performance of BPEL engines, which differ in focus and method.
We aim to compare the methods used in these approaches and provide guidance for further research in this area.
Based on the related work in the field of performance testing, we created a process engine specific comparison framework, which we used to evaluate and classify nine different approaches that were found using the method of a systematical literature survey.
With the results of the status quo analysis in mind, we derived directions for further research in this area.
In 2007, OASIS finalized their Business Process Execution Language 2.0 (BPEL) specification which defines an XML-based language for orchestrations of Web Services. As the validation of BPEL processes against the official BPEL XML schema leaves room for a plethora of static errors, the specification contains 94 static analysis rules to cover all static errors. According to the specification, any violations of these rules are to be checked by a standard conformant engine at deployment time. When a violation is not detected in BPEL processes during deployment, such errors are only detectable at runtime, making them expensive to find and fix.
Due to the large amount of rules, we have created a tag system to categorize them, allowing easier reasoning about these rules.
Next, we formalized the static rules and derived test cases based on these formalizations with the aim to evaluate the degree of support for static analysis of BPEL engines.
Hence, this work is the foundation of the static analysis capabilities of BPEL engines.