Performing methods of the WorkflowService, AdministrationService and the UserService will change the content of the audit trail database and other data sources being accessed during process execution. These changes will be applied in the context of a transaction.
Furthermore, applications (e.g. Session Bean methods) may be executed on behalf of a WorkflowService or AdministrationService. These applications may access transactional resources like databases or message queues, too.
Because transactions on multiple data sources need to be synchronized, Stardust uses EJB transaction support to perform global transactions in a two-phase-commit protocol.
Transaction demarcation for the WorkflowService and the AdministrationService has to be managed by the container to provide you with the highest degree of flexibility for your application design.
Hence, these beans always have to be deployed as follows:
<session>
<ejb-name>WorkflowService</ejb-name>
...
<transaction-type>Container</transaction-type>
...
</session>
Normally, each method of the Stardust services and default Message Driven Beans is thought to begin and complete a transaction and the changes in the audit trail database and the transactional resources accessed by the invoked applications will be visible for other transactions. To achieve this behavior, the deployment descriptor for the Stardust Session Beans should contain the following:
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>WorkflowService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>UserService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>AdministrationService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>QueryService</ejb-name>
<method-name>*</method-name>
</method>
...
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
</assembly-descriptor>
However, it might be desirable to perform subsequent methods of these beans in a
single transaction started before a Stardust Session Bean call, because the changes
should be applied as a whole or not at all. In this case, the Deployment
Descriptor should be:
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>WorkflowService</ejb-name>
<method-name>*</method-name>
</method>
<method>
<ejb-name>UserService</ejb-name> <method-name>*</method-name>
</method> <method> <ejb-name>AdministrationService</ejb-name>
<method-name>*</method-name>
</method> <method> <ejb-name>QueryService</ejb-name> <method-name>*</method-name> </method> ... <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor>
One of the Stardust EJBs always need the trans-attribute set to RequiresNew:
executeDaemonBody of the AdministrationService
responsible for daemon execution in the process engine.Therefore your assembly descriptor must contain the following container transaction segments:
<container-transaction>
<method>
<ejb-name>ForkingService</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
For reference Stardust ships with default deployment descriptors reflecting a basic deployment scenario.
The following steps have to be performed for creating an application embedding Stardust functionality:
carnot.ear
have to be deployed to your application server and connected to an audit trail
database. This step is described in detail in the
Deployment Concepts chapters of the Deployment Guide.
The carnot.ear file can be achieved by downloading
one of the Maven archetype templates from the Stardust artifactory
matching your requirements. Please refer to
chapter
Creating a Runtime Environment with Apache Maven in the
Installation Guide
section
Maven Archetypes of our Stardust Wiki
Maven/Basic Setup
page
for details on how to retrieve these configurations.carnot_client.jar and carnot.properties (provided in lib
and etc subdirectory of the Stardust installation directory) have to be part
of the classpath of the compilation and runtime environment for your client
application. The file carnot.properties has to be adjusted according to the
requirements of your client application. You can find a description of all Stardust
properties in the Stardust Properties
chapters of the Stardust Operation Guide.