Profiles are an attempt to modularize the different parts in Java EE, this blog entry by Roberto Chinnici's discusses the current advances in Profiles which are to become a part of the upcoming Java EE 6 release.
By the far the most animated part has been the discussion around the Web Profile, with several definitions being proposed. Personally, I found it very interesting to see how EG members crafted their proposals by following different routes and aiming for somewhat different goals. This is a testament to the activity and liveliness of the platform. At this stage, we think that the best path forward consists of polling the community for feedback on which definition of Web Profile they'd most like to see adopted by the expert group. One of the driving ideas around profiles is to move away from a big-bang model for the delivery of the platform, enabling smaller, focused communities to forge ahead in the context of a profile they define. It is natural then to achieve as much decoupling as possible from the beginning and push profiles into separate JSRs, to be finalized on their own timeline.
The blog post then continues enlisting each specification and discussing it some detail, finishing with the following remarks on Profiles.
As we expand the freedom to combine technologies in a product, the issue of compatibility requirements that span multiple technologies comes to the fore. For example, the Java EE 5 specification contains requirements that servlet containers must honor wrt the availability of JTA. The plan for Java EE 6 is to rewrite such requirements so that they will apply to any profiles and implementations thereof that contain the relevant combination of technologies. Going back to the example, any product conforming to any Java EE profile that includes both servlets and JTA will have to honor those requirements. The rationale has two components: on one hand, we think that the Java EE requirements add significant value to standalone technologies, as testified e.g. by the large number of servlet containers which implement JTA in a way that is compatible with what Java EE mandates; at the same time, calling out the requirements will help ensure that applications that target profiles will work on the full platform. Overall, this makes profiles more than just collections of independently tested technologies, because those technologies will be tied together in interesting ways, deliver more functionality than they would on their own. This brings me to the last point I'd like to make. One concern we heard around profiles is that they might weaken compatibility. Essentially, if my application targets the Web Profile (however defined) + JAX-RS 1.0, then it won't run on any plain Web Profile product. Although that's technically true, it's important to recognize that there is an upward compatibility guarantee in the form of the full platform, at least when the added technologies are required components, as JAX-RS is. This is no worse than (and, in fact, better than) the current compatibility story for, say, servlets + Struts. We do expect though that, whatever choice is made re the Web Profile, we may enter an "experimental" phase in which products with different feature sets will compete in the Web Profile space, until one feature set prevails. I'd describe that development as welcome and look forward to standardizing the winning feature set in a future Java EE profile. The Web Profile itself may evolve in the future by adding more technologies (but not by subtracting them, except via pruning), based on experience acquired after its first release.
Read Robertos' complete post on Profiles: http://weblogs.java.net/blog/robc/archive/2008/02/profiles_in_the_1.html