DDSOS: A Dynamic Distributed Service-Oriented ... - CiteSeerX

The 39th Annual Simulation Symposium (ANSS), Huntsville, AL, April 2006, pp. 160-167.

DDSOS: A Dynamic Distributed Service-Oriented Simulation Framework1 W. T. Tsai, Chun Fan, Yinong Chen Computer Science and Engineering Department, Arizona State University, Tempe AZ 85281 {wtsai, fanchun, yinong}@asu.edu Ray Paul Department of Defense, Washington D.C. USA [email protected] including DIS [9][10], ALSP [1], and HLA [11][12][13], XMSF (Extensible Modeling and Simulation Framework) [3][17] and the simulation grid system Cosim-Grid [14]. Service-oriented architecture (SOA) has emerged, as a new software development paradigm in recent years, in which major activities in application building are integrating existing services to deliver required functionalities. New simulation environments must provide facilities to simulate such activities of SOAbased applications. Pioneering work in this direction has been done in XMSF and Cosim-grid. The XMSF attempts to create a modeling and simulation framework that utilizes a set of web-enabled technologies to facilitate a new generation of modeling and simulation applications. XMSF involves Web/XML, Web services, and Internet/networking to improve the interoperability. One of the most significant pioneering steps made by XMSF is the XMSF web-based RTI. The XMSF RTI implements web application interface for the HLA/RTI such that the HLA/RTI can be accessed using Internet communication protocols such as SOAP and BEEP. XSMF and its Web-enabled RTI pave the initial step of using Web services for connecting simulations to different platforms. However, it is not sufficient to meet the specific requirements in building simulations in an SOA environment. For example, assume there are several client federates using the Web-enabled RTI to form a functional RTI. If one of the client federate fails, the entire simulation federation will have to halt and to restart when the failed client federate is recovered. An SOA application has the ability to dynamic reconfigure and reintegrate the system when services leave and join the system. Cosim-Grid [14] is a service-oriented simulation grid based on HLA, PLM (Product Lifecycle Management) [16], and grid/Web services. It applies

Abstract This paper presents the DDSOS framework developed at Arizona State University, which supports the simulation, development, and evaluation of large scale distributed systems such as network-centric and system-of-systems applications. The distinct features of the framework include automated simulation code generation from the specification, code deployment, simulation of different architectures with a templatebased platform builder, service-oriented multi-agent simulation for easy reconfiguration, and dynamic analyses of results from evaluation and monitoring. The framework and the associated tools have been implemented and applied in several governmental and industrial projects. Keywords: Distributed simulation, multi-agent simulation, service-oriented architecture, modeling language

1. Introduction Driven by problems raised in economic and technologic developments, especially the requirements from mission-critical applications, the modern modeling and simulation research is rapidly advancing in the past years. Many of these problems require distributed and collaborative solutions which cannot be modeled or simulated by employing a simplex simulation system. Distributed simulation techniques have been developed to address these problems. Distributed simulation techniques can be categorized into two groups: distributed analytic simulations and distributed virtual environments [4]. A number of modeling and simulation frameworks using distributed techniques have been developed, 1

The work is partially supported by US Department of Defense and by National Science Foundation.

1


to policy-based computing systems such as Global Information Grid (GIG) [7]. In the entire process, only the PSML-S model (specification) needs to be written manually and the required services are assumed to be available in libraries or service repositories. All the remaining steps can be performed using automated tools. Reconfiguration and recomposition of the simulation can also be done automatically at runtime. A part of DDSOS framework has been presented in [23]. However, [23] focuses more on the application of the framework, the case study and simulation results. This paper discusses more details about how the simulation agent services are built and how they work, along with the dynamic simulation configuration management and dynamic simulation code load/unload. Comparing to [23], more technique details are explored in this paper. A two-layered model-driven simulation development approach is adopted recently and presented only in this paper.

