Page History

...

This document describes how to run the ServiceMix's File Binding example and provides details about what it does. For information on the business use case, please refer to: Use Case for File Binding.

The File Binding example illustrates the following:

• use an example of declarative programming
• how to interact with the file system
• how to use a WorkManager thread pool

The source XML code for the File Binding example is located in the ServiceMix installation directory under the examples\file-binding directory in the servicemix.xml file. It is recommended that you refer to the source code servicemix.xml file while reading this document.

The File Binding XML file, servicemix.xml, contains two components and a supporting bean. One component waits for a file to be deposited into the the inbox directory, retrieves it, then routes the file over creates a normalized message that contains the file, then sends the message to the Normalized Message Router (NMR) to another component . The NMR routes the file to the other component, which deposits it into an outbox directory. The bean provides a thread pool to enhance the performance of the reading and processing of the files. Details about the components and bean are discussed below.

Running the File Binding Example

From a command shell, go to the File Binding example directory:

cd [servicemix_install_dir]\examples\file-binding

...

After a few seconds, the sample_555-3482xxx.xml file will appear in the outbox directory. To see this open another command window and do a directory listing on the outbox directory, for example:

...

If you would like to see more files moved from inbox to outbox, copy another file into the inbox directory. The file binding program continually polls (every 1000 ms) for new files while it is running, so any new file placed in the source directory, inbox, will be transmitted to the destination directory, outbox.

Stopping the File Binding Example

To terminate the File Binding example type "CTRL-C" in the command shell in which it is running and answer "y" to the "Terminate batch job (y/n)?" question.

...

Messages The logical flow through the components as followsof the program is:

1. The timer component sends a normalized message to inputSender through the Normalized Message Router (NMR).
2. inputSender converts the message (marshals it) into a JMS message, then uses the jmsTemplate bean to publish the message.
3. jmsTemplate uses the jmsFactory bean to get a connection to the port associated with the JMS topic called "demo.org.servicemix.source." The message is published on the "demo.org.servicemix.source" topic.
4. jencks (the JCA resource adapter) listens on port 61616 for messages.
5. inputReceiver subscribes to the "demo.org.servicemix.source" topic via jencks and receives the JMS message.
6. inputReceiver normalizes the JMS message and sends it to outputSender via the NMR.
7. outputSender marshals the normalized message to a JMS message and uses jmsTemplate to publish the message on the "demo.org.servicemix.result" topic.
8. jmsTemplate publishes it on the "demo.org.servicemix.result" topic using jmsFactory to get a connection to the result topic.
9. jencks listens on port 61616 for messages.
10. jmsTrace subscribes to the "demo.org.servicemix.result" topic and receives the JMS message via jencks.
11. jmsTrace converts the JMS message into a normalized message and sends it to trace via the NMR.
12. trace transforms the normalized message into a string and logs it to the console.
    
13. filePoller polls the inbox directory every 1000 ms looking for a file.
14. Once a file appears in the inbox directory, the filePoller gets a thread from the workManager. The thread will be used to process the file.
15. The filePoller creates a normalized message that contains the file to be transmitted. It sends the normalized message to the NMR. The NMR routes the message to the fileSender component.
16. The fileSender transforms the normalized message back into a file and "sends" it (places it) to the outbox directory.

Logging information is written to the console as files are transmittedEvery 5 seconds logging information is written to the console, followed by information from the trace component. Note, that the triggers' property values of "name", "My Example Job", "group", and "ServiceMix" are displayed along with a timestamp. Typical output looks like the following:

 
 
ServiceMix ESB: 1.0.1

