Security

In the SIMULIA Execution Engine environment, Java code runs in a secure environment meant to protect the server computer from malicious or errant code. Native code called by Java escapes the secure environment and has full access to the underlying hardware, file system, network resources, etc. Therefore, the SIMULIA Execution Engine will not load native component libraries. If the component implements a handler (the only part of the component that is used by the SIMULIA Execution Engine), no methods of that interface can access native code.

Related Topics
Component Executor
Reusable and Persistent Components

Threading and Reuse

Isight attempts to make efficient use of component code. Component runtime classes can be “reused” from one execution of the component to another, rather than creating a new instance each time. When executing parallel models or multiple models at the same time, the system may create multiple instances of such a component and reuse each one as demand for execution requires.

For components that use JNI code, issues of reuse and threading extend into the native code. It can be difficult to build native code that is thread-safe and reusable unless the code was originally designed with those goals. Writing thread-safe and serially reusable code is beyond the scope of this document. Selection of the proper reusePolicy and maxConcurrent properties of your component is important to match with the capabilities of the native code.

Component Structure

Proper structuring of a component and separation of the JNI part from the rest of the component can help to minimize many of the issues related to Java JNI technology. This section describes how to structure a component so that native code limitations are minimized.

Separate the component into three distinct parts.

  1. The first is the primary component code that implements the Component and SystemExtension interfaces, as all components must do. This part of the component should be pure Java (no methods declared native, and it must not contain System.loadLibrary()). This part contains the execute() method called by the infrastructure to execute the component at run time. This part can also contain classes that implement the component Editor and the component handler (ComponentHandler interface) if the component requires a handler. This part will be packaged into a single JAR file with the component XML descriptor.

  2. The second part is a Java library that is a JNI wrapper for the native code library. This Java library should contain the minimal amount of code possible. It must contain the System.loadLibrary() call and Java methods declared native. Ideally, the library should contain no conditional logic or functions of any kind; it is strictly an interface to the native code. This wrapper code will not be able to reference any class type defined in the primary component. This part will be packaged into a JAR file.

  3. The third part is the native code library implemented as a shared library appropriate for the operating system (e.g., DLL on Windows, SO on Linux, etc.).

Component Structure

The main component code and the JNI wrapper should be built separately and placed into separate JAR files. The native code should be compiled and linked into a native library file (e.g,. DLL, SO, etc.).

The component descriptor will list two dependencies: the Java wrapper JAR file and the native library file. The wrapper reference should be defined to use the shared loader option so that multiple instances of the component can use the same wrapper and native code. The component descriptor XML should be something similar to the following:

<Requires>
   <!-- Java wrapper for native code -->
   <Reference 
      name="mycomp.mywrapper" 
      version="1.0.*" 
      type="jar" 
      sharedloader="true"/>

   <!-- Native code library -->
   <Reference 
      name="mycomp.native.{platform}" 
      version="1.0.*" 
      type="library" 
      libname="mylib"/>
</Requires>

Before the component is published to the library, the referenced files should be published. For example, from the command-line client:

publish file:mywrapper.jar type:jar name:mycomp.mywrapper 
version:1.0.0 acl:#,AL,U,*,RE,U

publish file:mylib.dll type:library subtype:win32 
name:mycomp.native.win32 version:1.0.0 acl:#,AL,U,*,RE,U

Next, publish the component. The descriptor XML in the component JAR file contains the name, version, and other details, as a result you do not need to specify them on the publish command:

publish file:mycomp.jar type:metamodel acl:#,AL,U,*,RE,U