WS Binder

Penta, Massimiliano Di; Esposito, Raffaele; Villani, Maria Luisa; Codato, Roberto; Colombo, Massimiliano; Nitto, Elisabetta Di

doi:10.1145/1138486.1138502

Cited by 52 publications

(4 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Hence, for processes with NOPP > 0, it becomes crucial to take also special care of the sub-processes during testing. Some sophisticated contemporary SOAs make use of the principle of dynamic binding [43], i.e., they use a registry to find the most suitable concrete implementation of an abstract functionality at runtime, and invoke it dynamically using tools such as Daios [44]. In such SOAs, another important metric is NODAP, the number of dynamically bound service invocation activities in a process.…”

Section: B Initial Multi-level Soa Criticality Metric Setmentioning

confidence: 99%

The dark side of SOA testing: Towards testing contemporary SOAs based on criticality metrics

Leitner

Schulte

Dustdar

et al. 2013

2013 5th International Workshop on Principles of Engineering Service-Oriented Systems (PESOS)

View full text Add to dashboard Cite

Abstract-Service-Oriented Architectures (SOAs) have widely been accepted as the standard way of building large-scale, heterogeneous enterprise IT systems. In this paper, we explore the current limitations of testing contemporary SOAs, which are typically assemblies of various components, including services, message buses, business processes, and support components. We argue that, currently, SOA testing is too much concerned with testing single services or business processes, while there is little scientific literature on holistic testing of contemporary SOAs that includes all critical components and their mutual dependencies and interactions. In this paper, we detail the architecture of contemporary SOA, thoroughly assess the current state of research in respect of their testing, and introduce the notion of SOA criticality metrics as indicators for an individual component's criticality for the SOA as a whole. We enumerate an initial metric set for various component types and interactions, as well as discuss how these metrics can be used for testing contemporary SOA.

show abstract

Section: B Initial Multi-level Soa Criticality Metric Setmentioning

confidence: 99%

The dark side of SOA testing: Towards testing contemporary SOAs based on criticality metrics

Leitner

Schulte

Dustdar

et al. 2013

2013 5th International Workshop on Principles of Engineering Service-Oriented Systems (PESOS)

View full text Add to dashboard Cite

show abstract

“…Especially for mobile devices, more lightweight descriptions have been proposed in order to reduce the computation complexity entailed by semantic reasoning processes. Another solution is promoted for instance by the SeCSE language and associated SCENE framework (Di Penta, Esposito, Vilana, Codato, Colombo, & Di Nitto, 2006). This approach is based on the idea to provide separated -yet coherently integrated -tools to describe the composition logic and the adaptation logic.…”

Section: Service Composition and Evolution In The Context Of Workflowsmentioning

confidence: 99%

“…To achieve this kind of adaptability of service compositions, we propose to restructure the given service composition internally. Thus, in case a service fails or is no longer available, we could check and try to solve its replacement by another single service at the engine level, adopting approaches like (Di Penta, Esposito, Vilana, Codato, Colombo, & Di Nitto, 2006). However, we claim that it is worth to research an alternative solution by relying on the associated component-based architecture.…”

Section: Service Composition and Evolution In The Context Of Workflowsmentioning

confidence: 99%

“…Fractal and GCM are particularly well suited for component adaptability, because they come with high reconfiguration capabilities, even a specific language for expressing component reconfiguration and adaptation has been designed (Bennour, Henrio, & Rivera, 2009). Adaptation offered by a component model is more general than the one provided by approaches like, e.g., (Di Penta, Esposito, Vilana, Codato, Colombo, & Di Nitto, 2006). This is due to the fact that, with a component approach we are able to manage a more profound, i.e.…”

Section: Service Composition and Evolution In The Context Of Componen...mentioning

confidence: 99%

See 1 more Smart Citation

Mixing Workflows and Components to Support Evolving Services

Pfeffer

Baude

Legrand

et al. 2010

International Journal of Adaptive, Resilient and Autonomic Systems

View full text Add to dashboard Cite

Composite distributed services involve local and remote services that get orchestrated according to specific business logic. This logic can be programmed by applying a traditional general-purpose programming language, but is generally described using a workflow language that coordinates a set of given services. The services involved in the composition, or the composition may need to evolve both at the business logic level (workflow level) and the global architecture level. This paper presents a solution to ease such evolution for compound distributed services and the authors’ proposal enables the evolution of both the business logic and the underlying architecture. This paper suggests relying on a distributed software component model to represent and easily manage the set of local or remote software entities (services) involved in the composition. Composite services are represented in a model that combines the use of a distributed and hierarchical software component model and new timed-automata based workflow language. This combination makes explicit the separation between functional and non-functional concerns, and as a consequence this approach helps in defining the required and various evolution procedures in context to compound services.

show abstract

SCENE: A Service Composition Execution Environment Supporting Dynamic Changes Disciplined Through Rules

Colombo

Nitto

Mauri

2006

Service-Oriented Computing – ICSOC 2007

Self Cite

View full text Add to dashboard Cite

Service compositions are created by exploiting existing component services that are, in general, out of the control of the composition developer. The challenge nowadays is to make such compositions able to dynamically reconfigure themselves in order to address the cases when the component services do not behave as expected and when the execution context changes. We argue that the problem has to be tackled at two levels: on the one side, the runtime platform should be flexible enough to support the selection of alternative services, the negotiation of their service level agreements, and the partial replanning of a composition. On the other side, the language used to develop the composition should support the designer in defining the constraints and conditions that regulate selection, negotiation, and replanning actions at runtime. In this paper we present the SCENE platform that partially addresses the above issues by offering a language for composition design that extends the standard BPEL language with rules used to guide the execution of binding and re-binding self-reconfiguration operations.

show abstract

WS Binder

Cited by 52 publications

References 8 publications

The dark side of SOA testing: Towards testing contemporary SOAs based on criticality metrics

The dark side of SOA testing: Towards testing contemporary SOAs based on criticality metrics

Mixing Workflows and Components to Support Evolving Services

SCENE: A Service Composition Execution Environment Supporting Dynamic Changes Disciplined Through Rules

Contact Info

Product

Resources

About