OGSA (Open Grid Services Architecture) [15] to modeling and simulation to improve HLA in terms of dynamic sharing, autonomy, fault tolerance, collaboration, and security mechanisms. In terms of service-oriented architecture, Cosim-grid exposes its gird resource as services. These resources include scheduling broker, grid data access optimization, grid monitoring, grid data replication, etc. Similar to XMSF Web-enabled RTI, Cosim-grid starts adopting services as the basis to implement the simulation framework. However, the dynamic management of the services in Cosim-grid does not have the mechanisms to manage and to simulate services that implement fault-tolerant computing and reliability evaluation, which are critical in service-oriented computing in a unreliable internet environment. Both XMSF and Cosim-Grid utilize Web services as components in the component-based development without fully exploring the potential of the SOA (Service-Oriented Architecture) [19]. Thus the frameworks do take many advantages of SOA, such as dynamic reconfiguration and recomposition. The DDSOS (Dynamic Distributed ServiceOriented Simulation) framework presented in this paper aims at providing comprehensive support to the development and evaluation of SOA-based networkcentric and system-of-systems applications in their development phases. It also provides necessary supports to build SOA based simulation federations rapidly and efficiently. In the specification phase, a Process Specification and Modeling Language for Services (PSML-S) is provided for clients to model and specify the target system [22]. Model checking is performed to verify that certain properties hold in the specification [8]. Completeness and consistency analyses can also be performed [21]. During model checking, test cases can be generated for further testing. After model checking, an automated code generation service generates executable code based on the target system’s PSML-S model and the client-specified configuration. The PSML-S and the automated code generation deal with the high-level composition based on existing atomic functions (services), such as library functions and services in remote repositories that can be searched, discovered, and invocated. The generated code is then deployed to the distributed simulation services using the automated deployment service. Then the executable code is tested (validated) in the simulation environment using the test cases generated during the verification phase. The DDSOS framework also allows dynamic policy specification, verification, and enforcement via simulation as add-ons [23], which can provide support

2. The Architecture of DDSOS This section gives an overview of the DDSOS framework and how a functional simulation federation can be built using this framework.

2.1 SOA and DDSOS Framework Under SOA, software development is performed by three parties: Service providers, service brokers, and service requesters (application builders). Individual services have standard interfaces are developed independently. They are submitted to service brokers and listed in their service directory or repositories. The application builders search, find, bind, test, verify, and execute services in their applications at runtime. This new paradigm of application development gives the application builders the maximum flexibility to choose the best service brokers and the best services. The DDSOS framework integrates the SOA and simulation concepts. The framework supports modeling and simulating systems with the distributed, interactive, discrete–event driven focuses. The DDSOS framework provides the following services and tools: • Two layers of modeling support. At the upper layer, a high-level component and relation diagram model is specified. At the lower level layer, the PSML-S language is used for describing detailed process specifications, assuming that service providers can provide required component services. Models specified in both layers can be verified and

2


environment simulation agent services. By separating the system simulation agent services and the environment simulation agent services, one can easily change either one of the simulated environment or system without affecting the other. Thus the simulation clients can experiment the same system under different environments or study the behavior of the different system configuration under the same environment by changing one part of the simulation services only. Each of the system and environment simulation agents has a simulation engine to perform the real simulation’s computation tasks. The simulation code is like the plug-ins to the simulation engine such that the same simulation engine can be reused for different simulation federations. As a utility tool, the client control console is provided to the application builder or the simulation environment clients. The console can analyze the model (specification) of the target system written in PSML-S, convert the model to the constructs the simulation federation configuration, generate the simulation code based on the client specified configuration, bind with the required services through remote invocation to the application.

validated before being used for simulation. V&V activities can be applied are discussed in [8][21]. • An On-Demand Automated Dynamic Code Generator (service) can generate executable code for simulation and for real applications directly from the model (specification) written in PSML-S. • An On-Demand Automated Dynamic Code Deployment Service can support rapid and automated simulation/real-code deployment. • Simulation engines that carry out simulation tasks form a simulation federation (in HLA terms [11][12][13]). These engines can be geographically distributed on simulation services that are interconnected via an intranet and/or the internet. • An Extended Runtime Infrastructure to support the simulation services’ operations. As suggested in [4], the simulation engines here are separated from the target system model which makes the DDSOS framework flexible and generic. The design and implementation of the DDSOS framework follows the SOA concept and the system consists of three groups of components: services, a service directory, and the application. As shown in Figure 1, the service manager serves as the service directory, in which applications can look up the desired services. All the constituent services, including RunTime Infrastructure (RTI) services, system simulation agent services, environment simulation agent services, and other services, must register to the service manager before they can be utilized for building a simulation federation. The client control console can directly communicate with the selected services after it finds the information of these services from the service manager.

