Literature review service oriented architecture
Taub, K. Hart, J. Mcfarland, and T. Files 4.
Moving to a Service-Oriented Architecture
Name Size See more details All versions This version Views 15 15 Downloads 6 6 Data volume Indexed in. Versions Version You can cite all versions by using the DOI This DOI represents all versions, and will always resolve to the latest one. Read more. Preview Download. Data volume. Regarding fault tolerance, the architect has to consider, for example: the availability of variants, the best fault tolerance technique to be used in a certain context, how the system should fail and scenarios involving error detection and handling failure modes , the categories of faults to be tolerated fault latency , assumptions about the environment and components fault assumptions , etc.
The software architect developing a fault-tolerant SOA application should consider three major design issues when using design diversity: i selection of variants, since the variants need to be sufficiently diverse and able to tolerate software faults; ii selection of an adjudicator to determine the acceptability of the results obtained from the variants Daniels et al. For each of these design issues, the architect has to choose the specific fault tolerance technique to be used. Guidelines to support this task should also take into account implementations that realize different sets of quality requirements e.
The design decisions are also affected by characteristics of the functionality e. Variants can be executed either sequentially or in parallel and variant outputs can be adjudicated by adopting different voting and acceptance algorithms Daniels et al. When designing a system, the architect may reuse and adapt existing solutions. Nevertheless, existing work regarding fault-tolerant service compositions is written from different viewpoints and relies on different technical backgrounds. As a result, it is hard to compare them and to choose an appropriate solution to be applied. Thus, it is unclear the extent to which existing solutions support the above mentioned design issues related to software fault tolerance based on design diversity.
- essays for arnold schwarzenegger;
- essay on to my dear and loving husband.
- Service-oriented architecture.
- fun things to write an essay about!
- ideas for writing creative stories;
- write persuasive essays.
- An Overview of Service-Oriented Architecture - ePrints Soton!
In this sense, the contribution of this work is twofold: i the proposal of guidelines for supporting the design of fault-tolerant SOA based on a taxonomy for fault tolerance techniques and ii a systematic review of existing solutions for designing FT-compositions using design diversity. Results from reviewed solutions are presented to support reuse of existing solutions. The central purpose, which unifies the two contributions, is to support the architect in the design of fault-tolerant compositions.
The proposed guidelines utilize an existing taxonomy for fault-tolerant systems Pullum [ ] in order to guide architects in their design decisions. Guidelines support different decisions regarding the design of FT-SOA: first, the guidelines address different failure modes. This enables the architect to plan which faults are to be tolerated.
Subsequently, the guidelines support the architect in modelling the faults and the behavioural pattern of how these faults should be tolerated. This decision influences the choice of the adjudicator type. For example, intermittent faults can be detected and tolerated utilizing design diversity and majority election design techniques. Also, the number of variants will be directly affected by the number of concurrent failures to be tolerated.
The architect can assess the number of variants that are required to achieve the desired level of reliability. This design decision is also affected by the availability of resources as this will place limits on the number of variants that are feasible. The systematic review compares characteristics of existing solutions in order to support architectural-level decisions regarding software fault tolerance and SOA quality requirements.
We followed the literature review method proposed by Kitchenham [ ]. We first investigated design issues related to the selection and the execution of variants, as well as the adjudication of their outputs.
Secondly, we investigated which SOA-specific requirements were addressed by the existing solutions. The proposed guidelines address the three major design issues and their different implementation solutions.
Service-oriented architecture - Wikipedia
Finally, we report our main findings and identify gaps in current approaches in order to suggest opportunities for research on reliable SOA-based applications. The remainder of the paper is structured as follows. Section 5 presents important concepts related to SOA and software fault-tolerance. These concepts are utilized in the taxonomy for fault-tolerant SOA.
Section 5 presents the taxonomy combining elements from the fault-tolerance domain with elements from the SOA domain. Section 5 presents the results and discussion. It also presents results from the systematic literature review. Section 5 discusses the threats and the validity of the review. Section 5 presents related work, which also considers related literature reviews of software fault tolerance techniques. Finally, Section 5 presents some concluding remarks and directions for continuing work.
Many software systems are being implemented following the Service-Oriented Architecture SOA approach with the aim of achieving higher levels of interoperability Huhns and Singh [ ]; Papazoglou et al. SOA is focused on creating a design style, technology, and process framework that allow enterprises to develop, interconnect, and maintain enterprise applications and services efficiently and cost-effectively Huhns and Singh [ ].
A service in SOA is an exposed piece of functionality with three essential properties.
Ii literature review a service oriented architecture
Firstly, a service is self-contained in that it maintains its own state. Secondly, a service is platform-independent, implying that the interface contract to the service is limited to platform-independent assertions. Lastly, a service can be dynamically located, invoked and re combined Huhns and Singh [ ]; Papazoglou et al. Therefore, multiple services running over heterogeneous systems may then interact and be used as building blocks for new applications Papazoglou et al.
As previously mentioned, software architects can achieve the benefits of both fault-tolerant and service-oriented architectures by structuring variants as FT-compositions.
Papazoglou et al. We use this list to classify elements of our primary studies as described below:. Interoperability Capabilities : Whenever a service composition provides its functionalities by means of interfaces that are platform-independent, a client from any communication device using any computational platform, operating system, or programming language can reuse the solution. That is, the service composition aggregates services provided by other service providers into a distinct value-added service and may itself act as service provider Papazoglou et al.
Autonomic composition of services: service compositions should equip themselves with adaptive service capabilities so that they can continually morph themselves to respond to environmental demands and changes without compromising operational and financial efficiencies Papazoglou and Heuvel [ ]. Examples of support for autonomic composition of services include automatically discovering new partners to interact with; automatically selecting partners and options that would, for example, maximize benefits and reduce costs Papazoglou et al.
QoS-aware service compositions: To be successful service compositions need to be QoS-aware. For example, services should be composed in accordance with an extensible set of Quality-of-Service QoS properties and high-level policies e. QoS encompasses important non-functional service requirements, such as performance metrics response time, for instance , security attributes, transactional integrity, reliability, scalability, and availability Papazoglou and Heuvel [ ]; Papazoglou et al.
Business-driven automated compositions: a service composition at the business-level should pose the requirements, possibly from different stakeholders with conflicting needs, and the boundaries for the automatic composition at the system level. While the service composition at the business level should be supported by user-centered and highly interactive techniques, system level service compositions should be fully automated and hidden to the end users. System level compositions should be QoS-aware, should be generated and monitored automatically, and should also be based on autonomic computing principles Papazoglou and Heuvel [ ]; Papazoglou et al.
A fault is the identified or hypothesized cause of an error Avizienis et al. An error is part of the system state that is liable to lead to a failure Avizienis et al. A failure, in turn, occurs when the service delivered by the system deviates from the specified service Avizienis et al.
So, with software fault tolerance, we want to prevent failures by tolerating faults whose occurrences are known when errors are detected Lee and Anderson [ ]. Software faults are also called design faults or bugs Pullum [ ]. Software faults cannot be tolerated by simple replication of identical software components since the same mistake will exist in each copy of the components Lee and Anderson [ ].
"Knowledge Worth Spreading"
A solution to this problem is to introduce diversity into the software replicas Lee and Anderson [ ]; Lyu [ ]; Wilfredo [ ]. Design diversity is the provision of functionally-equivalent software components, called variants, through different designs and implementations. Design diversity begins with an initial requirements specification. Figure 1 illustrates the basic design diversity concept.
Inputs are distributed to variants. The variants execute their operations and produce their results, from which a single correct or acceptable result must be derived, if any Pullum [ ]. The mechanism responsible for this task is called an adjudicator.