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).
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.
If you are using interactive applications, please note the following restrictions:
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
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:
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|
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.
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.
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:
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.