scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

Contracts and Middleware for Safe SOA Applications

TL;DR: This position paper concerns formal methods for developing safe service-oriented architectures with support for resource management based on the specification of service requirements as declarative contracts and the enforcement of these contracts at the level of the middleware.
Abstract: This position paper concerns formal methods for developing safe service-oriented architectures (SOAs) with support for resource management. We seek an approach to building such SOAs based on the specification of service requirements as declarative contracts, and the enforcement of these contracts at the level of the middleware. Using hierarchical containers that provide the necessary middleware services, we expect to guarantee certain safety properties by construction and raise the level of model abstraction for verifying other necessary properties.

Summary (4 min read)

1. Introduction

  • The service-oriented architecture (SOA) paradigm facilitates component reuse, interoperability, scalability, and flexibility in assembling mission-specific applications.
  • SOA-based systems cannot yet support critical tasks because the underlying technologies fail to provide sufficient guarantees of safety or quality of service (QoS).
  • Long-running processes could degrade server performance, possibly to the point of causing the server to deny service to its customers.
  • To address these issues, the developer must typically augment an otherwise simple interaction protocol with logic that, e.g., monitors the time spent waiting for a response and that triggers some form of remediation when too much time has elapsed.
  • Flaws in these protocols can lead to safety violations and may be exploited by attackers.

2. Problem Description

  • SOAs must ensure safety while guaranteeing a level of service necessary to support clients, be they human users or other services.
  • Services communicate with each other by sending and receiving asynchronous messages, and service interactions often involve complex protocols of message exchange.
  • The protocols describe communication among multiple services, possibly running on different servers, and may involve operations on remote servers' resources.
  • Furthermore, it is possible that several constituent services running concurrently perform operations on different resources as parts of a single transaction.
  • To properly implement a distributed transaction across multiple constituent services requires elaborate protocols of message exchange among the constituents.

2.1. An example SOA

  • Consider a very simple web-based SOA application that allows customers to make on-line arrangements for flights with one specific airline (say, Delta) and accommodations with one specific hotel network (say, Hilton).
  • If the customer does select a flight/accommodation, TripManager forwards the relevant information back to the appropriate vendor service, which finalizes the transaction.
  • The vendor service then allocates the resource to the customer (charging their credit card accordingly), and returns to TripManager with a final acknowledgment.
  • Suppose a customer selects a combination of flight and accommodation that suits her needs.
  • The customer should not wait too long to learn if the trip arrangements are successfully finalized, but if TripManager is too hasty in aborting an attempt to finalize a set of options, it risks not finding good solutions.

2.2. Inter-process coordination issues

  • Consider two instances of the TripManager SOA, TripManager 1 and TripManager 2 , each independently processing a request to arrange travel and accommodation for a different customer.
  • Each instance must be careful to book the hotel and the corresponding flight as an atomic transaction.
  • To achieve this, the TripManager will commit a transaction in two phases, first sending two notifications of intent-for the selected flight to DeltaService, and for the selected hotel room to HiltonService, then waiting for acknowledgments from both before starting the second phase, which finalizes the commit, causing the constituent services to update their respective databases.
  • When the two instances of TripManager perform these sequences of operations concurrently, the following situation may occur.
  • Assume that both TripManager 1 and TripManager 2 begin the first phase of their respective commits by sending messages to both DeltaService and Hilton-Service.

2.3. Intra-process coordination issues

  • In addition to protocol flaws among multiple interacting services, a single service could exhibit safety problems if it is multi-threaded, and the concurrent threads operate over shared data without proper synchronization.
  • Each of the concurrently operating flows may read and modify shared variables.
  • To improve its performance, an SOA may deploy separate flows-each responsible for interacting with a different component service-and embed logic to compensate for those components that do not respond in a reasonable time or do not produce acceptable results.
  • With distribution and the need to synchronize come the kinds of complexity that lead to safety problems.
  • The flows must be synchronized to prevent races on the shared buffer and to ensure that the best solution over all solutions computed by the flows is among those returned by the service.

3. Research Directions

  • The authors see parallels between many of the safety issues that confront the developer of composite services and those addressed by Szumo, their approach to designing and analyzing systems for properties involving the synchronization of concurrent threads [2, 16] .
  • In Szumo, the tasks of system design and implementation are divided between the developer and the middleware.
  • The authors believe this idea of contract-enabled middleware could be applied in the context of SOAs, with containers playing the role of the middleware (Section 3.1).
  • The authors Szumo middleware could be promoted into a flow container, with which to synchronize the interaction of concurrent flows within a given service (Section 3.2).
  • The developer of a composite service would specify a contract that declares how the service will need to atomically commit operations with its suppliers.

