Originally posted by Billy Tsai:
how much documentation do you have?
my design is heavily based on the petstore architecture so it has many many classes and looks complex so I have like 10 pages of documentation.
Originally posted by Ajith Kallambella:
Use of BD decouples your clients from the enterprise tier and hides details such as JNDI lookups for the session facade(ServiceLocator) and in some implementations, can actually store the home reference to the session facade. BDs are also very handy if you have non-web based clients. In such a scenario, you may not have the controller which is typically a Servlet. Bundling BDs with stand-alone client jars is a very popular practice.
BDs normally have the same set of methods as the SFacade, but nothing precludes you from adding more behavior to BDs. For instance, a BD can act as a "business controller" and selectively choose an appropriate facade to service the requiest. For instance, a BankingServiceBD can look at the request parameters and select either a TellerFacade or a CustomerFacade to service the request. In this case, although the BD exposes just one method to the client, there is some business intelligence involved in how the request is processed and such nuances are neatly hidden from the clinet.
Hope this helps,
Originally posted by Anil Vupputuri:
According Service-to-Design Pattern, the flow something looks like,
Client -> Controller -> Dispatcher -> Session Facade -> Business Service (EJB)
Originally posted by Jitender Bhatia:
Document this. Say that by using so-and-so i get to achieve so-and-so. This will go a long way in ensuring that the examiner does not miss it.
Perhaps it is alright not to have a perfect solution (what is a perfect solution after all ? There are so many), but it is not alright not dealing with a requirement at all.