ejb design patterns n.
Skip this Video
Loading SlideShow in 5 Seconds..
EJB Design Patterns PowerPoint Presentation
Download Presentation
EJB Design Patterns

EJB Design Patterns

403 Views Download Presentation
Download Presentation

EJB Design Patterns

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. EJB Design Patterns Vijay Bhatt NCST Juhu, Mumbai (c) CDAC(Formerly NCST)

  2. EJB Design Patterns • Best practice solution to commonly recurring problems. • Enable us to design efficient, scalable and maintainable systems (c) CDAC(Formerly NCST)

  3. Benefits • Provides a high-level language to discuss design issues. • Provides much of the design. • Combinations of patterns form reusable architectures. (c) CDAC(Formerly NCST)

  4. Categories • 1) EJB Layer Architectural patterns: Architecture or partitioning of logic – Session Façade – Message Façade – EJB Command – Data Transfer Object Factory – Generic Attribute Access – Business Interface (c) CDAC(Formerly NCST)

  5. Categories • 2) Inter-tier Data Transfer Patterns: For transferring data from the client to the server and back. – Data Transfer Object • Domain DTO • Custom DTO – Data Transfer Hashmap – Data Transfer Rowset (c) CDAC(Formerly NCST)

  6. Categories • 3) Transaction and Persistence Patterns: transaction control, persistence and performance related – Version Number – JDBC for reading – Data Access Command Bean/Data Access Object – Dual Persistent Entity Bean (c) CDAC(Formerly NCST)

  7. Categories • 4) Client-side EJB Interaction Patterns: maintainability and performance from client point of view. – EJB Home Factory – Business Delegate (c) CDAC(Formerly NCST)

  8. Session Façade (c) CDAC(Formerly NCST)

  9. Background • Fine-grained access through remote interfaces increases network traffic and latency. • Overhead of multiple network calls • Processes involve multiple business objects. • Data access and business logic scattered across clients. • Tight coupling between classes. • Decrease in flexibility and design clarity. • Transactions not safe: When calling an entity beans methods directly, each method call is a separate unit of work, and a separate transaction. • Transaction not maintained across methods. (c) CDAC(Formerly NCST)

  10. Need • Invoke methods of multiple session or entity beans in one transaction and one bulk network call. (c) CDAC(Formerly NCST)

  11. Issue • How can an EJB client execute a Use case’s business logic in one transaction and one bulk network call? (c) CDAC(Formerly NCST)

  12. Solution 1 • Put extra logic into our entity beans to perform many operations on behalf of a single client call. • This solution introduces maintenance problems, because our entity bean layer will likely be used in many different ways over time. • Merging our application logic (verbs) with our persistence logic (nouns), which is poor application design. (c) CDAC(Formerly NCST)

  13. Solution 2 • Client demarcates a large transaction via the Java Transaction API (JTA). – High network overhead. – Poor concurrency. – High coupling. – Poor reusability. Other clients cannot reuse – Mixing of presentation logic with business logic. – Poor maintainability. Usage of the Java Transaction API (c) CDAC(Formerly NCST)

  14. The Solution • A server-side abstraction that serves as an intermediary, and buffers calls to entity beans. • Session beans will contain application logic to fulfill use-cases. • Each session bean performs bulk operations on entity beans on behalf of a single client request. • Clients have access to session beans only, not entity beans. (c) CDAC(Formerly NCST)

  15. Advantages • Low network overhead. • Lower overall overhead on client end. • Session bean is the transactional façade, localizes transactions to the server-side, and keeps them short, giving higher concurrency. • Lower coupling. • Entity beans remain reusabe. • Better maintainability: Clean separation of middleware (transaction) and application logic. • Clean verb-noun separation. (c) CDAC(Formerly NCST)

  16. Role of Use Cases • Do not map every use case to a session façade. • Consolidate them into fewer session beans based on some logical partitioning. • Design session facades to aggregate a group of the related interactions into a single session façade. • The use cases Create New Account, Change Account Information, View Account information, and so on all deal with the coarse-grained entity object Account. • For a banking application, group the interactions related to managing an account into a single session façade called AccountSessionFacade. (c) CDAC(Formerly NCST)

  17. Message Façade • For asynchronous use cases. (c) CDAC(Formerly NCST)

  18. Issue How can an EJB client invoke methods of multiple session or entity beans with one transaction, without need to block & wait for responses for each bean? (c) CDAC(Formerly NCST)

  19. Solution • Use a message driven beans to create a fault-tolerant asynchronous façade • Clients should have access to message driven beans only not to entity beans. (c) CDAC(Formerly NCST)

  20. EJB Home Factory (c) CDAC(Formerly NCST)

  21. Background • Multiple lookups of the same home are redundant. • Home is used only once • an EJBHome never goes stale and can be reused for the lifetime of the client application. • Requires a network call if JNDI server is on a different machine. (c) CDAC(Formerly NCST)

  22. Issue • How can a client lookup an EJBHome only once in the lifetime of its application and abstract the details of lookup? (c) CDAC(Formerly NCST)

  23. Solution • Abstract EJBHome lookup code into a reusable EJBHomeFactory which can cache EJBHomes for lifetime of the client application. (c) CDAC(Formerly NCST)

  24. Solution • Place EJB Home lookup code into a reusable EJB Home Factory, which can cache EJB Homes for the lifetime of a client application. • Reuse the same EJB home instance throughout the life time of the client. • Plain java class. • Singleton (c) CDAC(Formerly NCST)

  25. Client code AccountHome anAccountHome = (AccountHome)EJBHomeFactory.getFactory(). lookUpHome(AccountHome.class); import javax.ejb.*; import java.rmi.*; import java.util.*; import javax.naming.*; public class EJBHomeFactory { private Map ejbHomes; (c) CDAC(Formerly NCST)

  26. private static EJBHomeFactory aFactorySingleton; Context ctx; private EJBHomeFactory() throws NamingException { ctx = new InitialContext(); this.ejbHomes =Collections.synchronizedMap (new HashMap());} public static EJBHomeFactory getFactory() throws NamingException { if ( EJBHomeFactory.aFactorySingleton ==null ) { EJBHomeFactory.aFactorySingleton = new EJBHomeFactory(); } return EJBHomeFactory.aFactorySingleton;} (c) CDAC(Formerly NCST)

  27. public EJBHome lookUpHome(Class homeClass) throws NamingException { EJBHome anEJBHome = (EJBHome) this.ejbHomes.get(homeClass); if(anEJBHome == null) { anEJBHome = (EJBHome) javax.rmi.PortableRemoteObject.narrow (ctx.lookup(homeClass.getName()),homeClass); this.ejbHomes.put(homeClass, anEJBHome); } return anEJBHome; } } (c) CDAC(Formerly NCST)

  28. Business Delegate (c) CDAC(Formerly NCST)

  29. Background • When using Session and/or MessageFaçade, the client is coupled to the EJBlayer, creating dependencies between clientand server. (c) CDAC(Formerly NCST)

  30. Problems • Complicates client logic with complex error handling. – NamingExceptions, RemoteExceptions,EJBException to be caught • Couples the clients directly to EJB and JMS API’s. • Lookup and exception handling code • Dependency of client and server programmers on availability of the complete and compiled session bean layer. • Client programmers depend on the implementation of the Session Façade in order to compile and test their code. (c) CDAC(Formerly NCST)

  31. Cont… • Places recovery responsibility on clients. – When a transaction fails. – May not be necessary to propagate this error to the end application user and ask them to retry. – Instead, client code may automatically re-execute the transaction. – Client code needs to be explicitly aware of catching these transactions and re-trying them. (c) CDAC(Formerly NCST)

  32. Issue • How can intermediary between client & the session façade be created to facilitate decoupling the client from the EJB layer? (c) CDAC(Formerly NCST)

  33. Solution • Create a layer of business delegates: plain java classes that hide EJB API complexity by encapsulating code that required to discover, delegate to and recover from invocation on the session and message façade EJB layer (c) CDAC(Formerly NCST)

  34. Solution • Client-side Intermediary between a client and the Session Façade. • Introduce intermediate class business delegate to decouple business components from the code that uses them. • Manages the complexity of distributed component lookup, exception handling and recovery • Adapts the business component interface to a simpler interface for use by views. • Plain java classes (c) CDAC(Formerly NCST)

  35. How? • Clients locally invoke methods on the BD • BD delegates directly to a method with the same signature on the session façade, or populate a JMS message and send it to the Message Façade. • Maps one-to-one to session beans • Wrap multiple message driven beans. (c) CDAC(Formerly NCST)

  36. Functions of BD • Delegate method calls to an EJB. • Hide EJB specific system exceptions. – RemoteException and EJBException – JMS exceptions are caught in the business delegate and re-thrown to the client as a non-ejb specific exceptions,such as a BusinessDelegateException. – Application level exceptions are passed to the client. • Cache data locally. • Transparently re-try failed transactions. • Prototype business delegates can be written that • simply return dummy data. (c) CDAC(Formerly NCST)

  37. EJB Command (c) CDAC(Formerly NCST)

  38. EJB Command • Developing with a session façade and business delegates can result in long change-deploy-test roundtrips, which can become a bottleneck in a large project. • The crux of the problem is that the business logic is being placed in a layer of session EJB’s, which can be pretty heavy weight to develop with. (c) CDAC(Formerly NCST)

  39. Issue • How can a developer implement use case’s business logic in a lightweight manner to achieve all benefits of session façade & business delegate (c) CDAC(Formerly NCST)

  40. The Command Pattern • Wrap business logic in lightweight command objects • Decouple the client from EJB • Execute in one network call • Act as a façade to the EJB layer • Plain java class with gets, sets and an execute method. (c) CDAC(Formerly NCST)

  41. How? • Clients interact with the command object locally • Execute within a remote EJB server,transparently to the client. • Encapsulate individual units of work in an application. • A use case’s business logic encapsulated in a command. (c) CDAC(Formerly NCST)

  42. Command • Client creates a Command • Client sets attributes onto the command • Client calls the command’s execute method • Client calls gets on the command until it has retrieved all the data resulting from the execution of the command/use case. (c) CDAC(Formerly NCST)

  43. Interaction • The client instantiates the command object • The client calls an executeCommand method on the routing logic/CommandExecutor • The CommandExecutor delegates the call to an EJBCommandTarget (part of routing logic) • The command target knows how to send the command to the command server • CommandServer is a stateless session bean. • CommandServer calls the execute method on the command, which then goes about its business logic. (c) CDAC(Formerly NCST)

  44. Benefits • Rapid Application Development (RAD) • Separation of business logic from presentation logic. • Forces execution of use cases in single roundtrip. • Decouples client from EJB. • Commands can execute locally or produce dummy data. • Allows multiple return values. (c) CDAC(Formerly NCST)

  45. Disadvantages • Very coarse-grained transaction control. Commands can only run under the transaction settings of the CommandServer that executes them (as they are just plain java beans). The workaround for this is to deploy multiple command server session beans with different jndi names and transaction settings (configured in the deployment descriptors). • Can’t use security: Since business logic is embedded in the command beans. • Commands can become unmanageable on large projects. (c) CDAC(Formerly NCST)

  46. Data Transfer ObjectorValue Object (c) CDAC(Formerly NCST)

  47. Exchange of data • Read data from the server for displaypurposes • Change some data on the server by creating,updating or removing data. (c) CDAC(Formerly NCST)

  48. Need • Transfer bulk data with the server. – Many parameters in a method call. – Client gets multiple attributes from a session or entity bean by executing multiple fine-grained calls to the server. (c) CDAC(Formerly NCST)

  49. Problem • Each call to the server is a network call • Blocking on the client while the EJB server intercepts the call to the server and performs transaction and security checks and retrieval • Each method call executes in its own separate transaction if the client is not using Java Transaction API client demarcated transactions. (c) CDAC(Formerly NCST)

  50. Issue • How can a client exchange bulk data without the server making multiple fine-grained network calls? (c) CDAC(Formerly NCST)