T-Check for Technologies for Interoperability: Open Grid Services Architecture (OGSA): Part 1

Many current technology approaches exist for building systems that have interoperability requirements. This report investigates Open Grid Services Architecture (OGSA), one of the many technologies for accomplishing interoperability, using the T-Check technique. A T-Check is a simple and cost-efficient way to understand what a technology can and cannot do in a specific context. This report describes a T-Check exploration of the feasibility of using OGSA in the context of data management, finding that OGSA (a) provides data storage and retrieval where the specific implementation of the data store implementation is transparent and (b) allows addition or removal of data stores at runtime without affecting system operation. This report is part one of a two-part investigation; part two will look at OGSA in the context of load distribution

Architecting Service-Oriented Systems

Service orientation is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers such features as standardization, platform independence, well-defined interfaces, and tool support that enables legacy system integration. From a quality attribute point of view, the primary drivers for service orientation adoption are interoperability and modifiability. However, a common misconception is that an architecture that uses a service-oriented approach can achieve these qualities by simply putting together a set of vendor products that provide an infrastructure and then using this infrastructure to expose a set of reusable services to build systems. In reality, there are many architectural decisions that need to be made. An architectural decision that promotes interoperability or modifiability can negatively impact other qualities, such as availability, reliability, security and performance. The goal of this report is to present general guidelines for architecting service-oriented systems, how common service-oriented system components support these principles, and the effect that these principles and their implementation have on system quality attributes.</p

T-Check in Technologies for Interoperability: Web Services and Security—Single Sign-On

A single sign-on (SSO) solution is intended to provide a single authentication point for a set of Web services. The SSO solution for-wards the necessary authentication information to the Web services, which in turn authenticate the end user to legacy systems that implement the Web services' functionality. This technical note presents the results of applying the T-Check approach in an initial investigation of two Web services standards, WS-Security and SAML, to create an SSO solution that works inside a single organization. This approach involves (1) formulating hypotheses about the technology and (2) examining these hypotheses against specific criteria through hands-on experimentation. The outcome of this two-stage approach is that the hypotheses are either fully or partially sustained or refuted. In this report, four hypotheses-based on claims found in experience reports and on vendor Web sites-are examined: (1) it is possible to implement SSO for the two Web services using SAML and WS-Security; (2) it is fairly easy to implement a basic SSO solution; (3) the SSO solution will not have a major impact on the runtime behavior of the system; and (4) the SSO solution can provide the required access control. The first three hypotheses were sustained; it was not necessary to implement the fourth one to list options for adding access control

SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment

Service-oriented architecture (SOA) has become an increasingly popular mechanism for achieving interoperability between systems. Because it has characteristics of loose coupling, published interfaces, and a standard communication model, SOA enables existing legacy systems to expose their functionality as services, presumably without making significant changes to the legacy systems. Migration of legacy systems to service-oriented environments has been achieved within a number of domains-including banking, electronic payment, and development tools-showing that the promise is beginning to be fulfilled. While migration can have significant value, any specific migration requires a concrete analysis of the feasibility, risk, and cost involved. This technical note describes a new release of the Service Migration and Reuse Technique (SMART), which was initially developed in 2005. The Carnegie Mellon Software Engineering Institute (SEI) SMART process helps organizations to make initial decisions about the feasibility of reusing legacy components as services within an SOA environment. SMART considers the specific interactions that will be required by the target SOA environment and any changes that must be made to the legacy components. To achieve this, SMART gathers information about legacy components, the target SOA environment, and candidate services to produce (1) a preliminary analysis of the viability of migrating legacy components to services, (2) an analysis of the migration strategies available, and (3) preliminary estimates of the costs and risks involved in the migration

Cloud Computing at the Tactical Edge

Handheld mobile technology is reaching first responders, disaster-relief workers, and soldiers in the field to aid in various tasks, such as speech and image recognition, natural-language processing, decision making, and mission planning. However, these applications are computation intensive, so it is necessary to consider that (1) mobile devices offer less computational power than conventional desktop or server computers, (2) computation-intensive tasks consume large amounts of battery power, and (3) networks in hostile environments, such as those experienced by first responders and soldiers in the field, are often unreliable, and bandwidth is limited and inconsistent. While there has been considerable research in code offload to the cloud to enhance computation and battery life, most of this work assumes reliable connectivity between the mobile device and the cloud—an invalid assumption in hostile environments. This technical note presents a reference architecture for mobile devices that exploits cloudlets—virtual-machine-based, code-offload elements—that are in single-hop proximity to the mobile devices that they serve. Two implementations of this reference architecture are presented, along with an analysis of architecture tradeoffs.</p

Performance Analysis of WS-Security Mechanisms in SOAP-Based Web Services

Identity management (IdM) solutions in web services environments are often compared on the levels of performance and security they provide. Selecting the appropriate IdM solution for a given system or application often requires making tradeoffs between security and performance, while also considering the system's contextual and environmental requirements and constraints. This paper presents the results of a series of experiments targeted at analyzing the performance impact of adding WS-Security, a common security standard used in IdM frameworks, to SOAP-based web services. The goal of this work is to establish a baseline of performance data that can be used to explore performance/security tradeoffs in environments with complex attributes, such as resource or bandwidth limitations

Testing in Service-Oriented Environments

This report makes recommendations for testing service-oriented architecture (SOA) implementations consisting of infrastructure, services, and end-to-end processes. Testing implementations of SOA infrastructure, services, and end-to-end processing in support of business processes is complex. SOA infrastructure is often composed of multiple, independently constructed commercial products—often from different vendors—that must be carefully configured to interact in an appropriate manner. Services are loosely coupled components which are intended to make minimal assumptions about where, why, and under what environmental conditions they are invoked. Business processes link together multiple services and other systems in support of specific tasks. These services and systems may operate on remote platforms controlled by different organizations and with different SOA infrastructures. Such complications make it difficult to establish appropriate environments for tests, to ensure specific qualities of service, and to keep testing up-to-date with changing configurations of platforms, infrastructure, services, and other components

Results of SEI Line-Funded Exploratory New Starts Projects

<p>The Software Engineering Institute (SEI) annually undertakes several line-funded exploratory new starts (LENS) projects. These projects serve to (1) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (2) support further exploratory work to determine whether there is sufficient value in eventually funding the feasibility study work as an SEI initiative. Projects are chosen based on their potential to mature and/or transition software engineering practices, develop information that will help in deciding whether further work is worth funding, and set new directions for SEI work. This report describes the LENS projects that were conducted during fiscal year 2011 (October 2010 through September 2011).</p

Results of SEI Independent Research and Development Projects (FY 2010)

The Software Engineering Institute (SEI) annually undertakes several independent research and development (IRAD) projects. These projects serve to (1) support feasibility studies investigating whether further work by the SEI would be of potential benefit and (2) support further exploratory work to determine whether there is sufficient value in eventually funding the feasibility study work as an SEI initiative. Projects are chosen based on their potential to mature and/or transition software engineering practices, develop information that will help in deciding whether further work is worth funding, and set new directions for SEI work. This report describes the IRAD projects that were conducted during fiscal year 2010 (October 2009 through September 2010).</p