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)
- 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 :-).
- Q2) Can Service Facade calls another Service Facade?
Actually not - only in case you wish nested transactions like e.g. monitoring, auditing etc.
- Q3) Can Service Facade can call Service?
Yes, see also Simplest Possible EJB 3.1 Component. But: Services are optional in Java EE 6.
- Q4) Can Service can call another Service?
Yes. Absolutely. In best case both services should reside in the same component.
- 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".
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]