Recently, Web services gain momentum for developing flexible service-oriented architectures. Quality of service (QoS) issues are currently not part of the Web service standard stack, although non-functional attributes like performance, dependability or cost and payment play an important role for service discovery, selection, and composition. A lot of research is dedicated to different QoS models, at the same time omitting a way to specify how QoS parameters (esp. the performance related aspects) are assessed, evaluated and constantly monitored. Our contribution in this paper comprises a) an evaluation approach for QoS attributes of Web services, which works completely serviceand provider independent, b) a method to analyze Web service interactions by using our evaluation tool and extract important QoS information without any knowledge about the service implementation. Furthermore, our implementation allows assessing performance specific values (such as latency or service processing time) that usually require access to the server which hosts the service. The result of the evaluation process can be used to enrich existing Web service descriptions with a set of up-to-date QoS attributes, therefore, making it a valuable instrument for Web service selection. 1.

Abstract. Many emerging on-line data analysis applications require applying continuous query operations such as correlation, aggregation, and filtering to data streams in real-time. Distributed stream processing systems allow in-network stream processing to achieve better scalability and quality-of-service (QoS) provision. In this paper we present Synergy, a distributed stream processing middleware that provides sharing-aware component composition. Synergy enables efficient reuse of both data streams and processing components, while composing distributed stream processing applications with QoS demands. Synergy provides a set of fully distributed algorithms to discover and evaluate the reusability of available data streams and processing components when instantiating new stream applications. For QoS provision, Synergy performs QoS impact projection to examine whether the shared processing can cause QoS violations on currently running applications. We have implemented a prototype of the Synergy middleware and evaluated its performance on both PlanetLab and simulation testbeds. The experimental results show that Synergy can achieve much better resource utilization and QoS provision than previously proposed schemes, by judiciously sharing streams and processing components during application composition.

In a Business Process Execution Language (BPEL) process definition the sequence of exchanged messages typically originates from the sequence of business process activities and from the need of coordination of those activities across the participants of the process. As such business concerns (e.g. the sequence of business process steps) are often mixed with technical aspects (e.g. the sequence of coordination messages). In this article we present an architecture to separate business and technical concerns, which results in a clearer overview of the high-level business process and improves the flexibility and maintainability of the orchestration architecture. The described architecture depends on existing Web service standards. Different eventing and coordination specifications are discussed. The ultimate architecture is mainly based on the WS-Brokered Notification and WS-Coordination Framework specifications. 1. Structured Web services orchestration 1.1. A spaghetti of messages Web services orchestration refers to an executable business process that can interact with both internal and external Web services. The interactions occur at the message level. They include business logic and task execution order, and they can span applications and organizations to define a long-lived, transactional, multistep process model [1]. The business process execution language (BPEL) is the leading standard language for orchestration of Web services. A BPEL process defines how multiple service interactions are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination [2]. Figure 1 shows an example of a business process

Businesses increasingly provide and use services, applying formal (Web) services technology for the description, composition, and management of software as services. At the same time, social communities are emerging on the Web, applying less formal practices and Web 2.0 technology for the dissemination and aggregation of diverse content. In this paper, we are interested in the combination of these two trends in the form of service communities: social and business communities exchanging services. We discuss applications of service communities and introduce the concept of Service Clubs as a structuring mechanism for communities. Clubs have been specifically designed to support community-based, per-project interaction and composition of services.

Abstract. Modern enterprise applications and systems are characterized by complex underlying software structures, constantly evolving feature sets, and frequent changes in the data on which they operate. The dynamic nature of these applications and systems poses substantial challenges to their use and management, suggesting the need for automated solutions. This paper considers a specific set of dynamic changes, large data updates that reflect changes in the current state of the business, where the frequency of such updates can be multiple times per day. The paper then presents techniques and their middleware implementation for automatically managing requests streams directed at server applications subjected to dynamic data updates, the goal being to improve application reliability in face of evolving feature sets and business data. These techniques (1) automatically detect input patterns that lead to performance degradation or failures and then (2) use these detections to trigger application-specific methods that control input patterns to avoid or at least, defer such undesirable phenomena. Lab experiments using actual traces from Worldspan show a 16 % decrease in frequency of server restarts when using these techniques, at negligible costs in additional overheads and within delays suitable for the rates of changes experienced by this application. 1

