Defining Architectures for Interoperability
Systems of systems are dynamic entities. Systems are added, modified or removed from the SoS as requirements change. The integration infrastructure changes with advances of technology or needs for different quality of service (QoS) arise.
A system of systems architecture provides a framework for structuring the nodes that compose the system of systems, regardless of their source (commercial-off-the-shelf (COTS), non-developmental items (NDI), custom, legacy, services). It captures the scope of the nodes, and how they will interact within the system of systems. In essence, it is a vehicle for incorporating existing or planned nodes into the SoS, to make decisions, to analyze tradeoffs, to communicate, or ultimately to document the current status of the SoS architecture.
An evolvable architecture is both an architecture that allows the SoS to change and an architecture that changes as needed. Evolvable architectures are essential to achieving the efficient evolution of SoSs. The goal of an evolvable architecture is to isolate and insulate the SoS from the effects of change.
State of the Practice
Fundamentally, an evolvable architecture is a proactive mitigation against the risks of constant change. Evolvable architectures require up-front engineering; evolvability is very difficult and very expensive to add later. To achieve one, skilled people with sufficient time and resources to create, validate, control, and maintain it are required.
A system architect must have excellent current and predictive knowledge of the domain in which the SoS operates, integration technologies, and systems participating in the SoS, and must factor them into the definition and construction of the architecture. Obtaining detailed knowledge about the participating systems is often difficult often due to the lack of visibility of the internals of the nodes. The challenge for the architect is then to identify the changes that may occur and how likely they are to occur.
There are several mechanisms used by architects to to accommodate future change with minimal impact. Some of the most common are:
- Specialized layering: logical groupings of components so that the upper layers of the system are designed with more specialized domain knowledge whereas lower layers are less domain specific
- High modularity: self-contained, understandable components that are optimally scoped and sized for nonfunctional requirements and attributes such as maintainability
- Well-defined interfaces: focus on the essential characteristics of the component and hide the details of a specific node participating in the SoS
- Standard interfaces: industry standard interfaces promote node exchangeability
- Common integration mechanisms: mechanisms used consistently in the system wherever possible, such as inter-process communication, data transfer, and error handling
- What is the mission to be fulfilled by the SoS?
- How does the mission map to the nodes identified in the SoS architecture?
- How likely is that the mission will change?
- Can the SoS handle this change?
- What are the quality of service requirements imposed by the SoS mission?
- What are examples of operational scenarios that need to be satisfied by the SoS? Can the architecture support these scenarios?
- Security vs. Performance: How does the SoS address security requirements for dealing with heterogeneous, remote nodes at the possible expense of reduced performance?
- Functionality vs. QoS: What is the correct granularity for node interfaces? If the node interfaces are too coarse-grained, clients will receive more data than they need. If node interfaces are too fine-grained, clients will have to make multiple trips to the node to get all the data they need.
- Standard vs. Proprietary: Will the use of standard communication mechanisms be enough to satisfy QoS requirements? Will a proprietary communication mechanism prevent nodes from joining the SoS?
- Reduce risk misunderstandings
- Provide critical insight into the SoS's behavior
- Explore critical system attributes
- Validate operational scenarios
- Verify technical viability of the architecture
- Web Services using Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL)
- message-oriented middleware (MOM) such as IBM Websphere MQ, Microsoft Message Queuing (MSMQ)
- publish-subscribe system such as Java Message Service (JMS)
- Common Object Request Broker Architecture (CORBA)
- Jini Network Technology from Sun Microsystems
- directly invoke a service provider.
- use a directory service to find a service provider based on some criteria. The directory service returns the location of the service so the service consumer can invoke the service provider.
- use a service broker to pass on its request to one or more directory services.
- Common payload and protocol: Each service provides an interface that is invoked through a payload format and protocol that is understood by all the potential clients of that service. Payload is the term used by most messaging technologies to refer to the actual data being exchanged.
- Published and discoverable interfaces: Each service has a published and discoverable interface that allows systems to search for services that are best suited for their purposes.
- Loose coupling: Services are connected to other services and clients using standard, dependency-reducing, decoupled message-based methods such as XML document exchanges. As a note, service orientation encourages loose coupling, but does not guarantee it. A loosely coupled architecture is good for systems that do not require near-real-time responses.
- Multiple communication interfaces: Services can implement separately defined communication interfaces. For example, a service could have a Web services adapter, an IIOP (Internet InterORB Protocol) adapter, and an MQSeries adapter to serve clients of these three different types.
- Composability: Because services are coarse-grained reusable components that expose their functionality through a well-defined interface, systems can be built as a composition of services and evolve through the addition of new services.
- A set of applications that make use of services
- A set of services used by applications and other services—composed of service interfaces and underlying custom code or existing systems, either local or remote
- The middleware or infrastructure that allows the discovery of services and the data exchange between application and services
- Developers of applications that make use of services have to focus on the discovery and connection to services either statically at design time or dynamically at run time. The semantics of the information being exchanged is always a challenge, as well as what to do when a service is no longer available in the case of static binding.
- Developers of services have to focus on the description and granularity of services so that applications can easily locate and use them with acceptable QoS. If services are going to be additional interfaces to existing systems, focus is on the extraction of information from the systems and the wrapping of it within a defined message structure. If services are non-existent, the service-specific code needs to be written or reused from legacy systems. In this case, there are additional issues of service initialization. If reused, migration feasibility from legacy to target has to be analyzed.
- Developers of SOA infrastructure or middleware have to focus on providing a stable infrastructure as well as a set of common infrastructure services for discovery, communication, security, etc.
- How does one determine the architecture of such a system of systems? Can it only be determined at run-time? What evidence is available statically to help determine the architecture?
- What effect does not knowing the architecture have on the quality attributes of such a system? Is it possible to evaluate the quality attribute requirements of such a system?
- How can the system developer guarantee some level of service for the system that is being developed?
- How does a system that is integrated at runtime distinguish legitimate service requests from illegitimate ones?
- What impact will this have in the development of systems? How can dynamic identification be used to guarantee an acceptable level of quality of service?
The problem with many SoS architectures is that they tend to focus on technical issues, such as the ones mentioned above, and leave out the system goals. This is clear in the hype to migrate to service-oriented architectures, as pointed out in a CIO article by Hurwitz and Associates. SoS architectures tend to ignore issues such as:
The answers to these questions are usually readily available, the problem is that they are usually not considered in the development of an architecture for SoS interoperability.
Impact for Systems of Systems
An evolvable architecture is more than just an engineering issue. An evolvable architecture has direct implications on the acquisition strategy (e.g., providing time and resources to design and validate an evolvable architecture), contract vehicle(s), and the management and monitoring of development progress (e.g., measuring progress by the number of lines of code built won’t be useful when a system is composed of heterogeneous nodes).
Architects building an SoS architecture will have an even more difficult time dealing with architectural tradeoffs, such as:
In a SoS the architecture and design must evolve iteratively, focusing on critical capabilities first. Frequent executable representations of the architecture produced in each iteration will
Methods and Approaches
There are three main common architectural approaches to an SoS. Each has its advantages and disadvantages, and the maturity of the technologies used to implement each will vary.
Service-Oriented Architecture
The simplest way to define a service-oriented architecture is as an architecture built around a collection of services with well-defined interfaces—similar to DCOM (Distributed Component Object Model) or Object Request Brokers (ORBs) based on the CORBA specification. A system or application is designed and implemented as a set of interactions among these services.
A service is a coarse-grained, discoverable, and self-contained software entity that interacts with applications and other services through a loosely coupled, synchronous or asynchronous, message-based communication model [Brown 02, McGovern 03]. Common communication models are
Two characteristics of services that are particularly important are that they are discoverable and coarse-grained. Services need to be able to be discovered at design time and optionally at run time, not only by unique identity but also by keyword, interface, and behavior. Services are also ideally coarse-grained, that is, they usually implement more functionality and operate on larger data sets, as compared to components in component-based design. A typical example of a service is a credit card validation service [Lewis 05].
A service can be invoked in several ways, as shown in Figure 1 [Brown 02, Service Architecture 04]. A service consumer can
Figure 1: Forms of Service Invocation
In a service-oriented architecture, interoperability is simply defined as the ability of the service to be invoked by any potential client of the service [Stevens 03]. This definition of interoperability has a narrow scope, as it concerns syntactic and not semantic properties. Nonetheless, there are several attributes of an SOA that make this a possibility:
From a syntactic point of view, service-oriented architecture is very promising. The challenge lies in determining the number of adapters to implement and determining the right granularity of service interfaces, because it is not always known how systems will use the services. It is important to keep in mind that services are executed across a network as an exchange of a service request and a service response. If service interfaces are too coarse-grained, clients will receive more data than they need in their response message. If service interfaces are too fine-grained, clients will have to make multiple trips to the service to get all the data they need.
From a semantic point of view, service-oriented architectures by themselves do not offer any guarantees. Semantic interoperability depends on how the interface to a service is described and how the meaning of the information is shared with potential clients of the service. There is a great amount of research being done in this area because this is the difficult problem: How to know exactly what a service offers? How to interact with this service? What quality of service (QoS) does it offer?
It is also useful to distinguish between three types of components within an SOA, as presented in Figure 2:
Developers of each type of component have different challenges:
These are different types of challenges that present different kinds of problems. Each group will focus on its own problems and build components to optimize their concerns, which is sometimes detrimental to the engineering of end-to-end systems. How does an organization build an SOA-based system given these differences? How does it guarantee quality of service?
Grid Architecture
Grid computing is a form of distributed computing that involves coordinating and sharing computing, application, data, storage, or network resources across dynamic and geographically dispersed organizations. A Grid architecture represents the blueprint by which all this is possible.
The architecture of the Grid is often described in terms of "layers", each providing a specific function, as presented in Figure 3.
The Network Layer provides the connectivity for the resources in the Grid.
The Resource Layer contains all the resources that are part of the Grid, such as computers, storage systems, and specialized resources such as sensors.
The Middleware Layer provides the tools so that the lower layers can participate in a unified Grid environment.
The Application & Serviceware Layer includes all applications that use the resources of the Grid to fulfill their mission. It is also called the Serviceware Layer because it includes all common services that represent mostly application-specific management functions such as billing, time logging, and others.
The Grid is an emerging technology is currently being used mainly in e-science and e-business applications. Nonetheless, the Grid is attracting a lot of interest because of it end goal: "sharing computer power and data storage capacity over the Internet—that is, to turn the global network of computers into one vast computational resource."
The Open Grid Services Architecture (OGSA) is an SOA for the Grid. It is a non-proprietary effort by Argonne National Laboratory, IBM, the University of Chicago and other institutions, that combines Grid computing with Web services. The Globus Toolkit, being developed by the Globus Alliance and others, is an open source project that provides a set of software tools to implement the basic services and capabilities required to build Grid systems and applications. Most major Grid projects are being built using the Globus Toolkit.
Component-Based Architecture
A Component-Based Architecture (CBA) can be defined as an architecture built around a collection of components of "plug and play" nature—that is, they have well-defined interfaces, they can be integrated into the architecture using a common (or compatible) mechanism, and are potentially highly reusable. This definition sounds very similar to that of SOA presented above. This is because an SOA is a form of component-based architecture where components are discoverable and coarse-grained, two characteristics that are not mandatory in a CBA.
In a CBA, there is no rule as to the size of a components; a component is any piece of pre-existing code that defines interfaces and can be called to provide the functionality that the component encapsulates. There is a size spectrum for components, as shown in Figure 4. The left side of the spectrum is that of traditional fine grained components used by programmers, such as GUI widgets or algorithms. At the right side of the spectrum, components are full applications, either commercial-off-the-shelf (COTS) or custom. Control over interfaces is greater at the left side of the spectrum and less at the right side. This is why a component-based architecture can represent a challenge for builders of an SoS where the size of components tends to be closer to the right side of the spectrum.
There is also no infrastructure standard for the integration of components, although the two prevalent component frameworks are J2EE and .NET. The advantage of basing CBA on industry-accepted technologies is that components can be acquired in different ways: purchased from the marketplace, custom-built internally or externally, or reused from legacy applications. The market for commercial components is growing, as can be seen from the existence of component brokers such as ComponentSource.
Open Issues
Regardless of the approach selected for building an SoS architecture, there is a lack of guidance on how to architect an SoS, especially when the end goal is for the SoS to be created "on-the-fly." Creating systems on the fly involves dynamic discovery, composition, and invocation and therefore the architecture of the system may not be known until run-time.
Another issue that is worth exploring is testing of an SoS architecture through the use of scenarios specific to quality attributes, such as modifiability.
References
List of references from above text.
[Brown 02] Brown, A; Johnston, S.; & Kelly, K. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications, Rational Software Corporation. 2002
[Lewis 05] Lewis, Grace A. and Wrage, Lutz. Approaches to Constructive Interoperability, CMU/SEI-2004-TR-020 ESC-TR-2004-020, January 2005
[McGovern 03] McGovern, James; Tyagi, Sameer; Stevens, Michael; and Matthew, Sunil. Java Web Services Architecture. Morgan Kaufmann. 2003
[Stevens 03] Stevens, M. Service-Oriented Architecture Introduction, 2004