Java Platform Enterprise Edition Java Ee Specification 80 Linda Demichiel

Java Platform Enterprise Edition Java Ee
Specification 80 Linda Demichiel download
https://ebookbell.com/product/java-platform-enterprise-edition-
java-ee-specification-80-linda-demichiel-7435666
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
J2eetm Technology In Practice Building Business Applications With The
Javatm 2 Platform Enterprise Edition First Edition Cattell
https://ebookbell.com/product/j2eetm-technology-in-practice-building-
business-applications-with-the-javatm-2-platform-enterprise-edition-
first-edition-cattell-55582690
Web Services Patterns Java Platform Edition 1st Edition Paul B Monday
Auth
https://ebookbell.com/product/web-services-patterns-java-platform-
edition-1st-edition-paul-b-monday-auth-4491224
The Definitive Guide To Jython Python For The Java Platform Wierzbicki
https://ebookbell.com/product/the-definitive-guide-to-jython-python-
for-the-java-platform-wierzbicki-166945820
Pro Javafx Platform Script Desktop And Mobile Ria With Java Technology
1st Edition James L Weaver
https://ebookbell.com/product/pro-javafx-platform-script-desktop-and-
mobile-ria-with-java-technology-1st-edition-james-l-weaver-1646542

Eclipse Web Tools Platform Developing Javatm Web Applications Naci Dai
https://ebookbell.com/product/eclipse-web-tools-platform-developing-
javatm-web-applications-naci-dai-974792
Java For Programmers Deitel Harvey M Deitel Paul J
https://ebookbell.com/product/java-for-programmers-deitel-harvey-m-
deitel-paul-j-22042718
Java Puzzlers Traps Pitfalls And Corner Cases Joshua Bloch
https://ebookbell.com/product/java-puzzlers-traps-pitfalls-and-corner-
cases-joshua-bloch-2363062
Javatm Programming With Corbatm Advanced Techniques For Building
Distributed Applications 3rd Edition Gerald Brose
https://ebookbell.com/product/javatm-programming-with-corbatm-
advanced-techniques-for-building-distributed-applications-3rd-edition-
gerald-brose-1294322
Java P2p Unleashed Robert Flenner Michael Abbott Toufic Boubez
https://ebookbell.com/product/java-p2p-unleashed-robert-flenner-
michael-abbott-toufic-boubez-975792

Java™ Platform, Enterprise Edition
(Java EE) Specification, v8
Please post comments to javaee-spec@javaee.groups.io
Final Release- 7/31/17 Linda DeMichiel, Bill Shannon

iii
Specification: JSR-366 Java Platform, Enterprise Edition 8 Specification ("Specification")
Version: 8.0
Status: Final Release
Specification Lead: Oracle America, Inc. ("Specification Lead")
Release: August 2017
Copyright 2017 Oracle America, Inc. ("Oracle")
500 Oracle Parkway, Redwood City, CA 94065, U.S.A.
All rights reserved.
LIMITED LICENSE GRANTS
1. License for Evaluation Purposes. Oracle hereby grants you a fully-paid, non-exclusive, non-
transferable, worldwide, limited license (without the right to sublicense), under Oracle's applicable
intellectual property rights to view, download, use and reproduce the Specification only for the purpose of
internal evaluation. This includes (i) developing applications intended to run on an implementation of the
Specification, provided that such applications do not themselves implement any portion(s) of the
Specification, and (ii) discussing the Specification with any third party; and (iii) excerpting brief portions
of the Specification in oral or written communications which discuss the Specification provided that such
excerpts do not in the aggregate constitute a significant portion of the Specification.
2. License for the Distribution of Compliant Implementations. Oracle also grants you a perpetual, non-
exclusive, non-transferable, worldwide, fully paid-up, royalty free, limited license (without the right to
sublicense) under any applicable copyrights or, subject to the provisions of subsection 4 below, patent
rights it may have covering the Specification to create and/or distribute an Independent Implementation of
the Specification that: (a) fully implements the Specification including all its required interfaces and
functionality; (b) does not modify, subset, superset or otherwise extend the Licensor Name Space, or
include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor
Name Space other than those required/authorized by the Specification or Specifications being
implemented; and (c) passes the Technology Compatibility Kit (including satisfying the requirements of
the applicable TCK Users Guide) for such Specification ("Compliant Implementation"). In addition, the
foregoing license is expressly conditioned on your not acting outside its scope. No license is granted
hereunder for any other purpose (including, for example, modifying the Specification, other than to the
extent of your fair use rights, or distributing the Specification to third parties). Also, no right, title, or
interest in or to any trademarks, service marks, or trade names of Oracle or Oracle's licensors is granted
hereunder. Java, and Java-related logos, marks and names are trademarks or registered trademarks of
Oracle America, Inc. in the U.S. and other countries.
3. Pass-through Conditions. You need not include limitations (a)-(c) from the previous paragraph or any
other particular "pass through" requirements in any license You grant concerning the use of your
Independent Implementation or products derived from it. However, except with respect to Independent
Implementations (and products derived from them) that satisfy limitations (a)-(c) from the previous
paragraph, You may neither: (a) grant or otherwise pass through to your licensees any licenses under
Oracle's applicable intellectual property rights; nor (b) authorize your licensees to make any claims
concerning their implementation's compliance with the Specification in question.

Java EE 8, Final Release
iv
4. Reciprocity Concerning Patent Licenses.
a. With respect to any patent claims covered by the license granted under subparagraph 2 above that
would be infringed by all technically feasible implementations of the Specification, such license is
conditioned upon your offering on fair, reasonable and non-discriminatory terms, to any party seeking it
from You, a perpetual, non-exclusive, non-transferable, worldwide license under Your patent rights which
are or would be infringed by all technically feasible implementations of the Specification to develop,
distribute and use a Compliant Implementation.
b With respect to any patent claims owned by Oracle and covered by the license granted under
subparagraph 2, whether or not their infringement can be avoided in a technically feasible manner when
implementing the Specification, such license shall terminate with respect to such claims if You initiate a
claim against Oracle that it has, in the course of performing its responsibilities as the Specification Lead,
induced any other entity to infringe Your patent rights.
c Also with respect to any patent claims owned by Oracle and covered by the license granted under
subparagraph 2 above, where the infringement of such claims can be avoided in a technically feasible
manner when implementing the Specification such license, with respect to such claims, shall terminate if
You initiate a claim against Oracle that its making, having made, using, offering to sell, selling or
importing a Compliant Implementation infringes Your patent rights.
5. Definitions. For the purposes of this Agreement: "Independent Implementation" shall mean an
implementation of the Specification that neither derives from any of Oracle's source code or binary code
materials nor, except with an appropriate and separate license from Oracle, includes any of Oracle's
source code or binary code materials; "Licensor Name Space" shall mean the public class or interface
declarations whose names begin with "java", "javax", "com.sun" and “com.oracle” or their equivalents in
any subsequent naming convention adopted by Oracle through the Java Community Process, or any
recognized successors or replacements thereof; and "Technology Compatibility Kit" or "TCK" shall mean
the test suite and accompanying TCK User's Guide provided by Oracle which corresponds to the
Specification and that was available either (i) from Oracle 120 days before the first release of Your
Independent Implementation that allows its use for commercial purposes, or (ii) more recently than 120
days from such release but against which You elect to test Your implementation of the Specification.
This Agreement will terminate immediately without notice from Oracle if you breach the Agreement or
act outside the scope of the licenses granted above.
DISCLAIMER OF WARRANTIES
THE SPECIFICATION IS PROVIDED "AS IS". ORACLE MAKES NO REPRESENTATIONS OR
WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO,
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-
INFRINGEMENT (INCLUDING AS A CONSEQUENCE OF ANY PRACTICE OR
IMPLEMENTATION OF THE SPECIFICATION), OR THAT THE CONTENTS OF THE
SPECIFICATION ARE SUITABLE FOR ANY PURPOSE. This document does not represent any
commitment to release or implement any portion of the Specification in any product. In addition, the

v
Specification could include technical inaccuracies or typographical errors.
LIMITATION OF LIABILITY
TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ORACLE OR ITS
LICENSORS BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST
REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL
OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF
LIABILITY, ARISING OUT OF OR RELATED IN ANY WAY TO YOUR HAVING, IMPLEMENTING
OR OTHERWISE USING THE SPECIFICATION, EVEN IF ORACLE AND/OR ITS LICENSORS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
You will indemnify, hold harmless, and defend Oracle and its licensors from any claims arising or
resulting from: (i) your use of the Specification; (ii) the use or distribution of your Java application, applet
and/or implementation; and/or (iii) any claims that later versions or releases of any Specification furnished
to you are incompatible with the Specification provided to you under this license.
RESTRICTED RIGHTS LEGEND
U.S. Government: If this Specification is being acquired by or on behalf of the U.S. Government or by a
U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in the
Software and accompanying documentation shall be only as set forth in this license; this is in accordance
with 48 C.F.R. 227.7201 through 227.7202-4 (for Department of Defense (DoD) acquisitions) and with 48
C.F.R. 2.101 and 12.212 (for non-DoD acquisitions).
REPORT
If you provide Oracle with any comments or suggestions concerning the Specification ("Feedback"), you
hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis, and (ii)
grant Oracle a perpetual, non-exclusive, worldwide, fully paid-up, irrevocable license, with the right to
sublicense through multiple levels of sublicensees, to incorporate, disclose, and use without limitation the
Feedback for any purpose.
GENERAL TERMS
Any action related to this Agreement will be governed by California law and controlling U.S. federal law.
The U.N. Convention for the International Sale of Goods and the choice of law rules of any jurisdiction
will not apply.
The Specification is subject to U.S. export control laws and may be subject to export or import regulations
in other countries. Licensee agrees to comply strictly with all such laws and regulations and acknowledges
that it has the responsibility to obtain such licenses to export, re-export or import as may be required after
delivery to Licensee.
This Agreement is the parties' entire agreement relating to its subject matter. It supersedes all prior or
contemporaneous oral or written communications, proposals, conditions, representations and warranties
and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other

vi
communication between the parties relating to its subject matter during the term of this Agreement. No
modification to this Agreement will be binding, unless in writing and signed by an authorized
representative of each party.

vii
Java™ Platform, Enterprise Edition (Java EE) Specification,
v8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
EE.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
EE.1.1 Acknowledgements for the Initial Version. . . . . . . . . . . . . . . . . 2
EE.1.2 Acknowledgements for Version 1.3 . . . . . . . . . . . . . . . . . . . . . . 2
EE.1.3 Acknowledgements for Version 1.4 . . . . . . . . . . . . . . . . . . . . . . 2
EE.1.4 Acknowledgements for Version 5 . . . . . . . . . . . . . . . . . . . . . . . 3
EE.2 Platform Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
EE.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
EE.2.2 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
EE.2.3 Application Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
EE.2.3.1 Java EE Server Support for Application Components 11
EE.2.4 Containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
EE.2.4.1 Container Requirements . . . . . . . . . . . . . . . . . . . . . . . 12
EE.2.4.2 Java EE Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
EE.2.5 Resource Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
EE.2.6 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
EE.2.7 Java EE Standard Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
EE.2.7.1 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
EE.2.7.2 HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
EE.2.7.3 Java™ Transaction API (JTA) . . . . . . . . . . . . . . . . . . 13
EE.2.7.4 RMI-IIOP (Proposed Optional). . . . . . . . . . . . . . . . . . 14
EE.2.7.5 Java IDL (Proposed Optional). . . . . . . . . . . . . . . . . . . 14
EE.2.7.6 JDBC™ API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
EE.2.7.7 Java™ Persistence API . . . . . . . . . . . . . . . . . . . . . . . . 15
EE.2.7.8 Java™ Message Service (JMS) . . . . . . . . . . . . . . . . . . 15
EE.2.7.9 Java Naming and Directory Interface™ (JNDI) . . . . . 15
EE.2.7.10 JavaMail™. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
EE.2.7.11 JavaBeans™ Activation Framework (JAF). . . . . . . . . 16
EE.2.7.12 XML Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
EE.2.7.13 Java EE™ Connector Architecture . . . . . . . . . . . . . . . 16
EE.2.7.14 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
EE.2.7.15 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
EE.2.7.16 Concurrency Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . 18

