Extending Service-Orientated Architectures To The Deployed Land Environment

Introduction

The use of Service-Orientated Architecture (SOA) has become somewhat of a mantra within the Information and Communications Technology (ICT) discipline due to the advantages that accrue to the enterprise such as vendor diversity, interoperability, federation of capability, reusability and architectural composability [1]. SOA concepts have emerged from computing principles such as object orientation and distributed networking principles such as Distributed Common Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). SOA is now a mainstream capability offered by a variety of ICT vendors and is now also supported by the various architecture methodologies such as the (US) Department of Defence Architecture Framework [2].

Many military systems have been developed for a custom environment and therefore are difficult to tailor or modify. They may also have a user interface that is optimized for that particular environment. The use of SOA has scope to allow these systems to become more modular and flexible without modifying their presentation to the user and to build new systems (or enhancements) in the future that provide a more open architecture.

Military systems employing significant ICT elements may also benefit from the application of SOA principles to provide functional encapsulation, and reduction in coupling and agility in the same way that their commercial brethren can. The constraints of the deployed environment will mean that a different approach is required to ensure that the SOA can still provide benefits to the warfighter and/or the system acquirer. This paper highlights a number of these based on its experience with customers as well as studies conducted in internal research and development.

It must be noted that a SOA is just one element in the ICT toolbox that can be used to create systems to add value for an enterprise. A SOA, like any other element, needs to be driven by the overall Enterprise Architecture so that it has clear and consistent links to the business processes of the enterprise. The relationship of a SOA to an Enterprise Architecture is beyond the scope of this paper.

SOA overview

A SOA is an architecture (a framework of software elements and interfaces) that is orientated (centred on or provided by) towards services (well formed computational processes). These services may provide a variety of different functions based on a number of programming environments and languages and be located in a network of different hosts connected by a network. Services are consumed by service consumers that may in themselves be providing services to other consumers. Services may be both computer and human based and operate as combinations of services that are linked together or orchestrated in various arrangements to create functionality to implement a business process. SOA is well documented in the WS-* set of standards and includes such standards as Hyper Text Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP), Universal Discovery Directory Interface (UDDI), and Web Services Discovery Language (WSDL) [3] that are supported in both commercial and Free and Open Source (FOSS) SOA products.

An SOA has three main entities: one or more Service Providers, one or more Service Consumers, and a Service Registry (also referred to as a Service Discovery Agent [4]). The first two (Service Providers and Consumers) are somewhat self explanatory in that they represent the entities providing and consuming functionality in the enterprise. The Service Discovery Agent is the entity providing a description of the services available and their location within the enterprise. These entities and their relationships are shown in Figure 1.

This architecture does not require that any of these entities must exist within the enterprise itself; they may be externally provided capabilities from a business partner or service provider.

The architectural style of SOA encourages loose coupling between services to encourage interoperability and reuse. SOA also encourages the development of services in a technology-agnostic manner. For example the consumption of services from a provider written in Java on a Linux environment by a service consumer written in C# on a Windows environment without any specific a priori knowledge of this by the developers of either consumer or producer. Both of these styles promote improved flexibility and reuse of capability within systems that use SOA.

It is popular in many SOA offerings to introduce an Enterprise Service Bus (ESB) that supports high volumes of interactions and supports a unifying concept for functions such as service discovery, syntax translation and service interface enforcement, event-driven and message-orientated styles of operation [6] etc. The inclusion of an ESB can be a useful mechanism for the implementation of a SOA, particularly where there are heterogeneous service components or legacy elements to integrate, however it is not a strict requirement of a SOA.

For a SOA to be effective there are three characteristics that must exist [7]:

