In this section, SOA is compared to the High Level Architecture (HLA) and Service-Oriented Simulation Architecture (SOSA) (SISO 2010) and (Gu, Lo, and Yang 2007). As an abstract service architecture, SOA is not bound to any specific platform like J2EE, .NET, C (MacKen-zie et al. 2006, Page 4). The SOA is commonly defined as loosely coupled and a reference architecture, which makes the architecture more difficult to implement as opposed to the platform specific or tightly coupled architectures (MacKenzie et al. 2006, Page 5). The SOA
based implementation is always dependent on the external sources for requirements, plat-form, and design (MacKenzie et al. 2006, Page 5, Figure 1).
The basic unit of SOA is at a machine to human or machine to machine interaction. To be meaningful, the communication requires a shared language with rules and relations com-bined. The SOA architecture refers to shared syntax and semantics (see semantic) facilitated by information and behavioral models (MacKenzie et al. 2006, Page 8). In this research, the information model is used to lay out the chain of communication between the provider and client is based on the RDF/OWL notation (Section 3.3). The model is designed to bind the system and service together using interface oriented approach constructed at Figure 9. As in the object oriented paradigm, the interface facilitates encapsulating the system instances as stand-alone entities within the specific service-request, which also enables the descriptions for service and client to be based on the same root (MacKenzie et al. 2006, Page 10).
The key components to SOA for human to machine or machine to machine communication are visibility, interaction, and effect (MacKenzie et al. 2006, Page 13). An IT perspective to the architecture are unique and usable identification (ID), the request and response process, and effect translates to self-contained executable code (MacKenzie et al. 2006, Page 14):
• The visibility is equal to the unique and identifiable ID;
• The interaction is described by sequencing the entire function of the service to its individual components constituting as information model; and
• The effect is described by the behavioral model.
In the context of this research, the behavioral model would constitute as the implementation of the dynamic system (Figure 2) and the information model would constitute as the service layer design (Sections 3.3). The combined role of the behavioral and information model forms the basic stand-alone application (Figure 6). To accommodate both, the human to machine and machine to machine interaction, the notation used for the information model is RDF/OWL. Overall, the following guidelines are defined for usable SOA implementation (MacKenzie et al. 2006, Page 26):
• "Have entities that can be identified as services as defined by this Reference Model;"
• "Be able to identify how visibility is established between service providers and
con-sumers;"
• "Be able to identify how interaction is mediated;"
• "Be able to identify how the effect of using services is understood;"
• "Have descriptions associated with services;"
• "Be able to identify the execution context required to support interaction; and"
• "It will be possible to identify how policies are handled and how contracts may be modelled and enforced."
Whereas computer simulation applications are governed by mathematical models, the ser-vice is based on similar abstractions. But unlike the simulation, the patterns to follow for modelling services are based on hierarchical design, which is used to reflect the entities and causal connections among them. To encapsulating the continuous system inside the ser-vice provider is that SOA would, Therefore, require more detailed definitions to process the state-driven dynamic system. By using the process of elimination, requires identifying char-acteristics of the dynamic systems that share the causal relation with the state space (Table 2).
Table 2. Stateless service architecture at state-driven frame (Gu, Lo, and Yang 2007).
Functional requirements Origin
Analysis and specification methods SOA
Input and output as state driven Simulation specific
Time management Simulation specific
Scheduling and control software components SOA
Statistical data analysis Simulation specific
Visualization Simulation specific
Messaging SOA
Based on the visualization in Table 2 the extended scope of the SOA workflow, the elements requiring to be adjusted, include the input and output, time, statistics (engine), and UI visu-alization. To encapsulate an existing application inside a service the solution requires to be divided between the two roles of server and client. As the causality to this division of code, the input and output variables of the system need to be divided to global and local scopes.
This, in turn, leads to global run-time objects and interface based design principles (Partridge and Bailey 2010, Page 5)). In publications discussing the conflict with the stateless nature of SOA, a state driven architecture called HLA is often referred to within the context of pro-viding service support for continuous systems (SISO 2010). The architecture is primarily designed for integration in mind (SISO 2010). The HLA is also rigid and tight coupled, which makes the architecture to constitute as sandbox (SISO 2010). The key observations about the relations between SOA and HLA are (Dragoicea et al. 2012, Page 862):
• "HLA has good interoperability, synchronization and effective and uniform informa-tion exchange mechanism between the communicainforma-tion components (federates)"
• "SOA benefits from loose coupling, component reuse and scalability, but lacks a uni-form data exchange uni-format and time synchronization mechanisms."
• "The combination of HLA and SOA can extend the capabilities of the two protocols [technologies], and thus enable integrated simulation and real service."
Compared to the HLA, the causality of SOA as loosely coupled architecture is the indepen-dence from specific platform. This is also the main reason not to apply the HLA in projects.
The second reason to favor the SOA based implementation of service is that the process is more custom, and thus, more expertise driven. However, the abstract and expertise driven characteristics of the architecture can also be viewed as a deficit (depending on the observa-tion viewpoint)5.
However, the choice of implementing service architecture for simulation is not about the name of the architecture. It is; whether to implement the logic required by service at all?
This conflict is caused by the weight of the simulation-based development process, which, if compared to stateless applications, is heavy. Hence, if implementing the service layer to the simulation adds difficulty to an already complex problem, why to use it? According to the
5. A common misconceptions with regarding the SOA is that it is bound to the standard web protocols (http) - when in fact socket access with an XML data-stream objects is more than enough for the required remote communication. The challenge is; yes - the normal implementation of SOA (most likely) establishes the client communication over http or https, the process to use web protocols specifically is not defined by the SOA specification (MacKenzie et al. 2006). This view is underlined by the fact that according to its specification SOA is not platform or protocol specific (MacKenzie et al. 2006, Page 5, Figure 1).
research, the motivation to build applications using the service logic is long term usability (Balci, Arthur, and Ormsby 2011).
Encapsulating the system inside a service has to have some additional value to balance the additional complexity. The key benefits to service implementations are enhanced reusability, integration and interactions within the new system formed. The service design enables meth-ods like automated output evaluation, improved error-handing, and similarity measurements to be part of the process for implementation. On the other hand, the decision not to imple-ment service allows applications to be built with black box imple-mentality. This leads to enforcing the role of the programmer, and therefore, is inherently prone to complex software logic (as everything can be defined internally). The following classification to define the quality of reusability between low and high-quality simulations is used as an example (Balci, Arthur, and Ormsby 2011, Page 160 Figure 1):
• Conceptual model reusability,
• Network centric M and S application-level reusability (HLA, SOA),
• Model and Simulate application-level reusability,
• Model and Simulate commercial / of the shelf product-level reusability,
• Model and Simulate Component level reusability,
• Model and Simulate design level architecture,
• Model and Simulate programming framework-level reusability, and
• Model and Simulate programming-level reusability.
Due to the loose coupling of SOA, the implementation of the architecture is custom. The transition requires predetermined control flow (conceptual model) and data flow to be iso-lated to form an artificial barrier (interface) with the executing process (Figure 7). The key issue of this construct is the communication between the server and client (Section 3.3). In practice, the current method of conducting the communication is through messaging proto-col. The entire stack to execute simulation based service using currently available technolo-gies is collected to Table 3. The process to transform the existing schema to such request is covered in section 3.3.
Regardless whether the simulation output is a stable state (equilibrium) or transient, the
Table 3. Technical standard to classifying state-driven-service architecture fitness (Gu, Lo, and Yang 2007, Page 1130).
Applied ideology General method stand-alone
-Technical Network connectivity standards (HTTP (Hypertext Transfer Protocol), TCP (Transmission Control Pro-tocol))
Syntactical XML Based messaging
Semantic Ontology-based reasoning engine (OWL)
Pragmatic UML Sequence diagrams (Matlab/Simulink desing-space)
Dynamic Web services (J2EE)
Conceptual DoDAF, MDA (Server architecture)
trigger to communicate is more complex than the stateless application. The main reason for this conflict are the differences between continuous system designs (Simulation) and the stateless applications usually encapsulated to service using SOA. Unlike at stateless systems, the outcome for the continuous systems is harder to detect than for stateless systems. The conflict surrounding the formation of the state space is covered in section 2.3.
For the stateless systems, the transaction output to determine the success is usually in binary form - success or failure. To consider a booking service for airline tickets, transaction for bank-account, or on-line auction (normal SOA application), the characteristics of the suc-cessful transaction are clear and the range for viable input is easy to determine. Unlike for these stateless systems, for a simulation to model climate change or a plane during flight, the characteristics to successful run are less clear, and therefore, harder to determine.
Inspired to open HLA and accepting that SOA is not enough in its current configuration to service simulations most likely formed the idea for SOSA (Gu, Lo, and Yang 2007).
The goals of the commercial off-the-shelf (COTS) based approach to service simulation were to identify problems and to evaluate the requirements for state driven systems (Gu,
Lo, and Yang 2007, Page 1128). The gap at SOA with regarding input and output as state-driven characteristic, time management, statistical data analysis is summarized in Table 2.
As an attempt not to invent the wheel, but rather use existing components to make it better, the approach selected as the basis for the service architecture are MDA, SOA, and HLA (Gu, Lo, and Yang 2007, Page 1128). Based on the article SOSA is developed to service independently designed simulations for inter-platforms use (Table 4).
Table 4. Transition from SOSA to SOA (Gu, Lo, and Yang 2007, Page 1134)
SOA SOSA
Components Multi-resolution Simulation Process quality of service (see QoS) Reliable messaging | Simulation security Description Scenario Design | Mathematical model Messaging Time Driven | State Driven | System
Transport Transport
Overall, the topics covered in this section are service, SOA, HLA, and SOSA. The areas linked to service in this research are the information model and discovery (Section 3.3). The two key views to reconcile are: "There is not yet a clear conceptual picture of the underlying nature of what a service is" and "the service is the combination of the capability, and the mechanism used to access it."((Partridge and Bailey 2010, Page 4)). In the case of simula-tion, these capabilities are defined based on continuous system (Figure 6). The users of this service-type would require access into the simulation workflow and view the mathematical model upon which it was built - with access to the external input signals, state and time.
The full framework for the simulation service to adopt, spanning the domain and IT, fun-damentally requires something like the MDA (Section 2.4). The differences to conventional service versus the service based on the mathematical model is the QoS, describing the service functionality and messaging (Table 4).