Loading ServiceMix from file: servicemix.xml
[INFO] TraceComponentXmlBeanDefinitionReader - -Exchange: org.servicemix.jbi.messaging.InOnlyImpl@4fdf11 received IN message: 
org.servicemix.jbi.messaging.NormalizedMessageImpl@1be0369{properties: {org.servicemix.jms.message=ACTIVEMQ_TEXT_MESSAGE: 
id = 0 ActiveMQMessage{ , jmsMessageID = null, bodyAsBytes = org.activemq.io.util.ByteArray@1d1fc02, 
readOnlyMessage = true, jmsClientID = 'ID:Lisas-2828-1126207917359-23:0' ,
 jmsCorrelationID = 'null' , jmsDestination = demo.org.servicemix.result, jmsReplyTo = null, jmsDeliveryMode = 2, 
 jmsRedelivered = false, jmsType = 'null' , jmsExpiration = 0, jmsPriority = 4, jmsTime
stamp = 1126207938593, properties = {}, readOnlyProperties = true, entryBrokerName = 'ID:Lisas-2828-1126207917359-0:0' , 
entryClusterName = 'default' , consumerNos = [0], transactionId = 'null' , xaTransacted = false, 
consumerIdentifer = 'ID:Lisas-2828-1126207917359-14:0' , messageConsumed = false, transientConsumed = true, 
sequenceNumber = 7, deliveryCount = 1, dispatchedFromDLQ = false, messageAcknowledge = org.activemq.ActiveMQSession@1de7497,
jmsMessageIdentity = null, producerKey = ID:Lisas-2828-1126207917359-29: }, text = <?xml version="1.0" encoding="UTF-8"?>
<timer><name>My Example Job</name><group>ServiceMix</group><fullname>ServiceMix.My Example Job</fullname><description/><fireTime>
Thu Sep 08 12:32:18 PDT 2005</fireTime></timer>}}

Loading XML bean definitions from file [C:\Program Files\servicemix-1.0.1\examples\file-binding\servicemi.xml]
[INFO] FileSystemXmlApplicationContext - -Bean factory for application context [org.springframework.context.support.FileSystemXmlApplication
Context;hashCode=7486844]: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [workManager,jbi]; root of BeanFactory hierarchy
[INFO] FileSystemXmlApplicationContext - -2 beans defined in application context 
[org.springframework.context.support.FileSystemXmlApplicationContext;hashCode=7486844]
[INFO] CollectionFactory - -JDK 1.4+ collections available
[INFO] CollectionFactory - -Commons Collections 3.x available
[INFO] FileSystemXmlApplicationContext - -Unable to locate MessageSource with name 'messageSource': using default [org.springframework.conte
xt.support.DelegatingMessageSource@1d6776d]
[INFO] FileSystemXmlApplicationContext - -Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using defaul
t [org.springframework.context.event.SimpleApplicationEventMulticaster@4fce71]
[INFO] DefaultListableBeanFactory - -Pre-instantiating singletons in factory [org.springframework.beans.factory.support.DefaultListableBeanF
actory defining beans [workManager,jbi]; root of BeanFactory hierarchy]
[INFO] DefaultListableBeanFactory - -Creating shared instance of singleton bean 'workManager'
[INFO] DefaultListableBeanFactory - -Creating shared instance of singleton bean 'jbi'
Created MBeanServer with ID: 203c31:106bd250a5b:-7fff:Lisas:1
[INFO] SpringInitialContextFactory - -Loading JNDI context from: class path resource [jndi.xml]
[INFO] XmlBeanDefinitionReader - -Loading XML bean definitions from class path resource [jndi.xml]
[INFO] XmlBeanFactory - -Creating shared instance of singleton bean 'jndi'
RMIConnectorServer started at: service:jmx:rmi://lisas/jndi/rmi://localhost:1099/defaultJBIJMX
[INFO] JBIContainer - -ServiceMix JBI Container (http://servicemix.org/) name: defaultJBI running version: ServiceMix.
[INFO] JBIContainer - -Activating component for: [container=defaultJBI,name=fileSender,id=fileSender] with service: fileSender component: org.servicemix.components.file.FileWriter@b1cc87
[INFO] ComponentContextImpl - -Component: fileSender activated endpoint: fileSender : fileSender
[INFO] JBIContainer - -Activating component for: [container=defaultJBI,name=filePoller,id=filePoller] with service: filePoller component: or
g.servicemix.components.file.FilePoller@183e7de
[INFO] ComponentContextImpl - -Component: filePoller activated endpoint: filePoller : filePoller
[INFO] DeliveryChannel - -default destination serviceName for filePoller = fileSender

Note: In the servicemix.xml file, the "destinationService" attribute of the filePoller component is "foo:fileSender." The last line of output (above) shows the NMR using that to deliver the normalized message to fileSender.

Details

The following table provides more details about the function of each component and bean in the servicemix.xml file.

Related Documentation

For more information on the following topics please see:

Useful Code Hints

This section describes the start-up sequence and how the ServiceMix container interacts with the File Binding application. The Java class files are located in the servicemix-1.0.1.jar file in the ServiceMix installation directory. To look at the Java source code, unjar and decompile the .class files or download the source code. Please note: the downloadable source code is slightly different than the compiled binary code.

Viewing the Java source code is recommended for understanding the information in this section.

filePoller Details

1. The ServiceMix container reads the servicemix.xml file and sees it needs to instantiate a FilePoller.
2. The container calls the init() method of FilePoller, as well as the init() methods of its parents.
3. The container determines that FilePoller is an MBean and, therefore, calls the start() method of FilePoller, which it inherits from its parent PollingComponentSupport.
4. The start() method will: (See: PollingComponentSupport.java code fragment below)
   A. Create a timerTask.
   B. Schedule the timerTask at a fixed rate. The start() method uses the "timer" (created in the init method) to schedule the timerTask at a fixed rate: timer.scheduleAtFixedRate(timerTask, firstTime, period). Recall "period" is a property of FilePoller. It was assigned the value of 1000ms by dependency injection from the servicemix.xml file.
   C. timer will call the run() method of the timerTask periodically. timerTask's run method() is defined inline. This run() method will get the workManager object (see below for details).
   D. The workManager will call "scheduleWork(PollingComponentSupport.this)". Note: it passes in PollingComponent support, which by virtue of its inheritance hierarchy, is of type "Work", which is a "Runnable" object.
   E. "workManager.scheduleWork(Work)" will get a Thread, passing in a Runnable object, i.e. PollingComponentSupport, and call its run() method.
   F. PollingComponent's run() method calls poll(), which is implemented in FilePoller.
   G. From this point on the call sequence can be followed in FilePoller...
   H. The start() method of PollingComponentSupport, will eventually call super.start(), which propagates up to call the start() method of BaseLifeCycle, which sets the component state to "RUNNING."

Eventually, one of the threads that is polling (see step G) for a file in the inbox directory will see a one. It will use workManager's thread pool to get a thread for processing the file. Processing the file consists of streaming it from inbox, creating a normalized message, and sending the message to the NMR.

  timerTask = new TimerTask() {
     public void run() {
          try {
                getWorkManager().scheduleWork(PollingComponentSupport.this);
          }
          catch (Throwable e) {
                log.error("Failed to schedule work: " + e, e);
          }
     }
  };
  if (firstTime != null) {
     timer.scheduleAtFixedRate(timerTask, firstTime, period);
  }
  else {
     timer.scheduleAtFixedRate(timerTask, delay, period);
  }
}
super.start();

workManager Details

workManager is a property of the FilePoller object. This property is defined by a local reference, the "ref" attribute in the servicemix.xml file. The local reference is a bean which instantiates org.activemq.work.SpringWorkManager.

The SpringWorkManager is a Spring bean. By default when a Spring bean starts, the properties are set, and then the afterPropertiesSet() method is called by the container.

The workManager is used to allocate threads. The FilePoller asks for threads from the workManager for two operations:

1. The timerTask uses threads from the thread pool to periodically check the inbox directory for files.
2. The workManager will also allocate a thread to process a file (read, normalize and send to NMR). The workManager calls a scheduleWork() method which is non-blocking. Therefore, if multiple files need to be processed, FilePoller can continue making requests to the workManager to schedule work.

Summarizing, when the ServiceMix container instantiates an MBean it firsts sets the property values if there are any, then calls the init() method of the class and its' parent classes, if applicable. Then it calls the start() method of the class. When a Spring bean starts up, the properties are set and then the afterPropertiesSet() method is called.

Related Documentation

For more information on the following topics please see:

• NMR

• SpringFor details on the tags and attributes of the XML file (servicemix.xml), please see the description of the xsd file at: link to xsd description file.