Upload
siddhesh-bhobe
View
1.142
Download
0
Embed Size (px)
DESCRIPTION
Preventing disaster in your J2EE project
Citation preview
Persistent Systems Private Limitedhttp://www.persistent.co.in
1
J2EE Project Dangers Pitfalls to avoid for ensuring success of your project
Siddhesh Bhobe(based on articles in JavaWorld)
Persistent Systems Private Limitedhttp://www.persistent.co.in
2
Project Phases
• Vendor Selection: Picking the best possible mix of tools -- from the app server right down to your brand of coffee
• Design: You know exactly what you are building and how you will build it. Coding is OK!
• Development• Stabilization/Load Testing: Impose a feature freeze and focus
on build quality, as well as ensure that the system's vital statistics can be met
• Live: Date set in stone
We will consider the effect in context to the project phases
Persistent Systems Private Limitedhttp://www.persistent.co.in
3
Danger 1: Not understanding Java, EJB, J2EE• Project phase:
Design, Development • Project phase(s) affected:
Design, Development, Stabilization, Live • System characteristics affected:
Maintainability, scalability, performance
Persistent Systems Private Limitedhttp://www.persistent.co.in
4
Danger 1: Symptoms
• Not knowing what the following are and what they do:– When objects can be garbage collected -- dangling
references – Inheritance mechanisms used in Java – Method over-riding and over-loading – Why java.lang.String proves bad for performance – Pass-by reference semantics of Java (versus pass-by
value semantics in EJB) – Using == versus implementing the equals() method – Hotspot (and why old tuning techniques negate Hotspot
optimizations) – The JIT and when good JITs go bad (unset JAVA_COMPILER
and your code runs just fine, etc.) – The Collections API
Persistent Systems Private Limitedhttp://www.persistent.co.in
5
Danger 1: Symptoms
• EJBs that work when they are first called but never thereafter – Ex: stateless session beans that are returned to the ready pool
• Not knowing for what the developer is responsible, compared with what the container provides – Manual transaction management – Custom security implementations
• EJBs that do not correspond to the specification – fire threads– load native libraries– attempt to perform I/O
Do NOT look at EJBs from your vendors eyes!
Persistent Systems Private Limitedhttp://www.persistent.co.in
6
Danger 2: Over-Engineering
• Project phase: Design
• Project phase(s) affected: Development
• System characteristics affected: Maintenance, scalability, performance
Persistent Systems Private Limitedhttp://www.persistent.co.in
7
Danger 2: Symptoms
• Oversized EJBs • Role and relationships between EJBs not clear to
developers• Nonreusable EJBs, components, or services • EJBs starting new transactions when an existing
transaction will do • Data isolation levels set too high in an attempt to
be safe – Serializable, Repeatable Read, Read Committed, Read
Uncommitted
Persistent Systems Private Limitedhttp://www.persistent.co.in
8
Avoiding Over-Engineering
• Design and implementation should strictly be driven by the requirements, nothing more
• Don't try to second-guess what the system will need to look like in the future– That doesn’t mean you ignore performance and
scalability requirements!
• Leave scalability and fail over for the application server infrastructure to handle for you
• Employ Design Patterns
Persistent Systems Private Limitedhttp://www.persistent.co.in
9
Danger 3: Not separating Presentation from Business logic
• Project phase: Design
• Project phase(s) affected: Development
• System characteristics affected: Maintainability, extensibility, performance
Persistent Systems Private Limitedhttp://www.persistent.co.in
10
Danger 3: Symptoms
• Large and unwieldy JSPs • You find yourself editing JSPs when business logic
changes • A change in display requirements forces you to
edit and redeploy EJBs and other backend components
Persistent Systems Private Limitedhttp://www.persistent.co.in
11
Separating presentation from business logic• Reuse GUI frameworks like taglibs, rather than
trying to build your own• Use the Model 2 Architecture
Persistent Systems Private Limitedhttp://www.persistent.co.in
12
Danger 4: Not deploying where you develop• Project phase:
Development • Project phase(s) affected:
Stabilization, Parallel, Live • System characteristics affected:
Your sanity
Persistent Systems Private Limitedhttp://www.persistent.co.in
13
Danger 4: Symptoms
• Multiday or weeklong transitions to live systems • Major risk involved in going live, with many
unknowns and major usage scenarios not tested • Data in live systems not the same as data in
development or stabilization setups • Inability to run builds on developer machines • Application behavior is not the same in the
development, stabilization, and production environments
Duplicate environments completely and faithfully!Example: XAT
Persistent Systems Private Limitedhttp://www.persistent.co.in
14
Danger 5: Choosing the wrong vendors• Project phase:
Vendor Selection • Project phase(s) affected:
Design, Development, Stabilization/Load Testing, Live
• System characteristics affected: Scalability, performance, maintainability, stability
Persistent Systems Private Limitedhttp://www.persistent.co.in
15
Danger 5: Symptoms
• Tools not utilized properly • Significant system redesign required in order to
work around known or unknown bugs in the implementation
• Poor integration between different tools (application servers and IDEs, IDEs and debuggers, source control and build tools, etc)
• For IDEs, debuggers, etc., developers simply forsaking them in favor of their own favorite tools
Persistent Systems Private Limitedhttp://www.persistent.co.in
16
Choosing vendors correctly…
• The only way to evaluate is use!• The only way to evaluate a J2EE implementation is
to build a proof of concept that touches the features you are betting your architecture on.
• Continually evaluate the market.
Persistent Systems Private Limitedhttp://www.persistent.co.in
17
Danger 6: Not knowing your vendor• Project phase:
Vendor Selection • Project phase(s) affected:
Design, Development, Stabilization/Load Testing, Live
• System characteristics affected: Maintainability, scalability, performance
Persistent Systems Private Limitedhttp://www.persistent.co.in
18
Danger 6: Symptoms
• Development takes much longer than the worst estimate
• Developers reinvent the wheel when the vendor or implementation provides the required functionality out of the box
Persistent Systems Private Limitedhttp://www.persistent.co.in
19
How to understand your vendor better!• Subscribe to all the vendor-supplied support
resources you can find– email lists– news groups– release notes (especially those with a list of bug fixes)
• Invest in training as soon as possible• Build a quick proof of concept to break the team in
gently• Figure out the build process as early as possible
Your schedule doesn't give you the time to not do it!
Persistent Systems Private Limitedhttp://www.persistent.co.in
20
Danger 7: Not designing for scalability or performance• Project phase:
Design • Project phase(s) affected:
Development, Load Testing, Live • System characteristics affected:
Scalability, performance, maintainability
Persistent Systems Private Limitedhttp://www.persistent.co.in
21
Danger 7: Symptoms
• Unacceptably slow systems • Systems that make heavy use of server-side state
and cannot take full advantage of vendor clustering technology
Test for performance in exactly the same environmentExample cases: Tradec, XAT
Persistent Systems Private Limitedhttp://www.persistent.co.in
22
Danger 8: Antiquated development processes • Project phase:
Development • Project phase(s) affected:
Stabilization, Live • System characteristics affected:
Maintenance, code quality
Persistent Systems Private Limitedhttp://www.persistent.co.in
23
Danger 8: Symptoms
• Using the waterfall method.• Builds are a nightmare, because there is no build process• Build days equal lost development days because nothing
else gets done. • Components are not adequately tested before integration.
Integration testing involves taking two unstable components, strapping them together, then looking at the stack traces.
Using JUnit and ANT!http://www.javaworld.com/jw-10-2000/jw-1020-ant.html
Persistent Systems Private Limitedhttp://www.persistent.co.in
24
Danger 9: Failure to employ frameworks • Project phase:
Development • Project phase(s) affected:
Development, Stabilization, Live • System characteristics affected:
Maintenance, extensibility, code quality
Persistent Systems Private Limitedhttp://www.persistent.co.in
25
Danger 9: Symptoms
• Bugs in core libraries that are used multiple times in code.
• No set logging standards– system output is impossible to read or parse with scripts.
• Bad and inconsistent exception handling– sending back a SQLException stack trace when a user
tries to check out their shopping cart.
Persistent Systems Private Limitedhttp://www.persistent.co.in
26
Frameworks should address the following:• Logging • Exception handling • Getting a connection to resources like databases • Building JSP pages • Data validation
Related article:
http://www.javaworld.com/jw-09-2000/jw-0929-ejbframe.html
Persistent Systems Private Limitedhttp://www.persistent.co.in
27
Danger 10: Basing project plans and designs on marketing blurb• Project phase:
All phases; Vendor Selection particularly influenced
• Project phase(s) affected: All phases are affected
• System characteristics affected: Maintenance, extensibility, design quality, code quality
Persistent Systems Private Limitedhttp://www.persistent.co.in
28
Danger 10: Symptoms
• Technical decisions taken lightly because EJBs are “designed to be portable”
• Vendor selection performed without a "hands-on" trial of the product
• Needing to switch tools during a project lifecycle
Persistent Systems Private Limitedhttp://www.persistent.co.in
29
Suggestions
• Don’t believe vendors• Don’t believe whitepapers paid for by vendors• Download the tool you want to evaluate, roll up
your sleeves, and prototype with it
Persistent Systems Private Limitedhttp://www.persistent.co.in
30
MTV Top Ten
1. Not understanding Java, not understanding EJB, not understanding J2EE
2. Over-engineering3. Not separating presentation logic from business logic 4. Not deploying where you develop 5. Choosing the wrong vendor(s) 6. Not knowing your vendor(s) 7. Not designing for scalability or performance 8. Antiquated development processes 9. Not using frameworks 10. Basing project plans and designs on marketing blurb, not
technical fact
Persistent Systems Private Limitedhttp://www.persistent.co.in
31
To EJB, or not to EJB?
To EJB, or not to EJB: that is the question.Whether 'tis nobler in the mind, to sufferThe slings and arrows of outrageous licensing;Or to take arms against a sea of potential overheads and features,And by opposing end them? To roll your own: to reinvent the wheel;No more; and by reinvent, to say, we continueThe heart-ache of low-level systems maintained in-house,and the thousand natural shocksThat flesh is heir to; 'tis a consummationDevoutly to be avoided.
Persistent Systems Private Limitedhttp://www.persistent.co.in
32
EJB Advantages
• The underpinning EJB specification• Integration with the J2EE platform: servlets, JMS,
JCA, JSP, JDBC and so on• Almost transparent scalability• Free access and usage of complex resources:
transaction and security management, resource pooling, JNDI, component lifecycle management
• Strong and vibrant industry community
Persistent Systems Private Limitedhttp://www.persistent.co.in
33
EJB Disadvantages
• Large, complicated specification• Increased development time• Added complexity compared to straight Java
classes• Potential to produce a more complex and costly
solution than is necessary• Continual specification revisions
Persistent Systems Private Limitedhttp://www.persistent.co.in
34
Alternative Approaches
• Avoid EJB completely, yet still employ a Java solution– Explicitly handle (or ignore) issues such as
multithreading, scalability, and transaction management yourself.
– If they do, you will end up seeing methods like getConnection() and closeConnection(), plus a couple of XXXManagers: can quickly mushroom into a mini-container!
Persistent Systems Private Limitedhttp://www.persistent.co.in
35
Alternative Approaches
• Adopt an EJB-friendly design – Adopt design patterns, usually Model 2 Architecture– Allows for more robust middle tier later
Related Article:http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html
Persistent Systems Private Limitedhttp://www.persistent.co.in
36
Alternative Approaches
• Move to a completely different technology– CORBA– .NET – Jini/JavaSpaces (for non-commercial applications only!)
Persistent Systems Private Limitedhttp://www.persistent.co.in
37
Rules for choosing EJB
1. Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.
2. Choose EJB if you need transaction management. For online catalogues or read-only systems with low user
numbers, you probably don't need EJB. For financial systems or any system where you must
preserve the ACID properties, EJBs are a must.
3. Choose EJB if you need a comprehensive security model.
Persistent Systems Private Limitedhttp://www.persistent.co.in
38
Rules for not choosing EJB
1. Do not use EJB when you find no need for scalability, transaction management, or security and anticipate low numbers of read-only users.
2. Don't choose EJB if you don't need platform independence and don't mind being locked into one particular vendor. • Intranet Applications, for example!
3. Do not choose EJB if your team possesses no EJB experience
4. Do not use EJB just because your company got a free set of licenses from vendor X.
Persistent Systems Private Limitedhttp://www.persistent.co.in
39
EJB Folklore
• You don't need developers to understand SQL if you are using container managed entity beans: Myth!
• EJBs are portable between vendors: Half-myth– CMP entity beans are difficult to port. Session beans and
BMP entity beans usually port quite easily. – Applications that rely on a clustering implementation take
longer to port.– Administration and configuration tools are vendor-specific– Startup and shutdown scripts and build scripts are
vendor-specific too, unless vendor uses ANT
Persistent Systems Private Limitedhttp://www.persistent.co.in
40
EJB Folklore
• Security is free with EJB: Misunderstanding– Provides just a model, you need to set up your users and roles
yourself -- and potentially tie in to an existing authentication source, such as a database or LDAP server.
• EJB solutions are expensive: Mostly-true– Should soon change to a myth. Open source and low-cost
alternatives are offering real competition to the entrenched market leaders
• CMP is faster than BMP or BMP is faster than CMP: Misunderstanding– Depends on the quality of the vendor's CMP engine – The more proprietary an application server is, the more features
it can add to its CMP engine, like batch updates, smart updates, and more.
Persistent Systems Private Limitedhttp://www.persistent.co.in
41
EJB Folklore
• Entity beans are slow. True– Entity beans are often too slow and need to be worked
around by a combination of session beans and value objects.
– Most noticeable in cases where a finder method returns thousands of rows.
– In some cases, application servers try to be smart about loading data (lazy-loading), but such efforts often prove insufficient.
• Stateful session beans are bad and should be avoided. Myth– Prove valuable in certain situations– However, they should be used sparingly as server-side
state always adversely affects scalability
Persistent Systems Private Limitedhttp://www.persistent.co.in
42
From a Gartner Report…
• J2EE and Enterprise JavaBeans (EJB) are not the same– Most Java projects use Java Server Pages/servlet
capabilities and not EJB
• The more costly application servers are designed for EJBs, yet are using JSP/servlet capabilities instead
• Gartner estimates that by 2003, at least 70% of the new applications will be deployed on high-end application servers but 60% of all new J2EE application code will remain JSP/servlet-only
Persistent Systems Private Limitedhttp://www.persistent.co.in
43
How to make the right decision?
• Step 1: Identify and Quantify critical system requirements– Load factors (Max concurrent users, peak usage)– Security (SSL, Roles and Groups)– Transaction Management
• Step 2: Qualify technologies as per your requirements– Rule out technologies that are an overkill!
• Step 3: Evaluate– Proof of concept using the technology of your choice is a must
• Step 4: Decide and put support structure in place– Training and Mentoring– Right toolset
Persistent Systems Private Limitedhttp://www.persistent.co.in
44
There is no substitute for experience and planning!
• Get experience• Don’t bet on on-the-go training• Proactively source training before the project
starts, ideally before the design phase
Conclusion
Persistent Systems Private Limitedhttp://www.persistent.co.in
45
References
• Local copies of most of the articles referred here, we well as other interesting, related links can be found at http://reismagos/Papers/JavaAndJDBC/index.html in the Java Design Techniques section
• This presentation was based on articles from JavaWorld
• J2EE Design Patterns http://java.sun.com/blueprints/patterns/catalog.html