• Visibility—service consumers must be able to obtain (or discover) a description of the service (which includes characteristics such as Quality of Service, Safety, and Access Management) and to determine where the service can be found. Where a service is to be dynamically discovered, the service information must be visible through a searchable service registry. This requires meta-data in sufficient detail to describe not only the functionality of the service, but also the service contract that is used to access it. Each of the visible service characteristics should map to the service requirements in the Enterprise Architecture.
• Interaction—the actual usage of the service by a consumer with one or more effects being some tangible result. It is during the interaction that the effect of policies or service contracts will be visible. Such policies and contracts should map to the service requirement. These interactions are governed by the Service Level Agreements (SLAs) that define the performance and other parameters of the interaction.
• Effect—the effect or result of the use of the service, resulting in satisfaction of some or all of a business function at the enterprise level.

The deployed land environment

Military systems operating in the deployed land environment are subject to a number of constraints. Typically these can be abstracted to challenges relating to the environment, communications, security, operator interaction, and processing constraints.

Environmental

Harsh environment, temperature, humidity, shock and vibration specifications will limit the degree of sophistication and require a level of ruggedness for both processor and storage devices. The internal environment of a platform will often constrain the equipment’s weight, size, power draw, and heat production. The external environment will often dictate the availability of communications services to peers, headquarters, and partners.

All of these factors impact upon the level of processing and communications capability that can be used in the deployed land environment.

Communications

There have been a number of improvements in tactical battlespace communications over the past decade from fixed frequency single channel systems through to mobile ad-hoc wideband networks [8]. Once solely the domain of single channel voice radio systems the deployed land environment has begun to see the introduction of wideband IP data radios and the introduction of network attributes predicted earlier [9]. The complexity of terrain, operational demands or hostile countermeasures will also mean periods of significant degradation (to the extent of non-availability) of communications. There will also still be instances of legacy radio links that are not capable of carrying IP traffic. These constraints can impact upon the performance of systems that are designed for high-bandwidth/low-latency IP bearers and may create disconnected ‘islands’ of capability connected by legacy radio systems.

Operator usage

Users are often called upon to use the systems within the harsh environment as well as being subjected to the stress of the operation [10,11]. These factors require that interaction with the system must be designed to enable the completion of tasks in the most efficient and effective manner. Whilst end-user interfaces are not generally an aspect of a SOA-based design, the end user interface may itself be a consumer of services within the SOA. Where maintenance personnel are responsible for diagnostics and repair of a SOA-based system, it is critical that the SOA support facilities that enable those functions to be carried out effectively and efficiently.

Operator knowledge of the system is often limited to the material provided in training courses. Non-maintenance personnel can be expected to have little technical knowledge of the system beyond the way it is operated. Maintenance personnel’s knowledge will generally be limited to the diagnostic and repair processes needed to provide first-line preventative maintenance and repair. The SOA must be transparent, self-discovering, and self-healing to minimize training requirements and maximize effectiveness.

Processing limitations

The processing capability of systems in the land deployed environment is typically restricted due to the constraints imposed by environmental factors. This will often mean that low-performance processors will be required with a minimum of additional components in order to minimise power draw and heat production.

It should also be considered that the physical quantities of systems operating in this domain can be quite high. Where systems are deployed down to operating platforms (such as military vehicles) then the quantities deployed can be in the thousands, even for small forces.

SOA design should be able to provide a way to utilize services in an ICT ecosystem consisting of low and high powered devices. The devices can be tailored for the constraints of their environment and the services provided commensurate with their abilities. Thus lightweight, low power and portable handheld devices could be used by the warfighter that utilize services from larger and more-rugged devices mounted securely in vehicles.

SOA driven capability improvements

In general, the adoption of a SOA does not necessarily provide a significant change in the end-user experience for the person operating the system. A SOA can be retrofitted to extant systems without any noticeable user interface modification. There is however a number of benefits that a user, whether this is an operator, an acquirer or a maintainer, may obtain through the use of a SOA:

• Use of networked services—the SOA can provide a means of advertising and consuming capabilities to allow usage of a Network Centric Enterprise Model [12].
• Use of common services—the SOA can use well-known or advertised services for common information such as symbology or security.
• Access to services for specialised functions—where the SOA provides access to GIS capabilities, Targeting, Surveillance, Information Fusion, Messaging or Intelligence functions.
• Increased modularity and extensibility—system functionality at the service level is modular. Modifications can be made to extend the systems by extending the system services without necessarily impacting on other parts of the system.
• Improved diagnostics and management—consistent diagnostic methods can be built into each service to provide additional built-in-test capability to maintainers. Each service can be managed from a common maintenance capability.
• Access to swap-out and replacement of functionality—the underlying service with functionality X can be replaced with functionality Y (where Y may be >, = or < X depending on business requirements) without modification to service consumers.
• Reach-back/referencing—the system can utilize reach-back links where available to access information in rearward or strategic systems.
• Improved training and simulation—different services for operating in training and simulation modes can be used that employ strict separation of training from operational data.

Difficulties with current SOA approaches

Many SOA products are offered as either proprietary or FOSS licensed capabilities that are designed for commercial ICT environments with relatively stable environments and communications infrastructures. These may introduce a number of issues that must be considered prior to introduction into a deployed environment.

SOA infrastructure footprints

These products have difficulty coping with the processing and communications constraints of the deployed environment. Some vendor products require considerable memory footprints or introduce processing overheads that overwhelm the limited capabilities available to the processing system in the deployed environment.

Discovery and usage over high latency/error links

Communications mechanisms in the deployed land environment, even if based on IP, may experience periods of high latency and error. These conditions may adversely impact the SOA infrastructure’s ability to discover the best service to use and in the process create additional communications overhead. In addition to this once discovered, the traffic between service consumers and providers may be constrained due to link conditions resulting in at best delays to information provided to the user, or at worst the failure of the service to be utilized correctly. Bandwidth may vary whilst the link is in use and any application that expects a certain degree of latency and throughput may struggle in this environment.

Other constraints may be imposed such as the requirement for discovered services to be on a single IP broadcast domain. These requirements may not be feasible in the deployed environment with multiple geographically dispersed platforms which employ network architectures with multiple routed networks.

Security

The SOA implementation will need to take into account the security requirements of the deployed environment. Current SOA implementation may not be aware of the different links that information is passing over and the associated need to restrict or encrypt the information accordingly. It is important that security for the system is designed and implemented from the ground up [13].

Alternately a SOA infrastructure may be quite rigorous in the implementation of authentication of all service providers and consumers to each other. This may require significant administrative effort to setup which may be acceptable in a stable commercial environment but would prevent effective system usage in a more dynamic deployed land environment.

Management and administration

SOA software designed for the commercial environment will generally assume a dedicated and trained set of support personnel operating within a defined governance framework in order to maintain and administer the SOA based system.

The maintenance and support mechanisms for the SOA infrastructure may need to be tailored or supplemented to support the level of diagnostics and operator skill capabilities within the deployed environment.

Licensing

Licensing of SOA software for applications based on many small nodes can be problematic. This can be due to a number of factors such as the need for separate license fees for each platform (or processing element), or the need to install license server capabilities, or the requirement to node lock software licenses to a specific processing unit instance. This latter case has significant impact upon the logistics concepts that can be deployed to support the systems in the deployed environment.

Suggested approaches

In considering the constraints outlined earlier there are a number of approaches (technical, commercial, and procedural) that can be used to provide SOA capability in the land deployed environment whilst mitigating or avoiding some of the difficulties with current SOA implementations.

Maintain an appropriate governance process

Governance is defined as an agile and efficient decision and accountability framework [14]. SOA needs a governance process in order to identify reuse opportunities and determine what services need to exist within the system. Such a process can define the standards and practices that are to be used for both deployed and traditional environments, as well as defining the business rules that must be followed when deployed platforms are transitioned in to and out of the area of operations.

Identify business processes to be provided

A SOA approach requires that business processes are represented as services. The business processes in the deployed environment need to be well defined before an assessment is made as to whether and how these can be implemented as services within a SOA. Service modelling of the business process is a critical step for creating meaningful services [15]. Changes in the business processes need to be reviewed using a governance process in order to determine the follow on impact to the services implemented in the SOA.

