Java EE/Glassfish Application Logic

I am trying to understand where some of my application logic should go in my Java EE Application. I am new to Java EE and am looking at loading a lot of unstructured data from a legacy database and building a clean object model for use by my application. From my investigation I see Java EE apps have 2 components, Enterprise Bean and Web Application components. This part of my application will be responsible for loading the data, building the object model and sending messages via JMS based on the current state of the data to interested parties. The data will be updated by synchronisation with the database and from messages received via JMS from remote Java applications.

Is an EJB the correct place for this sort of functionality? How can I start the initialisation of my object model (main method Java App equivalent)? What is the best practice for creating a timed event to review the object model and send messages via JMS?

I have read a number of articles on Java EE, Glassfish, EJB's ... but still don't feel I have a clear p开发者_StackOverflow中文版icture of where I should be writing this functionality. Any examples I have seen of EJB tend to be around direct method calls on the beans from client applications.

At the moment I feel a Java application may do the job but we are looking at using RMI, and web clients in the future.

Java EE is traditionally used for client/server architectural style. The business logic is implemented in EJB session beans, which are usually invoked either from a web request, a JMS message or a RMI-IIOP remote call.

Is an EJB the correct place for this sort of functionality?

The logic goes into the EJB. But there are different types of EJB.

How can I start the initialisation of my object model (main method Java App equivalent)?

There is no such thing as a main method. But there are still some ways to be perform some processing corresponding to the application deployment and/or undeployment. You can look at ServletContextListener, Glassfish lifecycle module (non-standard) or maybe the newly introduced Singleton beans and @Startup annotation.

What is the best practice for creating a timed event to review the object model and send messages via JMS?

You can create an EJB Timer which will be called periodically. If you need the model to be loaded once in memory, I would suggest you look at Singleton beans also. With EJB 3.0, the problem was how to start the timer automatically, but I think they improved that in EJB 3.1 and timers can be started automatically by the application server when the application is deployed using the @Scheduled annotation. So it may somehow provide you with a desired starting point as you asked in your previous question.

You can send JMS message from any bean. JMS an external system just like the database. JMS message are received using special kind of EJB called Message-driven bean (MDB).

You application will not be a traditional web-EJB-database client-server application, but it should be feasible with Java EE which is definitively a very flexible model.

As you said, the examples tend to involve direct invocation. In my experience, that's not just the examples. None of the Java EE*1 apps I've seen use a long living object graph like you describe, instead, they typically operate on a single record (+children/related) in response to a web request, web service call or JMS message.

Your requirements break that mould and Java EE may not be the best fit. At face value, the kind of code you describe belongs in the EJB Container, but that container lacks a good long-living context to anchor your object graph to. The Web Container has such a context, but lacks facilities for timers and message handling and such. The cost of abandoning J2EE and using a plain Java application instead is of course to lose the application server's facilities for administration, deployment and monitoring.

A good choice might be to reach back to what made the Spring Framework big. I don't know if you're familiar with J2EE's history, but the sudden, huge popularity of the Spring Framework and Hibernate were essentially a community rebellion against the EJB container, versions 1.x / 2.x. What the Spring WebApplicationContext gave you was a robust, transactional back-end to a web application, taking advantage of MDB's and JTA while otherwise ignoring as much of the EJB Container as possible*2 (and greatly simplifying unit-testing in the process). You could take this approach and build your application as a single WAR file and boot up your back-end services with Spring.

An interesting alternative is to ditch the Java EE application server altogether and build your application on top of the OSGi framework. This is the "normal Java application" approach, with the OSGi runtime giving you the administration console and hot deployment features that you'd have had to roll your own of otherwise. The missing bits of infrastructure are the timer (use Quartz) and the Message-Driven Beans (use the JMS API directly). An OSGi application ends up feeling a bit like the Linux kernel and boot process, with services deployed and started according to run levels. Grab Apache Felix and have a look.

You didn't mention scale. If the object graph is huge, look into technologies like GigaSpaces or Coherence.

**1) Sun took the '2' out of the acronym with the introduction of EJB3*

**2) Entity EJBs 2.x were the worst part. EJB 3 can be viewed as largely an "if you can't beat them, join them" effort to standardize Hibernate.*