Precursor, in my experience most of the server-side apps I've measured (whether direct 3-tier, or an SOA layer) through usecase and stress/load testing point towards JavaEE focused development as being more scalable while maintaining a good performance. Small scale apps, however, obviously run well and smaller footprint when not JavaEE, I'm not disputing that.
Given the above statement, I have had several times where a constraint or requirements puts the application or service to be mandated on a (stock) Tomcat, which needless to say is not a JavaEE container, but it is the same application(s) but with different deployment constraints. I don't want to write two different apps, but I do want to maintain the perf/scalability that I've observed with a 'pure' JavaEE implementation/deployment.
Question: Are there any good practices around developing, deploying, and maintaining a 3-tier (web) or SOA (webservice/REST/RMI) service application that can support deployment in both Tomcat (javaSE w/ web servlet) a well as a full JavaEE container while still getting the benefits when utilizing JavaEE features?
Well, some of the services that a JEE application server provides you can also get in a servlet container like Tomcat, using frameworks (for lack of a better word) like Spring.
For instance, persistence, transaction demarcation, dependency injection and security can be added declaratively in both contexts, using XML, annotations or AOP (or a combination of these).
You can pretty clearly seperate these concerns from the code that makes up your business logic, which should at least make that code portable (in theory).
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.