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.
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?