Developing Web Applications Using the SIMULIA Execution Engine APIs

If you are developing Web applications that use the SIMULIA Execution Engine APIs, you need to consider issues regarding application design, configuration, and deployment.

A Web application that uses the SIMULIA Execution Engine APIs defines a typical three-tier infrastructure consisting of the Web browser (on the end user computer), a Web server running a J2EE Web container (servlets/JSP), and the SIMULIA Execution Engine, as illustrated in the following figure:



The browser communicates with the Web server through the HTTP or HTTPS protocols. The servlet in the Web tier uses the SIMULIA Execution Engine APIs to communicate with the SIMULIA Execution Engine. The APIs use RMI/IIOP behind the scenes to invoke Enterprise Java Beans (EJBs) in the application server tier. The SIMULIA Execution Engine API encapsulates and hides all the communication details, but there are some implications for how the servlet must define the connection to the SIMULIA Execution Engine.

WebLogic servers may use BEA proprietary T3 protocol instead of IIOP, but the concepts are the same for the purposes of this document.

Each of the tiers is typically deployed on separate computers but can also be co-located on a single piece of hardware or even run in the same process (JVM). However, the tiers are independent processes using well-defined communications protocols between them.

There are some important characteristics of this three-tier infrastructure that must be considered when developing Web applications:

  • Typically, The Web server is a single JVM process that handles all requests from all connected browser clients. If a single request consumes a significant portion of the JVM resources (for example, heap memory), the number of clients able to use the application at the same time will be limited. For example, loading an Isight model and job results can consume JVM memory resources. It is important to design the Web application to minimize the time over which such resources are held and to release resources when they are no longer needed.

  • The Web server is a “client” from the SIMULIA Execution Engine point of view. It uses the typical client APIs to get models, run jobs, get results, etc. Any synchronous SIMULIA Execution Engine client API can be used in the Web application. The Web server must have access to all the supporting SIMULIA Execution Engine client JAR files that contain the SIMULIA Execution Engine API implementations (e.g., EJB stubs for communicating with the SIMULIA Execution Engine, etc.). For more information, see Web Application Packaging.

    Note: SIMULIA Execution Engine APIs that define an asynchronous callback listener cannot be used by Web clients in a Servlet container. The container does not allow servlet code to be invoked by asynchronous events in the server. For example, the PSE.addJobMonitorListener()PSE.addPSEStatusListener(), and ResultRequestMgr.getAsynchronousResults() methods cannot be used in a Web application.

  • Similar to other SIMULIA Execution Engine clients, the Web application must supply connection information before the SIMULIA Execution Engine APIs can be used. The connection information contains the details on how to connect to the SIMULIA Execution Engine (server name, port number, etc.). Most SIMULIA Execution Engine clients use the SIMULIA Execution Engine Logon class to prompt the user for a connection profile (.CPR) file, user ID, and password. However, this mechanism cannot be used in the Web server because the Logon class uses a Swing GUI that is not allowed on the Web server and the Logon class prompts for user identity information that is not used in this scenario (user identity flows to the SIMULIA Execution Engine at the protocol layer: see next below). Therefore, the Web application must supply only the connection information, not user identity. The connection information can be supplied in the form of a connection profile (.CPR) file or a Java Properties object. For more information, see Server Connection and Web Application Initialization.

  • Unlike other clients, the Web server acts on behalf of many end users, so the identity of the Web server process itself is not important. In a secured environment the Web server (or an SSO infrastructure) must prompt for and authenticate user credentials. Authentication will have been done before any servlet code is invoked. Thus, a Web application does not have to implement any user ID prompting or logon facility. The user identity is managed by the Web server during the execution of the servlet. When the servlet calls the SIMULIA Execution Engine APIs—and they in turn call EJBs—in the SIMULIA Execution Engine, the RMI/IIOP protocols can carry the user identity information on each call from the Web server to the application server. The Web application itself does not have to pass user ID information explicitly to the application server. The Web server and application server must be configured properly for the security identity propagation to work. For more information, see Overview of Security.