Plan. Department of Informatics. Advanced Software Engineering Prof. J. Pasquier-Rocha Cours de Master en Informatique - SH 2003/04

Transcription

1 Plan 1. Application Servers 2. Servlets, JSP, JDBC 3. J2EE: Vue d ensemble 4. Distributed Programming 5. Enterprise JavaBeans 6. EJB: Transactions 7. EJB: Persistence Best Practices 8. Final Considerations

2 7. EJB: Persistence Best Practices EJB: Persistence Best Practices 1. Entity Beans or Session Beans plus JDBC? 2. Choosing between CMP and BMP 3. Choosing the right granularity for Entity Beans 4. Persistence Tips and Tricks

3 7. EJB: Persistence Best Practices 7.1 Entity Beans or Session Beans plus JDBC Entity Beans or Session Beans plus JDBC? Control Session beans are forcing you to call methods explicitly to load and store data. Thus, you are in command when to use JDBC explicitly. With entity beans, the container automatically loads and stores data. It might seem easier, but this loss of control might be a problem if you are not careful to tune your container properly and to start and end transactions at the right times, operations that require a single SQL statement can take several statements. Parameter Passing Analogy When you do a query via a session bean, it returns a result set to the client. This is similar to pass-by-value. With an entity bean, you use the "home" to get stubs to server-side objects. This is similar to pass-by-reference. This is no problem when session bean query entity beans collocated in the same process (there is no need to traverse the network). When involving remote clients, use the appropriate design patterns (Data Transfer Objects) to avoid performance issues due to network traffic.

4 7. EJB: Persistence Best Practices 7.1 Entity Beans or Session Beans plus JDBC Entity Beans or Session Beans plus JDBC? (2) Procedural Versus Object-Oriented Session beans that return sets are naturally suited for tabular, business data. Entity beans are Java objects and thus benefit from encapsulation and relationships, and represent data in an object-oriented fashion. Caching Middle-tier data caching is extremely important because it empowers you to reduce database traffic, and your database will most likely be your bottleneck. Session beans do not represent database data and therefore cannot be cached at all. Entity beans can be cached across multiple transactions if the application server is correctly set up. Migration Most EJB deployments are based on existing databases. These databases are likely to be tabular in nature, and many have SQL code that has been tuned over the years to be high-performing. Session bean persistence is somewhat procedural in nature and is a natural evolution of those legacy procedural systems. For some deployments, application developers can simply copy SQL code from existing solutions into the new EJB system.

5 7. EJB: Persistence Best Practices 7.2 Choosing between CMP and BMP Choosing between CMP and BMP Code Reduction and Rapid Application Development If you tell the EJB container a couple of things about your bean, containermanaged persistence can perform all data access logic for you. This reduces the size of your bean tremendously-no more JDBC code in your beans-which reduces overall development time. CMP beans are also fantastic for prototyping. If you need to get something working right away, go with CMP, knowing that you can take a BMP approach later if required. Performance CMP entity beans, if tuned properly, are much higher performing than BMP entity beans. Bugs CMP systems tend to be harder to debug than BMP systems (mistakes in CMP deployment descriptors, ). Control BMP gives you ultimate control over JDBC, and thus you have unlimited flexibility for how you map your objects to the database. For CMP, many containers support complex mappings, but some containers don't.

6 7. EJB: Persistence Best Practices 7.2 Choosing between CMP and BMP Choosing between CMP and BMP (2) Application Server and Database Independence One nice thing about CMP is that you have database independence. You can port your beans to use different databases (event object databases) without changing code. This is important for those who are providing beans to others. Unfortunately, using CMP you are not application server independent. Indeed, there is no standard way to specify the actual O/R mapping. Each container has its own tools, wizard, and/or mapping files that specify which fields correspond to which database columns. Relationships The EJB 2.0 CMP model offers many useful relationship features to bean providers (referential integrity, cardinality, cascading deletes, ) With BMP, you must write the scaffolding code to manage and persist the relationships between entity beans. This can get very difficult.

