Stateless session facade (anti)pattern

[allanjun]

Seam reference chapter 7 conversations and workspace management mentioned that one of the reasons that conversation came out was due to the the fault of the extremely limiting persistence context model supported by stateless architectures such as the Spring framework or the traditional stateless session facade (anti)pattern in J2EE.)

The application I'm working on is using the following architecture, we have entity beans provide access to data model, and on top of that stateless session beans act as facade to provide access to multiple entity beans, and then web action seam beans on top of service session beans. We need a service layer because the business logic and data access will be used by web services and another web application in further.

Is this a sound architecture? It seems that we only get the benefits of seam on the web layer. I looked at seam examples, eg booking, it uses stateful SB in web layer to serve jsf directly, I understand and like the benefit of this design. So, my question is, if the application is not a standalone web app, is stateless session facade still an anti pattern? How should we architect to utilise more seam features in such an app?

Thanks.

[gonorrhea]

Session facade was a pattern in Marinescu's EJB design patterns book IIRC.  That was for J2EE 1.4 spec.  Now in JEE 5 (and specifically EJB3), it's an anti-pattern b/c entity classes can be accessed directly in JSF.

So in Seam you shouldn't use session facade, you should use SFSB or JavaBean scoped to conversation context to model conversations.  This is all explained and demonstrated in the various Seam ref docs and books.

DAO pattern is optional as well in Seam apps.  DTO is now anti-pattern b/c entity classes are no longer entity beans (EJB) and thus can be serialized and referenced in presentation layer (JSF).

Remember that you can always add layers in a Seam app, but layers are not required (which is one of the pluses of this framework).

[allanjun]

Thanks for the reply Arbi.

But as I mentioned, we're not developing a standalone web app, the layers will be used by other services or applications.

I guess I could use SFSB in service layer and entity layer rather than SLSB, but what advantage do I get in this case?

[berat]

I met the same problem in my project.
Seam brings us a lot of benefit except managing webservices.
Many projects would met this kind of situation that if we need a webservice to serve external request, how would seam handle it? There would be no context, no conversation.

[luizfarruda]

I totally agree that this is not a anti-pattern but a common scenario nowadays and this scenario should be best addressed. The question is, IT nowadays should not be application oriented but business oriented, and some kind of customers following this premise already have A LOT of business logic encapsulated as SLSB or Composite Services exposed by webservices at ESB solution. This is the kind of situation that, imo, Seam can help only at presentation layer, as business, persistence and other kind of integrations is already encapsulated by services layer, that is reused not only by the this specific seam aplication but also for portlets in another web portal, and even for external boundaries to do b2b communication.

Does anyone agreed with my opinion?

Supposed that business is exposed by SLSB without seam annotations (scenario 1), Do Seam agregates that much when used only as presentation layer?

Supposed that business is exposed by Webservices at ESB environment (scenario 2), Do Seam agregates that much when used only as presentation layer?

[sashkanem]

Very common situation to me as well.

We have SFSBs and SLSBs in our application, service are exposed in many ways, we are trying to use seam to simplify our lives on the presentation layer development. suppose all this EJBs are not seam components. We need to load entities from already existing EJBs (that are not seam components). Suppose no seam managed entity manager, and no EJB-QL in seam components.

Is there any elegant way, to use seam only on presentation layer without using SFSB as seam components. We only need seam components as helper beans for our pages filtering, saving state etc.

I have used seam in several projects but still doubt about architecture issues.
Will be nice to hear ideas from more experienced people.

thanks