I'm not sure if this is the right forum to ask this, but it seems the most appropriate one, since I'm spanning several components of Spring. First, a little intro:
I'm developing some software on IBM WebSphere 7. I have a couple of EJBs (which in turn use some plugins, etc) (The customer wants EJBs, not that we really need them). Those EJBs are also exposed as WebServices. There is also a web application (Spring MVC), which uses those EJBs and some other components & services. There is no data access yet, but I'm planning to use JPA for that.
The point is, it all feels a bit messy, so I've been thinking about reorganizing stuff;
Since I didn't figure out how to wire spring into EJBs (to inject dependencies), EJBs are pretty much static with regards to their dependencies. I'm using @EJB injection here and there, but nothing major.
The idea to simplify all of this is:
- have a main "core" part with all of the components, plugins, etc
-- the main functionality would be implemented as simple services/components (JavaBeans), which would be annotated with @Component, so that they could be found (using component-scanning) and injected into other beans who would require them.
- Spring MVC as a web front-end (I already have that)
- (1) I would then just have an EJB facade, where I would use one of the above @Components which would handle the business logic
- (2) I would somehow? expose some @Components as web services
This would basically give me one project with major components, and an EJB project which would be just a facade.
I don't really know how to accomplish (1) and (2). For (2), I'm currently using generated stuff from RAD (IBM version of Eclipse), which generates proxys and registers a servlet in my Spring MVC webapp which exposes EJBs as Web Services.
With regards to (1): the way I understand it is that in the web app, the dispatcher servlet boots up spring context (BeanFactory), which can then be used. I'm not sure how can I get to this BeanFactory from an EJB context (even though the webapp is in the same EAR as EJBs -- hence the same JVM). Also, EJBs are instantiated using container infrastructure, so I'm guessing I'm limited to @Resource and @EJB dependencies there. But if I could get a hold of BeanFactory, I could just get a reference to a component, and I would just forward calls from EJB to service. To illustrate:
That way, Spring would be the main glue for components, most of it would be easily testable (EJB testing is not really fun!), and hopefully easier to understand and after all, more portable. EJB implementation would be very lightweight (just a facade for regular JavaBeans).
// EJB implementation method
public void init()
_springComponent = ???; // get BeanFactory somehow??? and resolve it via interface..
public String getFoo()
// _springComponent obtained somehow through BeanFactory
Thoughts, corrections, explanations, suggestions?