Overview of the architecture
The architecture of a Web Service and ULA based collaborative product design environment is shown in Fig.1. In the framework, the web-based technology is used to provide the remote communication with the user clients, while ULA is adopted primarily for the simulation connection. Through the ULA adaptor, simulation modules can join the HLA federation of a simulation application. The introduction of Web Service architecture helps to implement M&S (modeling and simulation) via the Internet, since current available HLA applications only support LAN distributed modules of simulation, which is a barrier for modern product development [8]. The client-server type of architecture is adopted, in which interactions between the server and client are realized by invoking Web Service published by them. The server executes all of the solid modeling operations, such as feature creation and conversion, maintenance of feature validity, and handles concurrency and synchronization of clients. These operations are accessible to the clients in the form of Web Service.
The client mainly provides facilities for the user’s modeling operations into the invocation of Web Service provided by the server. In order to lower network load, only high-level semantic messages (such as specifying operations and data needed to update the client user interface) are transferred between the server and client. The data transferred from the client to the server is in the form of CSCW request, which only specifies the request type and corresponding parameters, and the data transferred from the server to clients is in the form of CSCW response containing operation type and product data needed to update client display if necessary. Also, CSCW events, generated during the design process, are transferred between the clients and the server. The client user interface is updated incrementally by XML, i.e., only the changed, not the whole product data, is transferred. This ensures great reduction of the data amount transferred between the server and client, decrease in time delay of operation, and enhancement of the system response ability.
Session manager
The server not only executes the operations committed by clients but also coordinates and synchronizes clients’ operations in order to make sure that the modeling operations will not conflict. It is the task of the session manager to synchronize session participants to maintain the integrity and validity of solid modeling operations. It provides functionalities to start, join, leave and close a modeling session and manages all information streams between the clients and the kernel modeling system. As shown in Fig.2, the session manager consists of Request Arbitrator, Client Agent, Client Profile and Session Profile. Each of the session participants is assigned a Client Agent by the session manager. The Client Agent handles all the information between the client and server, collects and parses client’s request and hands it to the Request Arbitrator. The Request Arbitrator then selects one operation and passes the request to the kernel modeling system to execute according to certain arbitrating rules by resorting to the client profiles and the type of the operation. The Request Arbitrator also coordinates concurrency and synchronization of client’s operations. Synchronization is the process if propagating evolving data in order to keep the information consistent in a distributed environment. Two types of information can be distinguished here: (1) updated feature model data, and (2) updated state information. After executing the model operation successfully, the server updates the client user display with the modified data incrementally. Updating state information is achieved by triggering a CSCW event, i.e., when the kernel modeling system is idle, an idle event indicating this is triggered by the session manager on the server, and all of the clients are notified. The client profile, created upon the client starting or joining the design session, contains basic information of session participants. Session profile is created when a session is started.
Client-end mechanism
In order to reduce network load and the amount of data exchange between the client and server, user operation such as feature pick-up should be done locally as mush as possible on the client side, and only highlevel semantic messages, such as specifying operations and data needed to update the client user interface, are transferred between the server and client. As shown in Fig.3, three components can be identified on the client side: Client Agent, User Interactive Module and Display Module. Interaction between the client and server is accomplished by the Client Agent, who encapsulates user’s operation and information with XML and invokes the corresponding Web Service on the server. It collects and parses the parsed data to the display module. It is the task of the User Interaction Module to accept user operations on the client side and deliver to the Client Agent the operations that should be executed by the server.
Service encapsulation
Web Service is a self-contained, self-describing unit of modularity for publishing and delivering XML based services over the Internet. Web Services are consumed by the accepting and returning messages, which are encoded in XML. There are many ways to implement Web Service, for example FTP, HTTP, SMTP. Web Service provides a powerful approach that enables integration of distributed computational resources through open standardized protocol. A highly distributed collaborative simulation system can be built in a service-oriented environment through encapsulation of enterprise resources.
Four parts are necessary for a Java Web Service encapsulation:
1) A web server, it is the container for the HTTP requests, responses and SOAP engine.
2) The SOAP engine provides a mechanism for SOAP message, XML serialization and de-serialization.
3) WS adaptor. It is the interface between legacy systems and SOAP engine. A WS adaptor is a little like the ULA adaptor. It gets data from legacy resources and serializes it in XML stream format. It de-serializes the XML stream and puts the data to legacy resources.
4) Legacy resource. It refers to the software modules. As to simulation systems, legacy resource can be either standalone software or a simulation system.
WS adaptor
WS adaptor is a linker between SOAP engine and legacy resources. Thus it must implement the bidirectional interface to SOAP engine and legacy resources. The structure of a Java-based WS adaptor is shown in Fig.5. The WS adaptor exchanges data with SOAP engine through serialization and de-serialization. It provides several functions which seamlessly link the legacy resource through variable mapping and a uniform exterior interface. The uniform exterior interface links the C functions and libraries through JNI and transforms the data into Java type or object classes. It serializes the Java object as SOAP message and returns the message as response. Thus the service consumer can get access to the legacy resources in a highly distributed environment.