2.2 Model driven simulation DDSOS utilizes a two-layer modeling approach. At the upper layer, the target system’s components and the relationship among the components are specified, which is similar to Microsoft Visual Studio 2005 (Whitehorse) graphic model [24]. At the lower layer, PSML-S is utilized to specify the more detailed system specifications. The upper layer system architecture specified can be automatically converted into PSML-S (Process Specification and Modeling Language for Services) model. Thus, various analyses can be performed on the system architecture to ensure the correctness. First the upper layer system architecture can be translated to a high level PSML-S model where each block will be mapped to a highest level Actor element and connections will be mapped to Event elements owned by those Actor elements. Simulation users then can further decompose these high level PSML-S model elements into lower level ones to represent the target system in different levels of details. PSML-S is the modeling and specification language used in the DDSOS framework to model the target systems [22]. The model elements or constructs of the language include Actors, Actions, Attributes, Conditions, Data, Events, and their Relations. A sequence of the model elements represents a behavior of the service called a process. In other words, a client

Figure 1: SOA architecture of DDSOS framework

The RTI services provide necessary simulation runtime support for a simulation federation such as simulation time management and communication coordination. The real simulation tasks are performed by the system simulation agent services and the

3


the simulation federation via the client control console service. After receiving the client’s requests for looking up available simulation services, the client control console service will contact the service manager for the desired services and return the query results. The client then can use the client control services to bind the real simulation services to the virtual configuration. This approach supports the dynamic service binding. Once all the virtual services in the configuration have been bound to real services, the client control console service can then deploy the generated simulation code and runtime configurations to the specified simulation services to run the simulation. After the simulation run, the client can retrieve the simulation results from the participating simulation services. RTI service component RTI service component in DDSOS framework provides similar functionalities as that of HLT/RTI, which includes: ownership management, event management, time management, federation management service, code generation service, policy enforcement service, and reliability assessment. On top of the RTI service are the simulation engines which reside inside the simulation services providing wrappers and interfaces for the simulation applications. As has been discussed, there are different simulation engines: • System simulation engines: They are used to simulate the components of the target system modeled using the PSML-S; • Environment simulation engines: They are used to simulate the external environment that the target system will reside in. • Simulation meta engines: They are used to perform the tasks such as data collections and runtime dynamic policy enforcement. • Simulation adapter: It is used to provide a middleware between the real world participants and the simulation to make the hardware-in-the-loop and man-in-the-loop simulations possible. All these simulation engines depend on the services provided by RTI to correctly perform a designated simulation task since individual simulation services don’t have to know each others' existence and all the communications are conducted through RTI services. System simulation service component Figure 2 illustrates the structure of a system simulation agent service. It has a standard Web service interface that can be accessed by computer programs and a traditional standalone application GUI interface for human users to manage and to use the service conveniently. A third type of interfaces is provided through the MSMQ (Microsoft Messaging Queue) to

must specify their tasks using the model elements and processes. Application building starts from specifying elements in the PSML-S model generated from the upper level architecture by decomposing it. Once the specification for a system is ready, the builder can build the process model for both the system and its environment. Since the environment may also impact the target system behavior, it is necessary to take the external environment into account when modeling the target system. After the process model specification is completed, a variety of static analyses can be performed on the model, such as C&C (Completeness and Consistency) analysis and model checking. The detailed discussions on C&C and model checking are discussed in [8][21]. As has been discussed in [23], business logic specified in PSML-S model using processes can be systematically and automatically translated into simulation tasks that can be executed by the simulation engine. Events are the only method through which different Actors can communicate with each other. An Event can carry parameters to provide further information for the receiver to make decision on how to response to the incoming Event. Once the simulation tasks are specified in the PSML-S language, the automated code generation service can be applied to translate the processes into executable.

2.3 Main service components in DDSOS This section discusses the main components and their services in the DDSOS framework. Simulation client control console service This service serves as the interface between the simulation clients (application builders) and the DDSOS framework. The clients can edit and view the PSML-S model of the target system via the client control console service. Then the clients can build the simulation federation configuration, based on the target PSML-S model using any of the following methods: • Building the entire simulation federation configuration from the scratch; • Modifying existing simulation federation configuration; • Applying and modifying pre-defined simulation templates. The simulation federation configuration that we built is called a virtual configuration, because clients do not have to specify what real system/environment simulation agent services will be used for the simulation federation. Once the virtual configuration is ready, a client can look up services that can be used for

4