3.1. Containers

  • A container is an entity that encapsulates a software component from its environment-all interaction with the component from the outside is routed through the container, which may add new capabilities and enforce safety constraints by intercepting and issuing messages to and from the component.
  • The authors believe that contract-aware containers can automate the implementation of complex service interaction protocols and thereby dramatically simplify the addition of reliability enhancements, such as failsafes, bounded retry, and failover, by developers.
  • The authors envision two types of containers-flow and interprocess containers-that could help ameliorate the safety and level of service issues in the context of SOAs.
  • Here, S 1 and S 2 represent the servers that are running web service processes.
  • Each process has one or more flows, represented as white squares.

3.2. Flow container

  • To address the problems of concurrency within a single web service process, a flow container would encompass the flows of an individual process and govern the execution of these flows based on the satisfaction of programmersupplied synchronization contracts.
  • Flow containers would provide flows with certain safety guarantees, including freedom from simple races among accesses to shared variables by multiple concurrent flows.
  • Figure 2 depicts the flow containers as boxes with dark shading, surrounding the flows within each process.
  • The WS-BPEL specification provides for a notion of containers to hold shared resources [1] .
  • There is also related work on process containers for web services, but the synchronization aspects of their behavior are left open [7] .

3.3. Inter-process container

  • An inter-process container could allow multiple concurrent processes to safely commit atomic transactions involving multiple resources.
  • The authors envision such a container encompassing all processes running on a given server and governing their interaction with other processes by negotiating contracts between a client and its suppliers.
  • When coding up the TripManager service, the developer would write code to signal when a transaction should finalize rather than write the communication code needed to implement Trip-Manager's role in the commit protocol.
  • Otherwise, the container could either block execution of the statement until the time when it is able to successfully execute the commit or fail.
  • The authors envision a number of different policies being applicable here, including the use of bounded retry and failover.

3.4. Design for verification

  • In Szumo, the negotiation of contracts guarantees freedom from a large class of typical concurrency errors, including simple data races and a large class of deadlocks and starvation.
  • This general approach-conceding some degree of freedom during design in order to enable verification-has been called design for verification (D4V) [10, 6] .
  • The vision outlined in this position paper suggests an approach to D4V for SOAs.
  • Containers at multiple levels would ensure certain guarantees regarding concurrency, information flow and performance.
  • In cases where verification is not feasible, contracts provide information that may be used to guide and automate testing of the SOAs and of the individual services.

5. Summary and Challenges

  • This position paper calls for research to ensure safety and QoS in SOA applications.
  • The authors advocate for a contract-based D4V approach to building SOAs with strong guarantees of safety and QoS. Negotiation of contracts of the constituent services provides the composite system with certain safety guarantees by construction, thus enabling the analysis of other properties at a higher level of abstraction.
  • The authors paper focuses on web-based SOA applications; however, the approach may be also applied to other applications that make use of SOAs.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Contracts and Middleware for Safe SOA Applications
Beata Sarna-Starosta, R.E.K. Stirewalt and Laura K. Dillon
Department of Computer Science and Engineering
Michigan State University
East Lansing, MI 48824, USA
{bss,stire,ldillon}@cse.msu.edu
Abstract
This position paper concerns formal methods for devel-
oping safe service-oriented architectures (SOAs) with sup-
port for resource management. We seek an approach to
building such SOAs based on the specification of service re-
quirements as declarative contracts, and the enforcement of
these contracts at the level of the middleware. Using hier-
archical containers that provide the necessary middleware
services, we expect to guarantee certain safety properties
by construction and raise the level of model abstraction for
verifying other necessary properties.
1. Introduction
The service-oriented architecture (SOA) paradigm fa-
cilitates component reuse, interoperability, scalability,
and flexibility in assembling mission-specific applications.
However, SOA-based systems cannot yet support critical
tasks because the underlying technologies fail to provide
sufficient guarantees of safety or quality of service (QoS).
To do so, SOA developers need models, tools, and middle-
ware infrastructures that enable the design, implementation,
and verification of SOA-based applications.
Safety problems arise when services are composed. In-
stances, called processes, of a compositeserviceapplication
may execute for long periods of time and must be robust in
the face of remote-service failures. Long-running processes
could degrade server performance, possibly to the point of
causing the server to deny service to its customers. To ad-
dress these issues, the developer must typically augment an
otherwise simple interaction protocol with logic that, e.g.,
monitors the time spent waiting for a response and that trig-
gers some form of remediation when too much time has
elapsed. Flaws in these protocols can lead to safety vio-
lations and may be exploited by attackers.
To develop safe SOAs requires the ability to design
and package services as components, to specify composi-
tions, and to reason about global safety properties and QoS.
Herein lies the dilemma: Safety and QoS are complex non-
functional concerns, whose effects are global and thus dif-
ficult to verify. In prior work, we developed an approach,
called Szumo [2, 16], to building systems with strong guar-
antees relating to synchronization of concurrent threads—a
similarly global and cross-cutting non-functional concern.
Many of the safety issues that confront the developer of a
composite service bear a striking resemblance to those ad-
dressed by Szumo. This paper describes these safety issues
by way of a concrete example and argues for the use of a
Szumo-inspired solution to address them.
In Szumo, design and implementation of concurrency is
divided between the developer and middleware. In lieu of
writing low-level synchronization code, developers declare
synchronization contracts, which are explicit and which are
dynamically negotiated at run time by a middleware. In ad-
dition to raising the level of abstraction in development,
the use of such contract-enabled middleware relegates a
class of assurance obligations to the middleware, thereby
enabling a larger class of obligations to be discharged us-
ing abstract (and thus more compact) models. The use of
contracts and middleware in this capacity is an example of
design for verification (D4V) [10, 6, 11], a general approach
to dealing with complexity in which the developerconcedes
some degree of design freedom in order to enable efficient
verification of system properties with strong guarantees. In
the sequel, we postulate that a similar approach should en-
able the development of safe SOAs. A key insight is the
use of hierarchical containers, which build on the theory of
connector wrappers [15] and our prior work in implement-
ing connector wrappers [14]. The remainder of the paper
fleshes out these ideas in more detail.
2. Problem Description
SOAs must ensure safety while guaranteeing a level of
service necessary to support clients, be they human users
or other (composite) services. By safety, we mean that in-

tegrity should not be compromised as a side-effect of autho-
rized use; whereas by level of service, we mean to include
issues of usability, availability, and QoS. Services com-
municate with each other by sending and receiving asyn-
chronous messages, and service interactions often involve
complex protocols of message exchange. The protocols de-
scribe communication among multiple services, possibly
running on different servers, and may involve operations
on remote servers’ resources. Furthermore, it is possible
that several constituent services running concurrently per-
form operations on different resources as parts of a single
transaction. To properly implement a distributed transac-
tion across multiple constituent services requires elaborate
protocols of message exchange among the constituents. If
the constituent services are developed in an ad hoc manner,
subtle implementation flaws could result in safety problems
and degraded levels of service.
2.1. An example SOA
Consider a very simple web-based SOA application that
allows customers to make on-line arrangements for flights
with one specific airline (say, Delta) and accommodations
with one specific hotel network (say, Hilton). This Trip-
Manager SOA handles customers’ requests by contacting
two component web services, DeltaService and HiltonSer-
vice, responsible for finding, respectively, flights and ac-
commodations that satisfy the customers’ travel constraints.
Given a request to arrange only a flight or an accommoda-
tion, TripManager forwards the request, along with the cus-
tomer’s constraints, to the respective vendor service. The
service processes the request, and returns to TripManager
with a set of results including the flight or lodging options
meeting the customer’s requirements and, possibly, alter-
native options “close” to meeting these requirements. The
TripManager forwards the results to the customer who then
may choose one.
If no flight/accommodationis selected, the transaction is
aborted, either by an explicit termination of TripManager
by the customer, or by TripManagers time-out in case the
customer abandons the process. If the customer does select
a flight/accommodation,TripManager forwards the relevant
information back to the appropriate vendor service, which
finalizes the transaction. The transaction finalization pro-
ceeds according to a two-phase protocol. In the first phase,
TripManager notifies DeltaService (HiltonService) that it
intends to commit to the flight (hotel room) selected by the
customer, and waits for an acknowledgment from the ven-
dor service, confirming that the requested resource is avail-
able. If DeltaService (HiltonService) confirms the request,
the resource in question is provisionally allocated to the re-
questing TripManager service. In the second phase, Trip-
Manager sends to the vendor service a notification of com-
mitment. The vendor service then allocates the resource to
the customer (charging their credit card accordingly), and
returns to TripManager with a final acknowledgment.
Whether or not the customer decides to purchase the re-
quested flight or accommodation, processing the request
involves asynchronous message exchange between the in-
volved services. Furthermore, TripManager must fol-
low interaction protocols established with DeltaService and
HiltonService, so that the flight or lodging option initially
reported as available is indeed available after being selected
by the customer.
This scenario is additionally complicated when the re-
quest involves arrangements for both flight and accommo-
dation, as TripManager must then ensure consistency be-
tween the results returned by DeltaService and HiltonSer-
vice. For example, suppose a customer selects a combina-
tion of flight and accommodation that suits her needs. The
TripManager cannot just forward the selected flight infor-
mation to DeltaService and the selected accommodation in-
formation to HiltonService with instructions to finalize, be-
cause one might succeed and the other might fail (for in-
stance, a vendor’s server might crash). The difficulty lies
in ensuring that these transactions are processed atomically,
that is, either neither transaction or both transactions final-
ize while maintaining an acceptable level of service. The
customer should not wait too long to learn if the trip ar-
rangements are successfully finalized, but if TripManager
is too hasty in aborting an attempt to finalize a set of op-
tions, it risks not finding good solutions.
2.2. Inter-process coordination issues
Consider two instances of the TripManager SOA,
TripManager
1
and TripManager
2
, each independently pro-
cessing a request to arrange travel and accommodation for
a different customer. Each instance must be careful to book
the hotel and the corresponding flight as an atomic trans-
action. To achieve this, the TripManager will commit a
transaction in two phases, first sending two notifications of
intent—for the selected flight to DeltaService, and for the
selected hotel room to HiltonService, then waiting for ac-
knowledgments from both before starting the second phase,
which finalizes the commit, causing the constituent services
to update their respective databases.
When the two instances of TripManager perform these
sequences of operations concurrently, the following situ-
ation may occur. Assume that both TripManager
1
and
TripManager
2
begin the first phase of their respective com-
mits by sending messages to both DeltaService and Hilton-
Service. Suppose also that the message from TripManager
1
arrives at DeltaService
1
and is acknowledged before the
corresponding message from TripManager
2
arrives at
DeltaService
2
, and that the message from TripManager
2

DB
Delta
DB
Hilton
FlightFinder
1
RoomFinder
1
. . .
. . .
. . . . . .
FlightFinder
2
RoomFinder
2
. . .
. . . . . .
DeltaService
1
HiltonService
1
DeltaService
2
HiltonService
2
TripManager
2
TripManager
1
Figure 1. Concurrent operation of two TripManager processes
arrives at HiltonService
2
and is acknowledged before
the corresponding message from TripManager
1
arrives at
HiltonService
1
. At this point neither of the two TripMan-
ager processes may finalize and must re-attempt, which
could cause the same scenario to repeat until the TripMan-
ager processes time out.
The problems of service coordination are exacerbated in
a more realistic scenario, in which the TripManager service
can make travel and accommodation arrangements with
multiple vendors. To facilitate this capability, TripManager
might coordinate two subordinate services, FlightFinder
and RoomFinder, which serve as intermediaries, each com-
municating with the individual hotel and airlines services.
This situation is illustrated in Figure 1. To properly handle
this case, the commit initiated by TripManager will need to
compose hierarchically.
2.3. Intra-process coordination issues
In addition to protocol flaws among multiple interacting
services, a single service could exhibit safety problems if it
is multi-threaded, and the concurrent threads operate over
shared data without proper synchronization. In the context
of web services, concurrency is realized by means of a flow
construct provided by WS-BPEL [1]. Each of the concur-
rently operating flows may read and modify shared vari-
ables. For instance, to improve its performance, an SOA
may deploy separate flows—each responsible for interact-
ing with a different component service—and embed logic
to compensate for those components that do not respond in
a reasonable time or do not produce acceptable results. With
distribution and the need to synchronize come the kinds of
complexity that lead to safety problems.
For example, given a customer’s request to find a flight
to a specific destination, on a specific date and within a
specific price range, TripManager forwards this request to
FlightFinder. The FlightFinder service may then delegate
a primary flow to look for the flights to that destination
exactly meeting the customer’s constraints, and auxiliary
flows to look for the options where only the time or price
constraint is satisfied in case both constraints cannot be met.
Each flow writes its results to a separate variable, and after
all flows complete execution (or their execution exceeds al-
lowed time and is terminated), the best results are copied to
a shared buffer storing the service’s output. The flows must
be synchronized to prevent races on the shared buffer and to
ensure that the best solution over all solutions computed by
the flows is among those returned by the service.
In addition to the issues of flow-level parallelism, there
is also the issue of when to collect the resources allocated to
a process, especially if the threads allocated to this process
are either mutually blocked or waiting on a message from
a remote service that has crashed. Continuing with our ex-
ample, after FlightFinder receives all results supplied by
its provider services within an acceptable time frame, these
results should be returned to TripManager, and all the re-
sources allocated to FlightFinder (including the resources
for the flows which did not complete their execution within
that time frame) should be collected.

