Note that there are some explanatory texts on larger screens.

plurals
  1. POSingleton vs Stateless beans in the architecture of a Java EE application
    primarykey
    data
    text
    <p>A part of business logic at the core of my project has to perform a search on linked-data. Currently, I have implemented this part using a singleton session bean like this (SPARQL is a query language on RDF models which are constructed using linked data).</p> <pre><code>@Singleton @Startup public class SparqlEngine { @PostConstruct private void init() { // Initialiaze the model by connecting to the database } public ResultSet searchBySparql(String sparqlQuery) { // Perform the search on the model which is stored in the database } @PreDestroy private void cleanup() { // Close database connection } } </code></pre> <p>This EJB is exposed to the other parts of my application by another EJB named <code>SparqlEndpoint</code> which is responsible for converting the <code>ResultSet</code> to a more comfortable <code>SearchResult</code> object which contains the model in a string form with the syntax specified by the client, total number of results and other metadata. The <code>SparqlEndpoint</code> EJB is simply <code>@Stateless</code> and has a local interface which is used by the clients. These clients include JSF managed beans and a couple of EJBs which expose it as SOAP and RESTful web services.</p> <p>This is the most reasonable architecture that came to my mind, but I need to know if I have done it right. Should I use a <code>Singleton</code> bean to implement the core as I'm doing now, or a <code>Stateless</code> session bean is more appropriate? The database connection initialization usually takes a couple of seconds at least, and it may be useful to note than the it is a NoSQL one and does not support transactions. I'm not planning to add anything such as a write method to this bean. Is it correct for other EJBs to be stateless? If I want to expose my indexing engine (which performs writes on the database) as another EJB, how should I implement it?</p> <p>Thanks in advance.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COWhat is the rationale for making the SparqlEngine EJB a Singleton? What benefits are you getting by having just one bean per EJB container? Why create additional SLSB for returning SearchResult? Why not add a method to this Engine SLSB to return the transformation?
      singulars
    2. COI actually do not have solid reasons for designing the architecture like this, and I'm not sure about it being the best way either. Since the initialization is not a trivial task and takes time, I thought it may be a good idea to do it once at the time of deployment and let a singleton handle all database access tasks on an already initialized model (it is critical for the application to respond to queries fast).
      singulars
    3. COI introduced the Endpoint to do some sort of loose coupling and separation of concerns. There is actually a SparqlEngineLite EJB which initializes the model using a dump file and is used in testing environment where our NoSQL cluster is not available. The Endpoint EJB may have other tasks in the future which are not much related to the actual engine. Finally, also the web service EJB is subject to additions in the future. However, all this is just my own way of thinking and it would be of much pleasure if anyone can guide me to achieve a better one.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload