Announcement Announcement Module
Collapse
No announcement yet.
Spring alternative to Local EJB Architecture? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring alternative to Local EJB Architecture?

    Hello,

    I have just started to learn about the Spring framework, but I'm considering it as an alternative for my web applications development. Before taking the decission I'd like to solve a problem. This is my scenario:

    My organization is intending to develop some web applications. Each application will be deployed as a separate EAR in the same application server.

    - Some of the EARs will expose common business services. No GUI at all
    - Other EARs (maybe one per user profile) will be thin GUI web applications accessing the services implemented by the first ones. No business at all.

    We don't want to package the business services within the different interface applications (if a "business ear" needs to change, we'll have to rebuild all the "client ears").

    I suppose I need a container to keep my business objects alive and ready to be used by the GUI web applications...

    Local EJB architecture seems to be a good solution... but, what about Spring?

    I've read something about Spring lightweight container architecture, but I'm not able to find a good technology to implement my needs

    I suppose I should avoid remoting strategies. RMI is over the top for a non-distributed architecture.
    I need a kind of remoting through an intra-VM mechanism: callers living in a EAR, calling service objects living in the same application server but inside another EAR

    Any ideas?

    Thanks in advance,
    Josť Luis

  • #2
    Take a look at http://mule.mulesource.org/wiki/display/MULE/Home

    This would allow you to expose your services within the same jvm using the vm: endpoint but would not tie you into having all services installed in the same jvm as local ejb's would. Mule would allow you move services to different jvm's and still be able to access them by changing the endpoint in which the client looks for them. Just seems more flexible than using local ejbs . Also, Spring and Mule work very well together.

    Comment


    • #3
      Does OSGi fit the bill here? OSGi sure supports VM level services. Iam not sure how concrete Spring's support for OSGi is though. But one of the promises was the facility to export spring beans as OSGi services.

      Also, if your application server supports shared libraries like WebSphere does, then you would not have to rebuild the client ears. Deployment is reduced to just dropping the newly built business ear in the shared library folder.

      Comment

      Working...
      X