1. Introduction

Service Oriented Architectures (SOA) has become a buzzword these ways. Generally, it is confused with Web Services. But SOA is an architectural concept and web services are one way of implementing them.
The software is growing complex everyday. Modular designs, object-oriented approaches, and component based software were proposed by researchers to address complexity and promote re-use. However, issues of maintenance, deployment, and integration of large-scale software remained problem until the advent of SOA. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.
This paper discusses the SOA in general, covering the key points, requirements and issues involved in service-oriented computing. We will dive deeper into SOA and later explore how we can take SOA techniques and related technologies and evolve HLA to support a loosely coupled architecture allowing faster integration and execution play.

2. SOA Analogies

The principles of SOA can be found in numerous places. That is to say, there are examples that abound that are analogous to the SOA ideal. Consider how different items . potentially manufactured by different vendors -- integrate together to provide some repeatable service.
For instance, a DVD player, which can connect to virtually any TV, can also play just about any DVD movie. Those same DVDs can be played on another device, such as a laptop, or automobile entertainment system. All of these devices integrated with the DVD provide common operational service, although the quality of the service may be different.
As another example, consider batteries which are used for numerous consumer electronic devices. The common service provided is loosely coupled power. It is possible to take the same AA batteries out of a MP3 player, and plug them into a small flashlight, or wireless mouse to receive for power needs.
Similarly, the objective of SOA is to minimize unnecessary dependencies among systems and software elements. This in effect, is what loose coupling is all about.

3. Key Components of SOA
The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, and dynamic discovery. Each of these plays an essential role in SOA [1].
3.1 Service
A service in SOA is an exposed piece of functionality with three properties:
1. The interface contract to the service is platform-independent.
2. The service can be dynamically located and invoked.
3. The service is self-contained. That is, the service maintains its own state.
A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, I would select a service (see Figure 1). The last property of a service is that the service be self-contained.

Figure 1: Directory service
3.2 Message
Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.
3.3 Dynamic Discovery
Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:
1. Scalability of services; you can add services incrementally.
2. Decouples consumers from providers.
3. Allows for hot updates of services.
4. Provides a look-up service for consumers.
5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.
4. Need for the Loose Coupling of M&S

SOA is intended to provide and support the integration and interoperability of loosely coupled subsystems and software elements. This differs from most object based architectures, which bind data and processing tightly together. In these instances, integrated elements can not be decoupled, at least not easily.
For example, this tight coupling is a problem that affects many within the M&S community. There has been a long standing issue with how HLA is applied for enabling distributed simulation environments. For instance, a FOM typically does not provide loose coupling of federates. Or perhaps it should be said that the federate can not typically be loosely coupled with a FOM. Consider that each federate must be tooled to operate to the agreements of a FOM, and that these agreements may vary from FOM to FOM. The irony is that the coupling of federates is absolutely necessary to formulate a federation. It,s just that it can,t be considered a loose coupling because federates have to be made to play to a new sheet of music known as FOM. Thus, exchanging one federate for another, while possible, is not always easy.
The desire would be for the FOM to behave like a DVD, and the federate to function like a DVD player capable of loosely coupling with any FOM . and thus interoperating with other federates within a federation. In other words, in a SOA compliant HLA, a federate should be able to digest and adapt to a FOM and be able to perform accordingly. We must realize the quality of service may vary among any one of these federates, but the operational aspect (i.e., interoperability) should always be the same.
Specifically, the federate is capable of playing, whether efficiently or poorly, to the common model information identified in the FOM.

5 Elements of Service-Oriented Architectures

SOA gives several advantages. It allows seamless integration between different applications and platforms. Another advantage is that SOA allows extending the capabilities of already existing applications without disturbing them much. To realize the above advantages, SOAs impose the following requirements:

Loose coupling. No tight transactional properties would generally apply among the components. In general, it would not be appropriate to specify the consistency of data across the information resources that are parts of the various components. However, it would be reasonable to think of the high-level contractual relationships through which the interactions among the components are specified.

Implementation neutrality. The interface is what matters. We cannot depend on the details of the implementations of the interacting components. In particular, the approach
cannot be specific to a set of programming languages.

Flexible configurability. The system is configured late and flexibly. In other words, the
different components are bound to each other late in the process. The configuration
can change dynamically.

Long lifetime. We do not necessarily advocate a long lifetime for our components. However, since we are dealing with computations among autonomous heterogeneous parties in dynamic environments, we must always be able to handle exceptions. This means that the components must exist long enough to be able to detect any relevant exceptions, to take corrective action, and to respond to the corrective actions taken by others. Components must exist long enough to be discovered, to be relied upon, and to engender trust in their behavior.

Granularity. The participants in an SOA should be understood at a coarse granularity. That is, instead of modeling actions and interactions at a detailed level, it would be better to capture the essential high-level qualities that are (or should be) visible for the purposes of business contracts among the participants. Coarse granularity reduces dependencies among the participants and reduces communications to a few messages of greater significance.

Teams. Instead of framing computations centrally, it would be better to think in terms of how computations are realized by autonomous parties. In other words, instead of a participant commanding its partners, computation in open systems is more a matter of business partners working as a team. That is, instead of an individual, a team of cooperating participants is a better modeling unit. A team-oriented view is a consequence of taking a peer-to-peer architecture seriously.