Design using a service orientation

It is feasible to design a system with a Service Orientation without necessarily imposing all the overhead of a particular SOA infrastructure. Much of this is simply following sound and proven system architecture and design principles of loose coupling and modularity. However it is also necessary to ensure that the functionality defined for each service does not overlap, and that it is linked to the business functions that the system is required to deliver.

Identify SOA provisioning boundaries

It is important to identify where it makes sense to provide a SOA. There may be hard bounds due to communications constraints that will limit the SOA operation to within a limited number of platforms within a limited geographic area or to within a specific communications transport domain. Alternately there may be no communications driven boundary but the cost of implementing the necessary service mechanisms in all areas could outweigh the expected benefits. In either case an analysis is needed of where an SOA provides the best benefits as not all application types are well suited to SOA mechanisms [16].

The bounds of where the SOA exists will determine where sets of services within each SOA instance will be required. In the most extreme case a single node may be considered as a SOA instance with all service consumers and providers located within it. In the case of a platform there may be up to half a dozen nodes that are part of the SOA instance whilst in a barracks or headquarters structure there may be tens or hundreds.

Identifying the SOA boundaries also identifies the interactions that must occur between SOA instances that are not part of service consumer/producer conversations as shown in Figure 2. Such interactions may use formalised message or data link protocols.

Due to the dynamics of the deployed environment the system may also change its configuration by merging or splitting SOA instances. This identifies the need for business processes to provide support for the required changes to system configuration and their associated services within the SOA itself.

Consider different levels of service attributes

A service may deliver different levels of scope depending on the particular setting it is operating in. For instance a GIS data service may be capable of providing a full set of global data in a non-deployed setting but revert to the local data set for the operation once deployed.

Similarly a service may define a lower level of response or a reduced set of functionality when operating in a deployed environment to reduce the load on processing or communications resources.

Naturally where this approach is used each service consumer needs to be able to handle the associated response and provide a means of handling reduced service capability or performance.

Encapsulate legacy capability via façades

Implementing an SOA should not mean rewriting all existing capability. Where legacy capability is identified as providing a business process that should be available as a SOA, consideration should be made to providing a service façade to the legacy code which provides the necessary service interface but retains the current capability. Techniques such as SMART (Service-orientation Migration and Reuse Technique) [17] can be used to assist in this process.

Discoverability at different levels

One of the tenets of SOA is the ability to discover services and the ability of a service to be discoverable. In this paper such discovery operations are envisaged to be limited to services within the scope of the system or the surrounding enterprise, although publication to an external service registry could be possible in combined operations.

Different approaches could be used for service discovery to determine if wider (enterprise) or adjacent (workgroup) services were available. These could include options such as:

• Using static indicators of the initial service location and providing further discovery mechanisms within this service.
• Using a lightweight ESB or Service Crawling [18] to determine the appropriate service based on current network conditions as shown in Figure 4.

The second case retains location transparency at the expense of some processing to operate the ESB.

Utilise a flexible infrastructure licensing model

Sound SOA design would utilise wherever possible components that will fit within the mobile and dynamic deployed environment. Whilst the use of FOSS software may assist the designer to achieve this, the associated support and maintenance risks must also be considered. It may be possible to negotiate with proprietary license vendors to provide a more flexible licensing structure for hosts that are required to operate in a deployed environment.

Provide synchronisation methods

Where service elements that belong to disparate SOAs need to come together due to a reconfiguration of the deployed force or as a result of redeployment from the operation, there is a need to synchronise data and provide a single service capability for subsequent use of the system. This is a business process that should be supported by synchronisation methods designed into the service that can be activated as required—either through automated detection of the network configuration or through the action of a maintainer.

Allow for progressive implementation

