Some Interesting Java EE 6 Architecture Questions - With Answers

Got some interesting questions regarding Java EE 6 architecture and patterns: Let's say I have OrderManagement - i will say it implements Service Facade. It is directly being called from the Web tier(JSF beans). OrderManagement in turn calls PaymentService - which i hope is Service(not Service Facade). PaymentService calls MailingService which i hope is Service(not Service Facade). All of them are created with contract(interface) and interface's implementation is SLSB(state less session beans)

  1. Q1 ) Am i right in my understanding?
    Almost. I would not use interfaces in Java EE 6 as default pattern. In fact in Java EE 5 to Java EE 6 migrations are deleted about 80% of all interfaces. That considerably increased the maintainability of the system :-).
  2. Q2) Can Service Facade calls another Service Facade?
    Actually not - only in case you wish nested transactions like e.g. monitoring, auditing etc.
  3. Q3) Can Service Facade can call Service?
    Yes, see also Simplest Possible EJB 3.1 Component. But: Services are optional in Java EE 6.
  4. Q4) Can Service can call another Service?
    Yes. Absolutely. In best case both services should reside in the same component.
  5. Q5) MDBs can call Service Facade and Service both?
    Both. If a MDB calls a Service Facade, it is in the role of an external client. If it calls a Service - a rollback of the Service transaction will cause the message to be "undelivered".

This one is not directly related to your book [Real World Java EE Patterns - Rethinking Best Practices]-do you know any best practices for SFSB when deployed in a cluster where the NFRs are HA, Failover, fault tolerance with DR.(performance, scalability, extensibility is implicit NFRs)
A simple answer is: do not rely on replication of stateful state in cluster, see also: HA without clustering ...and "don't" distribute!

[The whole book "Real World Java EE Patterns - Rethinking Best Practices" describes lean Java EE architectures and patterns. See ServiceFacade, Service, PDO patterns and the chapter 6 "Pragmatic Java EE Architectures", Page 253] 

Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition the podcast:

Stay in touch:


>>Almost. I would not use interfaces in
>>Java EE 6 as default pattern.

So instead of first defining a contract, and coding against a contract, you define the functionality and code against the functionality. That may work in some scenarios; Great for small projects but death for serious projects.

You've induced couplings. Coder-designed interfaces exist for a reason: Separate the implementation from the contract.

Posted by jon on February 21, 2011 at 07:45 PM CET #


in Java we can use public / private to show what belongs to the contract and what not. Interfaces are perfect for strategy pattern, explicit public APIs or "protected variations".

So you are writing for every class an interface in "big" projects ? :-)

thanks for your feedback!,


Posted by on February 22, 2011 at 12:53 PM CET #

>>So you are writing for every class an >>interface in "big" projects

Of course not, that'd be ridiculous.

I see interfaces being used to specify a contract between the implementor and implementation. For my larger projects, EJBs intentionally have an interface with @Remote. EJBs then become coarse grained, recyclable services.

Without a contract, you are bound to the implementation. In a multi-tenant environment, often you will have multiple implementations that vary slightly, to cater different customer needs. Without interfaces, we'd have quite a mess on our hands.

side note:
I've found RMI/JRMP/CORBA to be orders of magnitude faster than XML, SOAP or REST... So we end up with a redundant, distributed system that has extremely low latency. I know this wasn't the original purpose of EJBs, but they're very effective in this manner.

Posted by jon on February 22, 2011 at 05:59 PM CET #


remoting only works with explicit @Remote interfaces. My answers in this post referred to local communication inside a component. For remote communication and public APIs, interfaces are o.k.

Btw. we have similar opinion: :-)

thanks for the clarifications!

Posted by on February 22, 2011 at 08:01 PM CET #

Hi Adam,

you say that the webtier should invoke the servicefacade methods, but how do you handle application exceptions in that scenario?


Posted by Alessio on February 22, 2011 at 09:10 PM CET #


you are usually invoking the ServiceFacade from a backing bean (e.g. @RequestScoped). There is no interface between. You can handle and transform all exceptions in the backing bean.

A good question!,


Posted by on February 22, 2011 at 09:32 PM CET #

Hi Adam and thanks for your reply!
I thought you would invoke it from (e.g.) JSF facelet.
So (using JSF) you call from the commandbutton a (e.g.) login method in the backing bean. That method within the backing bean then calls the servicefacade and also handles the exceptions, right?


Posted by Alessio on February 22, 2011 at 09:41 PM CET #



In "hello world" you could skip backing beans, but in "real world" you will need a place for presentation logic. CDI managed beans: @Named @RequestScoped are perfectly suitable for that purpose.

enjoy Java EE!,


Posted by on February 22, 2011 at 10:12 PM CET #

I thought services are independant and should not talk to each other and the job of archestration (interaction among services) be left to a facade. Am I carrying some old habits here?

Posted by Vijay on April 28, 2011 at 04:23 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments