J2EE Project Dangers Siddhesh

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)


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


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


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


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!


6

Danger 2: Over-Engineering

• Project phase: Design

• Project phase(s) affected: Development

• System characteristics affected: Maintenance, scalability, performance


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


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


9

Danger 3: Not separating Presentation from Business logic

• Project phase: Design

• Project phase(s) affected: Development

• System characteristics affected: Maintainability, extensibility, performance


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


11

Separating presentation from business logic• Reuse GUI frameworks like taglibs, rather than

trying to build your own• Use the Model 2 Architecture

http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html


12

Danger 4: Not deploying where you develop• Project phase:

Development • Project phase(s) affected:

Stabilization, Parallel, Live • System characteristics affected:

Your sanity


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


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


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


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.


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


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


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!


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


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


22

Danger 8: Antiquated development processes • Project phase:


Stabilization, Live • System characteristics affected:

Maintenance, code quality


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

http://www.javaworld.com/jw-10-2000/jw-1020-ant.html








24

Danger 9: Failure to employ frameworks • Project phase:


Development, Stabilization, Live • System characteristics affected:

Maintenance, extensibility, code quality


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.


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

http://www.javaworld.com/jw-09-2000/jw-0929-ejbframe.html


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


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


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


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


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.


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


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


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!


35


• 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

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html


36


• Move to a completely different technology– CORBA– .NET – Jini/JavaSpaces (for non-commercial applications only!)


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.


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.


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


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.


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


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


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


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


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

http://reismagos/Papers/JavaAndJDBC/index.html

http://www.javaworld.com/

http://java.sun.com/blueprints/patterns/catalog.html

Technology

J2EE Project Dangers Siddhesh