deisgn: adding service and DAO layers

[asookazian]

So I'm wondering how much value (and from a best practices concern) is there to always using a service and DAO layer with our Seam apps.  I know it depends on the size and complexity of the app (how much biz logic and persistence logic, for example) but as a best practice, what is the recommendation?

This is not typically covered in the Seam intro or books.  Is the SFSB backing bean for the JSF view considered a service component?  Or should there be helper POJOs or EJBs that serve as the service layer?  And then adding additional classes for the DAOs?

flow: JSF --> SFSB --> POJO (service) --> POJO (DAO) --> Entity class

thereby implementing a separation of concerns strategy which may help for unit testing, reusability, and maintenance/troubleshooting.

What do you think? And if you do write a service layer, what will the SFSB backing bean be responsible for?  Where do your Seam validator classes reside (which layer)?

I've learned recently that Spring/Struts/JDBC type apps are very layered and not collapsed like most of the Seam distro examples...

How reusable is your SFSB if it contains both persistence and biz logic?  And would the service layer be stateless or stateful typically?  And what happens if you inject stateless service components into the SFSB backing bean?

[nitingaur.nitin.gaur.keane.com]

I was searching for similar design pattern and came across this post. Not answering but putting my query here...

We decided to use service layer in between UI and SAF classes (EntityHome/EntityQuery). Basically idea is to intercept user actions to create placeholder for business logic and more control over framework operations such as logging, exception handling and security.

Home and Query objects are injected in Service class. I want to figure out which of the Home/Query methods should/must be intercepted in service class. Want to fix it at early stage of project so that I can declare all methods in an interface that any Service class will implement to avoid confusion. Any suggestions please...

[isonisak]

Seam encourages to use EJBs as JSF backing beans.

This might be too straighworward solution if high security and high load
is in question.

So traditional web layer (machine) and service layer (ejb machine)
is required and firewals in between.

How in this case Seam transactions and conversions work across all layers ?

[serkan.s.eskici.online.nl]

Well, I adhere to what Seam encourages to do, namely using your backing beans as services with some little optimalizations.

For example, if you have the same (complex) JPA queries across multiple classes, then you can refactor these as NamedQueries into the EntityBean, holding them in 1 place.

So this way you can avoid double code and the need for a DAO layer (and extra unneccessary injection and memory costs).

However, there was 1 situation where I had to define a DAO layer and that was because the system architecture was not allowing us to deploy the whole application into 1 EAR.

So we had to deploy our DAO layer to another machine and making remote calls from the front-end to use it.

Actually there is no good reason for making use of a layered architecture if your app is inside 1 EAR. Just realize that you're component based programming with Seam and thus you get the same loosly-coupling advantages with it as in layered architecture (with DI & Events).

Just my 2 cents...

[isonisak]

But if for security resons you have to make
web- and service(ejb) apps in separate machines, can
the Seam conversation handle also ejb-layers database
operations or how this should be done ?

[serkan.s.eskici.online.nl]

Sakari Isoniemi wrote on Jan 06, 2011 14:39:



But if for security resons you have to make
web- and service(ejb) apps in separate machines, can
the Seam conversation handle also ejb-layers database
operations or how this should be done ?

I know that Seam provides conversational Web-/REST services (check the documentation for more info), however I've never experimented with this.

Well, what you also can do is, keeping things simple:

• Make the service layer stateless either by defining it as SLSB, Webservices or REST.


• Keep the (conversation) state in the weblayer.

My own preference goes for REST. Because it's simple and easy setup and you can negotiate in the response with HTTP status messages. For example, if the database transaction in the service layer goes wrong, then you can send a HTTP 400 (or something) to the client to notify him that he also should rollback or undo his stuff.

This also has the advantage that the service layer is more scalable and cachable, although I prefer configuring caching right directly in the dbms than in the application layer but that's just another story :)

[nitingaur.nitin.gaur.keane.com]

Sakari Isoniemi wrote on Jan 06, 2011 09:22:

Seam encourages to use EJBs as JSF backing beans.

Thanks Sakari and Serkan

Well, We found hot deployment feature of JavaBeans very useful in development. EJB can not be hot deployed.
And we do not want add more than one layer between UI and DAO else it will drift away from what Seam recommends (less layers)

JSF -- POJO (service) -- POJO (DAO) -- Entity class

So in above flow, service (implemented as POJO) is action listener apart of containing service methods. Use of service also avoids any changes in EntityHome/EntityQuery objects. DB is existing so seam-gen reverse engineering works in our favour and generates UI and DAO (Home/Query).

However, packaging is still an EAR so that EJB door is open if required for any other work (WS, JMS etc)

Coming back to my original question - till now we are thinking that service should contain only action listener methods while it seems OK to expose other Home/Query methods (ex - managed, wire, getresultcount etc) directly to UI.

[isonisak]

After reading Allens great book Seam In Action, I
understood that distributed arch with conversion managed
global transactions can be achived with XA , that all
participants support.
Prerequisite is that Seam managed tranactions are used.

Using distributed transactions in a Seam application.


One of the main reasons for using JTA transactions is to take advantage of distributed transactions. Despite Seam wrapping global transactions around each request, only the JTA implementation can support distributed transactions. In that case, you can work with multiple persistence managers and get two-phase commits as long as the underlying data source is configured as an XA resource. Chapter 14 (online) demonstrates how to set up XA data sources in the sample application.

If WebService (REST) ach is more suitable then like
Serkan above suggested, that EJBs live in their own
transaction scope, that is different from Web layers
scope and conversion must be manually rolled back if
EJB-operation fails.
In this scenario can occur problems if Web layer conversion
is shorter than EJB-layers transaction scope.