Contracts and Middleware for Safe SOA Applications
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
Citations
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....
[...]
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....
[...]
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....
[...]
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....
[...]
1 citations
References
3,891 citations
577 citations
201 citations
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....
[...]
Related Papers (5)
Frequently Asked Questions (18)
Q2. What is the definition of a contract-aware container?
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.
Q3. What is the purpose of contract-enabled middleware?
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.
Q4. What are the two types of containers?
The flow and inter-process containers are depicted as darkly- and lightly-shaded boxes drawn within and around the component processes, respectively.
Q5. What does the author mean by safety?
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.
Q6. What is the role of contract-based middleware in SOA?
The SOA paradigm plays a significant role in today’s software engineering, with service compositions implementing more and more critical tasks.
Q7. What is the focus of this work?
Much of this work focuses on seamless multidatabase operations in scenarios where the collection of databases being accessed changes dynamically during execution.
Q8. What does the author say about the need for SOA?
To do so, SOA developers need models, tools, and middleware infrastructures that enable the design, implementation, and verification of SOA-based applications.
Q9. What are the main safety issues that arise when services are composed?
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.
Q10. What are the two research areas discussed in this paper?
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.
Q11. What is the definition of a 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.
Q12. What are the common examples of contract-based middleware?
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.
Q13. What is the definition of an inter-process container?
An inter-process container could allow multiple concurrent processes to safely commit atomic transactions involving multiple resources.
Q14. What is the main issue of flow-level parallelism?
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.
Q15. What is the purpose of this paper?
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.
Q16. What are the three instances of the same service executing on S1?
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.
Q17. What is the difficulty of ensuring that these transactions are processed atomically?
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.
Q18. What is the main idea of contract-enabled 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).