simulation scheduler class, which defines all necessary standard interfaces for a simulation engine to work in a system simulation agent service. That is to say that DDSOS framework can provide not only a mechanism through which clients can rapidly build a functional simulation but also the freedom and flexibility for clients to extend the framework to implement their own requirements. Environment simulation service component Similar to the system simulation agent services, an environment simulation agent service has two different interfaces. One is the Web service interface of the environment simulation agent service, which allows the computer programs to access and use the environment simulation agent service, and the other is traditional stand alone application GUI interface which allows the human users to manage and use the service. The core of an environment simulation agent service is the environment simulation engine, which can generate external simulation events based on the client-specified event generation rules and send them to the simulation federation at runtime. A client can deploy event generation rules and simulation runtime configuration at runtime. The event generation rules specify how the environment simulation agent service shall feed the simulated external events to the system simulation. The main elements of an event generation rule include: • Event Generation Rule ID: The unique identification for an event generation rule deployed to an environment simulation agent service. • Event Generation Rule Name: This is a literature name that clients can specify. • Event ID: This ID is for the event element specified in the PSML-S model of the target system. • Start Time Point: It specifies the time point when the events begin to be fed into the simulation. • Start Time Point Included: This attribute is of Boolean type. If its value is true, the specified events are allowed to be sent to the simulation at the given start time point. Otherwise, the specified events will not be sent to the simulation. • End Time Point: It specifies when the environment simulation agent service shall stop sending events to the simulation. • End Time Point Included: This attribute is of Boolean type. If the value is true, the specified events are allowed to be sent to the simulation before the end time point. Otherwise, the specified event will not be sent to the simulation. The Start Time Point and the End Time Point specifies a continuous period of simulation time.

make it possible for legacy distributed applications such as those utilizing Microsoft DCOM or Remoting technologies to communicate and work together with the system simulation agent services in the DDSOS framework.

Figure 2: A system simulation agent service

There are two message queues between the simulation engine and the Web service interface. One is for incoming events and the other is for incoming commands to the system simulation service. The simulation engine will always listen to the two queues. If there is an incoming event, the incoming events will be appended to the queue waiting to be processed by the simulation engine. If there is an incoming command, the simulation engine will immediately interpret the command and perform requested tasks such as starting the simulation, load/unload the simulation code and configuration, and reset the simulation queues. Task queue is especially for a multi-tasking simulation engine. In this type of engine, the engine can process multiple incoming events at the same time. Thus there will be more than one active simulation task. The simulation task queues are used to properly store the runtime simulation tasks for proper scheduling. The simulation engine can directly use the RTI services for communication and synchronization. Simulation runtime configurations require certain information that can be obtained only at runtime, for example, what RTI service(s) will be used in this simulation federation and what events this system simulation agent service will consume. These kinds of information will be automatically generated during simulation code generation and deployed to the system simulation agent services at runtime. In a system simulation engine, not only the simulation code and simulation runtime configurations but also the simulation engine itself can be dynamically changed. The clients are given the capability to build their own simulation engine for their specific requirements by extending the provided base

5

The 39th Annual Simulation Symposium (ANSS), Huntsville, AL, April 2006, pp. 160-167. • Max Number of Events: This attribute specifies the maximum number of events allowed during the specified time period. • Min Number of Events: This attributes specifies the minimum number of events that must be sent to the simulation during the specified time period. • Distribution Type and Average Number of Events: These two attributes together specify how the events will be distributed in the given time period. • Process to Handle This Event: This attribute is not specified by the client. It is extracted from the PSML-S model of the target system. It displays what processes in the PSML-S model are specified to handle the specified event. Similar to the system simulation agent services, the simulation runtime configurations are automatically generated and deployed to the environment simulation agent services at runtime. Once the runtime configurations are deployed, the environment simulation agent services are able to communicate with the RTI service(s) to perform various tasks such as sending out generated events. Other simulation service component Besides the system and environment simulation services discussed above, there are other types of simulation services such as global policy checking services, global simulation result analysis services, and simulation runtime monitoring services. These services provide support to clients to perform simulation related tasks. These simulations follow the same design philosophy which provides service-oriented computing capability while still keeps the backward compatibility with applications written using DCOM and Remoting.

partitioned and distributed across the available simulation services, what simulation services will be utilized for the simulation federation, and how the simulation will be driven. The DDSOS framework provides an easy way for clients to configure the desired simulation federation without knowing what simulation agent services are available, through a virtual configuration. The client only needs to decide how many services and what types of services will be used in the simulation and what processes to deploy to what services to build the virtual configuration. The client can dynamically bind actual services to the virtual configuration to build the concrete configuration. A virtual simulation configuration can be built by following the steps below (also see [23]): • A client selects the target system process model to be simulated • A client decides how many services and the types of the services to be used for this simulation • A client specifies o what Actors reside in what system simulation services. o what environment specifications (event generation rules) reside in what environment simulation services.