3. Research Directions
We see parallels between many of the safety issues that
confront the developer of composite services and those ad-
dressed by Szumo, our approach to designing and analyzing
systems for properties involving the synchronizationof con-
current threads[2, 16]. In Szumo, the tasks ofsystem design
and implementation are divided between the developer and
the middleware. The developer enhances the specification
of the system objects with declarative contracts which de-
scribe the objects’ requirements for exclusive resource ac-
cess. At run time, the middleware first composes and then
negotiates these local contracts to ensure that the exclusive
access requirements are satisfied globally, i.e., at the system
level.
We believe this idea of contract-enabled middleware
could be applied in the context of SOAs, with contain-
ers playing the role of the middleware (Section 3.1). Our
Szumo middleware could be promoted into a flow con-
tainer, with which to synchronize the interaction of concur-
rent flows within a given service (Section 3.2). In addition,
we believetheessential ideas could be extended to automate
the coordination of services that participate in hierarchical,
atomic transactions. In this case, the developer of a com-
posite service would specify a contract that declares how
the service will need to atomically commit operations with
its suppliers. These contracts would then be negotiated by
means of inter-process containers, thereby alleviating the
service developer from having to code up this tedious and
error-prone logic (Section 3.3).
3.1. Containers
A container is an entity that encapsulates a software
component from its environment—all interaction with the
component from the outside is routed through the container,
which may add new capabilities and enforce safety con-
straints by intercepting and issuing messages to and from
the component. We believe that contract-aware containers
can automate the implementation of complex service inter-
action protocols and therebydramatically simplify the addi-
tion of reliability enhancements, such as failsafes, bounded
retry, and failover, by developers.
We envision two types of containers—flow and inter-
process containers—that could help ameliorate the safety
and level of service issues in the context of SOAs. Figure 2
shows an example of a container-enhanced SOA-based sys-
tem. Here, S
1
and S
2
represent the servers that are run-
ning web service processes. P
1
, P
2
, and P
3
are instances
of three different web services executing on S
1
, whereas
P
4
and P
0
4
are two instances of the same service executing
on S
2
. Each process has one or more flows, represented as
white squares. The arrows connect the constituents of two
P
4
S
1
P
2
P
1
P
3
S
2
P’
4
Figure 2. Container-enhanced SOA
different composite processes—one comprising P
1
, P
3
and
P
0
4
, and the other comprising P
2
and P
4
—running across the
two servers. The flow and inter-process containers are de-
picted as darkly- and lightly-shaded boxesdrawn within and
around the component processes, respectively.
3.2. Flow container
To address the problems of concurrency within a sin-
gle web service process, a flow container would encompass
the flows of an individual process and govern the execu-
tion of these flows based on the satisfaction of programmer-
supplied synchronization contracts. The container would
synchronize concurrent process flows attempting to access
shared resources, and automate the negotiation of these
flows for exclusive resource access. Flow containers would
provideflows with certain safety guarantees, including free-
dom from simple races among accesses to shared variables
by multiple concurrent flows.
Figure 2 depicts the flow containers as boxes with dark
shading, surrounding the flows within each process. The
WS-BPEL specification provides for a notion of containers
to hold shared resources [1]. There is also related work on
process containers for web services, but the synchronization
aspects of their behavior are left open [7].
3.3. Inter-process container
An inter-process container could allow multiple concur-
rent processes to safely commit atomic transactions involv-
ing multiple resources.We envision such a container encom-
passing all processes running on a given server and gov-
erning their interaction with other processes by negotiating
contracts between a client and its suppliers. Figure 2 de-
picts inter-process containers as boxes with light shading
surrounding the processes within a server.
In our running example, to ensure atomic processing of
travel and accommodation requests, the TripManager ser-
vice might declare a contract that defines conditions under

which it needs to performatomic commits involving the air-
line and hotel services. Following Szumo syntax, such a
contract might be expressed in the form:
finalizing = FlightFinder RoomFinder
In English, this states that when the TripManager service is
in a finalizing state (i.e., when finalizing is true), it needs
to commit transactions involving the processes bound to
FlightFinder and RoomFinder. Consequently, when cod-
ing up the TripManager service, the developer would write
code to signal when a transaction should finalize rather than
write the communication code needed to implement Trip-
Managers role in the commit protocol. At run time, the
container would enforce that execution of code that signals
entry into a finalizing state succeeds if the container is able
to successfully execute the two-phase commit protocol with
the constituent services. Otherwise, the container could ei-
ther block execution of the statement until the time when it
is able to successfully execute the commit or fail. We en-
vision a number of different policies being applicable here,
including the use of bounded retry and failover.
If contracts, such as these, were explicitly declared and
available at run time, an inter-process container could use
them to automate the customization of a commit protocol
with the subordinate services, thereby alleviating the devel-
oper of TripManager from this design burden. Moreover, it
is possible that the contracts could be used to inform proto-
cols that attempt to avoid the repeated service denial (due to
failure to commit) presented earlier. This example is remi-
niscent of the behavior of two threads negotiating for exclu-
sive access to the same sets of resources while attempting
to avoid or recover from deadlock. The strategies used in
these cases require protocols that cannot be implemented
by a service in isolation.
3.4. Design for verification
In Szumo, the negotiation of contracts guarantees free-
dom from a large class of typical concurrency errors, in-
cluding simple data races and a large class of deadlocks and
starvation. These guarantees eliminate the need to analyze
systems with regard to such errors, and enable construction
of abstract models that facilitate reasoning about other prop-
erties. This general approach—conceding some degree of
freedom during design in order to enable verification—has
been called design for verification (D4V) [10, 6].
The vision outlined in this position paper suggests an
approach to D4V for SOAs. Containers at multiple levels
would ensure certain guarantees regarding concurrency, in-
formation flow and performance. These guarantees enable
assumptions that systems assembled from services that ex-
ecute within the containers will (or will not) exhibit certain
behaviors, eliminating the need to explicitly verify related
properties. We believethese guaranteeswill also permit ver-
ification of application-specific properties of SOAs based
on abstract (and thus compact) behavioralmodels,whichfa-
cilitate simpler and more efficient analyses. In cases where
verification is not feasible, contracts provide information
that may be used to guide and automate testing of the SOAs
and of the individual services.
4. Related Work
The ideas discussed in this paper are most closely related
to two research areas: modeling transactions for compos-
ite services and using contracts to express service require-
ments.
Transaction design has been studied extensively in the
context of database systems [3, 5]. The long-running, asyn-
chronous nature of SOA application processes exacerbates
problems of multidatabase transaction management. Thus,
the traditional notion of transactions has been augmented
to address problems of SOAs [18, 17, 8, 12, 4]. Much of
this work focuses on seamless multidatabase operations in
scenarios where the collection of databases being accessed
changes dynamically during execution. Proposed solutions
generally require a developer to define services using new,
special-purpose formalisms, specify transactional require-
ments (e.g., concurrency or QoS) at a low level, or pro-
vide global scheduling schemes for service components. In
contrast, we propose that the developer should express lo-
cal transactional requirements at a high level, in a manner
that integrates well with existing service specification lan-
guages, and that the data processing algorithms needed to
enforce the contracts be encapsulated in middleware. The
example in this paper illustrates only transactional require-
ments, but we believe this contract-based middleware ap-
proach can be extended to also support other important as-
pects of service execution, such as security and some QoS
requirements.
Contracts have been used to represent service-level
agreements (SLAs)—mutual QoS responsibilities among
collaborating services. Existing SLA specification lan-
guages (e.g., WSLA [9], SLAng [13]) enable developers
to formalize these agreements, which may then be enforced
automatically by appropriately extending network routers,
database management systems, middleware, and/or web
servers. SLAs do not typically express transactional re-
quirements of the type illustrated in our example. Ideas
from SLA specification languages, however, may prove
useful in suggesting how to extend contracts to express var-
ious QoS requirements.