There is merit in introducing SOA capability using a progressive implementation model that is driven by the governance process. This allows for the monitoring of system performance and subsequent adjustment of further SOA implementations from lessons learnt. The trade off of this approach is that it may require significant effort to provide these enhancements to units already deployed. To offset this it is possible to use the nature of SOA to permit units already deployed to continue to operate with the versions of the services they have on deployment, whilst upgrades only occur to units that are still in barracks or in maintenance. It should be noted that this approach requires a disciplined and effective approach to configuration management.

Provide failover service mechanisms

As the communications paths in the deployed environment are subject to degradation and failure more frequently than in a static setting, each critical consumer-producer relationship will need to have a failover mechanism provided as shown in Figure 5. This will allow the consumer to continue to have access to a version of the service when communications or service provision problems are encountered. Depending on the resources available to the node where the failover service is hosted this may be a full replication of the original service or may only provide a limited ability to respond to consumer requests. Similarly when communications are restored a mechanism is required to sense and restore access to the original service. In order to provide a degree of information synchronisation between the original and failover service, a background replication activity needs to occur if the information in the original service is dynamic. This synchronisation may use a series of filters to reduce the impact of information synchronisation on narrowband communications. Such filtering will result in a commensurate reduction of capability provided when the failover service is being used.

Align the SOA with the system modes

When the system is operating in the deployed environment there may be different modes that dictate what functionality and performance are required for each business process in each mode instance. These requirements should be translated to the service requirements that implement the business processes. This could mean that in some modes a service is limited in how much communications traffic it can generate or what other services it can consume itself. Alternately an ESB could redirect service consumers to different services in different modes as shown in Figure 6.

Use a SOA proxy pattern

In order to make transitions from a deployed to a non-deployed environment as seamless as possible, a lightweight ESB (a ‘deployed service bus’) could be used to act as an arbitrator between the use of local and enterprise network services. This approach depends on the ability of the bus to make decisions based on a particular network configuration or status, but preserves the SOA requirement for service location transparency by shielding the service consumer from knowledge about the service provider’s location.

This approach may also assist where the system provided in the deployed environment has to interact with an enterprise ESB to obtain services at an enterprise level. Information may be of different quality or latency when provided from different services and this needs to be represented in the service metadata. A mechanism to define the allowable hold time in each environment (such as information leasing [19]) could also be implemented.

Provide services on demand

Consider whether it is possible to trade off performance against other system resources (such as memory) by only loading and initializing services on the host as they are needed. Some SOA infrastructure software allows the SOA designer to determine whether services are started with the system itself or whether they remain dormant until used.

Provide transition into service using a governance framework

Using the Governance process described earlier, provide an orderly transition into service that considers the technological, logistical and operational requirements of both the system-in-being (if one exists) and the system-in-implementation. Determine which services are particular to application domains (and therefore unlikely to be reused) versus the services that are likely to be reused and focus governance effort on the latter. Failure to apply sufficient governance processes risks increases the effort required to implement and maintain the system and may place the entire implementation at risk [20].

Conclusion

The use of SOA principles within military systems can have benefits through the improvement in system flexibility and maintenance, as well as providing the user with access to richer information sets via the ability of services to reach out through the network. SOA design practices encourage the orientation of the system’s functions with the business practices of the warfighter.

Whilst these benefits are attractive, the practical reality of the deployed environment means that a number of constraints such as hardware, environment, network availability and performance need to be taken into consideration. Services will need to be both aware of these constraints and aligned with the business processes that are used in the deployed environment. Services may need to operate in different modes and with different performance depending on the configuration of the deployed system.

The set of design concepts and patterns proposed has been drawn from experience in different programs undertaken by the author. These may be able to assist in the development of SOA-based capability in such environments.

References

Author

Dennis Medlow is a Senior Systems Engineer with Saab Technologies Australia Pty. Ltd. with over 25 years of experience in the commercial ICT and defence industries. He has worked in a number of projects delivering capability into the land environment. Dennis holds Bachelor and Post-Graduate qualifications from the University of Adelaide and the University of South Australia and is a member of AOC and ACS. He is currently undertaking studies for a Doctorate in ICT Management with the University of South Australia.