NYCJava.net Main Page

About NYCJava.net JUG
Java Study Groups:
SCJP 6 (Programmer Cert.)
Java Mobile
Design Patterns and JEEnew
SCEA 5 (Architect Cert.)
Java Enterprise Study Group

RSVP for Dec 21
http://www.nycjava.net/JSPWiki/nytchp.logo.sm.gif
A member SIG of
http://nypc.org

Sponsor of the
NYC Java Meetup
http://www.nycjava.net/JSPWiki/meetup.png

help support NYC Java:
http://cafepress.com/nycjava
http://www.nycjava.net/JSPWiki/mug.jpg http://www.nycjava.net/JSPWiki/tshirt.jpg
Special thanks to:
Sun Microsystems
Prentice Hall
O'Reilly
JetBrains
Apress
and NYPC!
Book Reviews
Articles
Java Links
Java Jobs
Humor
About Duke
System Info
Find pages
About this Wiki
Wiki Quick Start
WikiEtiquette
Set your name in
UserPreferences

Edit this page



[RSS]

SCBCD 5_Section_1
Search Wiki:
Your trail: NYCJava.net
Section 1: EJB 3.0 Overview

1. Identify the uses, benefits, and characteristics of Enterprise JavaBeans technology, for version 3.0 of the EJB specification.

General Goals

- Make it easy to write applications: app developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, or other complex low-level APIs. (EJB 3 2.1 spec)
- Write Once, Run Anywhere" (EJB 3 2.1 spec)
- Build applications by combining components developed using tools from different vendors.
- Compatibility with existing server platforms
- Compatible with the Java programming language.
- Compatible with the CORBA protocols
- Interoperability between enterprise beans and Java platform EE components as well as other programming languages.
- Define the contracts that enable multiple vendor tools interoperability.
- Will be the standard component architecture for building oo and/or distributed business apps in Java.
- Support the development, deployment, and use of web services.
From EJB 3.0 spec 2.1

EJB 3.0 Specific Goals

- EJB simplification: elimination of requirements for the specification of home and component interfaces.
- Elimination of the requirement for enterprise beans to implement the javax.ejb.EnterpriseBean interface.
- Metadata specification by the use of annotations. Replace deployment descriptors by the use of annotations.
- Simplification of object persistence by the use of Java classes(Pojo's ?) rather than persistent connections.
- Easier dependency injection
- "Elimination of the requirement for EJB component interfaces for session beans." The business interface may be a simple Java interface.
- "Elimination of the requirement for home interfaces in session beans."
- "Elimination of all required interfaces for persistent interfaces entities>"
- "Elimination of the requirement for the implementation of callback interfaces."
- "Reduction of the requirements for usage of checked exceptions"
- "Encapsulate environmental dependencies and JNDI access by annotations, dependency injection and simple lookup mechanisms"
- "Extend EJB QL with a Java Persistence query language, supporting projection, explicit inner and outer join operations, bulk update/delete, subqueries and group-by. Add a dynamic query capability and support for native SOL queries."

From EJB 3.0 Simplified Specification

2. Identify the APIs that all EJB 3.0 containers must make available to developers.

- JDBC
- RMI-IIOP
- JNDI
- JAXP
- Java IDL
- JAAS
- JTA 1.1, the UserTransaction interface only
- JMS 1.1
- JavaMail 1.4, sending mail only
- JAF 1.1

From EJB 3.0 spec 21.1.1(Note: There are many optional api's.)


3. Identify correct and incorrect statements or examples about EJB programming restrictions.
21.1.2 Programming Restrictions

This section describes the programming restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 3.0 container. The restrictions apply to the implementation of the business methods. Section 21.2, which describes the container’s view of these restrictions, defines the programming environment that all EJB containers must provide.

• An enterprise bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.

This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean’s instances, others may distribute the instances across multiple JVMs.

• An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.

This is for the same reason as above. Synchronization would not work if the EJB container distributed enterprise bean’s instances across multiple JVMs.

• An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.

Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system.

• An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.

The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data.

• An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.

The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean to serve the EJB clients.

• The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language. The enterprise bean must not attempt to use the Reflection API to access information that the security rules of the Java programming language make unavailable.

Allowing the enterprise bean to access information about other classes and to access the classes in a manner that is normally disallowed by the Java programming language could compromise security

• The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.

These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container’s ability to properly manage the runtime environment.

• The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.

These networking functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container’s ability to properly manage the runtime environment.

• The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment.

• The enterprise bean must not attempt to directly read or write a file descriptor.

Allowing the enterprise bean to read and write file descriptors directly could compromise security.

• The enterprise bean must not attempt to obtain the security policy information for a particular code source.

Allowing the enterprise bean to access the security policy information would create a security hole.

• The enterprise bean must not attempt to load a native library. This function is reserved for the EJB container. Allowing the enterprise bean to load native code would create a security hole.

• The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean. This function is reserved for the EJB container. Allowing the enterprise bean to perform this function would create a security hole.

• The enterprise bean must not attempt to define a class in a package. This function is reserved for the EJB container. Allowing the enterprise bean to perform this function would create a security hole.

• The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).

These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security.

• The enterprise bean must not attempt to use the subclass and object substitution features of the Java Serialization Protocol.

Allowing the enterprise bean to use these functions could compromise security.

• The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getBusinessObject, SessionContext. getEJBObject, SessionContext.getEJBLocalObject, EntityContext. getEJBObject, or EntityContext.getEJBLocalObject instead.

To guarantee portability of the enterprise bean’s implementation across all compliant EJB 3.0 containers, the Bean Provider should test the enterprise bean using a container with the security settings defined in Table 24. The tables define the minimal functionality that a compliant EJB container must provide to the enterprise bean instances at runtime.

- EJB 3.0 Core Spec 21.1.2


4. Match the seven EJB roles with the corresponding description of the role's responsibilities.
1. Enterprise Bean Provider
2. Application Assembler
3. Deployer
4. EJB Server Provider
5. EJB Container Provider
6. Persistence Provider
7. System Administrator

For the descriptions refer to the EJB 3.0 Core Specification 2.2.1-2.2.7 and 22

5. Describe the packaging and deployment requirements for enterprise beans.

TODO: see EJB 3.0 Core Spec 19, 20


6. Describe the purposes and uses of annotations and deployment descriptors, including how the two mechanisms interact, how overriding is handled and how these mechanisms function at the class, method, and field levels.

TODO: see EJB 3.0 Simplified Spec 10 and ?



Go to top   Edit this page   More info...   Attach file...
This page last changed on 16-Nov-2006 22:37:12 PST by nycjava.