Java Reference
In-Depth Information
public class Tweet implements Serializable, Comparable<Tweet> {
private long tweetId;
private String message;
private Date received;
private String user;
// constructors, accessor/mutators, compareTo,
// toString/equals/hashCode methods all ommited for brevity.
// …
Thus, the implementation for the MessageSource will return Message s containing an object of type
Tweet as the payload. Examining the outline of the implementation is telling because the approach for
satisfying the interface becomes evident now that you know what interface requirements you're trying to
meet. With any luck, the beginnings of the final solution will crystallize. It is that simple!
package com.apress.springenterpriserecipes.springintegration.twitter;
public class TwitterMessageSource
implements MessageSource<Tweet>, InitializingBean {
public Message<Tweet> receive() {
return null;
// …
As you can see, the MessageSource reads from the external system, one message at a time. There are
no other interfaces to implement. You do, however, have some design constraints imposed on you not
by Spring Integration, but by the Twitter API. The Twitter API limits how many requests you can make to
it per hour. The operative word here is requests because the limitation doesn't apply to updates. As of
this writing, the API limits you to 100 requests per hour. After that, you are stalled until the top of the
next hour.
So, what you want is to be able to handle 100 messages on each pull if you get 100 messages, but to
not exceed the API request limit, which means using the API every 36 seconds at most. To be safe, let's
just assume that the poller will be scheduled to run every minute.
Before diving into the code, let's examine the configuration:
<?xml version="1.0" encoding="UTF-8"?>
Search WWH ::

Custom Search