Citations
More filters
Journal ArticleDOI
TL;DR: The model analyzes the structure of Internet-scale software and establishes an evaluation system of dependability for Internet- scale software including static metrics, dynamic metrics, prior metrics and correction metrics and integrates subjective and objective factors which impact on system quality.

6 citations


Cites background from "Contracts and Middleware for Safe S..."

  • ...This inference step can be straightforward if values for all of the other variables in the network, all metrics of an entity and dependability of its antecedent entities, are known exactly....

    [...]

Dissertation
01 Jan 2011
TL;DR: Overall, this thesis demonstrates that attestation can be made significantly more practical through the described new techniques, and may become a trustworthy and reliable assurance mechanism for web services.
Abstract: Remote attestation is a promising mechanism for assurance of distributed systems. It allows users to identify the software running on a remote system before trusting it with an important task. This functionality is arriving at exactly the right time as security-critical systems, such as healthcare and financial services, are increasingly being hosted online. However, attestation has limitations and has been criticized for being impractical. Too much effort is required for too little reward: a large, rapidly-changing list of software must be maintained by users, who then have insufficient information to make a trust decision. As a result attestation is rarely used today. This thesis evaluates attestation in a service-oriented context to determine whether it can be made practical for assurance of servers rather than client machines. There are reasons to expect that it can: servers run fewer programs and the overhead of integrity reporting is more appropriate on a server which may be protecting important assets. However, a literature review and new experiments show that problems remain, many stemming from the large trusted computing base as well as the lack of information linking software identity to expected behaviour. Three novel solutions are proposed. Web service middleware is restructured to minimize the software running at the endpoint, thus lowering the effort for the relying party. A key advantage of the proposed two-tier structure is that strong integrity guarantees can be made without loss of conformance with service standards. Secondly, a program modelling approach is investigated to further automate the attestation and verification process and add more information about system behaviour. Several sets of programs are modelled, including the bootloader, a web service and a menu-based shell. Finally, service behaviour is attested through source code properties established during compilation. This provides a trustworthy and verifiable connection between the identity of the software on a service platform and its expected runtime behaviour. This approach is applicable to any programming language and verification method, and has the advantage of not requiring a runtime monitor. These contributions are evaluated using an example e-voting service to show the level of assurance attestation can provide. Overall, this thesis demonstrates that attestation can be made significantly more practical through the described new techniques. Although some problem remain, with further improvements to operating systems and better software engineering methods, attestation may become a trustworthy and reliable assurance mechanism for web services.

6 citations


Cites background from "Contracts and Middleware for Safe S..."

  • ...[187] present the idea of using declarative contracts to specify services and then use these to guarantee certain safety properties....

    [...]