7 7. EJB: Persistence Best Practices 7.3 Choosing the right granularity for Entity Beans Choosing the right granularity for Entity Beans The granularity refers to how big (or small) your entity beans are. (e.g. command entity bean, command line entity bean). Another choice you have is to make some of your entity beans be Java classes. These Java classes would hang off other entity beans. For example, you could have an order entity bean that has a vector of line-item Java classes. In this case, there are a few rules to respect. Dependent value classes are quick to develop, but they do not guarantee all the usual entity beans benefits.

8 7. EJB: Persistence Best Practices 7.4 Persistence Tips and Tricks Persistence Tips and Tricks Normalizing and Denormalizing Data normalization is the process of eliminating data redundancy in a database, while denormalization is the process of increasing redundancy for performance. Highly normalized data schemas in general are closer conceptually to object-oriented schemas. This generally makes it easier to map your EJBs to your data schema. The disadvantage of normalized data schemas is that when put into production, they often suffer from performance problems. Use Your EJB Object Model to Drive Your Data Model Whenever you have the choice, your EJB object model should drive the development of your data model. The latter can be denormalized with caution to meet the actual performance needs of your EJBs. Living with a Legacy Database Design The vast majority of EJB developers are often forced to tolerate an existing legacy design, one that is often difficult, if not impossible, to change. A large market exists for tools to help deal with legacy databases. Do not underestimate the effort required to address that you have found with your legacy data and the legacy database design.

9 Plan 1. Application Servers 2. Servlets, JSP, JDBC 3. J2EE: Vue d ensemble 4. Distributed Programming 5. Enterprise JavaBeans 6. EJB: Transactions 7. EJB: Persistence Best Practices 8. Final Considerations

10 8. Final Considerations Final Considerations 1. Business Requirements 2. J2EE vs.net 3. Is EJB appropriate? 4. How to continue

11 8. Final considerations 8.1 Business requirements Business requirements Get as many of the business requirements as possible, in order to have a fairly complete basis for designing your object model: Build a complete list of requested features: asking questions about user interface and legacy integration requirements, use case-analysis, Consult with any subject matter experts you can access. Weight each feature based upon corporate and business goals, as well as the time anticipated to implement it.

12 8. Final Considerations 8.2 J2EE vs.net J2EE vs.net Some arguments for.net against J2EE:.NET has the very good Visual Studio.NET tool..net has a simpler programming model..net gives you language neutrality..net benefits from being strongly interweaved with the underlying operating system. Some arguments for J2EE against.net: J2EE is a proven platform, while.net is a rewrite and introduces risk as with any firstgeneration technology J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object models and take advantage of performance features. J2EE gives you platform neutrality and lets you use any operating system you prefer. Developers can use the environment they are most productive in. J2EE has a better legacy integration story through the Java Connector Architecture (JCA) J2EE lets you use Java, which is better than C# due to market-share and maturity.

13 8. Final considerations 8.3 Is EJB appropriate? Is EJB appropriate? Reasons that are not important at all: EJB server cost. Resource pooling Clean separation between logic and presentation Real reasons not to use EJB: You can't deal with the limitations of EJB (e.g. multithreaded engine ) You have existing skillsets or investments in a working technology. For complex applications, can you honestly believe your staff is capable of building a better application server than the best specialists? Your application is a big GUI to a database. Your application is simple and will not evolve over time. You need an initial system built extremely fast.

14 8. Final Considerations 8.3 Is EJB appropriate? Is EJB appropriate? (2) Real reasons to use EJB over Java classes: In the long term, your system is built faster and more reliably. It is easier to hire new employees. You benefit from the best practices the world is building around EJB. You can have different user interfaces. You can work with industry-standard tools to rapidly develop your system. You can separate your Web tier and application server.

15 8. Final Considerations 8.4 How to continue How to continue Staff your project Design a complete object model first Implement vertical slice first (one or two use cases) Verify scaling (stress tests): "Do not forget the network!" Get Design Patterns right early on. Invest in "good/appropriate" tools

16 Références Ce cours a été construit à partir de diverses présentations, de documents du web et livres: Didier DONSEZ (Université Joseph Fourier) Jürgen Stuber (Ecole des Mines de Nancy) Christophe Bouthier (Equipe ECOO, LORIA) Michael Factor (IBM Labs in Haifa) Livres de la bibliographie