As with most all EJBs, the biggest difference between the two methods is transactions. Timer EJB is an EJB, so each call will be a unique transaction, and the container will manage all these details for you.
A topic, especially if created from an EJB, will have an undefined transactional state. Most containers associate a lot of context with the current executable thread, especially the transactional state, this is one of the reasons (among other things) that self-consistent threads are a bad idea in an EJB container. Container context information may be missing or corrupt.
For an EJB timer, you can easily create one that fires every 15 seconds, but you will need to track and cancel it manually after 30 minutes. You can use ScheduleExpression to express the “every 15 s for 30 m” rule, but you still need to cancel the timer at the end (and this, frankly, will work more to properly create this expression). It’s easier to just put the start time in the Timer information, which will tell him when it will start, and then can complete itself on the last run.
In the days leading up to Java EE 6, timers were constant and kept reloading the container (although it did NOT reinstall the application). Now perseverance is optional, so you need to pay attention to this detail.
If this method was to be run from the Web layer (rather than the EJB layer), the flow restrictions are relaxed, or you can use Quartz Timer.
But EJB timers are pretty good, and better for Java EE 6. I would use EJB Timer, but I was comfortable with them, and they worked with more difficult to use pre-Java EE 6 for some time. If you are at the EJB level for the whole process, I would of course use them.