Use of SOA for Distributed Simulation: A Way Forward
David L. Drake & Katherine L. Morse, PhD
The Johns Hopkins University Applied Physics Laboratory (JHU/APL)
david.drake@jhuapl.edu
katherine.morse@jhuapl.edu
Keywords:
Service-Oriented Architecture, Simulation, Infrastructure, Cloud Computing
ABSTRACT: One of the promising directions for multi-architecture distributed simulation interoperability has been the
use of a Service-Oriented Architecture (SOA) for component management, installation, configuration, initialization, and
control. Many of the challenges of distributed simulation are addressed by SOA’s principles of interface
standardization, loose-coupling of services, and service composability. The impetus for employing SOA in this manner is
simulation asset reuse, increased accessibility, and the potential of rapid component deployment. Despite the upbeat
technical and financial outlook for employing SOA in this domain, there are barriers that have been recognized. This
paper presents a distributed simulation-specific architectural paradigm for employing SOA, descriptions of successful
implementations, and a hard look at both the current technical, financial, and managerial challenges to bridging the gap
between the traditional approach: operating distributed simulations in static, isolated configurations, and the use of a
SOA approach: using highly dynamic, reusable/reconfigurable simulations with multiple contributors.
1
Introduction
SOA is an architectural approach that supports
integrating software components as loosely coupled
services. Successful application of SOA allows systems
to adapt quickly, easily, and economically to support
rapidly changing needs while providing customers with
flexibility in their business processes and enabling them
to reuse their existing hardware and software assets by
connecting disparate applications and information
sources [1].
In this paper, we describe SOA and identify several
technical approaches for integrating it into distributed
simulations including:

Simulation components as services,

Federations as services and centralized simulation
management,

Federations with gateways as services
centralized simulation management,

Adding gateways as services & peer-to-peer
simulation communication, and

