ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

J2EE Clustering with JBoss
Pages: 1, 2, 3

Scheduler Service

The JBoss 3 Scheduler service is covered in detail by the JBoss 3: Administration and Development book. It has three interdependent components:

  • ScheduleManager, which serves as a centralized registry for registering and executing schedules.
  • ScheduleProvider, which abstracts the custom logic that creates schedules.
  • Schedulable, which represents a task that is executed at scheduled times.

Often, applications need to schedule tasks that have to be executed once in the scope of the application, whether it is running standalone or in a cluster of multiple nodes. Examples of such tasks include regular database cleanup, email notifications, and scheduled reports.

All JBoss ScheduleProvider services accept an MBean attribute that enables them to schedule tasks on only one node in the cluster (of one or more nodes). The attribute name is HASingleton and its value is a Boolean type. When set to True, all ScheduleProvider MBeans registered with the same name and deployed in the same cluster partition will coordinate and make sure that the schedule is only provided to the schedule manager on one of the nodes. When set to False, each of the schedule providers will act independently and as a result, they will all schedule tasks with their local scheduler managers. The default value of the attribute is True, which allows transparent transition of standalone schedule providers to a clustered environment.

The name of the partition where a singleton schedule provider service will be deployed can be set via the PartitionName attribute. By default, the value assumes the default JBoss partition name.

Here is an excerpt from the example service archive descriptor cluster-examples-service.xml, located in the server/all/farm directory in the JBoss installation.

<!--
 | This MBean is an example of an HA Schedule Target
 | which is identical to a regular Schedule Target
 | (the example class is the same, just the MBean has different names)
 - ->
<mbean code="org.jboss.varia.scheduler.example.SchedulableMBeanExample" 
       name="jboss.examples:service=HASchedulableMBeanExample">
</mbean>
<!- - -->

<!--
 | The Schedule Manager has to be started whenever
 | schedules are needed.
 |
 | Uncomment only if not started by 
 | another service (e.g. schedule-manager-service.xml)
 - ->
<mbean code="org.jboss.varia.scheduler.ScheduleManager"
       name="jboss:service=ScheduleManager">
   <attribute name="StartAtStartup">true</attribute>
</mbean>
<!- - -->

<!--
 | This is a single schedule Provider which works like the
 | one in schedule-manager-service.xml
 |
 | The key difference is the explicit use of the HASingleton MBean attribute
 | to make the provider a clustered singleton.
 | When HASingleton is set to true the MBean will usually declare dependency 
 | on a cluster partition. In this case it is the DefaultPartition.
 | When not explicitly set the attribute defaults to true. 
 |
 | The same attribute can also be used for the other schedule providers as well:
 | DBScheduleProvider and XMLScheduleProvider
 | 
 |
 - ->
<mbean code="org.jboss.varia.scheduler.SingleScheduleProvider"
       name="jboss:service=HASingleScheduleProvider">
   <depends>jboss:service=DefaultPartition</depends>   
   <depends>jboss:service=ScheduleManager</depends>
   <depends>jboss.examples:service=HASchedulableMBeanExample</depends>
   <attribute name="HASingleton">true</attribute>
   <attribute name="ScheduleManagerName">jboss:service=ScheduleManager</attribute>
   <attribute name="TargetName">jboss:service=HASchedulableMBeanExample</attribute>
   <attribute name="TargetMethod">
        ;hit( NOTIFICATION, DATE, REPETITIONS, SCHEDULER_NAME, java.lang.String )
   </attribute>
   <attribute name="DateFormat"></attribute>
   <attribute name="StartDate">NOW</attribute>
   <attribute name="Period">10000</attribute>
   <attribute name="Repetitions">10</attribute>
</mbean>
<!- - -->

The deployment descriptor above is almost identical to the one provided by schedule-manager-service.xml but is intended to be deployed via farming. Although not necessary, since the default value is True, the descriptor specifies the HASingleton attribute of the schedule provider for illustration of its usage.

Notification Service

When it comes to reliable, mission-critical, and sophisticated J2EE messaging, one API stands out: JMS. The JBossMQ service is a robust JMS implementation that meets the high standards commanded by the API for distributed, transactional, and secure messaging. Then why another notification service?

Most typical clustered applications are deployed in a symmetric, homogeneous environment where components need to notify each other about various lifecycle or domain-change events, much like AWT and Swing widgets exchange events. This is where the JBoss cluster notifications come in. They fill the need for reliable, quick, and lightweight events. Cluster notifications do not require new skills from developers familiar with JMX, because they comply with the JMX notifications API.

clustered notification diagram
Figure 4. Clustered notification service

If you have used JMX notifications before, the clustering extension should be a breeze. There are two common ways to employ clustered notifications: by extending HAServiceMBeanSupport or by delegating the work to instances of this class.

Let's look at an example that comes with the JBoss distribution. Here is an excerpt from the familiar descriptor cluster-examples-service.xml, located in server/all/farm.

<!--
 | This MBean is an example showing how to extend a cluster notification broadcaster 
 | Use the sendNotiication() operation to trigger new clustered notifications.
 | Observe the status of each instance of this mbean in the participating cluster partition nodes.
 - ->
<mbean code="org.jboss.ha.jmx.examples.HANotificationBroadcasterExample" 
	name="jboss.examples:service=HANotificationBroadcasterExample">
	<depends>jboss:service=DefaultPartition</depends>           
</mbean>
<!- - -->

<!--
 | This MBean is an example that shows how to delegate notification services 
 |    to a HANotificationBroadcaster. 
 | Use the sendNotiication() operation to trigger new clustered notifications.
 | Observe the status of each instance of this mbean in the participating cluster partition nodes.
 - ->
<mbean code="org.jboss.ha.jmx.examples.HANotificationBroadcasterClientExample" 
	name="jboss.examples:service=HANotificationBroadcasterClientExample">
	<depends>jboss.examples:service=HANotificationBroadcasterExample</depends>
	<attribute name="HANotificationBroadcasterName">
              jboss.examples:service=HANotificationBroadcasterExample
    </attribute>
</mbean>
<!- - -->

The MBean implemented by the HANotificationBroadcasterExample class provides common clustering services like shared distributed state, replication management, and notifications. It is a convenience class that can be extended and customized or used as is. Its most important attribute is PartitionName, which fixates the partition of nodes where all MBeans with the same name will work together.

The other MBean in this example is implemented by the HANotificationBroadcasterClientExample class. It uses the former MBean's services to broadcast notifications to the local listeners, as well as remote cluster listeners that have subscribed to the HANotificationBroadcasterExample MBean. At the same time, the client MBean will also receive all notifications sent through any instance of the broadcaster. Clear as mud?

Pages: 1, 2, 3

Next Pagearrow