Proceedings ArticleDOI
Guannan Si1, Jufeng Yang1, Jing Xu1, Shuo Wen1, Wei Tian1 
16 Jul 2012
TL;DR: The model analyzes the structure of Internet-scale software and establishes an evaluation system of dependability for Internet- scale software including static metrics, dynamic metrics, prior metrics and correction metrics and integrates subjective and objective factors which impact on system quality.
Abstract: Internet-scale software becomes an important mode of constructing software systems with the development of internet. Open, dynamic and uncontrollable Internet environment makes dependability evaluation of Internet-scale software very important. It is lack of a dependability evaluation model that analyzes system architecture from the most foundational elements and integrate aspects that impacts on the system, such as the technical, organizational, decisional and human aspects. This paper proposes an evaluation model of dependability for Internet-scale software on the basis of Bayesian Networks. The model analyzes the structure of Internet-scale software and establishes an evaluation system of dependability for Internet-scale software including static metrics, dynamic metrics, prior metrics and correction metrics. It integrates subjective and objective factors which impact on system quality. In this paper, we build Bayesian Network according to the structure analysis and refer to a bottom-up method that use Bayesian reasoning to analyses and calculate entity dependability and integration dependability layer by layer. A unified dependability of the whole system is worked out and is corrected by objective data. The analysis of experiment in a real system proves that the model in this paper is capable of evaluating the dependability of Internet-scale software clearly and objectively. Moreover, it offers effective help to the design, development, deployment and assessment of Internet-scale software.

5 citations


Cites methods from "Contracts and Middleware for Safe S..."

  • ...For Internet-scale software, most studies, such as [13][14][15][16][17], focus on validation and selection web services in order to assure quality of the system....

    [...]

Book ChapterDOI
TL;DR: This work proposes the use of Unified Modeling Language (UML) sequence diagrams as a means for analysis of BPEL process consistency and demonstrates the technique with two examples.
Abstract: An increasing number of software applications and business processes are relying upon the use of web services to achieve their requirements. This is due in part to the use of standardized composition languages like the Business Process Execution Language (BPEL). BPEL allows the process designer to compose a procedural workflow from an arbitrary number of available web services and supplemental “programming-like” activities (e.g., assigning values to variables). Such composition languages naturally bring concerns of reliability, consistency, and durability, let alone safety and security. Thus, there is a need for formal specification and analysis of BPEL compositions for high assurance satisfaction. We propose the use of Unified Modeling Language (UML) sequence diagrams as a means for analysis of BPEL process consistency and demonstrate our technique with two examples.

1 citations


Cites background from "Contracts and Middleware for Safe S..."

  • ...Sarna-Starosta et al. [ 3 ] propose a means of achieving safe service-oriented architectures through the specification of service requirements using declarative contracts....

    [...]

Proceedings Article
01 Jan 2004
TL;DR: This paper reports the experience elaborating connectors and connector wrappers as instantiations of a feature-oriented middleware framework called Theseus, which supports the design of asynchronous distributed applications and suggests techniques for designing middleware frameworks and composition tools that more explicitly reify and expose the features specified by connectors and connectors wrappers.
Abstract: Connectors and connector wrappers explicitly specify the protocol of interaction among components and afford the reusable application of extra-functional behaviors, such as reliability policies. Ideally, these specifications can be used for more than just modeling and analysis. We are investigating how to use them in the design and implementation of the middleware substrate of a distributed system. This paper reports our experience elaborating connectors and connector wrappers as instantiations of a feature-oriented middleware framework called Theseus, which supports the design of asynchronous distributed applications. The results of this case study indicate that the relationship between specification features and implementation-level features is not one-to-one and that some specification features have complex, often subtle, manifestations in Theseus’ design. This work reports the lessons learned designing these strategies and suggests techniques for designing middleware frameworks and composition tools that more explicitly reify and expose the features specified by connectors and connector wrappers.

1 citations

References
More filters
Book
01 Feb 1987
TL;DR: In this article, the design and implementation of concurrency control and recovery mechanisms for transaction management in centralized and distributed database systems is described. But this can lead to interference between queries and updates.
Abstract: This book is an introduction to the design and implementation of concurrency control and recovery mechanisms for transaction management in centralized and distributed database systems. Concurrency control and recovery have become increasingly important as businesses rely more and more heavily on their on-line data processing activities. For high performance, the system must maximize concurrency by multiprogramming transactions. But this can lead to interference between queries and updates, which concurrency control mechanisms must avoid. In addition, a satisfactory recovery system is necessary to ensure that inevitable transaction and database system failures do not corrupt the database.

3,891 citations

Journal ArticleDOI
01 Oct 1992
TL;DR: It is argued that the multidatabase research will become increasingly important in the coming years and basic research issues in multid atabase transaction management are outlined, followed by a discussion of open problems and practical implications.
Abstract: A multidatabase system (MDBS) is a facility that allows users access to data located in multiple autonomous database management systems (DBMSs). In such a system, global transactions are executed under the control of the MDBS. Independently, local transactions are executed under the control of the local DBMSs. Each local DBMS integrated by the MDBS may employ a different transaction management scheme. In addition, each local DBMS has complete control over all transactions (global and local) executing at its site, including the ability to abort at any point any of the transactions executing at its site. Typically, no design or internal DBMS structure changes are allowed in order to accommodate the MDBS. Furthermore, the local DBMSs may not be aware of each other and, as a consequence, cannot coordinate their actions. Thus, traditional techniques for ensuring transaction atomicity and consistency in homogeneous distributed database systems may not be appropriate for an MDBS environment. The objective of this article is to provide a brief review of the most current work in the area of multidatabase transaction management. We first define the problem and argue that the multidatabase research will become increasingly important in the coming years. We then outline basic research issues in multidatabase transaction management and review recent results in the area. We conclude with a discussion of open problems and practical implications of this research.

