Question on @Service annotated beans

[jonathandfields]

Hi,

In the past, I have used plain JMX MBeans to create my own services, which do things like create threads, access files, etc. These MBeans also do database access using Hibernate, managing their own transactions and sessions.

My question is how do the @Service annotated beans compare to the old "regular" MBeans?

On the one hand, can I still create threads, do file system access, etc, or is this prohibited as for EJBs?

On the other hand, are transactions being managed for the @Service annotated beans, like other EJBs, or do I still need to manage my own transactions and Hibernate sessions (or JPA entity managers).

Thanks,
Jon Fields

[wolfc]

A bean annotated with @Service acts as a stateful bean with just one instance available. So in effect it's the same as a singleton in EJB 3.1. Any lookup or injection of the service bean will result in an association with that single instance.

With the use of @Management the service bean will also expose a JMX view of itself. Note that lifecycle mbean methods are currently invoked, but I would rather eliminate that function and have the option of exposing a JMX view for stateless beans as well.

In effect this means that the service (/singleton) bean has the same 'prohibitions' as any other EJB. The limitations are put in place to make the bean portable and easily maintainable. You can create threads or access the file system in an EJB, but that means governing your own resources and giving up portability.

Resources available to any EJB (JPA entity managers, declarative transactions etc) are fully supported from a service bean.

[jonathandfields]

Thank you for the info.

I have numerous requirements for "daemon" processing. Watching a directory for files, copying the files, making SOAP calls to a web service, querying/updating the database. Walking a file system and creating a Lucene index. Etc. This processing needs to occur on a regular basis.

The way that I am doing this today is with regular MBeans, packaged in a SAR in an overall EAR application, which manage threads using java.util.concurrent.Executor framework. The threads are started via the JMX lifecycle methods (start/stop). Works great.

Unfortunately, JBoss Tools for Eclipse does not support SARs as a module in an EAR. Therefore, I'm interested in using @Service beans as a replacement for my plain MBeans for my daemon processing, as I move to JBoss Tools for development.

Portability is not a requirement. This only needs to work on JBoss.

Would it be OK to do mostly the same with @Service beans as I'm currently doing with plain MBeans? Threads are created/destroyed in the JMX lifecycle methods, as before. The threads would access resources as required to do their work. Only, if they needed to access DB resources, they would call an EJB - perhaps the @Service bean itself. The threads in essence would be the "driver" for the daemon processing, accessing all non-EJB resources directly, and delegating DB access to EJBs.

Or, is there a better way to handle this kind of daemon processing?

Thanks,
Jon