Common simulation components as services.
and
With these technical approaches in hand, we proceed to
describe how they can provide value to the distributed
simulation enterprise. We conclude by describing
efforts in this direction and issuing a challenge for
future improvements.
1.1
SOA Overview
When creating a SOA, software development teams
develop and make available software capabilities, while
retaining control of the software execution. Instead of
distributing software that allows independent execution
or linking libraries into executables, development teams
expose a capability or service to potential users. These
remote capabilities can be accessed directly by users
through desktop or web applications. Both end-users
and other services can be clients of a SOA service.
Software written for use by an end-user to access SOA
services is referred to as an application.
The capability provided by a service may be as simple
as saving or retrieving a piece of information, similar to
what a local database might do, or the function may be
significantly more complex, involving interaction with
vast amounts of data, use of substantial computer
resources for calculations, or sending and receiving
streams of information.
While services are often accessed directly by user
applications, they can also be accessed by other
services. In many cases, the services within a SOA are
built at different abstraction levels. Some services
provide baseline capabilities, while other services
leverage these baseline capabilities to provide more
complex capabilities. Using existing services as
building blocks to create higher level services
encourages composability and reuse, two of the guiding
principles of SOA. Many SOA architectural diagrams
illustrate their abstraction levels as strata and place their
services within a layer.
Separating the function of the service from the user of
the service allows the service provider flexibility with
regard to hardware. Servers that host services can be
clustered to maximize performance, load-balanced to
increase efficiency, or configured to fail-over to
redundant servers for high availability. Services can
also be hosted on multiple virtual machines that are
running on the same machine. In this configuration,
multiple services could run together on one physical
machine initially, but could be spread across multiple
physical machines easily when greater performance is
needed.
Reusability: Publishing a service makes it available to
other software projects. There are standard protocols
established for registering and finding services.
These are only some of the many possible choices
available to service implementers as they consider what
functions to provide to their potential users and how to
make them most attractive and capable for their use.
The actual location of service executions is often hidden
from application developers and end users. Application
developers and users instead rely on the existence of
services and their ability to perform functions as
advertised.
Composability: Applications and services can combine
information supplied by multiple services, combining
the information to show a correlation or relationship
that was not originally provided, as an example. These
are often called mashups.
Well-defined modular
services can act as the components for higher
complexity services. Through this use of modularity
and mashups, development effort for the individual
services and new, higher-tier projects will decrease
relative to a non-mashup development approach.
Further, as different methods are used to implement
similar capabilities, programs that use them may have
the option to select services based on efficiencies of a
given situation. Composability enables this happening
at the time of invocation by the selection of potentially
different services when needed.
Different hosts that are part of the same SOA may be
under control of different ownership domains. SOA
distributes governance of each information technology
(IT) resource to the organization best able to handle it:
the providers of the software. The service providers
benefit by being able to maintain control of the software
and hardware on which it runs. They have full control
over configuration, access, and software and of the
hardware upgrades. They do not have to deliver code or
binaries. Instead, they deploy the software as a service
that they host. The users of the service benefit because
they do not have to purchase the servers or maintain the
servers or software. Software and hardware upgrades
should be transparent to the user.
1.2
SOA Principles
SOA is not a physical architecture or a fixed set of
tools, but rather a philosophical approach to creating
architectures. To this end, SOA is driven by a set of
design principles [2]. The following is a list of some of
the key guiding principles of SOA design.
Abstraction: Generally, clients can ignore service
implementation details and think of services provided
by a SOA as “black boxes.” SOA clients are provided
information about input and output formats, but are not
usually provided with details of how processing is
actually accomplished, where systems and services are
located, or other internal details. SOA clients need only
be informed as to how to invoke the SOA services and
what to expect in return. It is worth noting that SOA
services need not be restricted to request-response
transactions. For example, a client could use a SOA
service to start and stop streamed content or direct two
SOA services to interact with one another.
Loose Coupling: Loosely-coupled services are those
that have interfaces that are designed for general use,
instead of being molded to fit a certain application.
Designing for loose coupling leads to services that are
more likely to be used by other projects because it is
easier for the developers of another project to adapt
their software to use a general interface than it is to
adapt to an interface that was designed for some
specific piece of software.
Discovery: SOA defines a standard way for developers
to find existing services that can be used in new projects
and for clients to check which services are available.
Standardized service discovery facilitates reuse.
1.3
SOA Governance
A critical concept to a successful SOA system
implementation is that of governance. Governance is a
set of information-sharing rules that are determined by
the SOA system architects and the SOA user base.
Since the goal of the creation of a SOA system is often
to organize and control the flow of information
throughout an organization, agreement is needed on the
interfaces and terminology that will be used throughout
the SOA. For example, if an organization’s billing
department is creating a service that will interface with
the contracts department, they should agree upon a
consistent format and terminology for representing the
organization’s fiscal years. Although this may seem to
be a small item to agree upon, it may be the case that
the calendaring system used by the two departments
may have differed before the planning of the SOA, and
so a change to business practices is required for one or
both of the departments if the SOA is to be successful.
There are many strategies for resolving these types of
issues, and it becomes one of the major steps in the
planned deployment of a SOA.
SOA governance is traditionally captured in two
locations (the term location is used to prevent confusion
since informal, formal, and automated means are used
to capture the governance rules): one is referred to as
the Policies and the other is referred to as the Registry
and Repository. The Policies define both design-time
and run-time rules that will be followed by all of the
service creators. Because a SOA is not normally
developed by a single team, agreement is needed on the
interfaces that will be used, and the formalized metaconcepts and ontologies on which the interfaces are
based. As part of these interface definitions, the
Policies document also defines the hierarchical
interoperability framework to which the services will
need to adhere.
The Policies document can also contain the design goals
of the SOA, such as delivering value to its stakeholders
and conforming to standards or laws, i.e., compliance
with Sarbanes-Oxley or the Health Insurance Portability
and Accountability Act (HIPAA) of 1996. Other goals
commonly stated in the Policies document include
providing an infrastructure that can accommodate
technical transformation and ensuring a quality of
service for clients.
The Policies document also addresses run-time rules.
These rules define the details of the service contracts
and the required security measures, expected service
levels, and the restrictions of service use.
Since clients can be responsible for both providing and
receiving information, the overall SOA services have
interdependencies on the service providers and their
services, and the quality of those services affect the
quality of the system as a whole. For that reason, the
Policies document frequently defines an ownership
relationship between service providers and their
services, and the rewards and penalties for service
providers that respectively meet or fail to meet the rules
stated in the Policies document. In a business setting,
these rewards and penalties are usually financial in
nature.
The Registry and Repository provide run-time detail for
the service providers and, if automated, to the services
themselves. The Registry lists all of the active services
and how each service can be reached. The Repository
contains pointers to design-time and run-time policy
information, and contains the architectural diagrams
showing how the SOA will be deployed and extended.
1.4
SOA and Web Services
Web services are one possible communication protocol
for a SOA. Web services enjoy wide tool support for
all major programming languages and operating
systems, reducing the effort required to integrate
heterogeneous components.
Web services communicate via Extensible Markup
Language (XML) messages typically sent over
Hypertext Transfer Protocol (HTTP) to web servers [3].
XML is a very portable file format since it is text-based
rather than binary-format. It is widely accepted and
easy to use as an interface protocol given the wide
number of tools and software components that have
been created to read and create XML files. On the
downside, traditional text-based XML is verbose and
XML-formatted files can be much more voluminous
than binary-format files. Using XML messages can
saturate networks more quickly than more compressed
formats; however, there are standards for compressing
XML ([4] and [5]) that ease this problem.
People first learning about SOA often make the mistake
of thinking that SOA services must be implemented via
web services using HTTP. Although this is frequently
the case, particularly for SOAs that are visible to enduser systems through web browsers, it need not be the
case. As long as the SOA principles are adhered to, in
general, any protocol can be used for the services to
communicate. Examples of non-web services are ad hoc
service interfaces run from within a programming
language, such as C++ [6] or Java [7], or a service
infrastructure such as Microsoft’s .NET Framework [8]
or the Common Object Request Broker Architecture
(CORBA) [9].
2
Application of SOA to LVC M&S
This section examines how the integration of SOA and
LVC distributed simulations can be accomplished.
2.1
Assumption of Composability
One of the concerns with using a SOA is that the
service interface protocol syntax and semantics need to
be well defined to allow communication between the
services. Current M&S assets at all levels (models,
federates,
federations,
and
multi-architecture
simulations) have not been written to use consistent or
interchangeable interfaces. To be able to connect M&S
assets as services, this will be required to some level,
even if translation components, such as gateways, are
employed. While composability is one of the principles
of SOA, it is not a guaranteed result of building a SOA.
Composability must be designed into the software
components during development. Composability is
more difficult to achieve than interoperability. It is not
enough for software components to be written in the
same language or communicate using a shared protocol;
composable services must have interfaces that are
syntactically and semantically consistent. This clearly
indicates the necessity for composability of
components.
To proceed with the concept of employing a SOA, the
presumption is made that the simulation systems being
integrated are composable without a SOA
infrastructure. To state it simply: a SOA cannot
compose components that were not already composable.
So arguments about the difficulty of composability are
not within the scope of an examination of the benefits
and barriers of employing SOA to LVC distributed
simulations.
2.2
Integration Approaches
Since SOA is less of a formalized architecture and more
of a framework under which to build an architecture,
there are a number of approaches that can be used to
integrate SOA with LVC distributed simulations. The
subsections that follow describe how the integration can
be approached.
2.2.1
Simulation Components as Services
The simplest architecture approach for applying SOA to
distributed simulation is to have the individual
simulation components act as services that are
accessible from a centralized SOA simulation
management system. A number of exemplars have
been implemented that have taken this approach. For
the exemplar to be shown as being more than just a
replacement for a distributed simulation infrastructure,
such as an RTI implementation, the simulation
management service acted in the role of a gateway for
individual simulation components, such as HLA
federates. This concept is depicted in Figure 1.
philosophical in nature. If the SOA infrastructure needs
to change for every change or additional simulation
component, the addition of the SOA infrastructure has
not gained the developers or users any advantage in
efficiency in development, deployment, or maintenance.
The next greatest hurdle is the communication
bottleneck that is caused when all of the simulation
components have to go through a gateway to
communicate to each other. This issue becomes more
apparent as the number of simulation components is
greater than three, placing the full extra-component
communication load on the gateway.
As an exemplar to show the feasibility of employing
SOA in a distributed simulation, the “Simulation
Components as Services and Centralized Simulation
Management” approach works, but it lacks scalability
unless other means are used to limit the reconfiguration
of the gateway(s) within the simulation management
service.
2.2.2
Figure 1. Simulation Components as Services with
Centralized Simulation Management
A wrapper is a software component that envelops a
piece of legacy software and makes it externally look
like a service. Through the use of wrappers, a
simulation component is treated as a service. By taking
this approach, it is easier to incorporate legacy software
components into a service-oriented architecture than to
rewrite the legacy software from scratch. The key to
success in this approach is to build a modular gateway
within the SOA infrastructure to perform the translation
between the simulation components. This allows the
simulation components to be written for different
simulation infrastructures, which demonstrates the
legitimacy of this integration approach.
Federations as Services and Centralized
Simulation Management
The “Federations as Services and Centralized
Simulation Management” paradigm is a minor but
important variation in the previous subsection,
“Simulation Components as Services with Centralized
Simulation Management,” which is to use a wrapper
around entire simulation architectures, creating services
at a higher level of abstraction, as shown within the red
rectangles in Figure 2. By doing so, the entire
functionality of the simulation architecture operates
within each of the services, including simulation
management and communication capabilities specific to
the simulation architecture.
In this paradigm, the SOA infrastructure also has the
responsibility of overall simulation management, such
as starting, pausing, and terminating the overall
simulation.
Although this approach is good for showing SOA’s
applicability for exemplars, there are some issues with it
in the long run. The greatest hurdle is that gateways are
traditionally implemented and configured in a very
specific manner for the simulation components for
which it is translating. In this case, it means that one of
the principles of SOA infrastructure, loose coupling, is
not followed because adding or modifying simulation
components causes a great deal of change to the
configuration of the gateway and the simulation service
management. A loosely coupled system would have
well-defined service interfaces that would not require
changes to the SOA.
This issue is more than
Figure 2. Federations as Services with Centralized
Simulation Management
This allows each of the simulation architectures to run
independently, while a wrapper service passes
simulation data from the network on to the SOA
simulation management service. Within the SOA
simulation management service, a gateway can pass
data between the architectures. By allowing the
architectures to be encapsulated, each of these services
is more autonomous, allowing the functionality within
the service to be more mutable with less effect on the
SOA simulation management
information that needs to
architecture boundaries will
gateway resident in the SOA
service.
service. Also, only the
be shared across the
be passed through the
simulation management
similar manner, and configured as part of simulation
initialization. That would allow the users of the SOA to
have a flexible interface definition that could be
configured as needed for each simulation exercise.
However, this approach still has the hurdle that gateway
is traditionally implemented and configured in a very
specific manner for the simulation components that for
which it is translating, which means that this approach
is still not loosely coupled since adding or modifying
the simulation architectures will still cause some
changes to the configuration of the gateway and the
simulation service management. This approach still
lacks well-defined service interfaces.
The issue with this structure is that it still has all of the
simulation architecture to simulation architecture
communication flowing through one point, the SOA
simulation manager service. For larger exercises, this
could be a serious communications bottleneck. A more
minor issue is that the gateways would need to pass
exercise-level simulation control protocols, such as
initialization, starting, pausing, and stopping. Most
gateways could have this capability added to it, but it
would mean that there was a mix of protocols within the
external facing end of the gateway.
2.2.3
Federations with Gateways as Services and
Centralized Simulation Management
The “Federations with Gateways as Services with
Centralized Simulation Management” paradigm
requires the services to use a standardized interface for
each of the architecture services, as illustrated in Figure
3.
Figure 3. Federations with Gateways as Services with
Centralized Simulation Management
To meet the interface specification, which would have
been defined and agreed upon by the users and
developers of the SOA in the SOA governance
documents, a gateway for each of the simulation
architectures would need to be included. Each of these
gateways would have to translate the data that needs to
be shared with the other simulation architecture services
into a common language that could be passed to the
other service.
2.2.4
Adding Gateways as Services & Peer-toPeer Simulation Communication
The “Adding Gateways as Services & Peer-to-Peer
Simulation Communication” paradigm addresses the
issues previously presented, and is illustrated in Figure
4.
If the same type of gateway is used in each simulation
architecture service, then it makes architectural sense to
have the gateway be provided as a service itself, one
that can be run as multiple instances, each with their
own configuration.
Using that approach, the
communication between simulation architectures can be
done point-to-point, or n-way, as needed, which would
allow the simulation architecture to simulation
architecture communication to be as direct as needed to
eliminate communication bottlenecks. The critical
concept that needs to be part of the SOA is that the
configuration of the simulation exercise needs to pass
the information to the simulation architecture services
the details of their peer services so that the peer-togateway-to-peer communication can be configured.
This is well within the capabilities of a SOA, and is
commonly used in non-simulation systems that share
information by using peer services that have relatively
short network distances.
This approach would work well if there were an agreed
upon language that the simulation architectures could
all use. An example of this approach was the use of the
U.S. Joint Battle Management Language (JBML) for
the George Mason University (GMU) North Atlantic
Treaty Organization (NATO) exercise [10], which used
SOA technology for information exchange among its
simulation component interfaces.
However, in general, this may be too constraining. One
protocol may not fit all of the situations for which the
SOA is intended. A variant of this to address this issue
is that the gateways used could be configurable in a
Figure 4. Adding Gateways as Services and Peer-to-Peer
Simulation Communication
This approach addresses all of the SOA requirements
for a simulation exercise management system. It could
integrate differing simulation architectures, as long as
there was a capability for those simulation architectures
to be compatible without the SOA infrastructure.
One of the challenges for this paradigm is a consistent
interface to the configuration of the gateway instances.
Although multiple gateway services could be used, such
as an HLA to DIS gateway and a HLA to TENA
gateway, the simulation exercise integrator would be
best served with a single general-purpose gateway that
was highly configurable. That would allow the
communication policies to be as configurable as the
simulation exercise integrator needs it to be, and the
SOA infrastructure would have a longer lifecycle since
it wasn’t tied to particular protocol specifications.
2.2.5
Common
Services
Simulation
Components
as
SOA provides a benefit to an architectural plan that
wasn’t taken full advantage of in the previous four
subsections, the concept of extracting common
functional components and implementing them as
stand-alone services so that they can be shared. For
instance, each of the simulation architectures has some
form of simulation activity logger that allows
developers and exercise managers to verify that the
simulations are operating as expected. By adding a
common log data collection and inspection service,
exercise-wide analysis can be performed [11]. This
doesn’t exclude the ability to perform simulation
architecture-specific log collection and analysis, but
rather enhances that capability. This concept of
extending the set of services to include common
simulation components is shown in Error! Reference
source
not
found.Figure
5.
Figure 5. Common Simulation Components as Services
The challenge to this is how the SOA governance would
request common service information to be available to
the services, or how the common services would
initialize or monitor the simulation architectures. This is
more of an issue in regard to getting the policy makers
to agree to the interface rather than a technical one, so
the challenge is surmountable.
2.3
SOA Capabilities Applicable to Distributed
Simulation
With application of SOA infrastructure approaches as
described in the subsection above, “Integration
Approaches,” a web site could be developed that would
interface with the SOA simulation management service
that would allow the activities in the bulleted list below.
These activities would allow the storage of components
and configurations into a “cloud,” which could reside in
either a public site that was controlled through secure
web services or into a secure government or military
network.
Simulation Component Installation: A developer would
be able to upload a simulation component to a
simulation architecture service, such as uploading a
semi-automated forces simulation onto an RTI service
that is storing a named instance of an HLA simulation.
Continuing the example, the interface could also allow a
modular FOM to be uploaded to the RTI service. The
compatibility of the modular FOM to the named
instance of an HLA simulation could also be verified as
part of the upload capability of the RTI service.
Different simulation architectures would allow similar
services to define its architecture-specific object
models.
Gateway Instance Configuration: A developer or
simulation manager would be able to upload a named
configuration file for a general-purpose gateway. The
configuration file would indicate, for example, how to
map communications from one simulation architecture
to another simulation architecture and back.
Simulation Exercise Configuration: A simulation
manager would be able to use a select, drag, and drop
interface to construct the overall simulation services.
The interface would allow the simulation manager to
show which named simulation architectures connect to
gateways running which named gateway configurations.
The interface would allow the configuration of the
simulation exercise to be named by the simulation
manager for future reference.
Simulation Exercise Initialization: A simulation
manager would be able to select a named simulation
configuration for initialization. The interface would
know of the object types available to populate the
exercise, and how to associate those objects to an
“owner,” which would be a named simulation
component within a named simulation architecture.
Simulation Exercise Execution Planning: A simulation
manager would be able to select a named initialized
simulation exercise for execution. The interface would
allow the simulation manager to invite participants to
interact with the simulation, including the time of the
simulation exercise start.
Simulation Exercise Execution: Before the simulation
exercise start time, the SOA simulation management
service would instantiate the simulation services as
needed, populate the simulation objects, and provide the
simulation managers with a status of the overall
simulation exercise, showing if it was ready to proceed.
Participants would be signaled to initialize their
interaction with the exercise. Some of the participants
would be using live or virtual components in the
exercise; others may interact directly with the
simulation components, such as a semi-automated
forces display; while others may be interfacing with
common web services through an interface. The
simulation exercise would progress through the
exercise, with status interfaces available to the
simulation managers.
Although this scenario may seem extreme, modifiable
multiuser online virtual games are able to do this today.
Game infrastructure developers, such as Muzzy Lane
[12], provide general-purpose SOA architectures for
“plugging in” game/simulation components, such as the
ones described above. In the case of Muzzy Lane, their
technology to allow online game creation is called their
Sandstone Platform [13].
3
The demonstration system contained three national C2
systems, a middleware C2 lexical GUI employing
JBML web services, three national simulation systems,
and a Joint Command, Control and Consultation
Information Exchange Data Model (JC3IEDM)
visualizer that provided a common operating picture for
the overall system. Each of the simulations that were
contributed had to be modified to communicate using
the common JBML rather than the C2 language
originally employed by the simulation. The United
States also contributed the JBML web services that
acted as a hub for the SOA communications. The threelayer web services communication architecture is
shown in Figure 7. The layers are:

The BML domain-configured service: provides the
representation of the domain-specific language in
the form of a grammar-based schema.

BML base services: defines the domain-configured
service in terms of BML, which represent the
information element groups that specify
information objects of interests.

Common data access service: this, the lowest level,
performs the exchange of information elements
between domains. It is normally hidden from the
simulations that interact with the higher-level
services. This is the level that interacts with the
database.
Leaning Forward
In this section, we describe two, unrelated efforts that
are leaning forward with respect to adopting SOA for
LVC. They’re not yet the future, but they’re steps
along that path.
3.1
enhanced version of BML, the JBML, as seen in Figure
6.
The MSG-048 November 2007 Demonstration
The NATO Modeling and Simulation Group Technical
Activity 48 was chartered to investigate the potential of
a standard formal language for multinational command
and control (C2) military operations within modeling
and simulation systems, dubbed the Battle Management
Language (BML). As a result of this charter, a SOAbased system was implemented to aid in the
development and demonstration of the virtues of BML.
A service-oriented approach was seen as a way to allow
multiple international contributors to provide services
that would employ BML for simulation exercise C2.
The demonstration was held in November of 2007.
Figure 7. MSG-048 Web Services Architecture
The team’s SIW paper [14] has the following
conclusion, which captures the enthusiasm for this
innovative approach to using SOA for a complex,
collaborative simulation demonstration.
Figure 6. MSG-048 November 2007 Demonstration System
Architecture
Each member of the coalition contributed one or more
simulation components/clusters, written to use the
The MSG-048 November 2007 demonstration
provides very strong evidence in favor of the
techniques employed as a basis for a SOA approach
to using simulations with C2 systems. First and
foremost, the approach based in formal linguistics
[…] and associated Web Services, with strong
semantics (using the JC3IEDM-derived vocabulary),
provided an extremely effective medium of expression
for communication among the various systems.
Perhaps equally important, the network-centric
development methodology proved highly effective,
especially when employed by national development
teams with a highly cooperative spirit, including
technical developers and military subject matter
experts.
Our key observation about this effort is that most
NATO nations cannot afford not to take this type of
integrative approach.
3.2
LVCAR-I Reusable Tools Recommendation
One of the other tasks under LVCAR-I, Reusable Tools,
examined approaches for improving the sharing and
reuse of development tools across programs and
communities [15]. The purpose was to mitigate the
existence of a wide range of tools utilizing a
correspondingly wide range of business models. Not
only does conversion between the formats supported by
these differing tools introduce cost and risk1, but the
tools are usually purchased in small quantities by
different DoD organizations without benefit of quantity
discounts or efficient use of licenses.
Figure 8 provides an illustration of the recommended
actions to migrate from one business model to another
in order to change business model focus for reusable
tools and take other actions beneficial to DoD’s reuse
goals.
Figure 8. Relationship of Long Term Recommendations
Correspondingly, one of the resulting recommendations
includes:
Where a large number of licenses have been and
continue to be procured from industry, take the
following actions in the order presented until a viable
option is identified:
a. Shift to open source.
b. Shift to Software as a Service.
Software as a Service (SaaS) does not necessarily mean
SOA from a technical perspective, but is essentially the
same from a business model perspective.
1
This issue is the subject of another LVCAR-I task, Common Data
Storage Formats.
We haven’t yet addressed open source, but its close
presence in the recommendation makes this a good
point to discuss its relationship to SOA. When
commercial industry adopts SOA, it tends to adopt an
open Application Programming Interface (API)
approach, i.e. the documentation for the API to the SOA
is publicly diseminated, but the design and
implementation of the SOA is proprietary. If the SOA
itself were open source, their would be little to no
commercial value to the vendor. The DoD is not a
commercial vendor. Providing open source for SOA
implementations can benefit the DoD by creating a pool
of successful example for contractors to reuse and
tailor. This approach can also improve the sustainability
of the DoD enterprise by creating an open source
support community from which all contractors can
draw. Other DoD initialtives using open source can be
found at <http://forge.mil>.
4
The Way Forward
As the last section illustrates, the technology and the
intent exist to move forward with adoption of SOA as a
useful tool in the LVC toolbox, but there is still
resistance to the business model changes necessary to
achieve such usefulness.
In their recent article, “If Only Einstein Were Still
Around to Help the Government Fix Information
Technology Acquisition,” Gunderson and Pullen [16]
observe:
In other words, technologists can fuel success when
they follow the money. By carefully observing existing
patterns of transactions, providing tools that reduce
barriers to those transactions, and expanding the
market space, IT practitioners can fan sparks into
bonfires by providing “enterprise” capabilities.
However, they need to start where the sparks already
exist. Defense leaders should take a cue from Einstein
and ask themselves why the dozens of previous
reports, roadmaps, and mandates aimed at fixing
aspects of Defense IT acquisition have not led to the
envisioned successes. Therefore, Einstein might have
suggested that the DE stop pushing particular
technologies, and focus on “market forces.”
Lest we be accused of missing the point being made by
Drs. Gunderson and Pullen, we are not advocating for
SOA for the sake of SOA. The examples in the
preceding section were intended to highlight the
business need for and the technical efficacy of SOA as a
technology for delivering LVC enterprise capability.
We conclude with a proposal to “fan sparks into
bonfires” for SOA in the LVC arena. Starting in 2010,
the Space Forum of the SIW began sponsoring the SISO
Smackdown [17]:
The SISO Simulation “Smackdown” is an
international cooperative experience where teams of
university students—with help from faculty advisors,
M&S (modeling and simulation) professionals within
industry, NASA, and other areas of government—
build and participate in a simulated lunar resupply
mission. Smackdown is a “distributed,” multi-team
cooperative competition that occurs simultaneously
across multiple time-zones. Participating teams
design, model, program, test, and operate a simulated
spacecraft—or other mission device such as a rover
or satellite—on a simulated mission from the Earth to
a virtual moon base.
It would be hard to overstate the success of this
initiative at engaging university students with
standards-based M&S technology and getting them
excited about the field. These students are
unencumbered by “can’t, don’t, shouldn’t, and won’t.”
We suggest that these energetic M&S pioneers are in an
excellent position to demonstrate that SOA “can, does,
should, and will” be a viable LVC solution.
5
Acknowledgements
The contents of this paper were drawn from the
JHU/APL report Live-Virtual-Constructive ServiceOriented Architecture: Service-Oriented Architecture
Application to Live-Virtual-Constructive Simulation:
Approach, Benefits, and Barriers, NSAD-R-2011-025,
funded under the LVCAR-I program by Dr. Gary Allen
of the Joint Training Integration and Evaluation Center
under Task JHS01 of Contract N00024-03-D-6606.
Much of this material is also covered in the tutorial
“Employing SOA FOR LVC Multi-Architecture
Distributed Simulations.”
References
[1] Carter, S., The New Language of Business: SOA &
Web 2.0, Upper Saddle River, NJ: IBM Press,
2007.
[2] Erl, T., Service-Oriented Architecture: Concepts,
Technology, and Design, Upper Saddle River, NJ:
Prentice Hall PTR, 2005.
[3] Extensible Markup Language (XML) 1.0 (Fifth
Edition), W3C Recommendation, 26 November
2008.
[4] Guardalben, G., “Compressing and Filtering XML
Streams,” <http://www.w3.org/2003/08/binaryinterchange-workshop/33-HiT-W3C-Workshop2003.pdf>, August 2003.
[5] Cheney, J., “Compressing XML with Multiplexed
Hierarchical PPM Models,” Proceedings of the
2001 IEEE Data Compression Conference, 2001.
[6] C++ reference
<http://en.wikipedia.org/wiki/C%2B%2B>.
[7] Java reference
<http://en.wikipedia.org/wiki/Java_(software_platf
orm)>.
[8] .NET Framework reference
<http://en.wikipedia.org/wiki/.NET_Framework>.
[9] CORBA reference
<http://en.wikipedia.org/wiki/Corba>.
[10] Pullen, M., Carey, S., Cordonnier, N., Khimeche,
L., Schade, U., de Reus, N., LeGrand, N.,
Mevassvik, O. M., Galan, S., Godoy, S. G.,
Powers, M., Galvin, K., “NATO MSG-048
Coalition Battle Management Initial Demonstration
Lessons Learned and Way Forward,” Spring 2008
Simulation Interoperability Workshop, 2008.
[11] Wagenbreth, G., Davis, D., Lucas, R., Yao, K-T.,
Ward, C., “Nondisruptive Data Logging: Tools for
USJFCOM Large-scale Simulations,” Fall 2010
Spring Simulation Interoperability Workshop,
2010.
[12] Web site for Muzzy Lane:
<http://www.muzzylane.com/ml/about>.
[13] Web site for Muzzy Lane Sandstone Platform:
<http://www.muzzylane.com/ml/sandstone_platfor
m>.
[14] Pullen, M., Carey, S., Cordonnier, N., Khimeche,
L., Schade, U., de Reus, N., LeGrand, N.,
Mevassvik, O. M., Galan, S., Godoy, S. G.,
Powers, M., Galvin, K., “NATO MSG-048
Coalition Battle Management Initial Demonstration
Lessons Learned and Way Forward,” Spring 2008
Simulation Interoperability Workshop, 2008.
[15] Morse, K.L., et al, “LVCAR Reusable
Development Tools,” Proceedings of the 2010 Fall
Simulation Interoperability Workshop, Orlando,
FL, September 20 – 24, 2010.
[16] Gunderson, C. And Pullen, M., “If Only Einstein
Were Still Around to Help the Government Fix
Information Technology Acquisition,” Defense
AT&L Magazine, November-December 2011.
[17] SISO Smackdown, http://sisosmackdown.com.
Author Biographies
DAVID L. DRAKE is a member of the Senior
Technical Staff in the Force Projection Department at
Johns Hopkins University Applied Physics Laboratory
performing research and development in the area of
modeling and simulation supporting the U.S.
government and military. Mr. Drake was the lead on the
Live Virtual Constructive (LVC) Service-Oriented
Architecture Task, and supports the LVC Architecture
Roadmap Implementation tasks for Common Gateways
and Bridges, Futures, and Reusable Tools. Mr. Drake
has 10 years experience in modeling and simulation
design, development, and standards, and 24 years as a
computer security professional in computer security
design, implementation and evaluation. Mr. Drake
received his Bachelors in Mathematics from State
University of New York at Buffalo. He is published in
the areas of simulation, service-oriented architecture,
grid computing, security, and risk assessment and has a
patent on the process for enterprise-wide intrusion
detection.
Dr. KATHERINE L. MORSE is a member of the
Senior Professional Staff at the Johns Hopkins
University Applied Physics Laboratory. She received
her B.S. in mathematics (1982), B.A. in Russian (1983),
M.S. in computer science (1986) from the University of
Arizona, and M.S. (1995) and Ph.D. (2000) in
information & computer science from the University of
California, Irvine. Dr. Morse has worked in the
computer industry for over 25 years, specializing in the
areas of simulation, computer security, compilers,
operating systems, neural networks, speech recognition,
image
processing,
and
engineering
process
development. Her Ph.D. dissertation is on dynamic
multicast grouping for data distribution management, a
field in which she is widely recognized as a foremost
expert. She is a member of Phi Beta Kappa, Dobro
Slovo, ACM, and a senior member of IEEE. Dr. Morse
was the 2007 winner of the IEEE Hans Karlsson
Award.