3.2 Code generation and deployment Automated simulation code generation and deployment are key services to reduce the effort that clients spend on building a simulation federation. In traditional simulation frameworks such as HLA/RTI or DevsJava, after building the model of the target system, clients still have to manually translate the model into the code of a programming language. This process usually is error-prone and costly. In the DDSOS framework, the executable code can be generated automatically based on the PSML-S model, the simulation federation configuration, and the constituent services. In this section, the focus will be put on how automated simulation code deployment is realized in DDSOS. Once the simulation code, clients can use the automated deployment service provided by the DDSOS framework to deploy the code onto the simulation services. The simulation code deployment is performed according to the client specified concrete simulation federation configuration. Each simulation service, including the RTI and system/environment simulation agent services, has the standard Web service interface to receive the generated code and configurations. The runtime simulation configurations are all plain text files,

3. Basic Services Provided by DDSOS This section presents the main functions of the DDSOS framework performed by six basic services: simulation configuration, simulation code generation, simulation code deployment, event space, and simulation re-composition. Due to the space limitation, only the dynamic simulation configuration management and automated code deployment will be discussed in this section. Brief discussions about other services can be found in [23]. How to achieve higher performance and reliability in DDSOS is discussed at the end of this section.

3.1 Simulation federation configuration Simulation federation configuration is one of the most important parts in the DDSOS framework. It specifies how the entire simulation federation is

6


code. After the simulation code is deployed onto a simulation agent service, the service will create a new application domain and load the binary code file into this newly created application domain. Then the simulation agent service is free to invoke any functions and to access any data in the deployed simulation code through reflection techniques. When a new set of simulation code need to be deployed, the simulation agent service can simply unload the additional application domain and create another new application domain to host the new set of simulation code. Since the simulation agent service accesses the functions and data in the deployed simulation code through reflection, i.e., only the names of the functions and data are needed to use them, this dynamic loading and unloading is totally transparent to the simulation engine. Without this feature, the dynamic simulation reconfiguration and re-composition can not be easily implemented.

which is easy to transfer these data between Web services using XML-based SOAP (Simple Object Access Protocol), because text is the native data type of SOAP. However, if the simulation code is compiled into binary code, transferring binary data between Web services using SOAP involves more work [2]. Traditionally, there are two main techniques to transfer binary data using XML: “by value” and “by references”. The former is to embed binary data as elements or attributes. XML supports binary data as content through the use of base64 or hexadecimal encoding, which are two data types in XML schema – xs:base64Binary and xs:hexBinary. In this way the binary data are transfer in the SOAP message as follows: /aW0KaxGGyQ= sdcao2JTgXE= Faa7vaOi2jQ=

In this example, the binary data are embedded in the message as the content of elements photo, sound, and hash, respectively. The latter technique is to put the URL or URI of the binary data as the content of the XML message. The receiver is responsible to extract the URL or URI to fetch the real data using HTTP protocol. In this way, the references of the binary data are transferred between the web services. Following is an example of a XML message using this technique.

Figure 3: Code generation and deployment

In the DDSOS framework, the former technique is adopted using base64 encoding. In this way, the deployment of the simulation code and configuration for a simulation service need one message only, which can avoid additional network traffic caused by data fetching actions in the latter technique. Another important issue is that simulation services should be able to dynamically load/unload generated simulation code. This will help achieving highest possible flexibility and reusability as well as enabling the dynamic simulation reconfiguration/re-composition. In order to do this, a new application domain is introduced besides the default application domain used by a simulation agent service to achieve dynamic loading/unloading, as illustrated in Figure 3. The ‘Loader’ marks the default application domain in a simulation agent service, and the ‘RemoteLoader’ marks the additional application domain used for dynamic loading and unloading deployed simulation

4. Conclusions This paper presented the service-oriented and distributed multi-agent DDSOS framework. This framework supports modeling and simulation of complex systems, with automated code generation, verification via model checking, validation via testing and policy enforcement. The DDSOS framework is based on the service-oriented architecture which allows different application architectures to be simulated. A scalable scheduler is used to switch between application and system support and thus allowed various features to be added to the simulation. Up to now, four versions of the DDSOS framework with supporting tools have been developed and have been applied in several real-world applications/ projects. These applications have shown the effectiveness of the DDSOS framework. A new version of the DDSOS

