Deploy an OSGi batch application

We can package an existing batch application as an OSGi application. We then deploy the package so that we can expose batch artifacts as services, making those artifacts visible to the batch container.

Package an OSGi batch application, modify the Blueprint xml file to describe batch artifacts as services, and export the OSGi batch application as an enterprise bundle archive (EBA). Then create the xJCL. Finally, deploy the OSGi batch application.

Tasks

1. Package an OSGi batch application.

   You package the OSGi batch application as an EBA. The EBA contains at least your batch bundle, which is a Blueprint bundle. The API bundle and the dispatcher bundles are installed once into the internal bundle repository.

   Read the topic on creating a client bundle and follow the steps to package your OSGi application.

2. Author the Blueprint xml.

   We must declare the job steps and batch data streams as services so that the scheduler can invoke them. If our OSGi batch application implements a checkpoint policy algorithm or a results algorithm, then we must also declare as a service each algorithm that the application implements.

   1. Declare each job step as a Blueprint service.

      1. Set the interface attribute.

         1. If the step is a compute intensive step, set the attribute to com.ibm.websphere.ci.CIWork.

         2. If the step is a transactional batch step, set the attribute to com.ibm.websphere.batch.BatchJobStepInterface.

      2. Set the ref attribute to the bean ID that declares the step bean.
      3. Declare a property with the xjcl:classname key and a value that is the Java class that implements the step.
      4. Declare a bean for the Java class that implements the step.

      5. Set the scope attribute to prototype.

      Compute intensive step example:

      <bean id="IVTStep1" class="com.ibm.websphere.batch.samples.tests.steps.GenerateDataStep" scope="prototype"/>
      
      <service ref="IVTStep1" interface="com.ibm.websphere.ci.CIWork" id="step1">
      	<service-properties>
      	      <entry key="xjcl:classname" value="com.ibm.websphere.batch.samples.tests.steps.GenerateDataStep"/>
      	</service-properties>
      </service> 
      

      Transactional batch step example:

      <bean id="EchoStep2" class="com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep" scope="prototype"/>
      
      <service ref="EchoStep2" interface="com.ibm.websphere.batch.BatchJobStepInterface" id="echostep1">
      	<service-properties>
      	      <entry key="xjcl:classname" value="com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep"/>
      	</service-properties>
      </service> 
      

   2. Declare each batch data stream as a Blueprint service.

      1. Set the interface attribute to com.ibm.websphere.batch.BatchDataStream.

      2. Set the ref attribute to the bean ID that declares the batch data stream bean.
      3. Declare a property with the xjcl:classname key and a value that is the Java class that implements the batch data stream.
      4. Declare a bean for the Java class that implements the batch data stream.

      5. Set the scope attribute to prototype.

      Batch data stream example:

      <bean id="output" class="com.ibm.websphere.batch.samples.tests.bds.TestOutputBatchDataStream" scope="prototype"/>
      <service ref="output" interface="com.ibm.websphere.batch.BatchDataStream" id="out1">
      	<service-properties>
            <entry key="xjcl:impl-class" value="com.ibm.websphere.batch.samples.tests.bds.TestOutputBatchDataStream"/>
      	</service-properties>
      </service>  
      

   3. Declare the checkpoint policy algorithm as a Blueprint service.

      If our OSGi batch application implements a checkpoint policy algorithm, then declare the algorithm as a Blueprint service. Otherwise, skip this step.

      1. Set the interface attribute to com.ibm.wsspi.batch.CheckpointPolicyAlgorithm.

      2. Set the ref attribute to the bean ID that declares the checkpoint bean.
      3. Declare a property with the xjcl:classname key and a value that is the Java class that implements the checkpoint policy algorithm.
      4. Declare a bean for the Java class that implements the checkpoint policy algorithm.

      5. Set the scope attribute to prototype.

      Checkpoint policy algorithm example:

      <bean id="chkpt" class="com.ibm.websphere.batch.samples.MyCheckpointAlgorithm" scope="prototype"/>
      <service ref="chkpt" interface="com.ibm.wsspi.batch.CheckpointPolicyAlgorithm" id="ck1">
      	<service-properties>
            <entry key="xjcl:impl-class" value="com.ibm.websphere.batch.samples.MyCheckpointAlgorithm"/>
      	</service-properties>
      </service>    
      

   4. Declare the results algorithm as a Blueprint service.

      If our OSGi batch application implements a results algorithm, then declare the algorithm as a Blueprint service. Otherwise, skip this step.

      1. Set the interface attribute to com.ibm.wsspi.batch.ResultsAlgorithm.

      2. Set the ref attribute to the bean ID that declares the results algorithm bean.
      3. Declare a property with the xjcl:classname key and a value that is the Java class that implements the results algorithm.
      4. Declare a bean for the Java class that implements the results algorithm.

      5. Set the scope attribute to prototype.

      Results algorithm example:

      <bean id="myres" class="com.ibm.websphere.batch.samples.MyResultsAlgorithm" scope="prototype"/>
      <service ref="myres" interface="com.ibm.wsspi.batch.ResultsAlgorithm" id="r1">
      	<service-properties>
            <entry key="xjcl:impl-class" value="com.ibm.websphere.batch.samples.MyResultsAlgorithm"/>
      	</service-properties>
      </service>    
      

3. Export the OSGi batch application as an EBA.

4. Create the xJCL.

   Create the xJCL as we would for other batch applications, with a few differences:

   • Make the application-name attribute on the job step the deployed asset name. The deployed asset is a composition unit.

   • Make the classname subelement of the step match the xjcl:classname property of the step service.

     The following example uses the xjcl:classname property of com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep from the transactional batch step example listed previously in this procedure.

     <step id="step1">
     <classname> com.ibm.websphere.batch.samples.tests.steps.TestBatchJobStep</classname>
     </step>
     

5. Deploy the OSGi batch application.

   See on deploying an OSGi application as a business-level application and follow the steps.

You packaged an OSGi batch application, modified the Blueprint xml to describe batch artifacts as services, and exported the OSGi batch application as an enterprise bundle archive (EBA). Then we created the xJCL. Finally, we deployed the OSGi batch application.

Subtopics

• OSGi batch applications
  OSGI batch applications are batch applications that we can package and deploy as OSGI applications so that we can expose batch artifacts as services.

Developing a simple compute-intensive application

Developing a simple transactional batch application

Deploy batch applications

Create a client bundle

Deploy an OSGi application as a business-level application