Hello!
Just started to follow the community and I dont know if this is the right
place to make questions but I take a chance.
My question is why do we still need to define an EJB module in an EAR?
You read everywhere of the classic composition of a Java EE application, to
have your business logic in an EJB-module and other stuff in a utility jar.
I think this concept is a little bit out of date now.
Recently I'm starting to restructure a classic JavaEE application, using
EJB, CDI, JMS and Servlet API. It's built up of several web applications
and also a RMI-interface, backed by EJB and CDI. Now imagine splitting up
the backend mud from 30 projects to ~300 in order to take control over the
code base. Getting rid of circular dependencies and carving out a start for
DDD. I do imagine a future where any of the projects could contain EJB
and/or CDI functionality. Refactoring EJB functionality from one project to
another make an impact to deployment of EAR. I need to manually control
that the application.xml is correctly generated. I just want to structure
my application in any way without always check that the EAR is correct.
Just compare to CDI. I dont have to tell EAR where my CDI-beans are. My
point is, EJB has great services I want to use but should not have an
impact on an application structure/architecture.
Best Regards, Hakan Fransson