Abstract. Today´s business applications are getting increasingly complex and sophisticated. These applications may evolve into long running activities able to adapt to different circumstances. They are typically built on top of middleware platforms, such as J2EE, and use transactions. Several specifications, such as the J2EE Activity Service, have been proposed for applications requiring support for long running activities. Moreover, these applications also demand high availability to prevent financial losses and/or service level agreements violations due to service unavailability or crashes. Replication is a means to attain high availability. However, current middleware does not provide highly available transactions. In the advent of crashes, running transactions abort and the application is forced to re-execute them, what results in a loss of availability and transparency. Moreover, many applications maintain state across transactions and aborting the current transaction might introduce inconsistencies in the application, sometimes requiring human assistance. The situation is worse for the case of long running activities, very common in the web service realm, for which high availability support is almost non-existent. Most approaches using J2EE consider the replication of either the application server or the database. This results in poor availability when the non-replicated tier crashes. In this paper, we present replication support for J2EE both for the application server and the database providing highly available transactions and long running activities. Failure masking is absolutely transparent to client applications. We have implemented and evaluated a prototype using ECPerf benchmark and a specific benchmark for long running activities. 1

When Web services are composed, transactions are needed to maintain the consistency of the distributed data in all but the most trivial cases. Today’s Web service transaction specifications still leave some issues unresolved, e.g., the specification of quality of service aspects. Therefore, we propose a modeling methodology that forces the software architect to address such issues at an early stage of development. The methodology is divided into four layers of UML diagrams which reference each other: structure, transactions, security, and workflow. This separation of concerns can also be used to incorporate the knowledge of several experts into the design. 1.

Abstract. This paper focuses on middleware concerns in BPEL workflows. When looking at those workflows from the implementation perspective, we observe that they have several BPEL-specific middleware requirements, which are not supported by current WS- * specifications and by most BPEL engines available to date. This demo paper will show the AO4BPEL Engine, which implements a container framework that allows the specification and enforcement of middleware requirements in BPEL processes. A deployment descriptor is used to specify the quality of service requirements of BPEL activities. A light-weight and aspectbased process container is used to enforce those requirements by calling dedicated middleware Web Services. We implemented those middleware Web Services by extending open source implementations of WS- * specifications for security, reliable messaging, and transactions. 1

A major goal of service-oriented architectures is to enable software interoperability in heterogeneous and dynamic environments. Web services standards and protocols aim to support this goal and middleware systems implementing these standards and protocols consequently are needed. Maintenance and administration of middleware is made difficult due to variations in standards and their constant evolution. In this paper, we introduce a new service-oriented middleware architecture for runtime Web services interoperability. Different from other middleware systems our approach applies service-oriented computing principles on the middleware layer, thereby establishing an on-demand model for middleware features. Clients can use middleware as services, dynamically discovering and using the services as interoperability requirements are determined. Further, middleware as services allows middleware to be provided and managed separately from its clients. We present the policy-based programming model, architecture, and details of our middleware, and discuss new challenges that arise in this context, such as distribution of middleware services. The approach is validated through a scenario integrating web service transaction middleware. 1.

Abstract. We discuss a case study for the hospital scenario where workflow model components are distributed across various computers or devices (e.g. mobile phones, PDAs, sensors, RFID tags). By using the concept of loosely-coupled processes we want to enable computerization of manually performed ad hoc medical tasks. That could decrease time, cost and resource consumption in a hospital. The challenges of loosely coupled process composition include: the requirement to manage flexibly the process logic, the need to overcome a heterogeneous software and hardware environment, and the management of the application domain (e.g. structure of organization, resources). The main question we address is what are the functional limitations and possibilities of current process composition approaches? In response to this question we describe and discuss the capabilities of Web service technologies. In addition, we sketch a plan to overcome these limitations. Finally, we propose a process composition approach based on BPEL4WS engine that satisfies medical scenario requirements. 1