Applications may be associated with activities to specify the action to be executed when the activity is instantiated at runtime. They are basically application programs. Multiple activities may use the same application but only one application may be executed within an activity.
There is an exception with interactive applications. You can define JFC applications, JSP Pages etc. in one interactive application to cover different application contexts (e.g. execution clients).

Application Type

Applications are categorized by having a unique application type describing the execution semantics and custom hooks to the modeling environment to have type-specific modeling facilities. Prescribed by the application type, every application has its own specific properties to be configured.

Stardust ships with a set of default application types for interactive and non-interactive activities as well:



Please refer to the chapter System Integration for detailed information on the usage of concrete applications. The list of default applications may be extended by writing custom application types.

Applications are a pure modeling concept. They have no persistent representation in the audit trail. As a model element, applications are first class model elements, i.e. they are shared between all process definitions.

An application in Stardust is visualized by an icon showing a desktop window. This icon may be overlaid by symbols representing a concrete application type.

Application Type and Target Portals

If you are using interactive applications, please note the following restrictions:

Non-Interactive Applications

Synchronous/Asynchronous Application

Applications associated with non-interactive activities, i.e. non-interactive applications, come in two different flavors:

Two very common synchronous application types deserve special attention. These are

Completion Method

Both application types are just for executing Java code at runtime - on a Session Bean or on a plain Java object. This is realized by executing one dedicated method, the completion method. See also Runtime Behavior.

As a model element non-interactive applications have the following properties:

Retry Mechanism of Non-interactive Applications

When specifying the retry time, the user should take in account the default transaction timeout. The retry count * delay + processing time should be less than transaction timeout. Following is the default transaction timeout of application servers:

Servers Default Transaction Timeout
WebSphere 120 seconds
WebLogic 30 seconds
JBoss 300 seconds

No indication is set in the audit trail to know if an application is executed more than once, if in the end the application succeeded. To find this, you should refer to the stack traces in the log files. In case of exceptions that are thrown within the application and if retry ends at the last cycle with an exception, only this last exception is shown in the audit trail. You need to check the log files to know about other exceptions. For example, exception1 is thrown, then exception2 and finally application completes. Retry is set to 3. In another case, first exception1 is thrown, then exception2 and then exception3 interrupts activity instance. Only exception3 is reported in the audit trail. To know about execption1 and exception2, you need to refer to the log files.

If the Stardust engine was stopped the hard way while the activity is executed, there is no difference between an application with retry configured and one without. Meaning an engine recovery will re-animate both but it is not visible to the user (except log file-scanning) if the application with retry-mechanism was already executed several times.

Interactive Applications

For interactive activities, workflow control is temporarily outside the engine, e.g. in a Windows client application or in a Web page. After creating an interactive activity, the current activity thread and transaction stop. Only when an activity instance is completed, control is returned to the Stardust runtime. Nevertheless, Stardust enables you at modeling time to store information in the associated application (interactive application) on behalf of a client.

Application Context

Because different client contexts may exist (e.g. Web-based client, native Windows client) Stardust will maintain client-specific information in the scope of so-called application contexts, allowing for an arbitrary number of such contexts to be associated to specific interactive applications. Stardust ships with the following application contexts:

As a model element interactive applications have the following properties:

Custom Application Types

The modeling and runtime environment can be customized to support arbitrary application types by using the Stardust Service Provider Interface (SPI). The use of the Stardust SPI is described in the Tutorial Stardust SPI Programming chapter of the Programming Guide.