Java Technologies – Trademark Guidelines

The goal is to give this non-technical audience the background they need to understand what engineers are talking about.

It is not clear to me what you (or your audience) are trying to achieve with this. I mean, fully understanding what engineers are talking about obviously requires training to become an engineer proper. OTOH learning only the direct meaning of specific buzzwords gives only superficial knowledge (which can in fact be more dangerous than no knowledge at all).

If, however, you want to let your audience understand the technical problems and challenges behind building an enterprise app, I suggest you minimize the mention of concrete acronyms and frameworks, and focus on describing the problems and solutions in a platform-neutral way. E.g. what happens (what pieces of data are coming and going from where to where, and a little bit of the how) between the user typing in http://www.amazon.com/ and getting to see his/her personal intro page. Then what happens in the background when she puts some books into his basket, and checks them out. Etc.

IMHO you don't necessarily need to go into details of "in .NET you use this-and-that for Object Relational Mapping while in Java you use that-other and their differences are ...". The fundamental problems are the same regardless of language / platform, and the logic of the solutions is similar enough.

Note also that technologies and acronyms come and go, but the nature of the basic problems doesn't change - in fact many of these (such as authentication & authorization, concurrency, transaction isolation, session handling etc.) has been around since the dawn of computing.

Update

Some of the well known current Java Enterprise technologies worth mentioning are:

• servlets
• JSP (getting obsolete but still widely used)
• JSF
• Struts
• Spring
• JPA
• Hibernate
• EJB

Web/application servers:

• Apache Tomcat
• Glassfish
• JBoss

Okie, so most of the *ilities that you have mentioned are nothing but Non-Functional Requirements (NFRs). Now, you cannot both have a cake and eat it too. Extending this basic principle, you can not be the best or in fact meet all your NFRs. So, what is important is find out the top 2 or 3 NFRs that is absolutely a must have and then evaluate your architecture to see where it stands with respect to the expected metrics on these NFRs. I have both witnessed and been a part of the team that did this exercise resulting in better envisioning and focus in deciding the architecture.

Side note: All the NFRs should not be described in qualitative terms (viz., highly performant), rather it should be quantitative that is measurable (viz. it should support 500 concurrent users)

This business. Think real value addition. :)