1. 2 Introduction Building enterprise applications is hard state management communications lookup resource management security and all this before we.

1

2

Introduction

Building enterprise applications is hard state management communications lookup resource management security and all this before we even get to the real problem

domain!

3

“Enterprise”

An enterprise system is one which … … shares some or all resources used … is intended for internal (or mostly internal) use … must work within existing architecture … will be deployed and maintained by internal IT staff … requires greater robustness … must fail gracefully (if it does fail) … must gracefully handle evolution over time

4

Item 3

Differentiate layers from tiers "N-tier systems are better than 2-tier systems"; why?

Network access hurts performance yet n-tier systems double the number of network traversals

So why do this? Connection pooling Centralization of logic Easier deployment

Question: can I get the best of both worlds? Tiers are physical nodes in the network; layers are logical

separations of related functionality Don't assume business logic (layer) must be on middle tier Not all business logic can rest in the middle (ex: input validation) Browser-servlet-database arrangement is 3 tiers, by the way

5

Item 4

Keep data and processors close together Reason: Obtaining data is often not a free action

Network access significantly slower (see Item 17) Keep data close to processors

Avoid flagrantly fetching or storing data remotely Cache data to avoid having to re-fetch it Store data locally (in-proc or local file) to avoid network access Be wary of cache-concurrency problems Be wary of cache-identity concerns

Keep processors close to data If we can't bring the data to the code, bring the code to the data Use stored procs to execute code in the same process as data Run Java code in JVM inside RDBMS (Oracle, DB/2, etc.) Avoids the cache-identity and cache-concurrency problems

6

Item 7

Be robust in the face of failure "Stuff happens": Code must deal gracefully with exceptions

Don't just "catch-and-log" Deal with exceptions as they were intended:

SQLExceptions: database failure RemoteExceptions: network failure EJBExceptions: container failure (never catch!) Application exceptions: user did something wrong (always catch!)

JSP, servlets, JMS, all need to handle exceptions gracefully Plan on dealing with failure:

How will you patch production code? How will you recover from database or network failure? How will you deal with OutOfMemoryErrors? How will you deal with users bookmarking web pages?

Thinking about failure up front yields better robustness In other words, have a unified "problem strategy"

Not all failures can be solved in code; solve what you can

7

Item 21

Consider partitioning components to avoid excessive load on any one server Distribution

split the system into smaller pieces (DNS) horizontal: segregate by data elements vertical: “split the system down the middle”

problem: doesn’t permit redundancy problem: which server you talk to has to be coded somewhere

Replication (Clustering) transparent copies across machines: “any node works” problem: update propagation problem: identity breeds contention

8

Item 26

Prefer rules engines for decision-making Complex decision-making can be painful in imperative

if/else if/else if/else style “If the customer is a Silver VIP, and they’re buying more than 5

widgets, but only if they live in California, do they get the 15% discount. Now if they live in Nevada…”

Maintenance, testing, understanding, all of it Particularly for n-stage decision-making (dependencies) This is where OO languages don’t excel Worse yet, this is the very code that needs to be dynamic/flexible

Instead, prefer a rules engine (JSR-94) to do it Put rules into a rules base Put data (“assert facts”) into the rules base Ask the engine for the results—it figures out dependencies

9

Item 37

Replicate resources when possible Imagine you are a kindergarten teacher:

20 kids, 1 jump rope. They all want the jumprope. Now what? Take turns and share? No: 1 min. of fun, 19 mins. of boring Jump less? same ratio (1:19 fun:boring) Jump faster? Penalizes the faster kids, not what you want

Ask any kindergarten teacher: you buy more jumpropes! Centralized resources create points of contention

Remembering the discussion of identity, we choose to replicate Because kids don’t care which jumprope they use

Choose to create new objects rather than reuse old ones Cost of synchronizaiton often isn’t worth the benefit GC doesn’t suck!

Replication implies issues with mutation Replicated resources always need a concurrency strategy You can put a time-to-live on data and refresh periodically (leasing data) Or you only replicate read-only or read-mostly data

Replication isn’t just multiple servers; caching is replication

10

Item 45

Never assume you own the data or the database Enterprise resources are shared, by definition

and in some cases, they’re shared without your knowledge … until the day that VP calls you to complain about your changes … or the report server the web guys created breaks

If they’re shared resources, they’re not yours to refactor this is why legacy systems remain alive for so long; it’s extremely

difficult to track down all the clients of a database/system Conclusions:

schemas run the risk of being “locked in” far more so than your code database longer-lived than most code that uses it; therefore, keep

schemas “code-neutral” put data constraints into relational constraints, not in code

11

Item 57

Security is a process, not a product “If you think technology can solve your security

problems, then you don’t understand the problems and you don’t understand the technology” (Secrets and Lies)

developers like to believe that “cryptography == security” for example, HTTPS makes credit card numbers secure, right?

Even when they’re sitting in the database? any number of attack vectors are open:

social engineering attacks database attacks man-in-the-middle attacks (inside the corporate firewall) … none of which attack SSL at all!

security is a mode of thinking, not “magic pixie dust” can an attacker guess another user’s JSESSIONID? can an attacker bypass page flow and authorization checks? can an attacker see critical information via Telnet?

12

Item 72

Don't fight GC Java coders try to “help” GC because “GC sucks”; NO! Different GC implementations have different effects

Mark-sweep, copying, generational, arena, ref-counting “Help”ing GC means different things here Myth: “objects expensive to create”; 10 CPU instructions Myth: “call System.gc()”; could force restart of GC pass (Use –XX:+DisableExplicitGC to turn System.gc() off)

Taxonomy of object lifecycle mechanisms: Object factory, object bank, finite object manager, object pool

Moral: code intentionally, don’t “help” GC before you profile

13

Conclusion

Not everything is cut-and-dried answers Many of these items contradict one another in places

Certain items will apply in certain situations Everything is context-dependent That’s what makes it fun!

In all things, be a little cynical If your experience seems to contradict the book, experiment! Just because it’s written in a book doesn’t make it right

Keep an eye on future developments Much of what’s here applies to Spring, Hibernate, .NET, … J2EE continues to evolve as well

14

Credentials

Who is this guy? Independent consultant and mentor Speaker

TechEd, No Fluff Just Stuff, VSLive!, JavaOne, and others Java Community Process EG member (JSR 175, 250, …) Author

Effective Enterprise Java (Addison-Wesley, 2004) Server-Based Java Programming (Manning, 2000) C# in a Nutshell (with Drayton, Albahari; OReilly, 2001) SSCLI Essentials (with Stutz, Shilling; OReilly, 2003) Papers at www.neward.net/ted/Papers Weblog at www.neward.net/ted/weblog