viii
EE.2.7.17 Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
EE.2.7.18 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
EE.2.7.19 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
EE.2.8 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
EE.2.9 Flexibility of Product Requirements . . . . . . . . . . . . . . . . . . . . 20
EE.2.10 Java EE Product Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
EE.2.11 Java EE Product Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
EE.2.12 Platform Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
EE.2.12.1 Java EE Product Provider . . . . . . . . . . . . . . . . . . . . . . 23
EE.2.12.2 Application Component Provider . . . . . . . . . . . . . . . . 23
EE.2.12.3 Application Assembler . . . . . . . . . . . . . . . . . . . . . . . . 23
EE.2.12.4 Deployer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
EE.2.12.5 System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . 24
EE.2.12.6 Tool Provider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
EE.2.12.7 System Component Provider. . . . . . . . . . . . . . . . . . . . 25
EE.2.13 Platform Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
EE.2.13.1 Java EE APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
EE.2.13.2 Java EE Service Provider Interfaces (SPIs) . . . . . . . . 26
EE.2.13.3 Network Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
EE.2.13.4 Deployment Descriptors and Annotations . . . . . . . . . 26
EE.2.14 Changes in J2EE 1.3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
EE.2.15 Changes in J2EE 1.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
EE.2.16 Changes in Java EE 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
EE.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
EE.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
EE.3.2 A Simple Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
EE.3.3 Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
EE.3.3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
EE.3.3.2 Non Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
EE.3.3.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
EE.3.3.4 Container Based Security . . . . . . . . . . . . . . . . . . . . . . 39
EE.3.3.5 Distributed Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
EE.3.3.6 Authorization Model . . . . . . . . . . . . . . . . . . . . . . . . . . 41
EE.3.3.7 HTTP Login Gateways . . . . . . . . . . . . . . . . . . . . . . . . 43
EE.3.3.8 User Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ix
EE.3.3.9 Lazy Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 45
EE.3.4 User Authentication Requirements. . . . . . . . . . . . . . . . . . . . . . 46
EE.3.4.1 Login Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
EE.3.4.2 Required Login Mechanisms. . . . . . . . . . . . . . . . . . . . 46
EE.3.4.3 Unauthenticated Users. . . . . . . . . . . . . . . . . . . . . . . . . 48
EE.3.4.4 Application Client User Authentication . . . . . . . . . . . 49
EE.3.4.5 Resource Authentication Requirements . . . . . . . . . . . 50
EE.3.5 Authorization Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . 51
EE.3.5.1 Code Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
EE.3.5.2 Caller Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . 51
EE.3.5.3 Propagated Caller Identities. . . . . . . . . . . . . . . . . . . . . 52
EE.3.5.4 Run As Identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
EE.3.6 Deployment Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
EE.3.7 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
EE.3.7.1 Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
EE.3.7.2 Instance-based Access Control . . . . . . . . . . . . . . . . . . 54
EE.3.7.3 User Registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
EE.4 Transaction Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
EE.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
EE.4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
EE.4.2.1 Web Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
EE.4.2.2 Transactions in Web Component Life Cycles. . . . . . . 58
EE.4.2.3 Transactions and Threads . . . . . . . . . . . . . . . . . . . . . . 59
EE.4.2.4 Enterprise JavaBeans™ Components . . . . . . . . . . . . . 60
EE.4.2.5 Application Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
EE.4.2.6 Applet Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
EE.4.2.7 Transactional JDBC™ Technology Support. . . . . . . . 60
EE.4.2.8 Transactional JMS Support . . . . . . . . . . . . . . . . . . . . . 61
EE.4.2.9 Transactional Resource Adapter (Connector) Support 61
EE.4.3 Transaction Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
EE.4.3.1 Multiple Java EE Platform Interoperability . . . . . . . . 61
EE.4.3.2 Support for Transactional Resource Managers . . . . . . 62
EE.4.4 Local Transaction Optimization . . . . . . . . . . . . . . . . . . . . . . . . 62
EE.4.4.1 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
EE.4.4.2 A Possible Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
EE.4.5 Connection Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
EE.4.6 JDBC and JMS Deployment Issues . . . . . . . . . . . . . . . . . . . . . 64
EE.4.7 Two-Phase Commit Support . . . . . . . . . . . . . . . . . . . . . . . . . . 65

x
EE.4.8 System Administration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . 65
EE.5 Resources, Naming, and Injection . . . . . . . . . . . . . . . . . . . . .67
EE.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
EE.5.1.1 Chapter Organization . . . . . . . . . . . . . . . . . . . . . . . . . 68
EE.5.1.2 Required Access to the JNDI Naming Environment. . 70
EE.5.2 JNDI Naming Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
EE.5.2.1 The Application Component’s Environment . . . . . . . 71
EE.5.2.2 Application Component Environment Namespaces . . 72
EE.5.2.3 Accessibility of Environment Entry Types . . . . . . . . . 74
EE.5.2.4 Sharing of Environment Entries . . . . . . . . . . . . . . . . . 74
EE.5.2.5 Annotations and Injection . . . . . . . . . . . . . . . . . . . . . . 75
EE.5.2.6 Annotations and Deployment Descriptors . . . . . . . . . 79
EE.5.2.7 Other Naming Context Entries . . . . . . . . . . . . . . . . . . 80
EE.5.3 Responsibilities by Java EE Role. . . . . . . . . . . . . . . . . . . . . . . 80
EE.5.3.1 Application Component Provider’s Responsibilities . 81
EE.5.3.2 Application Assembler’s Responsibilities. . . . . . . . . . 81
EE.5.3.3 Deployer’s Responsibilities. . . . . . . . . . . . . . . . . . . . . 81
EE.5.3.4 Java EE Product Provider’s Responsibilities . . . . . . . 82
EE.5.4 Simple Environment Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . 83
EE.5.5 Enterprise JavaBeans™ (EJB) References. . . . . . . . . . . . . . . . 89
EE.5.5.2 Application Assembler’s Responsibilities. . . . . . . . . . 94
EE.5.5.3 Deployer’s Responsibilities. . . . . . . . . . . . . . . . . . . . . 96
EE.5.5.4 Java EE Product Provider’s Responsibilities . . . . . . . 97
EE.5.6 Web Service References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
EE.5.7 Resource Manager Connection Factory References. . . . . . . . . 98
EE.5.7.2 Deployer’s Responsibilities. . . . . . . . . . . . . . . . . . . . 104
EE.5.7.3 Java EE Product Provider’s Responsibilities . . . . . . 105
EE.5.7.4 System Administrator’s Responsibilities . . . . . . . . . 106
EE.5.8 Resource Environment References. . . . . . . . . . . . . . . . . . . . . 106
EE.5.8.1 Application Component Provider’s Responsibilities 106
EE.5.9 Message Destination References . . . . . . . . . . . . . . . . . . . . . . 109
EE.5.9.2 Application Assembler’s Responsibilities. . . . . . . . . 112

xi
EE.5.10 UserTransaction References. . . . . . . . . . . . . . . . . . . . . . . . . . 114
EE.5.11 TransactionSynchronizationRegistry References. . . . . . . . . . 116
EE.5.12 ORB References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
EE.5.13 Persistence Unit References . . . . . . . . . . . . . . . . . . . . . . . . . . 119
EE.5.13.2 . . . . . . . . .Application Assembler’s Responsibilities122
EE.5.13.3 Deployer’s Responsibility . . . . . . . . . . . . . . . . . . . . . 123
EE.5.13.4 Java EE Product Provider’s Responsibility. . . . . . . . 123
EE.5.13.5 System Administrator’s Responsibility. . . . . . . . . . . 123
EE.5.14 Persistence Context References . . . . . . . . . . . . . . . . . . . . . . . 124
EE.5.14.2 . . . . . . . . .Application Assembler’s Responsibilities127
EE.5.14.3 Deployer’s Responsibility . . . . . . . . . . . . . . . . . . . . . 128
EE.5.14.4 Java EE Product Provider’s Responsibility. . . . . . . . 129
EE.5.14.5 System Administrator’s Responsibility. . . . . . . . . . . 129
EE.5.15 Application Name and Module Name References . . . . . . . . . 129
EE.5.16 Application Client Container Property. . . . . . . . . . . . . . . . . . 130
EE.5.17 Validator and Validator Factory References . . . . . . . . . . . . . 130
EE.5.18 Resource Definition and Configuration . . . . . . . . . . . . . . . . . 132
EE.5.18.1 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
EE.5.18.2 Requirements Common to All Resource Definition
Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
EE.5.18.3 DataSource Resource Definition . . . . . . . . . . . . . . . . 135
EE.5.18.4 JMS Connection Factory Resource Definition . . . . . 138
EE.5.18.5 JMS Destination Definition. . . . . . . . . . . . . . . . . . . . 140