7


[17] XMSF SAIC Web-Enabled RTI, 2003. http://www.movesinstitute.org/xmsf/projects/WebRTI/ XmsfSaicWebEnabledRtiDecember2003.pdf [18] D. C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Wiley & Sons, 2000. [19] M. P. Singh, M. N. Huhns, Service-Oriented Computing, John Wiley & Sons, 2005 [20] T. Tsai, Weiwei Song, Ray Paul, Zhibin Cao, Hai Huang, Services-Oriented Dynamic Reconfiguration Framework for Dependable Distributed Computing, COMPSAC 2004, September 28-30, 2004, Hong Kong, pp.554-559. [21] W. T. Tsai, Y. Chen, R. Paul, H. Huang, X. Zhou, X. Wei, "Adaptive Testing, Oracle Generation, and Test Script Ranking for Web Services," 29th Annual International Computer Software and Applications Conference (COMPSAC), Edinburgh, Scotland, July 25-28, 2005, pp. 101-106. [22] W.T. Tsai, Ray A. Paul, Bingnan Xiao, Zhibin Cao, Yinong Chen, "PSML-S: A Process Specification and Modeling Language for Service Oriented Computing", the 9th IASTED International Conference on Software Engineering and Applications (SEA), Phoenix, November 2005. [23] W. T. Tsai, C. Fan, Y. Chen, R. Paul, "A ServiceOriented Modeling and Simulation Framework for Rapid Development of Distributed Applications, to appear in Simulation Modelling Practice and Theory, Elsservier, 2006. [24] Bridge the gap between development and operations with Whitehorse, Brian A. Randell and Rockford Lhotka, http://msdn.microsoft.com/msdnmag/issues/ 04/07/whitehorse/default.aspx

framework is being developed to include more features such as dynamic reliability assessment and distributed policy enforcement.

References [1] [2]

[3]

[4] [5] [6]

[7] [8]

[9] [10]

[11]

[12]

[13]

[14]

[15] [16]

Aggregate Level Simulation Protocol, http:// alsp.ie.org/alsp/ XML, SOAP, and Binary Data, Adam Bosworth (Microsoft), Martin Gudgin (Microsoft), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Jeffrey Schlimmer (Microsoft), 2003. http:// www.xml.com/pub/a/2003/02/26/binaryxml.html#2_1 Donald Brutzman, Michael Zyda, J. Mark Pullen, and Katherine L. Morse, Exntensible Modeling and Simulation Framework (XMSF): Challenges for WebBased Modeling and Simulation, Findings and Recommendations Report of the XMSF Technical Challenges Workshop and Strategic Opportunities Symposium, October 2002. http://www.movesinstitute. org/xmsf/XmsfWorkshopSymposiumReportOctorbler2 002.pdf D. Chappell, Enterprise Service Bus, O’Reilly Media, 2004 Enterprise service bus Q&A: http://www.ebizq.net/ hot_topics/esb/features/6117.html?&pp=1 R. M. Fujimoto, "Parallel and Distributed Simulation", Proceedings of Winter Simulation Conference, edited by P.A. Farrington, H.B. Nembhard, D.T. Sturrock, and G.W. Evans, 1999, pp. 122 – 131. Global Information Grid (GIG): http:// www.nsa.gov/ia/industry/gig.cfm?MenuID=10.3.2.2 H. Huang, W. T. Tsai, R. Paul, Y. Chen, "Automated Model Checking and Testing for Composite Web Services", 8th IEEE International Symposium on Object-oriented Real-time distributed Computing (ISORC), Seattle, May 2005, 300-307. IEEE Std 1278.1-1995. IEEE Standard for Distributed Interactive Simulation – Application Protocols, 1995. IEEE Std 1278.2-1995. IEEE Standard for Distributed Interactive Simulation – Communication Services and Profiles, 1995. IEEE Std1516-2000: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) Framework and Rules, 2000. IEEE Std1516.1-2000: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification, 2000. IEEE Std1516.2-2000: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification, 2000. B.H. Li, X. Chai, Y. Di, H. Yu, Z. Du, and X. Peng, Research on Service Oriented Simulation Grid, Autonomous Decentralized Systems, ISADS 2005 Proceedings, April 4-8, 2005, pp7- 14 Open Grid Services Architecture: http:// www.globus.org/ogsa/ IBM Product Lifecycle Management: http://www03.ibm.com/solutions/plm/index.jsp

8