6. Beyond HLA Evovled

Figure 2: Beyond HLA

There are different view points whether HLA is a SOA or not. Consider a case of an HLA federation. Suppose an HLA federate ‘A’ publishes and produces some data. Now if another federate ‘B’ can also publish and produce same data then it can easily replace federate ‘A’. So, in this case HLA acts an SOA. Figure 2 shows capabilities can be added to already existing federates and made available as service.
However, if the new federate that replaces some other federate but does not publish same data as specified in Federation Object Model (FOM) for the federate to be replaced then inter-operability is not possible in true sense. This means in HLA, a federate is tightly bound to FOM and this may require some effort to make it suitable for another federation. On this view, some authors claim that HLA is not a SOA.

6.1 Opportunity for Applying SOA Principles

It can be argued that the great thing about DIS was that it fit closer to an SOA approach. Consider one could take any 2.03 DIS simulation and make it work within any other 2.03 DIS simulation environment. It was a simple mechanism allowing a simulation to be decoupled and reattached to other environments. It could be argued that a RPR-FOM Federate could also work within any RPR-FOM Federation, but consider the difficulty to take a federate and make it easily work for different FOMs and, just as importantly, different RTI implementations [3] .
The truth however is that HLA provides a much more extendible approach for interoperability than DIS provides. There.s no limitation to a specific set of Protocol Data Units (PDUs) as DIS requires. The FOM is intended to be an extension enabler allowing
federates to be better represented and reflected in a distributed environment. Furthermore the mechanisms of exchange are architected in a manner that is much more optimal in comparison to the performance of DIS, which required updates of complete entities whether information changed or not. Essentially HLA allows only the data that needs to be exchanged to be ultimately reflected, and therefore can be much more efficient. The key is to advance HLA in a manner that it adheres to SOA principles.

6.2 Federates as Software Agents

The mechanics of SOA are commonly attributed to the application of software agents, where self-autonomous software agents interact among one another; acting as providers and consumers in a very loosely coupled environment. A provider can be a web service providing functional remote procedures and data access, whereas a consumer can be a client application that might request a provider for computational analysis or access of specific data and/or the autonomously receipt of subscribed information when it becomes available It is quite possible that in HLA, a federate could be considered a software agent as well. The key requirement for this capability to take hold is through the application of common interfaces

6.3 The Application of a Common Interface

The interoperability and loose coupling of integrated elements, which SOA achievescan be attributed to the following two constraints:

1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.

2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

According to these constraints the key for SOA interoperability is the application of common interface. Specifically we can identify from analysis the following requirements for supporting the loose coupling of an interoperable environment:

The common interface must be leveraged by all participating software agents (i.e. federates)
That the interfaces must be accessible and understood by all providers and consumers
· Interfaces serve as the framework for the messages that are to be exchanged
· Minimal system behavior is provided by these interfaces (or messages)
· An XML schema should be applied to define the vocabulary and structure
· Additional services should be able to be added without impairing the common interface.
· A principle need within the M&S community is to determine how common interfaces can be established, shared and integrated within a distributed component simulation environment that is supported by HLA federates and other resources.

6.4 Making HLA a true Service Oriented Architecture

Tight binding of a federate with FOM sometimes deviate HLA from being a true SOA. What is required is another mechanism to define the interface; a more modular approach that can be utilized in different ways.
This is where the concept of Base Object Models (BOMs) makes sense. A BOM is a standards-based approach for describing a reusable component or piece part of a simulation or system. BOMs are unique in that they are able to represent or support discrete patterns of interplay within or among simulations.
A BOM distinguishes between a component’s or piece part’s interface and its implementation. Specifically, a BOM reflects a language neutral interface that identifies the essential elements provided by a component or piece part. The implementation (or
functionality) for that component or piece part can be captured independently through source code, a binary object such as a Windows DLL, a Unix Object, or in other ways such as the Simulation Reference Markup Language (SRML).
This separation of interface from implementation allows BOMs to serve as building blocks for supporting the composability of loosely coupled systems
Using BOMs, concept of adaptability and aggregation is met along with loose
coupling requirement of SOA. Using BOMs, HLA federates can be made loosely coupled in web services framework as shown in Figure 3.

Figure 3: SOA Service and Connections with HLA and BOMs


SOA is the latest buzzword these days. This paper clearly brings out two important conclusions. Firstly, SOA is general purpose architecture; although, it is talked about in business applications but it finds equal importance in military simulation domains as well. Secondly, SOA should not be confused with Web Services. Web Services are just one way of implementing SOA.
In later part of the paper, it is shown that HLA may not be considered a true SOA on the grounds that a federate is tightly bound to FOM and does not satisfy the criteria of loosely coupled of SOA. However, separating simulation’s interface from its implementation using BOM based Application Frameworks (BAF), HLA can be converted into a true SOA.


1. Principles of Service Oriented Computing available through

2. Paul, Tram Chase, Larry Root, Karl Crosson, Moving Towards a Service Oriented Architecture (SOA) for Distributed Simulation Component Environments, SimVentions Inc.

3. Per M Gustavvson, Service Oriented Simulations Concept, SimTect, Sydney, Australia, May 2005.