xii
EE.5.18.6 Mail Session Definition. . . . . . . . . . . . . . . . . . . . . . . 142
EE.5.18.7 Connector Connection Factory Definition . . . . . . . . 144
EE.5.18.8 Connector Administered Object Definition . . . . . . . 146
EE.5.19 Default Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
EE.5.19.1 Java EE Product Provider's Responsibilities. . . . . . . 148
EE.5.20 Default JMS Connection Factory . . . . . . . . . . . . . . . . . . . . . . 148
EE.5.21 Default Concurrency Utilities Objects . . . . . . . . . . . . . . . . . . 149
EE.5.22 Managed Bean References . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
EE.5.23 Bean Manager References . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
EE.5.24 Support for Dependency Injection . . . . . . . . . . . . . . . . . . . . . 153
EE.6 Application Programming Interface . . . . . . . . . . . . . . . . . .157
EE.6.1 Required APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
EE.6.1.1 Java Compatible APIs . . . . . . . . . . . . . . . . . . . . . . . . 157
EE.6.1.2 Required Java Technologies . . . . . . . . . . . . . . . . . . . 158
EE.6.1.3 Pruned Java Technologies. . . . . . . . . . . . . . . . . . . . . 161
EE.6.2 Java Platform, Standard Edition (Java SE) Requirements . . . 161
EE.6.2.1 Programming Restrictions. . . . . . . . . . . . . . . . . . . . . 161
EE.6.2.2 Java EE Security Manager Related Requirements . . 162
EE.6.2.3 Additional Requirements. . . . . . . . . . . . . . . . . . . . . . 168
EE.6.3 Enterprise JavaBeans™ (EJB) 3.2 Requirements . . . . . . . . . 177
EE.6.4 Servlet 4.0 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
EE.6.5 JavaServer Pages™ (JSP) 2.3 Requirements . . . . . . . . . . . . . 179
EE.6.6 Expression Language (EL) 3.0 Requirements . . . . . . . . . . . . 179
EE.6.7 Java™ Message Service (JMS) 2.0 Requirements. . . . . . . . . 179
EE.6.8 Java™ Transaction API (JTA) 1.2 Requirements . . . . . . . . . 181
EE.6.9 JavaMail™ 1.6 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 182
EE.6.10 Java EE™ Connector Architecture 1.7 Requirements . . . . . . 183
EE.6.11 Web Services for Java EE 1.4 Requirements . . . . . . . . . . . . . 184
EE.6.12 Java™ API for XML-based RPC (JAX-RPC) 1.1 Requirements
(Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
EE.6.13 Java™ API for RESTful Web Services (JAX-RS) 2.1 Require-

xiii
ments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
EE.6.14 Java API for WebSocket 1.1 (WebSocket) Requirements . . . 185
EE.6.15 Java API for JSON Processing 1.1 (JSON-P) Requirements . 185
EE.6.16 Java API for JSON Binding 1.0 (JSON-B) Requirements . . . 185
EE.6.17 Concurrency Utilities for Java EE 1.0 (Concurrency Utilities) Re-
quirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
EE.6.18 Batch Applications for the Java Platform 1.0 (Batch) Require-
ments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
EE.6.19 Java™ API for XML Registries (JAXR) 1.0 Requirements (Op-
tional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
EE.6.20 Java™ Platform, Enterprise Edition Management API 1.1 Re-
quirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
EE.6.21 Java™ Platform, Enterprise Edition Deployment API 1.2 Re-
quirements (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
EE.6.22 Java™ Authorization Contract for Containers (JACC) 1.5 Re-
quirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
EE.6.23 Java™ Authentication Service Provider Interface for Containers
(JASPIC) 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 188
EE.6.24 Java EE Security API 1.0 Requirements . . . . . . . . . . . . . . . . 188
EE.6.25 Debugging Support for Other Languages (JSR-45) Requirements
188
EE.6.26 Standard Tag Library for JavaServer Pages™ (JSTL) 1.2 Re-
quirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
EE.6.27 Web Services Metadata for the Java™ Platform 2.1 Require-
ments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
EE.6.28 JavaServer Faces™ 2.3 Requirements . . . . . . . . . . . . . . . . . . 189
EE.6.29 Common Annotations for the Java™ Platform 1.3 Requirements
190
EE.6.30 Java™ Persistence API 2.2 Requirements . . . . . . . . . . . . . . . 191
EE.6.31 Bean Validation 2.0 Requirements. . . . . . . . . . . . . . . . . . . . . 191
EE.6.32 Managed Beans 1.0 Requirements . . . . . . . . . . . . . . . . . . . . . 191
EE.6.33 Interceptors 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 192
EE.6.34 Contexts and Dependency Injection for the Java EE Platform 2.0
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
EE.6.35 Dependency Injection for Java 1.0 Requirements . . . . . . . . . 192
EE.7 Interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
EE.7.1 Introduction to Interoperability . . . . . . . . . . . . . . . . . . . . . . . 193

xiv
EE.7.2 Interoperability Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
EE.7.2.1 Internet and Web Protocols. . . . . . . . . . . . . . . . . . . . 194
EE.7.2.2 OMG Protocols (Proposed Optional) . . . . . . . . . . . . 195
EE.7.2.3 Java Technology Protocols . . . . . . . . . . . . . . . . . . . . 196
EE.7.2.4 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
EE.8 Application Assembly and Deployment . . . . . . . . . . . . . . .199
EE.8.1 Application Development Life Cycle. . . . . . . . . . . . . . . . . . . 200
EE.8.1.1 Component Creation . . . . . . . . . . . . . . . . . . . . . . . . . 201
EE.8.1.2 Application Assembly . . . . . . . . . . . . . . . . . . . . . . . . 203
EE.8.1.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
EE.8.2 Library Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
EE.8.2.1 Bundled Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
EE.8.2.2 Installed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
EE.8.2.3 Library Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
EE.8.2.4 Library Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
EE.8.2.5 Dynamic Class Loading . . . . . . . . . . . . . . . . . . . . . . 208
EE.8.2.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
EE.8.3 Class Loading Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 210
EE.8.3.1 Web Container Class Loading Requirements . . . . . . 211
EE.8.3.2 EJB Container Class Loading Requirements . . . . . . 212
EE.8.3.3 Application Client Container Class Loading Require-
ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
EE.8.3.4 Applet Container Class Loading Requirements . . . . 215
EE.8.4 Application Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
EE.8.4.1 Assembling a Java EE Application . . . . . . . . . . . . . . 215
EE.8.4.2 Adding and Removing Modules . . . . . . . . . . . . . . . . 218
EE.8.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
EE.8.5.1 Deploying a Stand-Alone Java EE Module. . . . . . . . 221
EE.8.5.2 Deploying a Java EE Application . . . . . . . . . . . . . . . 223
EE.8.5.3 Deploying a Library . . . . . . . . . . . . . . . . . . . . . . . . . 225
EE.8.5.4 Module Initialization. . . . . . . . . . . . . . . . . . . . . . . . . 225
EE.8.6 Java EE Application XML Schema . . . . . . . . . . . . . . . . . . . . 226
EE.8.7 Common Java EE XML Schema Definitions. . . . . . . . . . . . . 229
EE.9 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
EE.9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
EE.9.2 Profile Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
EE.9.3 General Rules for Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
EE.9.4 Expression of Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . 233

xv
EE.9.5 Requirements for All Java EE Profiles. . . . . . . . . . . . . . . . . . 233
EE.9.6 Optional Features for Java EE Profiles. . . . . . . . . . . . . . . . . . 234
EE.9.7 Full Java EE Product Requirements . . . . . . . . . . . . . . . . . . . . 234
EE.10 Application Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
EE.10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
EE.10.2 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
EE.10.3 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
EE.10.4 Resources, Naming, and Injection . . . . . . . . . . . . . . . . . . . . . 239
EE.10.5 Application Programming Interfaces . . . . . . . . . . . . . . . . . . . 239
EE.10.6 Packaging and Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 239
EE.10.7 Java EE Application Client XML Schema. . . . . . . . . . . . . . . 242
EE.11 Service Provider Interface . . . . . . . . . . . . . . . . . . . . . . . . . . .245
EE.11.1 Java™ EE Connector Architecture. . . . . . . . . . . . . . . . . . . . . 245
EE.11.2 Java™ Authorization Service Provider Contract for Containers .
245
EE.11.3 Java™ Transaction API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
EE.11.4 Java™ Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
EE.11.5 JavaMail™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
EE.12 Compatibility and Migration. . . . . . . . . . . . . . . . . . . . . . . . .247
EE.12.1 Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
EE.12.2 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
EE.12.2.1 Java Persistence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
EE.12.2.2 JAX-WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
EE.13 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249
EE.13.1 Java EE SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Appendix EE.A: Previous Version Deployment Descriptors. . . . . . 251
EE.A.1 Java EE 7 Application XML Schema. . . . . . . . . . . . . . . . . . . 251
EE.A.2 Common Java EE XML Schema Definitions. . . . . . . . . . . . . 255
EE.A.3 Java EE 7 Application Client XML Schema . . . . . . . . . . . . . 255
EE.A.5 Common Java EE XML Schema Definitions. . . . . . . . . . . . . 261
EE.A.8 Common Java EE 5 XML Schema Definitions . . . . . . . . . . . 264

xvi
EE.A.10 J2EE 1.4 Application XML Schema . . . . . . . . . . . . . . . . . . . 266
EE.A.11 Common J2EE 1.4 XML Schema Definitions . . . . . . . . . . . . 267
EE.A.12 J2EE:application 1.3 XML DTD . . . . . . . . . . . . . . . . . . . . . . 267
EE.A.13 J2EE:application 1.2 XML DTD . . . . . . . . . . . . . . . . . . . . . . 268
EE.A.14 J2EE 1.4 Application Client XML Schema . . . . . . . . . . . . . . 268
EE.A.15 J2EE:application-client 1.3 XML DTD . . . . . . . . . . . . . . . . . 271
EE.A.16 J2EE:application-client 1.2 XML DTD . . . . . . . . . . . . . . . . . 272
Appendix EE.B: Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . .273
EE.B.1 Changes in Early Draft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
EE.B.1.1 Additional Requirements. . . . . . . . . . . . . . . . . . . . . . 273
EE.B.1.2 Editorial Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
EE.B.2 Changes in Early Draft 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
EE.B.2.2 Removed Requirements . . . . . . . . . . . . . . . . . . . . . . 274
EE.B.3 Changes in Public Review Draft . . . . . . . . . . . . . . . . . . . . . . 274
EE.B.4 Changes in Proposed Final Draft . . . . . . . . . . . . . . . . . . . . . . 275
EE.B.5 Changes in Final Release Draft . . . . . . . . . . . . . . . . . . . . . . . 275
Appendix EE.C: Related Documents . . . . . . . . . . . . . . . . . . . . . . . . .277

1
C H A P T E R EE.1
Introduction
Enterprises today need to extend their reach, reduce their costs, and lower the
response times of their services to customers, employees, and suppliers.
Typically, applications that provide these services must combine existing
enterprise information systems (EISs) with new business functions that deliver
services to a broad range of users. The services need to be:
• Highly available, to meet the needs of today’s global business environment.
• Secure, to protect the privacy of users and the integrity of the enterprise.
• Reliable and scalable, to ensure that business transactions are accurately and
promptly processed.
In most cases, enterprise services are implemented as multitier applications.
The middle tiers integrate existing EISs with the business functions and data of
the new service. Maturing web technologies are used to provide first tier users
with easy access to business complexities, and eliminate or drastically reduce user
administration and training.
The Java™ Platform, Enterprise Edition (Java™ EE) reduces the cost and
complexity of developing multitier, enterprise services. Java EE applications can
be rapidly deployed and easily enhanced as the enterprise responds to competitive
pressures.
Java EE achieves these benefits by defining a standard architecture with the
following elements:
• Java EE Platform - A standard platform for hosting Java EE applications.
• Java EE Compatibility Test Suite - A suite of compatibility tests for verify-
ing that a Java EE platform product complies with the Java EE platform stan-
dard.

2
• Java EE Reference Implementation - A reference implementation for proto-
typing Java EE applications and for providing an operational definition of the
Java EE platform.
This document is the Java EE platform specification. It sets out the
requirements that a Java EE platform product must meet.
EE.1.1 Acknowledgements for the Initial Version
This specification is the work of many people. Vlada Matena wrote the first draft as
well as the Transaction Management and Naming chapters. Sekhar Vajjhala, Kevin
Osborn, and Ron Monzillo wrote the Security chapter. Hans Hrasna wrote the
Application Assembly and Deployment chapter. Seth White wrote the JDBC API
requirements. Jim Inscore, Eric Jendrock, and Beth Stearns provided editorial
assistance. Shel Finkelstein, Mark Hapner, Danny Coward, Tom Kincaid, and Tony
Ng provided feedback on many drafts. And of course this specification was formed
and molded based on conversations with and review feedback from our many
industry partners.
EE.1.2 Acknowledgements for Version 1.3
Version 1.3 of this specification grew out of discussions with our partners during the
creation of version 1.2, as well as meetings with those partners subsequent to the
final release of version 1.2. Version 1.3 was created under the Java Community
Process as JSR-058. The JSR-058 Expert Group included representatives from the
following companies and organizations: Allaire, BEA Systems, Bluestone Software,
Borland, Bull S.A., Exoffice, Fujitsu Limited, GemStone Systems, Inc., IBM, Inline
Software, IONA Technologies, iPlanet, jGuru.com, Orion Application Server,
Persistence, POET Software, SilverStream, Sun, and Sybase. In addition, most of
the people who helped with the previous version continued to help with this version,
along with Jon Ellis and Ram Jeyaraman. Alfred Towell provided significant
editorial assistance with this version.
EE.1.3 Acknowledgements for Version 1.4
Version 1.4 of this specification was created under the Java Community Process as
JSR-151. The JSR-151 Expert Group included the following members: Larry W.
Allen (SilverStream Software), Karl Avedal (Individual), Charlton Barreto

ACKNOWLEDGEMENTS FOR VERSION 5 3
(Borland Software Corporation), Edward Cobb (BEA), Alan Davies (SeeBeyond
Technology Corporation), Sreeram Duvvuru (iPlanet), B.J. Fesq (Individual),
Mark Field (Macromedia), Mark Hapner (Sun Microsystems, Inc.), Pierce Hickey
(IONA), Hemant Khandelwal (Pramati Technologies), Jim Knutson (IBM), Elika
S. Kohen (Individual), Ramesh Loganathan (Pramati Technologies), Jasen Minton
(Oracle Corporation), Jeff Mischkinsky (Oracle Corporation), Richard Monson-
Haefel (Individual), Sean Neville (Macromedia), Bill Shannon (Sun Microsystems,
Inc.), Simon Tuffs (Lutris Technologies), Jeffrey Wang (Persistence Software,
Inc.), and Ingo Zenz (SAP AG). My colleagues at Sun provided invaluable
assistance: Umit Yalcinalp converted the deployment descriptors to XML Schema;
Tony Ng and Sanjeev Krishnan helped with transaction requirements; Jonathan
Bruce helped with JDBC requirements; Suzette Pelouch, Eric Jendrock, and Ian
Evans provided editorial assistance. Thanks also to all the external reviewers,
including Jeff Estefan (Adecco Technical Services).
EE.1.4 Acknowledgements for Version 5
Version 5 (originally known as version 1.5) of this specification was created under
the Java Community Process as JSR-244. The JSR-244 Expert Group included the
following members: Kilinc Alkan (Individual), Rama Murthy Amar Pratap
(Individual), Charlton Barreto (Individual), Michael Bechauf (SAP AG), Florent
Benoit (INRIA), Bill Burke (JBoss, Inc.), Muralidharan Chandrasekaran
(Individual), Yongmin Chen (Novell, Inc.), Jun Ho Cho (TmaxSoft), Ed Cobb
(BEA), Ugo Corda (SeeBeyond Technology Corporation), Scott Crawford
(Individual), Arulazi Dhesiaseelan (Hewlett-Packard Company), Bill Dudney
(Individual), Francois Exertier (INRIA), Jeff Genender (The Apache Software
Foundation), Evan Ireland (Sybase, Inc.), Vishy Kasar (Borland Software
Corporation), Michael Keith (Oracle Corporation), Wonseok Kim (TmaxSoft, Inc.),
Jim Knutson (IBM), Elika Kohen (Individual), Felipe Leme (Individual), Geir
Magnusson Jr. (The Apache Software Foundation), Scott Marlow (Novell, Inc.),
Jasen Minton (Oracle Corporation), Jishnu Mitra (Borland Software Corp), David
Morandi (E.piphany), Nathan Pahucki (Novell, Inc.), David Morandi (E.piphany,
Inc.), Ricardo Morin (Intel Corporation), Nathan Pahucki (Novell, Inc.), Matt
Raible (Individual), Dirk Reinshagen (Individual), Narinder Sahota (Cap Gemini),
Suneet Shah (Individual), Bill Shannon (Sun Microsystems, Inc.), Rajiv Shivane
(Pramati Technologies), Scott Stark (Jboss, Inc), Hani Suleiman (Ironflare AB),
Kresten Krab Thorup (Trifork), Ashish Kumar Tiwari (Individual), Sivasundaram
Umapathy (Individual), Steve Weston (Cap Gemini), Seth White (BEA Systems),
and Umit Yalcinalp (SAP AG). Once again, my colleagues at Sun provided

4
invaluable assistance: Roberto Chinnici provided draft proposals for many issues
related to dependency injection.
Version 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 Chang (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).
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.), Alex Heneveld (Individual),
Minehiko Iida (Fujitsu), 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 (TmaxSoft).

ACKNOWLEDGEMENTS FOR VERSION 8 5
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.

7
C H A P T E R EE.2
Platform Overview
This chapter provides an overview of the Java™ Platform, Enterprise Edition
(Java EE™).
EE.2.1 Architecture
The required relationships of architectural elements of the Java EE platform are
shown in Figure EE.2-1. Note that this figure shows the logical relationships of the
elements; it is not meant to imply a physical partitioning of the elements into
separate machines, processes, address spaces, or virtual machines.
The Containers, denoted by the separate rectangles, are Java EE runtime
environments that provide required services to the application components
represented in the upper half of the rectangle. The services provided are denoted
by the boxes in the lower half of the rectangle. For example, the Application
Client Container provides Java Message Service (JMS) APIs to Application
Clients, as well as the other services represented. All these services are explained
below. See Section EE.2.7, “Java EE Standard Services”.
The arrows represent required access to other parts of the Java EE platform.
The Application Client Container provides Application Clients with direct access
to the Java EE required Database through the Java API for connectivity with
database systems, the JDBCTM
API. Similar access to databases is provided to JSP
pages, JSF applications, and servlets by the Web Container, and to enterprise
beans by the EJB Container.
As indicated, the APIs of the JavaTM
Platform, Standard Edition (Java SE), are
supported by Java SE runtime environments for each type of application
component.

8
Figure EE.2-1 Java EE Architecture Diagram
The following sections describe the Java EE Platform requirements for each
kind of Java EE platform element.
EE.2.2 Profiles
The Java EE 6 specification introduced the notion of “profiles” (see Chapter EE.9,
“Profiles”).
New in Java EE 8
Application Client Container
Application
Client
HTTP
SSL
Database
Web Container
Java SE
Servlet
JSP
Applet Container
Java SE
Applet
HTTP
SSL
JMS
Connectors
JTA
JAXR
WS
Metadata
JSF
JSTL
Management
Web
Services
JACC
Java
Persistence
JAX-RPC
Security
JAX-RS
CDI
&
DI
JASPIC
Java SE
JAXR
JMS
Web
Services
Management
Java
Persistence
JAX-RPC
WS
Metadata
CDI
&
DI
JavaMail
WebSocket
EL
EJB
Bean
Validation
JSONB
JSONP
Batch
JSONP
Bean
Validation
Optional as of Java EE 7
JavaMail
Concurrency
Utilities
JSONB
EJB Container
EJB
Java SE
Web
Services
JMS
Connectors
JTA
JAXR
JACC
WS
Metadata
Management
Java
Persistence
JAX-RPC
Security
JAX-RS
CDI
&
DI
JASPIC
JavaMail
Batch
Bean
Validation
JSONP
JSONB
Concurrency
Utilities
JAX-RPC

PROFILES 9
A profile is a configuration of the Java EE platform targeted at a specific class
of applications.
Profiles are not a new concept, nor are they unique to the Java EE platform.
The Java Community Process Document (version 2.10) gives the following
definition of a profile: “A Specification that references one of the Platform
Edition Specifications and zero or more other JCP Specifications (that are not
already a part of a Platform Edition Specification). APIs from the referenced
Platform Edition must be included according to the referencing rules set out in
that Platform Edition Specification. Other referenced specifications must be
referenced in their entirety.”
All Java EE profiles share a set of common features, such as naming and
resource injection, packaging rules, security requirements, etc. This guarantees a
degree of uniformity across all products and, indirectly, applications that fall
under the “Java EE platform” umbrella. This also ensures that developers who are
familiar with a certain profile, or with the full platform, can move easily to other
profiles, avoiding excessive compartmentalization of skills and experience.
Beyond the basic functionality outlined above, profiles are free to include any
set of technologies that are part of the platform, provided that all rules in the
present specification that pertain to the included technologies—either alone or in
combination with others—are followed.
This last point is worth stressing. If profiles only included pointwise
technologies, they would be little more than bundles of APIs with few or no tie-
ins. Instead, the definition of profiles adopted here guarantees that whenever this
specification defines requirements on combinations of technologies, these
requirements will be honored in all products based on Java EE profiles.
As a concrete example, consider the use of transactions in a servlet container.
In isolation, neither the Servlet specification nor the Java Transaction API
specification defines a complete programming model for portable applications.
This specification fills that gap by introducing its own set of requirements that
pertain to the combination of Servlets and JTA. These requirements must be
satisfied by any Java EE profile-based product that includes those two
technologies, thus offering application developers a more complete programming
model shared across all relevant Java EE profiles.
A separate specification, the Java EE Web Profile Specification, defines the
Java EE Web Profile, the first profile of the Java EE platform.
Additional profiles may be defined in accordance with the rules of the Java
Community Process and those contained in the present specification. In particular,
profiles are initiated by submitting a Java Specification Request and are released
at completion on their own schedule, independently of any concurrent revision of

10
the platform itself or of other profiles. This ensures maximum flexibility in
defining and releasing a new profile or an updated version of an existing one.
In accordance with the definition of profiles given above, a profile may end
up being either a proper subset or a proper superset of the platform, or it may
overlap with it to a certain extent. This flexibility guarantees that future profiles
will be able to cover uses well beyond those originally envisioned by the platform
specification.
As the previous paragraphs made clear, creating a new profile is a significant
undertaking. The decision to create a profile should take into account its potential
drawbacks, especially in terms of fragmentation and developer confusion. In
general, a profile should be created only when there is a natural developer
constituency and a well-understood class of applications that can benefit from it.
It is also recommended that a profile cast a comprehensive net on its area of
interest, to minimize the occurrence of overlapping or competing profiles. Java
EE platform features such as optional components and extensibility can be used
by profiles to achieve a better fit to their intended target.
EE.2.3 Application Components
The Java EE runtime environment defines four application component types that a
Java EE product must support:
• Application clients are Java programming language programs that are typically
GUI programs that execute on a desktop computer. Application clients offer a
user experience similar to that of native applications and have access to all of
the facilities of the Java EE middle tier.
• Applets are GUI components that typically execute in a web browser, but can
execute in a variety of other applications or devices that support the applet
programming model. Applets can be used to provide a powerful user interface
for Java EE applications. (Simple HTML pages can also be used to provide a
more limited user interface for Java EE applications.)
• Servlets, JSP pages, JSF applications, filters, and web event listeners typically
execute in a web container and may respond to HTTP requests from web cli-
ents. Servlets, JSP pages, JSF applications, and filters may be used to generate
HTML pages that are an application’s user interface. They may also be used
to generate XML or other format data that is consumed by other application
components. A special kind of servlet provides support for web services using
the SOAP/HTTP protocol. Servlets, pages created with the JavaServer Pag-

CONTAINERS 11
es™ technology or JavaServer™ Faces technology, web filters, and web
event listeners are referred to collectively in this specification as “web com-
ponents.” Web applications are composed of web components and other data
such as HTML pages. Web components execute in a web container. A web
server includes a web container and other protocol support, security support,
and so on, as required by Java EE specifications.
• Enterprise JavaBeans™ (EJB) components execute in a managed environment
that supports transactions. Enterprise beans typically contain the business logic
for a Java EE application. Enterprise beans may directly provide web services
using the SOAP/HTTP protocol.
EE.2.3.1 Java EE Server Support for Application Components
The Java EE servers provide deployment, management, and execution support for
conforming application components. Application components can be divided into
three categories according to their dependence on a Java EE server:
• Components that are deployed, managed, and executed on a Java EE server.
These components include web components and Enterprise JavaBeans compo-
nents. See the separate specifications for these components.
• Components that are deployed and managed on a Java EE server, but are load-
ed to and executed on a client machine. These components include web re-
sources such as HTML pages and applets embedded in HTML pages.
• Components whose deployment and management is not completely defined by
this specification. Application Clients fall into this category. Future versions of
this specification may more fully define deployment and management of Ap-
plication Clients. See Chapter EE.10, “Application Clients,” for a description
of Application Clients.
EE.2.4 Containers
Containers provide the runtime support for Java EE application components.
Containers provide a federated view of the underlying Java EE APIs to the
application components. Java EE application components never interact directly
with other Java EE application components. They use the protocols and methods of
the container for interacting with each other and with platform services. Interposing
a container between the application components and the Java EE services allows the
container to transparently inject the services required by the component, such as

12
declarative transaction management, security checks, resource pooling, and state
management.
A typical Java EE product will provide a container for each application
component type: application client container, applet container, web component
container, and enterprise bean container.
EE.2.4.1 Container Requirements
This specification requires that containers provide a Java Compatible™ runtime
environment, as defined by the Java Platform, Standard Edition, v8 specification
(Java SE). The applet container may use the Java Plugin product to provide this
environment, or it may provide it natively. The use of applet containers providing
JDK™ 1.1 APIs is outside the scope of this specification.
The container tools must understand the file formats for the packaging of
application components for deployment.
The containers are implemented by a Java EE Product Provider. See the
description of the Product Provider role in Section EE.2.12.1, “Java EE Product
Provider”.
This specification defines a set of standard services that each Java EE product
must support. These standard services are described below. The Java EE
containers provide the APIs that application components use to access these
services. This specification also describes standard ways to extend Java EE
services with connectors to other non-Java EE application systems, such as
mainframe systems and ERP systems.
EE.2.4.2 Java EE Servers
Underlying a Java EE container is the server of which it is a part. A Java EE Product
Provider typically implements the Java EE server-side functionality using an
existing transaction processing infrastructure in combination with Java Platform,
Standard Edition (Java SE) technology. The Java EE client functionality is typically
built on Java SE technology.
EE.2.5 Resource Adapters
A resource adapter is a system-level software component that typically implements
network connectivity to an external resource manager. A resource adapter can
extend the functionality of the Java EE platform either by implementing one of the
Java EE standard service APIs (such as a JDBC™ driver), or by defining and

DATABASE 13
implementing a resource adapter for a connector to an external application system.
Resource adapters may also provide services that are entirely local, perhaps
interacting with native resources. Resource adapters interface with the Java EE
platform through the Java EE service provider interfaces (Java EE SPI). A resource
adapter that uses the Java EE SPIs to attach to the Java EE platform will be able to
work with all Java EE products.
EE.2.6 Database
The Java EE platform requires a database, accessible through the JDBC API, for the
storage of business data. The database is accessible from web components,
enterprise beans, and application client components. The database need not be
accessible from applets. The Java EE Product Provider must also provide a
preconfigured, default data source for use by the application in accessing this
database. See Section EE.5.19, “Default Data Source”.
EE.2.7 Java EE Standard Services
The Java EE standard services include the following (specified in more detail later
in this document). Some of these standard services are actually provided by Java SE.
EE.2.7.1 HTTP
The HTTP client-side API is defined by the java.net package. The HTTP server-
side API is defined by the servlet, JSP, and JSF interfaces and by the web services
support that is a part of the Java EE platform.
EE.2.7.2 HTTPS
Use of the HTTP protocol over the SSL protocol is supported by the same client and
server APIs as HTTP.
EE.2.7.3 Java™ Transaction API (JTA)
The Java Transaction API consists of two parts:

14
• An application-level demarcation interface that is used by the container and ap-
plication components to demarcate transaction boundaries.
• An interface between the transaction manager and a resource manager used at
the Java EE SPI level.
EE.2.7.4 RMI-IIOP (Proposed Optional)
The RMI-IIOP subsystem is composed of APIs that allow for the use of RMI-style
programming that is independent of the underlying protocol, as well as an
implementation of those APIs that supports both the Java SE native RMI protocol
(JRMP) and the CORBA IIOP protocol. Java EE applications can use RMI-IIOP,
with IIOP protocol support, to access CORBA services that are compatible with the
RMI programming restrictions (see the RMI-IIOP specification for details). Such
CORBA services would typically be defined by components that live outside of a
Java EE product, usually in a legacy system. Only Java EE application clients are
required to be able to define their own CORBA services directly, using the RMI-
IIOP APIs. Typically such CORBA objects would be used for callbacks when
accessing other CORBA objects.
Java EE products must be capable of exporting Enterprise JavaBeans
components using the IIOP protocol and accessing enterprise beans using the
IIOP protocol, as specified in the EJB specification. The ability to use the IIOP
protocol is required to enable interoperability between Java EE products, however
a Java EE product may also use other protocols. Requirements for use of the RMI-
IIOP APIs when accessing Enterprise JavaBeans components have been relaxed
as of EJB 3.0. See the Enterprise JavaBeans specification for details.
Support for CORBA, including use of IIOP and Java IDL, is Proposed
Optional as of Java EE 8. See Section EE.6.1.3, “Pruned Java Technologies.”
EE.2.7.5 Java IDL (Proposed Optional)
Java IDL allows Java EE application components to invoke external CORBA
objects using the IIOP protocol. These CORBA objects may be written in any
language and typically live outside a Java EE product. Java EE applications may use
Java IDL to act as clients of CORBA services, but only Java EE application clients
are required to be allowed to use Java IDL directly to present CORBA services
themselves.

JAVA EE STANDARD SERVICES 15
EE.2.7.6 JDBC™ API
The JDBC API is the API for connectivity with relational database systems. The
JDBC API has two parts: an application-level interface used by the application
components to access a database, and a service provider interface to attach a JDBC
driver to the Java EE platform. Support for the service provider interface is not
required in Java EE products. Instead, JDBC drivers should be packaged as resource
adapters that use the facilities of the Connector API to interface with a Java EE
product. The JDBC API is included in Java SE, but this specification includes
additional requirements on JDBC device drivers.
EE.2.7.7 Java™ Persistence API
The Java Persistence API is the standard API for the management of persistence and
object/relational mapping. It provides an object/relational mapping facility for
application developers using a Java domain model to manage a relational database.
The Java Persistence API is required to be supported in Java EE. It can also be used
in Java SE environments.
EE.2.7.8 Java™ Message Service (JMS)
The Java Message Service is a standard API for messaging that supports reliable
point-to-point messaging as well as the publish-subscribe model. This specification
requires a JMS provider that implements both point-to-point messaging as well as
publish-subscribe messaging. The Java EE Product Provider must also provide a
preconfigured, default JMS connection factory for use by the application in
accessing this JMS provider. See Section EE.5.20, “Default JMS Connection
Factory”.
EE.2.7.9 Java Naming and Directory Interface™ (JNDI)
The JNDI API is the standard API for naming and directory access. The JNDI API
has two parts: an application-level interface used by the application components to
access naming and directory services and a service provider interface to attach a
provider of a naming and directory service. The JNDI API is included in Java SE,
but this specification defines additional requirements.

16
EE.2.7.10 JavaMail™
Many Internet applications require the ability to send email notifications, so the Java
EE platform includes the JavaMail API along with a JavaMail service provider that
allows an application component to send Internet mail. The JavaMail API has two
parts: an application-level interface used by the application components to send
mail, and a service provider interface used at the Java EE SPI level.
EE.2.7.11 JavaBeans™ Activation Framework (JAF)
The JAF API provides a framework for handling data in different MIME types,
originating in different formats and locations. The JavaMail API makes use of the
JAF API. The JAF API is included in Java SE and so is available to Java EE
applications.
EE.2.7.12 XML Processing
The Java™ API for XML Processing (JAXP) provides support for the industry
standard SAX and DOM APIs for parsing XML documents, as well as support for
XSLT transform engines. The Streaming API for XML (StAX) provides a pull-
parsing API for XML. The JAXP and StAX APIs are included in Java SE and so are
available to Java EE applications.
EE.2.7.13 Java EE™ Connector Architecture
The Connector architecture is a Java EE SPI that allows resource adapters that
support access to Enterprise Information Systems to be plugged in to any Java EE
product. The Connector architecture defines a standard set of system-level contracts
between a Java EE server and a resource adapter. The standard contracts include:
• A connection management contract that lets a Java EE server pool connections
to an underlying EIS, and lets application components connect to an EIS. This
leads to a scalable application environment that can support a large number of
clients requiring access to EIS systems.
• A transaction management contract between the transaction manager and an
EIS that supports transactional access to EIS resource managers. This contract
lets a Java EE server use a transaction manager to manage transactions across
multiple resource managers. This contract also supports transactions that are
managed internal to an EIS resource manager without the necessity of involv-
ing an external transaction manager.

JAVA EE STANDARD SERVICES 17
• A security contract that enables secure access to an EIS. This contract pro-
vides support for a secure application environment, which reduces security
threats to the EIS and protects valuable information resources managed by the
EIS.
• A thread management contract that allows a resource adapter to delegate work
to other threads and allows the application server to manage a pool of threads.
The resource adapter can control the security context and transaction context
used by the worker thread.
• A contract that allows a resource adapter to deliver messages to message driv-
en beans independent of the specific messaging style, messaging semantics,
and messaging infrastructure used to deliver messages. This contract also
serves as the standard message provider pluggability contract that allows a
message provider to be plugged into any Java EE server via a resource adapt-
er.
• A contract that allows a resource adapter to propagate an imported transaction
context to the Java EE server such that its interactions with the server and any
application components are part of the imported transaction. This contract
preserves the ACID (atomicity, consistency, isolation, durability) properties
of the imported transaction.
• An optional contract providing a generic command interface between an appli-
cation program and a resource adapter.
EE.2.7.14 Security Services
The Java™ Authentication and Authorization Service (JAAS) enables services to
authenticate and enforce access controls upon users. It implements a Java
technology version of the standard Pluggable Authentication Module (PAM)
framework and supports user-based authorization. The Java™ Authorization
Service Provider Contract for Containers (JACC) defines a contract between a Java
EE application server and an authorization service provider, allowing custom
authorization service providers to be plugged into any Java EE product. The Java™
Authentication Service Provider Interface for Containers (JASPIC) defines an SPI
by which authentication providers implementing message authentication
mechanisms may be integrated in client or server message processing containers or
runtimes. The Java EE Security API leverages JASPIC, but provides an easier to use
SPI for authentication of users of web applications and defines identity store APIs
for authentication and authorization.

18
EE.2.7.15 Web Services
Java EE provides full support for both clients of web services as well as web service
endpoints. Several Java technologies work together to provide support for web
services. The Java API for XML Web Services (JAX-WS) and the Java API for
XML-based RPC (JAX-RPC) both provide support for web service calls using the
SOAP/HTTP protocol. JAX-WS, which is included in Java SE, is the primary API
for web services and is a follow-on to JAX-RPC. JAX-WS offers extensive web
services functionality, with support for multiple bindings/protocols. JAX-WS and
JAX-RPC are fully interoperable when using the SOAP 1.1 over HTTP protocol as
constrained by the WS-I Basic Profile specification. Support for JAX-RPC has been
made optional as of Java EE 7. See Section EE.6.1.3, “Pruned Java Technologies”.
JAX-WS and the Java Architecture for XML Binding (JAXB) define the
mapping between Java classes and XML as used in SOAP calls, and provide
support for 100% of XML Schema. JAXB is included in Java SE. The SOAP with
Attachments API for Java (SAAJ), which is also included in Java SE, provides
support for manipulating low level SOAP messages. The Web Services for Java
EE specification fully defines the deployment of web service clients and web
service endpoints in Java EE, as well as the implementation of web service
endpoints using enterprise beans. The Web Services Metadata specification
defines Java language annotations that make it easier to develop web services.
The Java API for XML Registries (JAXR) provides client access to XML registry
servers. Support for JAXR has been made optional as of Java EE 7. See
Section EE.6.1.3, “Pruned Java Technologies”.
The Java API for JSON Processing (JSON-P) provides a convenient way to
process (parse, generate, transform, and query) JSON text. The Java API for
JSON Binding (JSON-B) provides a convenient way to convert between JSON
text and Java objects. The Java API for WebSocket (WebSocket) is a standard API
for creating WebSocket applications.
The Java API for RESTful Web Services (JAX-RS) provides support for web
services using the REST style. RESTful web services better match the design
style of the web and are often easier to access using a wide variety of
programming languages. JAX-RS provides a simple high-level API for writing
such web services as well as a low-level API that can be used to control the details
of the web service interaction.
EE.2.7.16 Concurrency Utilities
The Concurrency Utilities for Java EE is a standard API for providing asynchronous
capabilities to Java EE application components through the following types of

INTEROPERABILITY 19
objects: managed executor service, managed scheduled executor service, managed
thread factory, and context service.
EE.2.7.17 Batch
The Batch Applications for the Java Platform API (Batch) provides a programming
model for batch applications and a runtime for scheduling and executing jobs.
EE.2.7.18 Management
The Java 2 Platform, Enterprise Edition Management Specification defines APIs for
managing Java EE servers using a special management enterprise bean. The Java™
Management Extensions (JMX) API is also used to provide some management
support.
EE.2.7.19 Deployment
The Java 2 Platform, Enterprise Edition Deployment Specification defines a
contract between deployment tools and Java EE products. The Java EE products
provide plug-in components that run in the deployment tool and allow the
deployment tool to deploy applications into the Java EE product. The deployment
tool provides services used by these plug-in components. Support for the
Deployment Specification has been made optional as of Java EE 7. See
Section EE.6.1.3, “Pruned Java Technologies.”
EE.2.8 Interoperability
Many of the APIs described above provide interoperability with components that
are not a part of the Java EE platform, such as external web or CORBA services.
Figure EE.2-2 illustrates the interoperability facilities of the Java EE platform.
(The directions of the arrows indicate the client/server relationships of the
components.)

20
.
EE.2.9 Flexibility of Product Requirements
This specification doesn’t require that a Java EE product be implemented by a single
program, a single server, or even a single machine. In general, this specification
doesn’t describe the partitioning of services or functions between machines, servers,
or processes. As long as the requirements in this specification are met, Java EE
Product Providers can partition the functionality however they see fit. A Java EE
product must be able to deploy application components that execute with the
semantics described by this specification.
Figure EE.2-2 Java EE Interoperability
Java EE Platform
Database
Applet
Container
HTTP
SSL
IIOP
JRMP
Web
Container
EJB
Container
HTTP
SSL
SOAP
HTTP
JRMP
Application
Client
Container
EJB / IIOP / SSL
IIOP
JRMP
HTTP
SSL
SOAP
HTTP
IIOP
JRMP
HTTP
SSL
SOAP
HTTP
IIOP

JAVA EE PRODUCT PACKAGING 21
A typical low end Java EE product will support applets using the Java Plugin
in one of the popular browsers, application clients each in their own Java virtual
machine, and will provide a single server that supports both web components and
enterprise beans. A high end Java EE product might split the server components
into multiple servers, each of which can be distributed and load-balanced across a
collection of machines. While such machines might exist on-site in an enterprise,
they might also reside, for example, in a public cloud. This specification does not
prescribe or preclude any of these configurations.
A wide variety of Java EE product configurations and implementations, all of
which meet the requirements of this specification, are possible. A portable Java
EE application will function correctly when successfully deployed in any of these
products.
EE.2.10 Java EE Product Packaging
This specification doesn't include requirements for the packaging of a Java EE
product. A Java EE product might be provided on distribution media, for download
on the web, or as a service available only on the web, for example. A Java EE
product must include implementations of all the APIs required by this specification.
These implementations might depend on other software or services not included in
the Java EE product. The customer may be required to combine or configure the
product with other software or services that are necessary to meet the requirements
of this specification. The documentation for the Java EE product must fully
describe all the required software and configuration.
For example, a Java EE product might depend on a database server, a naming
service, a mail service, and/or a messaging service. All configurations in which
the product is defined to operate must include all the software and services
necessary to meet the requirements of this specification.
Whether these services are available (running, accessible on the network,
properly configured, operating correctly, etc.) may be controlled independently of
the Java EE product — they may be unavailable when the Java EE server is
started, or they may fail while the Java EE server is running. This specification
does not require the Java EE product to assure the availability of these services.
However, if such a service is needed to meet the requirements of this
specification, the Java EE product must ensure that the service has been
configured for use and will be usable when it is available.
For example, this specification requires that applications can use a database.
If the Java EE product requires a database server to be separately installed, and
requires the Java EE product to be configured to use that database, such

22
configuration must be done before applications are deployed. This ensures that
the operational environment of applications includes all the required services.
EE.2.11 Java EE Product Extensions
This specification describes a minimum set of facilities available to all Java EE
products. A Java EE profile may include some or all of these facilities, as described
in Chapter EE.9, “Profiles”. Products implementing the full Java EE platform must
provide all of them (see Section EE.9.7, “Full Java EE Product Requirements”).
Most Java EE products will provide facilities beyond the minimum required by this
specification. This specification includes only a few limits to the ability of a product
to provide extensions. In particular, it includes the same restrictions as Java SE on
extensions to Java APIs. A Java EE product must not add classes to the Java
programming language packages included in this specification, and must not add
methods or otherwise alter the signatures of the specified classes.
However, many other extensions are allowed. A Java EE product may provide
additional Java APIs, either other Java optional packages or other (appropriately
named) packages. A Java EE product may include support for additional protocols
or services not specified here. A Java EE product may support applications
written in other languages, or may support connectivity to other platforms or
applications.
Of course, portable applications will not make use of any platform extensions.
Applications that do make use of facilities not required by this specification will
be less portable. Depending on the facility used, the loss of portability may be
minor or it may be significant.
We expect Java EE products to vary widely and compete vigorously on
various aspects of quality of service. Products will provide different levels of
performance, scalability, robustness, availability, and security. In some cases this
specification requires minimum levels of service. Future versions of this
specification may allow applications to describe their requirements in these areas.
EE.2.12 Platform Roles
This section describes typical Java Platform, Enterprise Edition roles. In an actual
instance, an organization may divide role functionality differently to match that
organization’s application development and deployment workflow.
The roles are described in greater detail in later sections of this specification.

PLATFORM ROLES 23
EE.2.12.1 Java EE Product Provider
A Java EE Product Provider is the implementor and supplier of a Java EE product
that includes the component containers, Java EE platform APIs, and other features
defined in this specification. A Java EE Product Provider is typically an application
server vendor, a web server vendor, a database system vendor, or an operating
system vendor. A Java EE Product Provider must make available the Java EE APIs
to the application components through containers. A Product Provider frequently
bases their implementation on an existing infrastructure.
A Java EE Product Provider must provide the mapping of the application
components to the network protocols as specified by this specification. A Java EE
product is free to implement interfaces that are not specified by this specification
in an implementation-specific way.
A Java EE Product Provider must provide application deployment and
management tools. Deployment tools enable a Deployer (see Section EE.2.12.4,
“Deployer”) to deploy application components on the Java EE product.
Management tools allow a System Administrator (see Section EE.2.12.5, “System
Administrator”) to manage the Java EE product and the applications deployed on
the Java EE product. The form of these tools is not prescribed by this
specification.
EE.2.12.2 Application Component Provider
There are multiple roles for Application Component Providers, including, for
example, HTML document designers, document programmers, and enterprise bean
developers. These roles use tools to produce Java EE applications and components.
EE.2.12.3 Application Assembler
The Application Assembler takes a set of components developed by Application
Component Providers and assembles them into a complete Java EE application
delivered in the form of an Enterprise Archive (.ear) file. The Application
Assembler will generally use GUI tools provided by either a Platform Provider or
Tool Provider. The Application Assembler is responsible for providing assembly
instructions describing external dependencies of the application that the Deployer
must resolve in the deployment process.

24
EE.2.12.4 Deployer
The Deployer is responsible for deploying application clients, web applications, and
Enterprise JavaBeans components into a specific operational environment. The
Deployer uses tools supplied by the Java EE Product Provider to carry out
deployment tasks. Deployment is typically a three-stage process:
1. During Installation the Deployer moves application media to the server, gen-
erates the additional container-specific classes and interfaces that enable the
container to manage the application components at runtime, and installs appli-
cation components, and additional classes and interfaces, into the appropriate
Java EE containers.
2. During Configuration, external dependencies declared by the Application
Component Provider are resolved and application assembly instructions de-
fined by the Application Assembler are followed. For example, the Deployer
is responsible for mapping security roles defined by the Application Assembler
onto user groups and accounts that exist in the target operational environment.
3. Finally, the Deployer starts up Execution of the newly installed and config-
ured application.
In some cases, a specially qualified Deployer may customize the business
logic of the application’s components at deployment time. For example, using
tools provided with a Java EE product, the Deployer may provide simple
application code that wraps an enterprise bean’s business methods, or customizes
the appearance of a JSP or JSF page.
The Deployer’s output is web applications, enterprise beans, applets, and
application clients that have been customized for the target operational
environment and are deployed in a specific Java EE container.
For example, in the case of cloud deployments, the Deployer would be
responsible for configuring the application to run in the cloud environment. The
Deployer would install the application into the cloud environment, configure its
external dependencies, and might handle aspects of provisioning its required
resources.
EE.2.12.5 System Administrator
The System Administrator is responsible for the configuration and administration of
the enterprise’s computing and networking infrastructure. The System
Administrator is also responsible for overseeing the runtime well-being of the
deployed Java EE applications. The System Administrator typically uses runtime

PLATFORM CONTRACTS 25
monitoring and management tools provided by the Java EE Product Provider to
accomplish these tasks.
For example, in a cloud scenario, the System Administrator would be
responsible for installing, configuring, managing, and maintaining the cloud
environment, including the resources that are made available to applications
running in the environment.
EE.2.12.6 Tool Provider
A Tool Provider provides tools used for the development and packaging of
application components. A variety of tools are anticipated, corresponding to the
types of application components supported by the Java EE platform. Platform
independent tools can be used for all phases of development through the
deployment of an application and the management and monitoring of an application
server.
EE.2.12.7 System Component Provider
A variety of system level components may be provided by System Component
Providers. The Connector Architecture defines the primary APIs used to provide
resource adapters of many types. These resource adapters may connect to existing
enterprise information systems of many types, including databases and messaging
systems. Another type of system component is an authorization policy provider as
defined by the Java Authorization Service Provider Contract for Containers
specification.
EE.2.13 Platform Contracts
This section describes the Java Platform, Enterprise Edition contracts that must be
fulfilled by a Java EE Product Provider implementing the full Java EE platform.
Java EE profiles may include some or all of these facilities, as described in
Chapter EE.9, “Profiles”.
EE.2.13.1 Java EE APIs
The Java EE APIs define the contract between the Java EE application components
and the Java EE platform. The contract specifies both the runtime and deployment
interfaces.

26
The Java EE Product Provider must implement the Java EE APIs in a way that
supports the semantics and policies described in this specification. The
Application Component Provider provides components that conform to these
APIs and policies.
EE.2.13.2 Java EE Service Provider Interfaces (SPIs)
The Java EE Service Provider Interfaces (SPIs) define the contract between the Java
EE platform and service providers that may be plugged into a Java EE product. The
Connector APIs define service provider interfaces for integrating resource adapters
with a Java EE application server. Resource adapter components implementing the
Connector APIs are called Connectors. The Java EE Authorization APIs define
service provider interfaces for integrating security authorization mechanisms with a
Java EE application server.
The Java EE Product Provider must implement the Java EE SPIs in a way that
supports the semantics and policies described in this specification. A provider of
Service Provider components (for example, a Connector Provider) should provide
components that conform to these SPIs and policies.
EE.2.13.3 Network Protocols
This specification defines the mapping of application components to industry-
standard network protocols. The mapping allows client access to the application
components from systems that have not installed Java EE product technology. See
Chapter EE.7, “Interoperability,” for details on the network protocol support
required for interoperability.
The Java EE Product Provider is required to publish the installed application
components on the industry-standard protocols. This specification defines the
mapping of servlets and JSP pages to the HTTP and HTTPS protocols, and the
mapping of EJB components to IIOP and SOAP protocols.
EE.2.13.4 Deployment Descriptors and Annotations
Deployment descriptors and Java language annotations are used to communicate the
needs of application components to the Deployer. The deployment descriptor and
class file annotations are a contract between the Application Component Provider or
Assembler and the Deployer. The Application Component Provider or Assembler is
required to specify the application component’s external resource requirements,
security requirements, environment parameters, and so forth in the component’s
deployment descriptor or through class file annotations. The Java EE Product

CHANGES IN J2EE 1.3 27
Provider is required to provide a deployment tool that interprets the Java EE
deployment descriptors and class file annotations and allows the Deployer to map
the application component’s requirements to the capabilities of a specific Java EE
product and environment.
EE.2.14 Changes in J2EE 1.3
The J2EE 1.3 specification extends the J2EE platform with additional enterprise
integration facilities. The Connector API supports integration with external
enterprise information systems. A JMS provider is now required. The JAXP API
provides support for processing XML documents. The JAAS API provides security
support for the Connector API. The EJB specification now requires support for
interoperability using the IIOP protocol.
Significant changes have been made to the EJB specification. The EJB
specification has a new container-managed persistence model, support for
message driven beans, and support for local enterprise beans.
Other existing J2EE APIs have been updated as well. See the individual API
specifications for details. Finally, J2EE 1.3 requires support for J2SE 1.3.
EE.2.15 Changes in J2EE 1.4
The primary focus of J2EE 1.4 is support for web services. The JAX-RPC and
SAAJ APIs provide the basic web services interoperability support. The Web
Services for J2EE specification describes the packaging and deployment
requirements for J2EE applications that provide and use web services. The EJB
specification was also extended to support implementing web services using
stateless session beans. The JAXR API supports access to registries and
repositories.
Several other APIs have been added to J2EE 1.4. The J2EE Management and
J2EE Deployment APIs enable enhanced tool support for J2EE products. The
JMX API supports the J2EE Management API. The J2EE Authorization Contract
for Containers provides an SPI for security providers.
Many of the existing J2EE APIs have been enhanced in J2EE 1.4. J2EE 1.4
builds on J2SE 1.4. The JSP specification has been enhanced to simplify the
development of web applications. The Connector API now supports integration
with asynchronous messaging systems, including the ability to plug in JMS
providers.

28
Changes in this J2EE platform specification include support for deploying
class libraries independently of any application and the conversion of deployment
descriptor DTDs to XML Schemas.
Other J2EE APIs have been enhanced as well. For additional details, see each
of the referenced specifications.
EE.2.16 Changes in Java EE 5
With this release, the platform has a new name – Java Platform, Enterprise Edition,
or Java EE for short. This new name gets rid of the confusing “2” while
emphasizing even in the short name that this is a Java platform. Previous versions
are still referred to using the old name “J2EE”.
The focus of Java EE 5 is ease of development. To simplify the development
process for programmers just starting with Java EE, or developing small to
medium applications, Java EE 5 makes extensive use of Java language
annotations, which were introduced by J2SE 5.0. Annotations reduce or eliminate
the need to deal with Java EE deployment descriptors in many cases. Even large
applications can benefit from the simplifications provided by annotations.
One of the major uses of annotations is to specify injection of resources and
other dependencies into Java EE components. Injection augments the existing
JNDI lookup capability to provide a new simplified model for applications to gain
access to the resources needed from the operational environment. Injection also
works with deployment descriptors to allow the deployer to customize or override
resource settings specified in the application’s source code.
The use of annotations is made even more effective by providing better
defaults. Better default behavior and better default configuration allows most
applications to get the behavior they want most of the time, without the use of
either annotations or deployment descriptors in many cases. When the default is
not what the application wants, a simple annotation can be used to specify the
required behavior or configuration.
The combination of annotations and better defaults has greatly simplified the
development of applications using Enterprise JavaBeans technology and
applications defining or using web services. Enterprise beans are now
dramatically simpler to develop. Web services are much easier to develop using
the annotations defined by the Web Services Metadata specification.
The area of web services continues to evolve at a rapid pace. To provide the
latest web services support, the JAX-RPC technology has evolved into the JAX-
WS technology, which makes heavy use of the JAXB technology to bind Java

CHANGES IN JAVA EE 6 29
objects to XML data. Both JAX-WS and JAXB are new to this version of the
platform.
Major additions to Java EE 5 include the JSTL and JSF technologies that
simplify development of web applications, and the Java Persistence API
developed by the EJB 3.0 expert group, which greatly simplifies mapping Java
objects to databases.
Minor additions include the StAX API for XML parsing. Most APIs from
previous versions have been updated with small to medium improvements.
Java EE 6 continues the “ease of development” focus of Java EE 5.
One of the major improvements introduced in Java EE 6 is the Contexts and
Dependency Injection (CDI) technology, which provides a uniform framework for
the dependency injection and lifecycle management of “managed beans”.
The Java EE 6 Managed Bean specification defines the commonalities across
the spectrum of Java EE managed objects, extending from basic managed beans
through EJB components.
The Bean Validation specification, introduced in this release, provides a
facility for validation of managed objects. Bean Validation is integrated into the
Java Persistence API, where it provides an automated facility for the validation of
JPA entities.
Java EE 6 adds the JAX-RS API as a required technology of the Java EE
Platform. JAX-RS is the API for the development of Web services built according
to the Representational State Transfer (REST) architectural style.
Java EE 6 also introduces the Java EE Web Profile, the first new profile of the
Java EE Platform.
Since its inception, the Java EE platform has been targeted at offloading the
developer from common infrastructure tasks through its container-based model and
abstraction of resource access. In recent releases the platform has considerably
simplified the APIs for access to container services while broadening the range of
the services available. In this release we continue the direction of improved
simplification, while extending the range of the Java EE platform to encompass
emerging technologies in the web space.

30
The Java EE 7 platform adds first-class support for recent developments in
web standards, including Web Sockets and JSON, which provide the
underpinnings for HTML 5 support in Java EE. Java EE 7 also adds a modern
HTTP client API as defined by JAX-RS 2.0.
Also new in the Java EE 7 platform is the Batch API, which provides a
programming model for batch applications and a runtime for scheduling and
executing jobs, and the Concurrency Utilities API, which provides asynchronous
capabilities by means of managed executor service, managed scheduled executor
service, managed thread factory, and context service.
The CDI dependency injection facility introduced in Java EE 6 is enhanced as
well as more broadly utilized by the Java EE 7 platform technologies, and the
managed bean model is further aligned to remove inconsistencies among Java EE
component classes in aspects of CDI injection and interceptor support. The
declarative transaction functionality introduced by EJB is been made available in
a more general way through CDI interceptors, so that it may be leveraged by other
managed beans. The Bean Validation facility is extended to the automatic
validation of method invocations and likewise made available via CDI
interceptors.
Java EE 7 also continues the "ease of development" focus of Java EE 5 and
Java EE 6. Most notably, Java EE 7 includes a revised and greatly simplified JMS
2.0 API. Ease of development encompasses ease of configuration as well. To that
end, Java EE 7 broadens the resource definition facilities introduced in Java EE 6
to encompass more of the standard platform resource types, and also provides
default database and JMS connection factory resources. It also improves the
configuration of application security, including new descriptors for security
permissions. Java EE 7 further simplifies the platform by making optional the
technologies that were identified as candidates for pruning in Java EE 6, namely:
EJB Entity Beans, JAX-RPC 1.1, JAXR 1.0, and JSR-88 1.2.
Finally, Java EE 7 lays groundwork for enhancements to the platform for use
in cloud environments in a future release. Such features include resource
definition metadata, improved security configuration, and support for database
schema generation via the Java Persistence API.
Java EE 8 continues the focus on modern web applications of Java EE 7 and
broadening the range of such applications. Java EE 8 introduces the JSON Binding
API (JSON-B) for mapping between JSON text and Java objects, building on the
JSON Processing API (JSON-P) introduced in Java EE 7. The JSON Processing

CHANGES IN JAVA EE 8 31
API itself is updated to reflect additional JSON standards. Servlet undergoes major
enhancement with the addition of support for the new HTTP/2 protocol. JAX-RS
adds support for server-sent events and, building on concurrency facilities added in
Java SE 8, a reactive client API. The new Java EE Security API provides enhanced
support for authentication and authorization in web modules, and also introduces
APIs for access to identity stores. The Bean Validation facility is updated to reflect
enhancements made in Java SE 8 and to extend the range of validated objects. While
the focus of CDI in this release is to extend its scope beyond Java EE with the
introduction of a bootstrapping API, CDI also includes enhancements for event
processing and alignment on Java SE 8 features.

33
C H A P T E R EE.3
Security
This chapter describes the security requirements for the Java™ Platform,
Enterprise Edition (Java EE) that must be satisfied by Java EE products.
In addition to the Java EE requirements, each Java EE Product Provider will
determine the level of security and security assurances that will be provided by
their implementation.
EE.3.1 Introduction
Almost every enterprise has security requirements and specific mechanisms and
infrastructure to meet them. Sensitive resources that can be accessed by many users
or that often traverse unprotected open networks (such as the Internet) need to be
protected.
Although the quality assurances and implementation details may vary, they all
share some of the following characteristics:
• Authentication: The means by which communicating entities (for example,
client and server) prove to one another that they are acting on behalf of specific
identities that are authorized for access.
• Access control for resources: The means by which interactions with resourc-
es are limited to collections of users or programs for the purpose of enforcing
integrity, confidentiality, or availability constraints.
• Data integrity: The means used to prove that information has not been modi-
fied by a third party (some entity other than the source of the information).
For example, a recipient of data sent over an open network must be able to de-
tect and discard messages that were modified after they were sent.

34
• Confidentiality or Data Privacy: The means used to ensure that information
is made available only to users who are authorized to access it.
• Non-repudiation: The means used to prove that a user performed some ac-
tion such that the user cannot reasonably deny having done so.
• Auditing: The means used to capture a tamper-resistant record of security re-
lated events for the purpose of being able to evaluate the effectiveness of secu-
rity policies and mechanisms.
This chapter specifies how Java EE platform requirements address security
requirements, and identifies requirements that may be addressed by Java EE
Product Providers. Finally, issues being considered for future versions of this
specification are briefly mentioned in Section EE.3.7, “Future Directions”.
EE.3.2 A Simple Example
The security behavior of a Java EE environment may be better understood by
examining what happens in a simple application with a web client, a JSP user
interface, and enterprise bean business logic. (The example is not meant to specify
requirements.)
In this example, the web client relies on the web server to act as its
authentication proxy by collecting user authentication data from the client and
using it to establish an authenticated session.
Step 1: Initial Request
The web client requests the main application URL, shown in Figure EE.3-1.
Figure EE.3-1 Initial Request
Since the client has not yet authenticated itself to the application environment,
the server responsible for delivering the web portion of the application (here-
after referred to as “web server”) detects this and invokes the appropriate
authentication mechanism for this resource.
Step 2: Initial Authentication
The web server returns a form that the web client uses to collect authentica-
Web Client
Web Server
Request access to
protected resource

Exploring the Variety of Random
Documents with Different Content

Mary raised her head, and, though her face was wet, she smiled.
Her hand went out to him, but she noticed it and drew it back. Rob
saw it too, but did not seek to take it. They were looking at each
other bravely. His eyes proposed to her, while he could not say a
word, and hers accepted him. On the hills men were shooting birds.
Rob knew that Mary loved him. An awe fell upon him. 'What am I?'
he cried, and Mary put her hand in his. 'Don't, dear,' she said, as his
face sank on it; and he raised his head and could not speak.
The colonel sighed, and his cheeks were red. His head sank upon his
hands. He was young again, and walking down an endless lane of
green with a maiden by his side, and her hand was in his. They sat
down by the side of a running stream. Her fair head lay on his
shoulder, and she was his wife. The colonel's lips moved as if he
were saying to himself words of love, and his arms went out to her
who had been dead this many a year, and a tear, perhaps the last he
ever shed, ran down his cheek.
'I should not,' Mary said at last, 'have let you talk to me like this.'
Rob looked up with sudden misgiving.
'Why not?' he cried.
'Papa,' she said, 'will never consent, and I—I knew that; I have
known it all along.'
'I am not going to give you up now,' Rob said passionately, and he
looked as if he would run away with her at that moment.
'I had no right to listen to you,' said Mary. 'I did not mean to do so,
but I—I'—her voice sank into a whisper—'I wanted to know——'
'To know that I loved you! Ah, you have known all along.'
'Yes,' said Mary, 'but I wanted—I wanted to hear you say so
yourself.'
Rob's arms went over her like a hoop.

'Rob, dear,' she whispered, 'you must go away, and never see me
any more.'
'I won't,' cried Rob; 'you are to be my wife. He shall not part us.'
'It can never be,' said Mary.
'I shall see him—I shall compel him to consent.'
Mary shook her head.
'You don't want to marry me,' Rob said fiercely, drawing back from
her. 'You do not care for me. What made you say you did?'
'I shall have to go back now,' Mary said, and the softness of her
voice contrasted strangely with the passion in his.
'I shall go with you,' Rob answered, 'and see your father.'
'No, no,' said Mary; 'we must say good-bye here, now.'
Rob turned on her with all the dourness of the Anguses in him.
'Good-bye,' he said, and left her. Mary put her hand to her heart, but
he was already turning back.
'Oh,' she cried, 'do you not see that it is so much harder to me than
to you?'
'Mary, my beloved,' Rob cried. She swayed in her saddle, and if he
had not been there to catch her she would have fallen to the
ground.
Rob heard a footstep at his side, and, looking up, saw Colonel
Abinger. The old man's face was white, but there was a soft look in
his eye, and he stooped to take Mary to his breast.
'No,' Rob said, with his teeth close, 'you can't have her. She's mine.'
'Yes,' the colonel said sadly; 'she's yours.'

CHAPTER XIX
THE VERDICT OF THRUMS
On a mild Saturday evening in the following May, Sandersy Riach,
telegraph boy, emerged from the Thrums post-office, and, holding
his head high, strutted off towards the Tenements. He had on his
uniform, and several other boys flung gutters at it, to show that they
were as good as he was.
'Wha's deid, Sandersy?' housewives flung open their windows to ask.
'It's no a death,' Sandersy replied. 'Na, na, far frae that. I daurna tell
ye what it is, because it's agin' the regalations, but it'll cause a
michty wy doin' in Thrums this nicht.'
'Juist whisper what it's aboot, Sandersy, my laddie.'
'It canna be done, Easie; na, na. But them 'at wants to hear the
noos, follow me to Tammas Haggart's.'
Off Sandersy went, with some women and a dozen children at his
heels, but he did not find Tammas in.
'I winna hae't lyin' aboot here,' Chirsty, the wife of Tammas, said,
eyeing the telegram as something that might go off at any moment;
'ye'll better tak it on to 'imsel. He's takkin a dander through the
buryin' ground wi' Snecky Hobart.'
Sandersy marched through the east town end at the head of his
following, and climbed the steep, straight brae that leads to the
cemetery. There he came upon the stone-breaker and the bellman
strolling from grave to grave. Silva McQuhatty and Sam'l Todd were

also in the burying-ground for pleasure, and they hobbled toward
Tammas when they saw the telegram in his hand.
'"Thomas Haggart,"' the stone-breaker murmured, reading out his
own name on the envelope, '"Tenements, Thrums."' Then he stared
thoughtfully at his neighbours to see whether that could be looked
upon as news. It was his first telegram.
'Ay, ay, deary me,' said Silva mournfully.
'She's no very expliceet, do ye think?' asked Sam'l Todd.
Snecky Hobart, however, as an official himself, had a general notion
of how affairs of state are conducted.
'Rip her open, Tammas,' he suggested. 'That's but the shell, I'm
thinkin'.'
'Does she open?' asked Tammas, with a grin.
He opened the telegram gingerly, and sat down on a prostrate
tombstone to consider it. Snecky's fingers tingled to get at it.
'It begins in the same wy,' the stone-breaker said deliberately;
'"Thomas Haggart, Tenements, Thrums."'
'Ay, ay, deary me,' repeated Silva.
'That means it's to you,' Snecky said to Tammas.
'Next,' continued Tammas, 'comes, "Elizabeth Haggart, 101, Lower
Fish Street, Whitechapel, London."'
'She's a' names thegether,' muttered Sam'l Todd, in a tone of
remonstrance.
'She's a' richt,' said Snecky, nodding to Tammas to proceed.
'Elizabeth Haggart—that's wha the telegram comes frae.'
'Ay, ay,' said the stone-breaker doubtfully, 'but I ken no Elizabeth
Haggart.'

'Hoots,' said Snecky; 'it's your ain dochter Lisbeth.'
'Keep us a',' said Tammas, 'so it is. I didna un'erstan' at first; ye see
we aye called her Leeby. Ay, an' that's whaur she bides in London
too.'
'Lads, lads,' said Silva, 'an' is Leeby gone? Ay, ay, we all fade as a
leaf; so we do.'
'What!' cried Tammas, his hand beginning to shake.
'Havers,' said Snecky, 'ye hinna come to the telegram proper yet,
Tammas. What mair does it say?'
The stone-breaker conned over the words, and by and by his face
wrinkled with excitement. He puffed his cheeks, and then let the air
rush through his mouth like an escape of gas.
'It's Rob Angus,' he blurted out.
'Man, man,' said Silva, 'an' him lookit sae strong an' snod when he
was here i' the back-end o' last year.'
'He's no deid,' cried Tammas, 'he's mairit. Listen, lads, "The thing is
true Rob Angus has married the colonel's daughter at a castle Rob
Angus has married the colonel."'
'Losh me!' said Sam'l, 'I never believed he would manage't.'
'Ay, but she reads queer,' said Tammas. 'First she says Rob's mairit
the dochter, an' neist 'at he's mairit the colonel.'
'Twa o' them!' cried Silva, who was now in a state to believe
anything.
Snecky seized the telegram, and thought it over.
'I see what Leeby's done,' he said admiringly. 'Ye're restreected to
twenty words in a telegram, an' Leeby found she had said a' she had

to say in fourteen words, so she's repeated hersel to get her full
shilling's worth.'
'Ye've hit it, Snecky,' said Tammas. 'It's juist what Leeby would do.
She was aye a michty thrifty, shrewd crittur.'
'A shilling's an awfu' siller to fling awa, though,' said Sam'l.
'It's weel spent in this case,' retorted Tammas, sticking up for his
own; 'there hasna been sic a startler in Thrums since the English kirk
steeple fell.'
'Ye can see Angus's saw-mill frae here,' exclaimed Silva, implying
that this made the affair more wonderful than ever.
'So ye can,' said Snecky, gazing at it as if it were some curiosity that
had been introduced into Thrums in the night-time.
'To think,' muttered Tammas, ''at the saw-miller doon there should
be mairit in a castle. It's beyond all. Oh, it's beyond, it's beyond.'
'Sal, though,' said Sam'l suspiciously, 'I wud like a sicht o' the castle.
I mind o' readin' in a booky 'at every Englishman's hoose is his
castle, so I'm thinkin' castle's but a name in the sooth for an ord'nar
hoose.'
'Weel a wat, ye never can trust thae foreigners,' said Silva; 'it's weel
beknown 'at English is an awful pretentious langitch too. They slither
ower their words in a hurried wy 'at I canna say I like; no, I canna
say I like it.'
'Will Leeby hae seen the castle?' asked Sam'l.
'Na,' said Tammas; 'it's a lang wy frae London; she'll juist hae heard
o' the mairitch.'
'It'll hae made a commotion in London, I dinna doot,' said Snecky,
'but, lads, it proves as the colonel man stuck to Rob.'
'Ay, I hardly expected it.'

'Ay, ay, Snecky, ye 're richt. Rob'll hae manage't him. Weel, I will say
this for Rob Angus, he was a crittur 'at was terrible fond o' gettin' his
ain wy.'
'The leddy had smoothed the thing ower wi' her faither,' said
Tammas, who was notorious for his knowledge of women; 'ay, an'
there was a brither, ye mind? Ane o' the servants up at the Lodge
said to Kitty Wobster 'at they were to be mairit the same day, so I've
nae doot they were.'
'Ay,' said Sam'l, pricking up his ears, 'an' wha was the brither
gettin'?'
'Weel, it was juist gossip, ye understan'. But I heard tell 'at the leddy
had a tremendous tocher, an' 'at she was called Meredith.'
'Meredith!' exclaimed Silva McQuhatty, 'what queer names some o'
thae English fowk has; ay, I prefer the ord'nar names mysel.'
'I wonder,' said Snecky, looking curiously at the others, 'what Rob
has in the wy o' wages?'
'That's been discuss't in every hoose in Thrums,' said Sam'l, 'but
there's no doubt it's high, for it's a salary; ay, it's no wages.'
'I dinna ken what Rob has,' Silva said, 'but some o' thae writers
makes awfu' sums. There's the yeditor o' the Tilliedrum Weekly
Herald noo. I canna tell his income, but I have it frae Dite Deuchars,
wha kens, 'at he pays twa-an'-twenty pound o' rent for's hoose.'
'Ay, but Rob's no a yeditor,' said Sam'l.
'Ye're far below the mark wi' Rob's salary,' said Tammas. 'My ain
opeenion is 'at he has a great hoose in London by this time, wi' twa
or three servants, an' a lad in knickerbuckers to stan' ahent his chair
and reach ower him to cut the roast beef.'
'It may be so,' said Snecky, who had heard of such things, 'but if it is
it'll irritate Rob michty no to get cuttin' the roast 'imsel. Thae

Anguses aye likit to do a'thing for themsels.'
'There's the poseetion to think o',' said Tammas.
'Thrums'll be a busy toon this nicht,' said Sam'l, 'when it hears the
noos. Ay, I maun awa an' tell the wife.'
Having said this, Sam'l sat down on the tombstone.
'It'll send mair laddies on to the papers oot o' Thrums,' said Tammas.
'There's three awa to the printin' trade since Rob was here, an' Susie
Byars is to send little Joey to the business as sune as he's auld
eneuch.'
'Joey'll do weel in the noospaper line,' said Silva; 'he writes a better
han' than Rob Angus already.'
'Weel, weel, that's the main thing, lads.'
Sam'l moved off slowly to take the news into the east town end.
'It's to Rob's creedit,' said Tammas to the two men remaining, ''at he
wasna at all prood when he came back. Ay, he called on me very
frank like, as ye'll mind, an' I wasna in, so Chirsty dusts a chair for
'im, and comes to look for me. Lads, I was fair ashamed to see 'at in
her fluster she'd gien him a common chair, when there was hair-
bottomed anes in the other room. Ye may be sure I sent her for a
better chair, an' got him to change, though he was sort o' mad like
at havin' to shift. That was his ind'pendence again.'
'I was aye callin' him Rob,' said Snecky, 'forgettin' what a grand man
he was noo, an', of coorse, I corrected mysel, and said Mr. Angus.
Weel, when I'd dune that mebbe a dozen times he was fair stampin's
feet wi' rage, as ye micht say. Ay, there was a want o' patience aboot
Rob Angus.'
'He slippit a gold sovereign into my hand,' said Silva, 'but, losh, he
wudna lat me thank 'im. "Hold yer tongue," he says, or words to that
effec', when I insistit on't.'

At the foot of the burying-ground road Sam'l Todd could be seen
laying it off about Rob to a little crowd of men and women. Snecky
looked at them till he could look no longer.
'I maun awa wi' the noos to the wast toon end,' he said, and by and
by he went, climbing the dyke for a short cut.
'Weel, weel, Rob Angus is mairit,' said Silva to Tammas.
'So he is, Silva,' said the stone-breaker.
'It's an experiment,' said Silva.
'Ye may say so, but Rob was aye venturesome.'
'Ye saw the leddy, Tammas?'
'Ay, man, I did mair than that. She spoke to me, an' speired a lot
aboot the wy Rob took on when little Davy was fund deid. He was
fond o' his fowk, Rob, michty fond.'
'What was your opeenion o' her then, Tammas?'
'Weel, Silva, to tell the truth I was oncommon favourably impreesed.
She shook hands wi' me, man, an' she had sic a saft voice an' sic a
bonny face I was a kind o' carried awa; yes, I was so.'
'Ay, ye say that, Tammas. Weel, I think I'll be movin'. They'll be keen
to hear aboot this in the square.'
'I said to her,' continued Tammas, peering through his half-closed
eyes at Silva, ''at Rob was a lucky crittur to get sic a bonny wife.'
'Ye did!' cried Silva. 'An' hoo did she tak that?'
'Ou,' said Tammas complacently, 'she took it weel.'
'I wonder,' said Silva, now a dozen yards away, ''at Rob never sent
ony o' the papers he writes to Thrums juist to lat's see them.'

'He sent a heap,' said Tammas, 'to the minister, meanin' them to be
passed roond, but Mr. Dishart didna juist think they were quite the
thing, ye un'erstan', so he keeps them lockit up in a press.'
'They say in the toon,' said Silva, ''at Rob would never hae got on
sae weel if Mr. Dishart hadna helpit him. Do you think there's
onything in that?'
Tammas was sunk in reverie, and Silva at last departed. He was out
of sight by the time the stone-breaker came to.
'I spoke to the minister aboot it,' Tammas answered, under the
impression that Silva was still there, 'an' speired at him if he had
sent a line aboot Rob to the London yeditors, but he wudna say.'
Tammas moved his head round, and saw that he was alone.
'No,' he continued thoughtfully, addressing the tombstones, 'he
would neither say 'at he did nor 'at he didna. He juist waved his han'
like, to lat's see 'at he was at the bottom o't, but didna want it to be
spoken o'. Ay, ay.'
Tammas hobbled thoughtfully down one of the steep burying-ground
walks, until he came to a piece of sward with no tombstone at its
head.
'Ay,' he said, 'there's mony an Angus lies buried there, an' Rob's the
only are left noo. I hae helpit to hap the earth ower five, ay, sax o'
them. It's no to be expeckit, no, i' the course o' natur' it's no to be
expeckit, 'at I should last oot the seventh: no, but there's nae sayin'.
Ay, Rob, ye wasna sae fu' o' speerits as I'll waurant ye are the noo,
that day ye buried Davy. Losh, losh, it's a queer warld.'
'It's a pretty spot to be buried in,' he muttered, after a time; and
then his eyes wandered to another part of the burying-ground.
'Ay,' he said, with a chuckle, 'but I've a snod bit cornery up there for
mysel. Ou ay.'

THE END
Printed by T. and A. Constable, Printers to His Majesty at the
Edinburgh University Press

*** END OF THE PROJECT GUTENBERG EBOOK WHEN A MAN'S
SINGLE: A TALE OF LITERARY LIFE ***
Updated editions will replace the previous one—the old editions will
be renamed.
Creating the works from print editions not protected by U.S.
copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.
START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE

PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK
To protect the Project Gutenberg™ mission of promoting the free
distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.
Section 1. General Terms of Use and
Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.
1.B. “Project Gutenberg” is a registered trademark. It may only be
used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.

1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.
1.E. Unless you have removed all references to Project Gutenberg:
1.E.1. The following sentence, with active links to, or other
immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
1.E.2. If an individual Project Gutenberg™ electronic work is derived
from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.
1.E.3. If an individual Project Gutenberg™ electronic work is posted
with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.
1.E.4. Do not unlink or detach or remove the full Project
Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute this
electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1

with active links or immediate access to the full terms of the Project
Gutenberg™ License.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.
1.E.7. Do not charge a fee for access to, viewing, displaying,
performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.
1.E.8. You may charge a reasonable fee for copies of or providing
access to or distributing Project Gutenberg™ electronic works
provided that:
• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information

about donations to the Project Gutenberg Literary Archive
Foundation.”
• You provide a full refund of any money paid by a user who
notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.
• You provide, in accordance with paragraph 1.F.3, a full refund of
any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.
• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.
1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™
electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.
1.F.
1.F.1. Project Gutenberg volunteers and employees expend
considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or

damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.
1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for
the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.
1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you
discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.
1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.
1.F.5. Some states do not allow disclaimers of certain implied
warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.
1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,
the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.
Section 2. Information about the Mission
of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.
Volunteers and financial support to provide volunteers with the
assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will

remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.
Section 3. Information about the Project
Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.
The Foundation’s business office is located at 809 North 1500 West,
Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact
Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many

small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.
The Foundation is committed to complying with the laws regulating
charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.
While we cannot and do not solicit contributions from states where
we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.
International donations are gratefully accepted, but we cannot make
any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.
Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.
Section 5. General Information About
Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.

Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.
Most people start at our website which has the main PG search
facility: www.gutenberg.org.
This website includes information about Project Gutenberg™,
including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Java Platform Enterprise Edition Java Ee Specification 80 Linda Demichiel

More Related Content

Similar to Java Platform Enterprise Edition Java Ee Specification 80 Linda Demichiel (20)

Recently uploaded (20)

Java Platform Enterprise Edition Java Ee Specification 80 Linda Demichiel