This specification defines the Jakarta™ EE Web Profile (“Web Profile”), a profile of the Jakarta™ Platform, Enterprise Edition specifically targeted at web applications.
1.1. Target and Rationale for the Web ProfileThe Web Profile is targeted at developers of modern web applications.
With the term “modern” we intend to highlight the fact that the world of web applications has made much progress since the introduction of the first Servlet specification. Inevitably, the number of technologies used to create even simple web applications had grown by leaps and bounds. In fact, few web applications today are written directly to the servlet API: most applications rely on standard or third-party frameworks and libraries, often developed as open source, which in turn use the services of the servlet container.
Besides managing HTTP interactions, most web applications have significant requirements in the areas of transaction management, security and persistence. Such requirements can be readily addressed by technologies that have been part of the Jakarta EE platform for quite some time, such as the Jakarta Enterprise Beans 3.x technology and the Jakarta Persistence, but that are rarely supported by “plain” servlet containers. By incorporating many of these APIs, the Web Profile aims at raising the bar for what should be considered a basic stack for the development of web applications using the Java platform.
Targeting “modern” web applications then implies offering a reasonably complete stack, composed of standard APIs, and capable out-of-the-box of addressing the needs of a large class of web applications. Furthermore, this stack should be easy to grow, so as to address any remaining developer needs.
Against this drive towards completeness, one wishes to balance a desire to limit the footprint of web containers, both in physical and in conceptual terms. From the point of view of developers learning the Web Profile, it is more valuable to have a small, focused profile, with as little overlap between technologies as possible, rather than a more powerful but overly complex one, with redundant APIs.
In defining the Web Profile we strove to find a middle ground between these two sets of requirements.
In terms of completeness, the Web Profile offers a complete stack, with technologies addressing presentation and state management (Jakarta Server Faces, Jakarta Server Pages), core web container funtionality (Jakarta Servlet), business logic (Jakarta Enterprise Beans Lite), transactions (Jakarta Transactions), persistence (Jakarta Persistence) and more.
As for simplicity, it leaves out many of the enterprise backend APIs that are part of the Jakarta EE platform. It also relies on the pluggability features in the Servlet specification to allow applications to use libraries that extend the servlet container with minimal configuration overhead.
Finally, it is worth reminding that Web Profile products are allowed to ship with more technologies than the required ones. It is conceivable that products will offer a choice at installation time between different configurations, some richer in extensions, or even allow for complete customization beyond the required core (“à la carte” installation).
1.2. Determining Applicable Requirements Profile definitions can be quite terse, amounting to little more than a list of required technologies and a (possibly empty) set of additional requirements, beyond those entailed by all the referenced specifications. Being the first profile of the Java™ EE 6 Platform to be defined, we expect the Web Profile specification to be used as a model for future profiles. It will also be seen as a starting point for understanding how the requirements defined in the Jakarta EE Platform specification apply to a profile that subsets the platform itself, a significant innovation in this version of the platform. (The case of a profile that is a superset of the platform is much easier to picture.) To help with this process, this section attempts to shed light on how one should go from the definition of the Web Profile to figuring out the exact set of requirements that apply to it, and consequently to any product that implements it.As dictated by the general rules for Jakarta EE profiles in the Platform specification, products that implement the Web Profile must honor:
all requirements of the Jakarta EE Platform specification that apply to all profiles;
all requirements of this specification;
all requirements of the individual component specifications;
all requirements in the Jakarta EE Platform specification that are conditional on the presence of a specific technology or combinations of technologies.
Let’s look at some examples of requirements from each grouping.
For the first one, the Jakarta EE Platform specification mandates support for the Java™ Platform, Standard Edition 11 API.
In the second category one can point out the requirement to support Jakarta EE web application modules ( .war files) (see Additional Requirements).
The third category is hopefully self-explanatory. For example, Web Profile products must implement the Servlet API, which in turn means they need to satisfy all the requirements listed in the Jakarta Servlet specification.
The fourth category is the most complex. As a first example, since a Web Profile product is required to implement the Servlet technology, it must also follow all general requirements for Jakarta EE web containers in the Platform specification. Additionally, it must follow all security requirements in the Platform specification that pertain to Jakarta EE web containers, all interoperability requirements for such containers, etc. Furthermore, since a Web Profile product must implement the Jakarta Transactions API, it must also satisfy all the Platform specification’s transaction management-related requirements for web components, which indeed are conditional on the presence of Jakarta Servlet and Jakarta Transactions.
As a negative example for the fourth category of requirements, consider the Jakarta Messaging technology. Since it is not a required component of the Web Profile, Web Profile products are not required to include an implementation of Jakarta Messaging, nor do they have to support other Jakarta Messaging-related requirements, like the ability to inject message destination references. On the other hand, a Web Profile product that included an implementation of Jakarta Messaging would be required to honor all the Jakarta Messaging-related requirements in the Jakarta EE Platform specification.
Particular care should be taken when determining applicable requirements based on the presence of Jakarta Enterprise Beans Lite in the Web Profile. As described in the Jakarta Enterprise Beans specification, Jakarta Enterprise Beans Lite is a subset of the Jakarta Enterprise Beans API. When examining an Jakarta Enterprise Beans-related requirement in the Jakarta EE Platform spec, one must first of all determine which API classes, component types and Jakarta Enterprise Beans container services are mentioned in the requirement itself. Only if all of them fall inside the Jakarta Enterprise Beans Lite subset that requirement is considered applicable to Web Profile products.
For example, since Jakarta Enterprise Beans Lite does not include any remote functionality, the EJB annotation may not be used to inject a remote reference, something that should be kept in mind when evaluating the requirements in the Platform specification section “Jakarta Enterprise Beans References”.
1.3. Acknowledgements for Version 6Version 6 of this specification was created under the Java Community Process as JSR-316. The spec leads for the JSR-316 Expert Group were Bill Shannon (Sun Microsystems, Inc.) and Roberto Chinnici (Sun Microsystems, Inc.). The expert group included the following members: Florent Benoit (Inria), Adam Bien (Individual), David Blevins (Individual), Bill Burke (Red Hat Middleware LLC), Larry Cable (BEA Systems), Bongjae Chan (Tmax Soft, Inc.), Rejeev Divakaran (Individual), Francois Exertier (Inria), Jeff Genender (Individual), Antonio Goncalves (Individual), Jason Greene (Red Hat Middleware LLC), Gang Huang (Peking University), Rod Johnson (SpringSource), Werner Keil (Individual), Michael Keith (Oracle), Wonseok Kim (Tmax Soft, Inc.), Jim Knutson (IBM), Elika S. Kohen (Individual), Peter Kristiansson (Ericsson AB), Changshin Lee (NCsoft Corporation), Felipe Leme (Individual), Ming Li (TongTech Ltd.), Vladimir Pavlov (SAP AG), Dhanji R. Prasanna (Google), Reza Rahman (Individual), Rajiv Shivane (Pramati Technologies), Hani Suleiman (Individual).
1.4. Acknowledgements for Version 7Version 7 of this specification was created under the Java Community Process as JSR-342. The Expert Group work for this specification was conducted by means of the http://javaee-spec.java.net project in order to provide transparency to the Java community. The specification leads for the JSR-342 Expert Group were Bill Shannon (Oracle) and Linda DeMichiel (Oracle). The expert group included the following members: Deepak Anupalli (Pramati Technologies), Anton Arhipov (ZeroTurnaround), Florent Benoit (OW2), Adam Bien (Individual), David Blevins (Individual), Markus Eisele (Individual), Jeff Genender (Individual), Antonio Goncalves (Individual), Jason Greene (Red Hat, Inc.), Minehiko Iida (Fujitsu), Alex Heneveld (Individual), Jevgeni Kabanov (Individual), Ingyu Kang (Tmax Soft, Inc.), Werner Keil (Individual), Jim Knutson (IBM), Ming Li (TongTech Ltd.), Pete Muir (Red Hat, Inc.), Minoru Nitta (Fujitsu), Reza Rahman (Caucho Technology, Inc), Kristoffer Sjogren (Ericsson AB), Kevin Sutter (IBM), Spike Washburn (Individual), Kyung Koo Yoon (Tmax Soft).
1.5. Acknowledgements for Version 8Version 8 of this specification was created under the Java Community Process as JSR-366. The Expert Group work for this specification was conducted by means of the http://javaee-spec.java.net and https:javaee.github.io/javaee-spec projects in order to provide transparency to the Java community. The specification leads for the JSR-366 Expert Group were Bill Shannon (Oracle) and Linda DeMichiel (Oracle). The expert group included the following members: Florent Benoit (OW2), David Blevins (Tomitribe), Jeff Genender (Savoir Technologies), Antonio Goncalves (Individual), Jason Greene (Red Hat), Werner Keil (Individual), Moon Namkoong (TmaxSoft, Inc.) Antoine Sabot-Durand (Red Hat), Kevin Sutter (IBM), Ruslan Synytsky (Jelastic, Inc.), Markus Winkler (oparco - open architectures & consulting). Reza Rahman (Individual) participated as a contributor.
1.6. Acknowledgements for Jakarta EE 8The Jakarta EE 8 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).
1.7. Acknowledgements for Jakarta EE 9The Jakarta EE 9 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).
1.8. Acknowledgements for Jakarta EE 9.1The Jakarta EE 9.1 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).
1.9. Acknowledgements for Jakarta EE 10.0The Jakarta EE 10 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4