Deploying an OSGi batch application

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

About this task

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.

Procedure

  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.

    You must declare the job steps and batch data streams as services so that the scheduler can invoke them. If your OSGi batch application implements a checkpoint policy algorithm or a results algorithm, then you 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 your 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 your 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 you 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.

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

Results

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 you created the xJCL. Finally, you deployed the OSGi batch application.

Task topic    

Terms and conditions for information centers | Feedback

Last updated: April 18, 2014 05:01 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-iseries&topic=tgrid_cgbatchosgi
File name: tgrid_cgbatchosgi.html