577 citations

Proceedings ArticleDOI
23 May 2004
TL;DR: This work uses the semantics of SLAng to define a notion of SLA compatibility, and an extension to UML that enables the modelling of service situations as a precursor to analysis, implementation and provisioning activities.
Abstract: SLAng is an XML language for defining service level agreements, the part of a contract between the client and provider of an Internet service that describes the quality attributes that the service is required to possess. We define the semantics of SLAng precisely by modelling the syntax of the language in UML, then relating the language model to a model that describes the structure and behaviour of services. The presence of SLAng elements imposes behavioural constraints on service elements, and the precise definition of these constraints using OCL constitutes the semantic description of the language. We use the semantics to define a notion of SLA compatibility, and an extension to UML that enables the modelling of service situations as a precursor to analysis, implementation and provisioning activities.

201 citations

Proceedings ArticleDOI
03 May 2003
TL;DR: This work presents a means of characterizing connector wrappers as protocol transformations, modularizing them, and reasoning about their properties, drawn from commonly practiced dependability enhancing techniques.
Abstract: Increasingly systems are composed of parts: software components, and the interaction mechanisms (connectors) that enable them to communicate. When assembling systems front independently developed and potentially mismatched parts, wrappers may be used to overcome mismatch as well as to remedy extra-functional deficiencies. Unfortunately the current practice of wrapper creation and use is ad hoc, resulting in artifacts that are often hard to reuse or compose, and whose impact is difficult to analyze. What is needed is a more principled basis for creating, understanding, and applying wrappers. Focusing on the class of connector wrappers (wrappers that address issues related to communication and compatibility), we present a means of characterizing connector wrappers as protocol transformations, modularizing them, and reasoning about their properties. Examples are drawn from commonly practiced dependability enhancing techniques.

129 citations


"Contracts and Middleware for Safe S..." refers background in this paper

  • ...In lieu of writing low-level synchronization code, developers declare synchronization contracts, which are explicit and which are dynamically negotiated at run time by a middleware....

    [...]

Frequently Asked Questions (18)
Q1. What are the contributions in "Contracts and middleware for safe soa applications" ?

This position paper concerns formal methods for developing safe service-oriented architectures ( SOAs ) with support for resource management. 

The authors believe that contract-aware containers can automate the implementation of complex service interaction protocols and thereby dramatically simplify the addition of reliability enhancements, such as failsafes, bounded retry, and failover, by developers. 

In addition to raising the level of abstraction in development, the use of such contract-enabled middleware relegates a class of assurance obligations to the middleware, thereby enabling a larger class of obligations to be discharged using abstract (and thus more compact) models. 

The flow and inter-process containers are depicted as darkly- and lightly-shaded boxes drawn within and around the component processes, respectively. 

By safety, the authors mean that in-tegrity should not be compromised as a side-effect of authorized use; whereas by level of service, the authors mean to include issues of usability, availability, and QoS. 

The SOA paradigm plays a significant role in today’s software engineering, with service compositions implementing more and more critical tasks. 

Much of this work focuses on seamless multidatabase operations in scenarios where the collection of databases being accessed changes dynamically during execution. 

To do so, SOA developers need models, tools, and middleware infrastructures that enable the design, implementation, and verification of SOA-based applications. 

called processes, of a composite service application may execute for long periods of time and must be robust in the face of remote-service failures. 

The ideas discussed in this paper are most closely related to two research areas: modeling transactions for composite services and using contracts to express service requirements. 

To address the problems of concurrency within a single web service process, a flow container would encompass the flows of an individual process and govern the execution of these flows based on the satisfaction of programmersupplied synchronization contracts. 

Existing SLA specification languages (e.g., WSLA [9], SLAng [13]) enable developers to formalize these agreements, which may then be enforced automatically by appropriately extending network routers, database management systems, middleware, and/or web servers. 

An inter-process container could allow multiple concurrent processes to safely commit atomic transactions involving multiple resources. 

In addition to the issues of flow-level parallelism, there is also the issue of when to collect the resources allocated to a process, especially if the threads allocated to this process are either mutually blocked or waiting on a message from a remote service that has crashed. 

The example in this paper illustrates only transactional requirements, but the authors believe this contract-based middleware approach can be extended to also support other important aspects of service execution, such as security and some QoS requirements. 

P2, and P3 are instances of three different web services executing on S1, whereas P4 and P′4 are two instances of the same service executing on S2. 

The difficulty lies in ensuring that these transactions are processed atomically, that is, either neither transaction or both transactions finalize while maintaining an acceptable level of service. 

The authors believe this idea of contract-enabled middleware could be applied in the context of SOAs, with containers playing the role of the middleware (Section 3.1).