# Showcase

## Docbook demo

The above diagram highlights the interactions and key services provided by the Spring Batch framework. The colors used are important to understanding the responsibilities of a developer in Spring Batch. Grey represents an external application such as an enterprise scheduler or a database. It's important to note that scheduling is grey, and should thus be considered separate from Spring Batch. Blue represents application architecture services. In most cases these are provided by Spring Batch with out of the box implementations, but an architecture team may make specific implementations that better address their specific needs. Yellow represents the pieces that must be configured by a developer. For example, they need to configure their job schedule so that the job is kicked off at the appropriate time. They also need to create a job configuration that defines how their job will be run. It is also worth noting that the ItemReader and ItemWriter used by an application may just as easily be a custom one made by the developer for the specific batch job, rather than one provided by Spring Batch or even an architecture team.

The following example shows the use of the `osgi` namespace within the familiar Spring beans element:

The following example shows the use of the `osgi` namespace within the familiar Spring beans element:

    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:osgi="http://www.springframework.org/schema/osgi"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd
           http://www.springframework.org/schema/osgi
           http://www.springframework.org/schema/osgi/spring-osgi.xsd">

        <osgi:service id="simpleServiceOsgi" ref="simpleService"
          interface="org.xyz.MyService" />
    </beans>

Use Spring Framework `beans` schema as the default namespace.

Import Spring Dynamic Modules schema and associate a prefix with its namespace (`osgi` in this example).

Make sure to import Spring beans schema version 2.5.

Use Spring Dynamic Modules elements using the declared namespace prefix (in this example `osgi`).

The Batch Application Style is organized into four logical tiers, which include Run, Job, Application, and Data. The primary goal for organizing an application according to the tiers is to embed what is known as "separation of concerns" within the system. These tiers can be conceptual but may prove effective in mapping the deployment of the artifacts onto physical components like Java runtimes and integration with data sources and targets. Effective separation of concerns results in reducing the impact of change to the system. The four conceptual tiers containing batch artifacts are:

- Run Tier: The Run Tier is concerned with the scheduling and launching of the application. A vendor product is typically used in this tier to allow time-based and interdependent scheduling of batch jobs as well as providing parallel processing capabilities.

- Job Tier: The Job Tier is responsible for the overall execution of a batch job. It sequentially executes batch steps, ensuring that all steps are in the correct state and all appropriate policies are enforced.

- Application Tier: The Application Tier contains components required to execute the program. It contains specific tasklets that address the required batch functionality and enforces policies around a tasklet execution (e.g., commit intervals, capture of statistics, etc.)

- Data Tier: The Data Tier provides the integration with the physical data sources that might include databases, files, or queues.

As a summary, the following table lists the attributes names, possible values and a short description for each of them.

## `service` element attribute

As a summary, the following table lists the attributes names, possible values and a short description for each of them.

OSGi <service> attributes

Name | Values | Description
--- | --- | ---
interface | fully qualified class name (such as java.lang.Thread) | the fully qualified name of the class under which the object will be exported
ref | any bean name | Reference to the named bean to be exported as a service in the service registry.
context-class-loader | unmanaged | service-provider | Defines how the context class loader will be managed when an operation is invoked on the exported service. The default value is `unmanaged` which means that no management of the context class loader is attempted. A value of `service-provider` guarantees that the context class loader will have visibility of all the resources on the class path of bundle exporting the service.
auto-export | disabled | interfaces | class-hierarchy | all-classes | Enables Spring to automatically manage the set of service interfaces advertised for the service. By default this facility is `disabled`. A value of `interfaces` advertises all of the Java interfaces supported by the exported service. A value of `class-hierarchy` advertises all the Java classes in the hierarchy of the exported service. A value of `all-classes` advertises all Java interfaces and classes.
ranking | any integer value | Specify the service ranking to be used when advertising the service. Default value is 0.

## The `bean-name` attribute

The `bean-name` attribute is a convenient short-cut for specifying a filter expression that matches on the `bean-name` property automatically set when exporting a bean using the `service` element (see ).

Consider the following exporter/importer declarations:

    <bean id="messageServiceBean" scope="bundle" class="com.xyz.MessageServiceImpl"/>
    <!-- service exporter -->
    <osgi:service id="messageServiceExporter" ref="messageServiceBean" interface="com.xyz.MessageService"/>

    <osgi:reference id="messageService" interface="com.xyz.MessageService"
       bean-name="messageServiceBean"/>

the name used with `bean-name` attribute

will match only OSGi services that advertise MessageService interface and have the property named `org.springframework.osgi.bean.name` set to value `messageServiceBean`. In short, this means finding all Spring-DM exported beans that implement interface MessageService and are named `messageServiceBean`.

## XRef Samples

This paragraph demonstrates several features of XRef.

- A straight link generates the cross-reference text: .

- A link to an element with an XRefLabel: .

- A link with an EndTerm: .

## The Second Chapter

Some content here

## The Third Chapter

Some content here

## The Fourth Chapter

Chapter 4

Some content here

## blah

org.castor.core.Nature Sun Java