Fig 2 - uploaded by Khaldoon Al-Zoubi
Content may be subject to copyright.
Source publication
Distributed simulation practice outside the military sector is still limited. Having plug-and-play or automatic middleware
interoperability is one of the main challenges is needed to advance distributed simulation, as indicated by several surveys;
hence, interoperability must be achieved effortlessly with rational cost. They further indicate the ne...
Contexts in source publication
Context 1
... constraint via ensuring safe timestamp- ordered processing of simulation events within each LP. In current systems, the common implementation of conservative-based distributed simulation cycle to advance simulation time (e.g. [9][10][39]) is summarized as follows: (1) Time- coordinator requests minimum time from all LPs. (2) Time-coordinator calculates global minimum time, broadcasts it to all LPs, and waits for their replies. (3) Time- coordinator instructs all LPs to execute events with the minimum global time, waits for all LPs replies, and starts again with step #1. In optimistic algorithms, each LP maintains its Local Virtual time (LVT) and advances “optimistically” without explicit synchronization with other processors. On the other hand, a causality error is detected if a LP receives a message from another processor with a timestamp in the past (i.e. with a time-stamp less than the LVT); such messages are called straggler messages. To fix the detected error, the LP must rollback to the event before the straggler message timestamp; hence undo all performed computation. Time Warp algorithms focus on providing efficient rollback by reducing memory and communication overhead such as the mechanisms presented in [15]. Distributed simulation Middleware main objective is interfacing different simulation environments, allowing synchronization for the same simulation run across a distributed network. Those simulation entities are usually heterogeneous. For example, each simulation environment may differ from other entities in its simulation engine, algorithms, model representation, and formalism. This comes as no surprise that a number of surveys placed the middleware of distributed simulation as the most area of interest to overcome current distributed simulation challenges and to meet future expectation, as indicated by a number of surveys of experts of different simulation background [6][28]. The defense sector is currently one of the largest users of distributed simulation technology, mainly to provide virtual distributed training environment between remote parties, relying on the High Level Architecture (HLA) [21] middleware to provide a general architecture for simulation interoperability and reuse. On the other hand, the current adoption of distributed simulation in the industry is still limited. Further, HLA could not make a breakthrough in the industry since its adoption in 1996 due to a number of issues such as its complexity, tied to programming languages and lack of interoperability in interfacing different Run-Time Infrastructure (RTI) vendors, since RTI-to-RTI interface is not standardized. RTI is the software layer that connects and synchronizes different HLA simulation entities (called federates) together where federates are interfaced with local RTIs via callback function interface (Figure 1). The HLA interoperability and scalability issues have caused the consideration of using existing Service-oriented architectures (SOA) technologies in distributed simulation middleware, mainly CORBA [18], SOAP-based WS [12], and RESTful WS [26]. WSDL and SOAP are the main elements enable SOAP-based Web-services (WS) interoperability. SOAP-based Web-services provides interoperability in a similar way as CORBA: WSDL corresponds to IDL role whereas SOAP corresponds to ORB data marshalling/serialization function. Further, Web-service ports addressed by URIs whereas CORBA objects addressed by references. Both ports and objects contain a collection of procedures (i.e. called services by WS) similar to a Java/C++ classes. Those procedures glue software components across the network, hence providing and RPC-style type of software interoperability, as shown in Figure 2. The server exposes a group of services via ports (Figure 2). Each service is actually an RPC where semantic are described via that procedure parameters. Client programmers need to construct service stubs with their software at compile time. Clients, at run time, consume a service by invoking its stub, which is in turn converted into XML SOAP message (to describe the RPC call), wrapped within HTTP message and sent to the server port, using the appropriate port URI. Once the message is received at the server side, the HTTP server passes the message into the SOAP layer (usually called SOAP engine like Apache AXIS [36]). SOAP engines are usually running inside HTTP servers as Java programs, called Servlets. The SOAP layer parses the SOAP message and converts it into an RPC call, applied to the appropriate procedure of the proper port. The server returns results into clients in the same way. Thus, the SOAP message role is to provide a common representation among all parties to the invoked procedure at runtime. In a distributed simulation environment, different components act as peers to each other. This means that each acts as client when it needs to send information while acts as a server via exposing different RPCs (i.e. services), as shown in Figure 2. Service providers need to publish their services, as XML WSDL documents. Clients programming stubs (Figure 2) are generated via compiling the WSDL document into programming stubs. Programmers then need to write the body of those stubs and compiling them with their software. [23][29] are examples of SOAP-based WS distributed simulation. In reality, RPCs are heterogeneous interface, since they were invented by different programmers, and need to be written and compiled before being used. RPCs also expose internal implementation, leading to impractical and complex interoperability standards. It is almost impossible to interoperate independent-developed simulation systems via RPC-style without requesting major software implementation changes. This makes it impractical to support. Further, existing solutions lack of composition scalability, for example, programming stub is needed for every remote service. However, in case of HLA the scalability is even worst, since the RTI is treated like a bus where all simulation entities use it for synchronizations. Furthermore, API complexity makes it difficult for distributed simulation to break outside expert programmers circle. RESTful WS exposes all services as resources with uniform connectors (channels) where messages are transferred between those resources through those uniform channels. REST is usually implemented using HTTP, URIs, and usually XML because these are the main pillars of the Web today. In this case, resources (services) are named and addressed by URIs, resources connectors are HTTP channels (usually called methods), and connectivity semantics are usually described in XML messages (Figure 3). RESTful applications APIs are expressed as URI templates [16] that can be created at runtime. Variables in URI templates (written within braces {}) are assigned at runtime by clients before a request is sent to the server, enabling clients to name their services URIs at the server side. For example, username in template <.../users/ {username}> can be substituted with any string to get the actual URI instance (such as <.../users/user1> or <.../users/user2>). Further, URIs may include query variables to define the request scope by appending them to a URI after the question mark “?”. For instance, request via GET channel to URI <. google.com/search?q=DEVS> would instruct Google search engine to return information only about keyword “DEVS”. RESTful services can be described formally using XML either using Application Description Language (WADL) [37] or WSDL 2.0 [22][38]. From distributed simulation viewpoint, there are some differences between SOAP- based WS and RESTful WS as follows: (1) SOAP groups all services as procedures and expose them via a port (i.e. addressed by single URI) whereas REST exposes each service as a resource (i.e. addressed by single URI). (2) SOAP-based WS communicates simulation information (i.e. semantics) in form of procedure parameters whereas REST defines them as XML messages. (3) SOAP-based WS transmits all SOAP messages (i.e. RPC description) using HTTP POST channel whereas REST uses all HTTP channels to transfer simulation semantics. (4) SOAP- based WS clients need to have a stub for each corresponding service while REST clients communicate in the same uniform way. (5) SOAP-based WS client stubs skeleton usually built via tools, but they still need to be written, integrated with existing software and compiled by programmers whereas REST does not usually require this process, hence follows a dynamic approach. REST critics usually raise few issues such as REST only uses the four HTTP channels to transfer all messages so that those methods might not be enough for some applications: mainly, GET (to read), POST (to append new data), PUT (to create/update), and DELETE (to remove). This misleading comes from naming those virtual channels as “methods” in HTTP standards (RFC 2616 [14]), hence being confused with regular programming methods. Perhaps, it is ample to mention that SOAP-based WS transfers all SOAP messages using only the HTTP POST channel, thus, single method is enough in this case. Another issue is that REST heavily depends on HTTP, on other hand; SOAP-based WS can send SOAP messages using different protocol from HTTP like TCP/IP. This is because SOAP is a message describes an RPC via a network so that it can be sent using TCP socket. This is a misleading issue because: (1) HTTP is the Web protocol, thus sending SOAP messages using different protocol from HTTP makes it not Web service any more, hence complicates interoperability with other heterogeneous even further. (2) REST is message-oriented, thus, those messages are portable to different protocols like TCP/IP. For example, all simulation synchronization messages presented here portable to different protocol, similar to SOAP. However, a universal standard is part of REST principles and makes no sense to use different protocol from ...
Context 2
... present, most works in distributed simulation are invested in optimizing simulation algorithms and in achieving efficient interoperability between different independent- developed simulation entities. These two areas define the current challenges of distributed simulation and future trends [ 28]. For further thorough details, we discuss distributed simulation current state-of-the-art in [35]. Parallel/distributed simulations are typically composed of a number of sequential simulations where each is responsible of part of the entire model. Each of these subparts is a sequential simulation, which is usually referred to as a logical process (LP). The main purpose of synchronization algorithms is to produce the same results as if the simulation were preformed sequentially in a single processor. The second purpose is to optimize the simulation speed by executing the simulation as fast as possible. They fall in two categories: Conservative and optimistic. Conservative algorithms were introduced in late 1970s by Chandy-Misra [9] and Bryant [8]. This approach always satisfies local causality constraint via ensuring safe timestamp- ordered processing of simulation events within each LP. In current systems, the common implementation of conservative-based distributed simulation cycle to advance simulation time (e.g. [9][10][39]) is summarized as follows: (1) Time- coordinator requests minimum time from all LPs. (2) Time-coordinator calculates global minimum time, broadcasts it to all LPs, and waits for their replies. (3) Time- coordinator instructs all LPs to execute events with the minimum global time, waits for all LPs replies, and starts again with step #1. In optimistic algorithms, each LP maintains its Local Virtual time (LVT) and advances “optimistically” without explicit synchronization with other processors. On the other hand, a causality error is detected if a LP receives a message from another processor with a timestamp in the past (i.e. with a time-stamp less than the LVT); such messages are called straggler messages. To fix the detected error, the LP must rollback to the event before the straggler message timestamp; hence undo all performed computation. Time Warp algorithms focus on providing efficient rollback by reducing memory and communication overhead such as the mechanisms presented in [15]. Distributed simulation Middleware main objective is interfacing different simulation environments, allowing synchronization for the same simulation run across a distributed network. Those simulation entities are usually heterogeneous. For example, each simulation environment may differ from other entities in its simulation engine, algorithms, model representation, and formalism. This comes as no surprise that a number of surveys placed the middleware of distributed simulation as the most area of interest to overcome current distributed simulation challenges and to meet future expectation, as indicated by a number of surveys of experts of different simulation background [6][28]. The defense sector is currently one of the largest users of distributed simulation technology, mainly to provide virtual distributed training environment between remote parties, relying on the High Level Architecture (HLA) [21] middleware to provide a general architecture for simulation interoperability and reuse. On the other hand, the current adoption of distributed simulation in the industry is still limited. Further, HLA could not make a breakthrough in the industry since its adoption in 1996 due to a number of issues such as its complexity, tied to programming languages and lack of interoperability in interfacing different Run-Time Infrastructure (RTI) vendors, since RTI-to-RTI interface is not standardized. RTI is the software layer that connects and synchronizes different HLA simulation entities (called federates) together where federates are interfaced with local RTIs via callback function interface (Figure 1). The HLA interoperability and scalability issues have caused the consideration of using existing Service-oriented architectures (SOA) technologies in distributed simulation middleware, mainly CORBA [18], SOAP-based WS [12], and RESTful WS [26]. WSDL and SOAP are the main elements enable SOAP-based Web-services (WS) interoperability. SOAP-based Web-services provides interoperability in a similar way as CORBA: WSDL corresponds to IDL role whereas SOAP corresponds to ORB data marshalling/serialization function. Further, Web-service ports addressed by URIs whereas CORBA objects addressed by references. Both ports and objects contain a collection of procedures (i.e. called services by WS) similar to a Java/C++ classes. Those procedures glue software components across the network, hence providing and RPC-style type of software interoperability, as shown in Figure 2. The server exposes a group of services via ports (Figure 2). Each service is actually an RPC where semantic are described via that procedure parameters. Client programmers need to construct service stubs with their software at compile time. Clients, at run time, consume a service by invoking its stub, which is in turn converted into XML SOAP message (to describe the RPC call), wrapped within HTTP message and sent to the server port, using the appropriate port URI. Once the message is received at the server side, the HTTP server passes the message into the SOAP layer (usually called SOAP engine like Apache AXIS [36]). SOAP engines are usually running inside HTTP servers as Java programs, called Servlets. The SOAP layer parses the SOAP message and converts it into an RPC call, applied to the appropriate procedure of the proper port. The server returns results into clients in the same way. Thus, the SOAP message role is to provide a common representation among all parties to the invoked procedure at runtime. In a distributed simulation environment, different components act as peers to each other. This means that each acts as client when it needs to send information while acts as a server via exposing different RPCs (i.e. services), as shown in Figure 2. Service providers need to publish their services, as XML WSDL documents. Clients programming stubs (Figure 2) are generated via compiling the WSDL document into programming stubs. Programmers then need to write the body of those stubs and compiling them with their software. [23][29] are examples of SOAP-based WS distributed simulation. In reality, RPCs are heterogeneous interface, since they were invented by different programmers, and need to be written and compiled before being used. RPCs also expose internal implementation, leading to impractical and complex interoperability standards. It is almost impossible to interoperate independent-developed simulation systems via RPC-style without requesting major software implementation changes. This makes it impractical to support. Further, existing solutions lack of composition scalability, for example, programming stub is needed for every remote service. However, in case of HLA the scalability is even worst, since the RTI is treated like a bus where all simulation entities use it for synchronizations. Furthermore, API complexity makes it difficult for distributed simulation to break outside expert programmers circle. RESTful WS exposes all services as resources with uniform connectors (channels) where messages are transferred between those resources through those uniform channels. REST is usually implemented using HTTP, URIs, and usually XML because these are the main pillars of the Web today. In this case, resources (services) are named and addressed by URIs, resources connectors are HTTP channels (usually called methods), and connectivity semantics are usually described in XML messages (Figure 3). RESTful applications APIs are expressed as URI templates [16] that can be created at runtime. Variables in URI templates (written within braces {}) are assigned at runtime by clients before a request is sent to the server, enabling clients to name their services URIs at the server side. For example, username in template <.../users/ {username}> can be substituted with any string to get the actual URI instance (such as <.../users/user1> or <.../users/user2>). Further, URIs may include query variables to define the request scope by appending them to a URI after the question mark “?”. For instance, request via GET channel to URI <. google.com/search?q=DEVS> would instruct Google search engine to return information only about keyword “DEVS”. RESTful services can be described formally using XML either using Application Description Language (WADL) [37] or WSDL 2.0 [22][38]. From distributed simulation viewpoint, there are some differences between SOAP- based WS and RESTful WS as follows: (1) SOAP groups all services as procedures and expose them via a port (i.e. addressed by single URI) whereas REST exposes each service as a resource (i.e. addressed by single URI). (2) SOAP-based WS communicates simulation information (i.e. semantics) in form of procedure parameters whereas REST defines them as XML messages. (3) SOAP-based WS transmits all SOAP messages (i.e. RPC description) using HTTP POST channel whereas REST uses all HTTP channels to transfer simulation semantics. (4) SOAP- based WS clients need to have a stub for each corresponding service while REST clients communicate in the same uniform way. (5) SOAP-based WS client stubs skeleton usually built via tools, but they still need to be written, integrated with existing software and compiled by programmers whereas REST does not usually require this process, hence follows a dynamic approach. REST critics usually raise few issues such as REST only uses the four HTTP channels to transfer all messages so that those methods might not be enough for some applications: ...
Context 3
... present, most works in distributed simulation are invested in optimizing simulation algorithms and in achieving efficient interoperability between different independent- developed simulation entities. These two areas define the current challenges of distributed simulation and future trends [ 28]. For further thorough details, we discuss distributed simulation current state-of-the-art in [35]. Parallel/distributed simulations are typically composed of a number of sequential simulations where each is responsible of part of the entire model. Each of these subparts is a sequential simulation, which is usually referred to as a logical process (LP). The main purpose of synchronization algorithms is to produce the same results as if the simulation were preformed sequentially in a single processor. The second purpose is to optimize the simulation speed by executing the simulation as fast as possible. They fall in two categories: Conservative and optimistic. Conservative algorithms were introduced in late 1970s by Chandy-Misra [9] and Bryant [8]. This approach always satisfies local causality constraint via ensuring safe timestamp- ordered processing of simulation events within each LP. In current systems, the common implementation of conservative-based distributed simulation cycle to advance simulation time (e.g. [9][10][39]) is summarized as follows: (1) Time- coordinator requests minimum time from all LPs. (2) Time-coordinator calculates global minimum time, broadcasts it to all LPs, and waits for their replies. (3) Time- coordinator instructs all LPs to execute events with the minimum global time, waits for all LPs replies, and starts again with step #1. In optimistic algorithms, each LP maintains its Local Virtual time (LVT) and advances “optimistically” without explicit synchronization with other processors. On the other hand, a causality error is detected if a LP receives a message from another processor with a timestamp in the past (i.e. with a time-stamp less than the LVT); such messages are called straggler messages. To fix the detected error, the LP must rollback to the event before the straggler message timestamp; hence undo all performed computation. Time Warp algorithms focus on providing efficient rollback by reducing memory and communication overhead such as the mechanisms presented in [15]. Distributed simulation Middleware main objective is interfacing different simulation environments, allowing synchronization for the same simulation run across a distributed network. Those simulation entities are usually heterogeneous. For example, each simulation environment may differ from other entities in its simulation engine, algorithms, model representation, and formalism. This comes as no surprise that a number of surveys placed the middleware of distributed simulation as the most area of interest to overcome current distributed simulation challenges and to meet future expectation, as indicated by a number of surveys of experts of different simulation background [6][28]. The defense sector is currently one of the largest users of distributed simulation technology, mainly to provide virtual distributed training environment between remote parties, relying on the High Level Architecture (HLA) [21] middleware to provide a general architecture for simulation interoperability and reuse. On the other hand, the current adoption of distributed simulation in the industry is still limited. Further, HLA could not make a breakthrough in the industry since its adoption in 1996 due to a number of issues such as its complexity, tied to programming languages and lack of interoperability in interfacing different Run-Time Infrastructure (RTI) vendors, since RTI-to-RTI interface is not standardized. RTI is the software layer that connects and synchronizes different HLA simulation entities (called federates) together where federates are interfaced with local RTIs via callback function interface (Figure 1). The HLA interoperability and scalability issues have caused the consideration of using existing Service-oriented architectures (SOA) technologies in distributed simulation middleware, mainly CORBA [18], SOAP-based WS [12], and RESTful WS [26]. WSDL and SOAP are the main elements enable SOAP-based Web-services (WS) interoperability. SOAP-based Web-services provides interoperability in a similar way as CORBA: WSDL corresponds to IDL role whereas SOAP corresponds to ORB data marshalling/serialization function. Further, Web-service ports addressed by URIs whereas CORBA objects addressed by references. Both ports and objects contain a collection of procedures (i.e. called services by WS) similar to a Java/C++ classes. Those procedures glue software components across the network, hence providing and RPC-style type of software interoperability, as shown in Figure 2. The server exposes a group of services via ports (Figure 2). Each service is actually an RPC where semantic are described via that procedure parameters. Client programmers need to construct service stubs with their software at compile time. Clients, at run time, consume a service by invoking its stub, which is in turn converted into XML SOAP message (to describe the RPC call), wrapped within HTTP message and sent to the server port, using the appropriate port URI. Once the message is received at the server side, the HTTP server passes the message into the SOAP layer (usually called SOAP engine like Apache AXIS [36]). SOAP engines are usually running inside HTTP servers as Java programs, called Servlets. The SOAP layer parses the SOAP message and converts it into an RPC call, applied to the appropriate procedure of the proper port. The server returns results into clients in the same way. Thus, the SOAP message role is to provide a common representation among all parties to the invoked procedure at runtime. In a distributed simulation environment, different components act as peers to each other. This means that each acts as client when it needs to send information while acts as a server via exposing different RPCs (i.e. services), as shown in Figure 2. Service providers need to publish their services, as XML WSDL documents. Clients programming stubs (Figure 2) are generated via compiling the WSDL document into programming stubs. Programmers then need to write the body of those stubs and compiling them with their software. [23][29] are examples of SOAP-based WS distributed simulation. In reality, RPCs are heterogeneous interface, since they were invented by different programmers, and need to be written and compiled before being used. RPCs also expose internal implementation, leading to impractical and complex interoperability standards. It is almost impossible to interoperate independent-developed simulation systems via RPC-style without requesting major software implementation changes. This makes it impractical to support. Further, existing solutions lack of composition scalability, for example, programming stub is needed for every remote service. However, in case of HLA the scalability is even worst, since the RTI is treated like a bus where all simulation entities use it for synchronizations. Furthermore, API complexity makes it difficult for distributed simulation to break outside expert programmers circle. RESTful WS exposes all services as resources with uniform connectors (channels) where messages are transferred between those resources through those uniform channels. REST is usually implemented using HTTP, URIs, and usually XML because these are the main pillars of the Web today. In this case, resources (services) are named and addressed by URIs, resources connectors are HTTP channels (usually called methods), and connectivity semantics are usually described in XML messages (Figure 3). RESTful applications APIs are expressed as URI templates [16] that can be created at runtime. Variables in URI templates (written within braces {}) are assigned at runtime by clients before a request is sent to the server, enabling clients to name their services URIs at the server side. For example, username in template <.../users/ {username}> can be substituted with any string to get the actual URI instance (such as <.../users/user1> or <.../users/user2>). Further, URIs may include query variables to define the request scope by appending them to a URI after the question mark “?”. For instance, request via GET channel to URI <. google.com/search?q=DEVS> would instruct Google search engine to return information only about keyword “DEVS”. RESTful services can be described formally using XML either using Application Description Language (WADL) [37] or WSDL 2.0 [22][38]. From distributed simulation viewpoint, there are some differences between SOAP- based WS and RESTful WS as follows: (1) SOAP groups all services as procedures and expose them via a port (i.e. addressed by single URI) whereas REST exposes each service as a resource (i.e. addressed by single URI). (2) SOAP-based WS communicates simulation information (i.e. semantics) in form of procedure parameters whereas REST defines them as XML messages. (3) SOAP-based WS transmits all SOAP messages (i.e. RPC description) using HTTP POST channel whereas REST uses all HTTP channels to transfer simulation semantics. (4) SOAP- based WS clients need to have a stub for each corresponding service while REST clients communicate in the same uniform way. (5) SOAP-based WS client stubs skeleton usually built via tools, but they still need to be written, integrated with existing software and compiled by programmers whereas REST does not usually require this process, hence follows a dynamic approach. REST critics usually raise few issues such as REST only uses the four HTTP channels to transfer all messages so that those methods might not be enough for some applications: mainly, GET (to read), POST (to append new data), PUT (to ...
Context 4
... systems, the common implementation of conservative-based distributed simulation cycle to advance simulation time (e.g. [9][10][39]) is summarized as follows: (1) Time- coordinator requests minimum time from all LPs. (2) Time-coordinator calculates global minimum time, broadcasts it to all LPs, and waits for their replies. (3) Time- coordinator instructs all LPs to execute events with the minimum global time, waits for all LPs replies, and starts again with step #1. In optimistic algorithms, each LP maintains its Local Virtual time (LVT) and advances “optimistically” without explicit synchronization with other processors. On the other hand, a causality error is detected if a LP receives a message from another processor with a timestamp in the past (i.e. with a time-stamp less than the LVT); such messages are called straggler messages. To fix the detected error, the LP must rollback to the event before the straggler message timestamp; hence undo all performed computation. Time Warp algorithms focus on providing efficient rollback by reducing memory and communication overhead such as the mechanisms presented in [15]. Distributed simulation Middleware main objective is interfacing different simulation environments, allowing synchronization for the same simulation run across a distributed network. Those simulation entities are usually heterogeneous. For example, each simulation environment may differ from other entities in its simulation engine, algorithms, model representation, and formalism. This comes as no surprise that a number of surveys placed the middleware of distributed simulation as the most area of interest to overcome current distributed simulation challenges and to meet future expectation, as indicated by a number of surveys of experts of different simulation background [6][28]. The defense sector is currently one of the largest users of distributed simulation technology, mainly to provide virtual distributed training environment between remote parties, relying on the High Level Architecture (HLA) [21] middleware to provide a general architecture for simulation interoperability and reuse. On the other hand, the current adoption of distributed simulation in the industry is still limited. Further, HLA could not make a breakthrough in the industry since its adoption in 1996 due to a number of issues such as its complexity, tied to programming languages and lack of interoperability in interfacing different Run-Time Infrastructure (RTI) vendors, since RTI-to-RTI interface is not standardized. RTI is the software layer that connects and synchronizes different HLA simulation entities (called federates) together where federates are interfaced with local RTIs via callback function interface (Figure 1). The HLA interoperability and scalability issues have caused the consideration of using existing Service-oriented architectures (SOA) technologies in distributed simulation middleware, mainly CORBA [18], SOAP-based WS [12], and RESTful WS [26]. WSDL and SOAP are the main elements enable SOAP-based Web-services (WS) interoperability. SOAP-based Web-services provides interoperability in a similar way as CORBA: WSDL corresponds to IDL role whereas SOAP corresponds to ORB data marshalling/serialization function. Further, Web-service ports addressed by URIs whereas CORBA objects addressed by references. Both ports and objects contain a collection of procedures (i.e. called services by WS) similar to a Java/C++ classes. Those procedures glue software components across the network, hence providing and RPC-style type of software interoperability, as shown in Figure 2. The server exposes a group of services via ports (Figure 2). Each service is actually an RPC where semantic are described via that procedure parameters. Client programmers need to construct service stubs with their software at compile time. Clients, at run time, consume a service by invoking its stub, which is in turn converted into XML SOAP message (to describe the RPC call), wrapped within HTTP message and sent to the server port, using the appropriate port URI. Once the message is received at the server side, the HTTP server passes the message into the SOAP layer (usually called SOAP engine like Apache AXIS [36]). SOAP engines are usually running inside HTTP servers as Java programs, called Servlets. The SOAP layer parses the SOAP message and converts it into an RPC call, applied to the appropriate procedure of the proper port. The server returns results into clients in the same way. Thus, the SOAP message role is to provide a common representation among all parties to the invoked procedure at runtime. In a distributed simulation environment, different components act as peers to each other. This means that each acts as client when it needs to send information while acts as a server via exposing different RPCs (i.e. services), as shown in Figure 2. Service providers need to publish their services, as XML WSDL documents. Clients programming stubs (Figure 2) are generated via compiling the WSDL document into programming stubs. Programmers then need to write the body of those stubs and compiling them with their software. [23][29] are examples of SOAP-based WS distributed simulation. In reality, RPCs are heterogeneous interface, since they were invented by different programmers, and need to be written and compiled before being used. RPCs also expose internal implementation, leading to impractical and complex interoperability standards. It is almost impossible to interoperate independent-developed simulation systems via RPC-style without requesting major software implementation changes. This makes it impractical to support. Further, existing solutions lack of composition scalability, for example, programming stub is needed for every remote service. However, in case of HLA the scalability is even worst, since the RTI is treated like a bus where all simulation entities use it for synchronizations. Furthermore, API complexity makes it difficult for distributed simulation to break outside expert programmers circle. RESTful WS exposes all services as resources with uniform connectors (channels) where messages are transferred between those resources through those uniform channels. REST is usually implemented using HTTP, URIs, and usually XML because these are the main pillars of the Web today. In this case, resources (services) are named and addressed by URIs, resources connectors are HTTP channels (usually called methods), and connectivity semantics are usually described in XML messages (Figure 3). RESTful applications APIs are expressed as URI templates [16] that can be created at runtime. Variables in URI templates (written within braces {}) are assigned at runtime by clients before a request is sent to the server, enabling clients to name their services URIs at the server side. For example, username in template <.../users/ {username}> can be substituted with any string to get the actual URI instance (such as <.../users/user1> or <.../users/user2>). Further, URIs may include query variables to define the request scope by appending them to a URI after the question mark “?”. For instance, request via GET channel to URI <. google.com/search?q=DEVS> would instruct Google search engine to return information only about keyword “DEVS”. RESTful services can be described formally using XML either using Application Description Language (WADL) [37] or WSDL 2.0 [22][38]. From distributed simulation viewpoint, there are some differences between SOAP- based WS and RESTful WS as follows: (1) SOAP groups all services as procedures and expose them via a port (i.e. addressed by single URI) whereas REST exposes each service as a resource (i.e. addressed by single URI). (2) SOAP-based WS communicates simulation information (i.e. semantics) in form of procedure parameters whereas REST defines them as XML messages. (3) SOAP-based WS transmits all SOAP messages (i.e. RPC description) using HTTP POST channel whereas REST uses all HTTP channels to transfer simulation semantics. (4) SOAP- based WS clients need to have a stub for each corresponding service while REST clients communicate in the same uniform way. (5) SOAP-based WS client stubs skeleton usually built via tools, but they still need to be written, integrated with existing software and compiled by programmers whereas REST does not usually require this process, hence follows a dynamic approach. REST critics usually raise few issues such as REST only uses the four HTTP channels to transfer all messages so that those methods might not be enough for some applications: mainly, GET (to read), POST (to append new data), PUT (to create/update), and DELETE (to remove). This misleading comes from naming those virtual channels as “methods” in HTTP standards (RFC 2616 [14]), hence being confused with regular programming methods. Perhaps, it is ample to mention that SOAP-based WS transfers all SOAP messages using only the HTTP POST channel, thus, single method is enough in this case. Another issue is that REST heavily depends on HTTP, on other hand; SOAP-based WS can send SOAP messages using different protocol from HTTP like TCP/IP. This is because SOAP is a message describes an RPC via a network so that it can be sent using TCP socket. This is a misleading issue because: (1) HTTP is the Web protocol, thus sending SOAP messages using different protocol from HTTP makes it not Web service any more, hence complicates interoperability with other heterogeneous even further. (2) REST is message-oriented, thus, those messages are portable to different protocols like TCP/IP. For example, all simulation synchronization messages presented here portable to different protocol, similar to SOAP. However, a universal standard is part of REST principles and makes no sense to use different protocol from ...
Citations
... Researchers have worked on combining M&S with web technologies for more than 20 years by imagineering the possibilities [33,58], proposing architectures for implementation [22,128,79,89], pondering risk, trust and accountability [18] and investigating the composability of M&S services [106,109]. In section 4 of the article "'Grand challenges for modeling and ▲ simulation: simulation everywhere-from cyberinfrastructure to clouds to citizens'" published in 2015, Tolk analyses the technical and conceptual requirements for cloud-based M&S from a high-level perspective. ...
Models of the dynamic behaviour of mechatronic systems and their simulation provide a helpful way of dealing with the systems’ inherent complexity during both development and operations. However, the current state of technology has two significant shortcomings with respect to the use and reuse of models and simulations in a distributed setting: a lack of Findability, Accessibility, Interoperability, Reusability (FAIRness) and the heterogeneity of the models’ interfaces. We explored the use of Semantic Web concepts and -technologies to provide modelling and simulation (M&S) entities and -capabilities as a service. Specifically, they were made available through a hypermedia application programming interface (API)—a service that fully implements the architectural style of the Web, Representational State Transfer (REST). This thesis shows that the approach makes sense; that it is new with respect to its specific focus; feasible; and directly useful. It is found that the approach increases the FAIRness of the exposed M&S entities and -capabilities and enables software agents to use them without being specifically programmed to do so on a syntactic level. Consequently, the problems caused by the interface heterogeneity of models are alleviated. In conclusion, the approach promotes the reuse of system models by multiple stakeholders for the development of systems as well as for the operations of distributed processes, and leads to interesting applications and further research.
... Researchers have worked on combining M&S with web technologies for more than 20 years by imagineering the possibilities (Fishwick, 1996;Mckee et al., 2017a), proposing architectures for implementation (Cubert and Fishwick, 1997;Al-Zoubi and Wainer, 2011;Ribault and Wainer, 2012;Shekhar et al., 2016), pondering risk, trust and accountability (Cayirci, 2013a) and investigating the composability of M&S services (Tolk, 2013;Tolk and Mittal, 2014). Below, we will elaborate what we perceive as the key aspects of MSaaS. ...
In this contribution, initial results of a research project on modelling and simulation as a service (MSaaS) within the context of optimal operation of distribution grids by exploiting flexibility are summarized. Based on a brief description of service-oriented architecture (SOA), definitions and key aspects of MSaaS as well as open conceptual and technical challenges are outlined. Some specific aspects and challenges are then related to a possible application: a service that predicts the flexibility that a power-to-heat system can offer is implemented as an instance of MSaaS. The calculations are based on the current state of the system and a model defined in the equation-based, object-oriented language Modelica, as well as historical data when available. Thereby, an accurate and reliable representation of the flexibility becomes available that facilitates its use for system balancing, energy market participation and grid operations. This functionality is exposed through a representational state transfer (REST)-based service interface, designed to allow for the straightforward integration with existing systems and other virtual resources. The service architecture and initial results of the implementation are described.
... However, many web-based simulation systems are under the control of single team or a closed community, using interfaces that are tied to their implementation. 9,10 Instead, the RESTful Interoperability Simulation Environment (RISE) middleware 10,11 uses RESTful web services to hide all the functionalities in resources named with uniform resource identifiers (URIs). These URIs are connected to each other via uniform virtual channels in which simulation synchronization is achieved via XML messages using hypertext transfer protocol (HTTP) methods. ...
... rule : { (0,0,0) + trunc(uniform(1,9)) + 1/ 1000 } 1 { trunc(0,0,0) = 1 and (0,0,0) != 0 } Life cycle of diamondback moth. ...
We introduce an integrated framework for modeling and simulation of ecosystems based on cellular models. The framework integrates cellular modeling, web-based simulation, and geographic information systems (GISs) for data collection and visualization. In this framework, data extraction from GISs is automated; we use the Cell-DEVS formalism for modeling the ecosystem and the CD++ cellular modeling tool within the RISE (RESTful Interoperability Simulation Environment) middleware for web-based simulation. The simulation results are easily integrated with Google Earth data for visualization. We discuss the design, implementation, and benefits of the integrated approach for modeling and simulation in spatial analysis of ecosystem services. We show different case studies in the area of ecological systems, demonstrating how to apply the framework, its usability, and flexibility. We focus on the use of models available in remote servers, their integration with GIS data for inputs, and georeferenced visualization of the results. We show how the modeling methods based on DEVS and their modular interfaces make it easy to build such an architecture and we discuss its application to the field of environmental systems.
... In contrast, SIMaaS does not provide any such scheme; rather it relies on the OS to make effective use of the multiple cores on the physical server by pinning container processes to cores. The RESTful interoperability simulation environment (RISE) [3] is a cloud middleware that applies RESTful APIs to interface with the simulators and allows remote management through Android-based handheld devices. Like RISE, SIMaaS also uses RESTful APIs for clients to interact with our service and for the internal interaction between the containers and the management solution. ...
Many seemingly simple questions that individual users face in their daily lives may actually require substantial number of computing resources to identify the right answers. For example, a user may want to determine the right thermostat settings for different rooms of a house based on a tolerance range such that the energy consumption and costs can be maximally reduced while still offering comfortable temperatures in the house. Such answers can be determined through simulations. However, some simulation models as in this example are stochastic, which require the execution of a large number of simulation tasks and aggregation of results to ascertain if the outcomes lie within specified confidence intervals. Some other simulation models, such as the study of traffic conditions using simulations may need multiple instances to be executed for a number of different parameters. Cloud computing has opened up new avenues for individuals and organizations with limited resources to obtain answers to problems that hitherto required expensive and computationally-intensive resources. This paper presents SIMaaS, which is a cloud-based Simulation-as-a-Service to address these challenges. We demonstrate how lightweight solutions using Linux containers (e.g., Docker) are better suited to support such services instead of heavyweight hypervisor-based solutions, which are shown to incur substantial overhead in provisioning virtual machines on-demand. Empirical results validating our claims are presented in the context of two case studies.
... They use GET operations to read resource data, PUT operations to create new resources or update them, and DELETE to remove a resource. For example, a simple session could include the following sequence: [16] and [17]. Although RISE can manage different simulators, we have a using CD++, a simulation toolkit based on the DEVS and Cell-DEVS formalisms. ...
We discuss the design and development of an infrastructure for serious gaming applications using a formal Modeling and Simulation environment based on the DEVS formalism. The research uses the RISE simulation middleware services to build a serious game application that can be deployed on a mobile device using a properly developed mobile client. We propose a mobile client that leverages the cloud services provide by a RISE server to obtain simulation data to be used in a serious gaming application. In particular, our prototype provides a stock trading game. The simulation model is based on a Brownian motion economic model that has been analyzed comparatively to real data.
... In this way, users can reuse and share simulation resources on-site without worrying about the limitations of their local workstations in terms of processing power or memory capacity. SOAP-based Web Services use the Remote Procedure Call (RPC) to allow two distributed heterogeneous systems to call the functions of each other; but it exposes the implementation details and lacks scalability [21]. Another better way is to use RESTful Web Services. ...
... Access to RESTful Web Services is through Web resources (URIs) and XML messages using HTTP methods (GET, PUT, POST and DELETE). Based on these ideas proposed in [21], the authors presented the RESTful Interoperability Simulation Environment (RISE) middleware. The main objective of RISE is to support interoperability and mash-ups of distributed simulations regardless of the modeling formalism, programming language, or simulation engine. ...
... As discussed in section 2, RESTful Web Services can further increase the scalability in terms of the plug-and-play interoperability and availability. In [21], the authors presented the first existing RESTful Interoperability Simulation Environment (RISE) middleware. RISE is accessed through Web resources (URIs) and XML messages using HTTP methods. ...
In this paper, we discuss how Cellular Discrete Event System Specification (Cell-DEVS) theory can be used in modeling and simulation of the crowd. We will show that the efficient cell update mechanism of Cell-DEVS allows for more efficient entity-based simulation of the crowd compared to cellular automata. On the other hand the formal interfacing mechanisms provided by this theory allows for integration of other components such as DEVS atomic processing component or visualization and building information modeling components with the Cell-DEVS model. Finally, we describe in details of the design and development of several pedestrian models and present the results.
... In the future, we will also include the synchronization of the right tool pane with the online CD++Repository, to extend the set of models to be reused and facilitate searching and uploading models. Likewise, we will explore the integration with different versions of the simulator using Web Services [32] or the RISE middleware [33], which would allow the users to use a lightweight client on their computers and running advanced simulations on high performance servers remotely. ...
We introduce CD++Builder, an open-source environment that aims at providing easy-to-use graphical modeling tools to simplify the construction of models and the execution of simulations of complex Discrete Event System Specification (DEVS) models. The architecture and implementation of CD++Builder focuses on providing simple definition and reuse of components, offering easy extensibility to support new features. CD++Builder includes graphical editors for DEVS-coupled models, DEVS-Graphs and C++ atomic models; it provides code templates that are synchronized with their graphical versions, and it greatly simplifies the software installation and update procedures. We show how this environment can be used to build and simulate DEVS models, and we compare the process with previous versions and other simulation tools, showing that CD++Builder can improve model development by creating DEVS models in a completely assisted manner, including advanced graphical interfaces.
... In particular, many advanced implementations are now built on SOAP Web Services to communicate (Wainer and Al-Zoubi 2010). Nevertheless, building SOA-based simulations is still complex, as the services usually address the interoperability of simulation engines at a low level of abstraction (Wainer et al. 2010;Wainer and Al-Zoubi 2011). The Grid and Cloud models of computation have some limitations. ...
... Although this experiment was successful, the development required a considerable implementation effort (approximately 2160 person/hours), mostly due to the utilization of a SOA-based solution. Instead, we have had success with a new RESTful Web Services interface, called RISE (Restful Interoperability Simulation Environment), which can solve these issues by imitating the Web interoperability style (Ribault and Wainer 2012;Al Zoubi 2011 Al Zoubi and). The Representational State Transfer style can help solving the interoperability limitations, and it makes easy the development of mashups, which can be developed in a shorter period of time (for instance, the last clients we developed, which will be adapted for this research project took only 375 person/hours for the same simulation environment discussed above). ...
It has been a decade since the Workshop on Grand Challenge for Modeling & Simulation (M&S) was held at Dagstuhl in Germany (www.dagstuhl.de/02351). Grand challenges provide a critical focal point for research and development and can potentially create the critical mass needed to bring substantial transformation and benefit to a community. The Workshop addressed a wide variety of M&S theoretical, methodological and technological issues across many application areas. This Panel reflects on progress made since the Workshop, new Grand Challenges that have emerged over the past ten years and key M&S milestones for the next decade.
... In the future, we will also include the synchronization of the right tool pane with the online CD++Repository, to extend the set of models to be reused and facilitate searching and uploading models. Likewise, we will explore the integration with different versions of the simulator using Web Services [32] or the RISE middleware [33], which would allow the users to use a lightweight client on their computers and running advanced simulations on high performance servers remotely. ...
... Instead, the Representational State Transfer style (REST) focuses on the resources more than on the operations, solving the interoperability limitation and making easy the development of Mash-Ups [7] (which reuse and combine existing services to build a new web application). Based on these ideas, in [8] we introduced the first existing RESTful Interoperability Simulation Environment (RISE) middleware. ...
... They use GET operations to read resource data, PUT operations to create new resources or update them, and DELETE to remove a resource. For example, a simple session could include the following sequence: [8]. Although RISE can manage different simulators, we have a using CD++, a simulation toolkit based on the DEVS and Cell-DEVS formalisms. ...
In recent years, numerous applications have been deployed into mobile devices. However, until now, there have been no attempts to run simulations on handheld devices. We want investigate different architectures for running and man-aging simulations on handheld devices, and putting the simula-tion services in the Cloud. We propose a hybrid simulation and visualization approach, where a dedicated mobile application is running on the client side and the RISE simulation server is hosted in the Cloud. In particular, with our prototype, we ex-plore the remote management of a simulation tool using a ded-icated native application running on an Android Smartphone, and showing the evolution of a simulation model for a forest fire spread, mashing-up the generated graphics with online GIS services.
