What are EJB’s

Enterprise beans are Java EE components that implement Enterprise JavaBeans (EJB) technology. Enterprise beans run in the EJB container, a runtime environment within the Application Server.
An EJB is essentially a managed component that is created, controlled, and destroyed by the JEE container in which it lives. This control allows the container to control the number of EJBs currently in existence and the resources they are using, such as memory and database connections. Each container will maintain a pool of EJB instances that are ready to be assigned to a client.

When a client no longer needs an EJB, the EJB instance will be returned to the pool and all of its resources will be released. At times of heavy load, even EJB instances that are still in use by clients will be returned to the pool so they can service other clients. When the original client makes another request of its EJB, the container will reconstitute the original EJB instance to service the request. This pooling and recycling of EJB instances means that a few EJB instances, and the resources they use, can be shared between many clients.This maximizes the scalability of the EJB-based application.

There are two different types of EJB that are suited to different purposes:

• Session EJB—A Session EJB is useful for mapping business process flow (or equivalent application concepts). There are two sub-types of Session EJB — stateless and stateful. Session EJBs commonly represent “pure” functionality that is created as it is needed.

• Message-driven EJB—A Message-driven EJB is very similar in concept to a Session EJB, but is only activated when an asynchronous message arrives.

As an application designer, you should choose the most appropriate type of EJB based on the task to be accomplished.
Entity EJB are not part of EJB 3.0 but now are part of JP (Java Persistence) API

Common Uses of EJB’s

So, given all of this, where would you commonly encounter EJBs and in what roles? Well, the following are some examples:

• In a Web-centric application, the EJBs will provide the business logic that sits behind the Web-oriented components, such as servlets and JSPs. If a Web-oriented application requires a high level of scalability or maintainability, use of EJBs can help to deliver this.

• Thick client applications, such as Swing applications, will use EJBs in a similar way to Web-centric applications. To share business logic in a natural way between different types of client applications, EJBs can be used to house that business logic.

• Business-to-business (B2B) e-commerce applications can also take advantage of EJBs. Because B2B e-commerce frequently revolves around the integration of business processes, EJBs provide an ideal place to house the business process logic. They can also provide a link between the Web technologies frequently used to deliver B2B and the business systems behind.

• Enterprise Application Integration (EAI) applications can incorporate EJBs to house processing and mapping between different applications. Again, this is an encapsulation of the business logic that is needed when transferring data between applications (in this case, in-house applications).

When to use Enterprise Beans

You should consider using enterprise beans if your application has any of the following requirements:

• The application must be scalable. To accommodate a growing number of users, you may need to distribute an application’s components across multiple machines. Not only can the enterprise beans of an application run on different machines, but also their location will remain transparent to the clients.

• Transactions must ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.

• The application will have a variety of clients. With only a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.

Entity Beans

Starting from JEE5 the entity beans have been replaced by Java Persistence API entities. The entities are used to view in an object oriented way o persistent store. In the real world the persistent stores are always relational databases. Typically an entity represents a table in a relational database, and each entity instance corresponds to a row in that table.

Advantages:

• It can run outside of a JEE container.

• Offers a object oriented view of a data base.

• Declaratively transactional support (only if the entity is managed by a Java EE compliant container) Verify This !
  

• Declaratively security support (only if the entity is managed by a Java EE compliant container) Verify This !
  

• Transaction aware (only if the entity is managed by a Java EE compliant container) Verify This !
  

Disadvantages: Dig on this !

Stateless Session Beans

A session bean represents a single client inside the Application Server. To access an application that is deployed on the server, the client invokes the session bean’s methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server.

As its name suggests, a session bean is similar to an interactive session. A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) When the client terminates, its session bean appears to terminate and is no longer associated with the client.
A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client, but only for the duration of the invocation.

The life cycle of a stateless session bean

Advantages:

• Scalability because stateless session beans can support multiple clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients. The instances can be pooled by the container.

• A stateless session bean can implement a web service, but other types of enterprise beans cannot.

• Declaratively transactional support

• Declaratively security support

• Portability

• Transaction aware

Disadvantages:

• Need a JEE container to be executed (the Entity beans can be executed outside a JEE container). Find better than this !

Stateful Session Beans

The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.

The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears.

The life cycle of a stateful session bean

Advantages:

• Declaratively transactional support

• Declaratively security support

• Portability

• Transaction aware

Disadvantages:

• Need a JEE container to be executed (the Entity beans can be executed outside a JEE container) Find better than this !

Message Driven Beans

A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. It normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events. The messages can be sent by any Java EE component (an application client, another enterprise bean, or a web component) or by a JMS application or system that does not use Java EE technology. Message-driven beans can process JMS messages or other kinds of messages.

The Life Cycle of a Message-Driven Bean

Advantages:

• Scalabity; A message-driven bean’s instances retain no data or conversational state for a specific client. The instances can be pooled by the container.

• Simplicity; Unlike a session bean, a message-driven bean has only a bean class.

• Loose coupling between the client and the server; The client have no direct reference to the MDB

• Declaratively transactional support

• Declaratively security support

• Portability

• Transaction aware

• Firewall issues; in some organizations the ports used by JMS can be closed.

• Need a JEE container to be executed (the Entity beans can be executed outside a JEE container). Find better than this !

Bibliography:

The Java EE 5 Tutorial


Introduction to EJBs

Java Security Architecture

Main Concepts :

• Protection Domain ( java.security.ProtectionDomain )

A fundamental concept and important building block of system security is the protection domain . A domain can be scoped by the set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which permissions are granted.

The protection domain concept serves as a convenient mechanism for grouping and isolation between units of protection. For example, it is possible (but not yet provided as a built-in feature) to separate protection domains from interacting with each other so that any permitted interaction must be either through trusted system code or explicitly allowed by the domains concerned.

Protection domains generally fall into two distinct categories: system domain and application domain.
It is important that all protected external resources, such as the file system, the networking facility, and the screen and keyboard, be accessible only via system domains.

A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Protection domains are determined by the policy currently in effect. The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions, as illustrated by the figure below.

• Permissions ( java.security.Permission )

The permission classes represent access to system resources. In essence, permissions determine whether access to a resource of the JVM is granted or denied. The java.security.Permission class is an abstract class and is subclassed, as appropriate, to represent specific accesses.

An applet or an application using a security manager can obtain access to a system resource only if it has permission.

Commonly used permissions :

1. java.security.Permission This abstract class is the ancestor of all permissions. It defines the essential functionalities required for all permissions.
2. java.security.BasicPermission The BasicPermission class extends the Permission class. It can be used as the base class for permissions that want to follow the same naming convention as BasicPermission.
3. java.security.Permissions This class is designed to hold a heterogeneous collection of permissions. Basically, it is a collection of java.security.PermissionCollection objects.
4. java.io.FilePermission
5. java.net.SocketPermission This class represents access to a network via sockets.
6. java.util.PropertyPermission
7. java.lang.RuntimePermission
8. java.awt.AWTPermission

• Policy (java.security.Policy)

The Java 2 security policy defines the protection domains for all running Java code with access privileges and a set of permissions such as read and write access or making a connection to a host.

The system security policy for a Java application environment, specifying which permissions are available for code from various sources, is represented by a Policy object. More specifically, it is represented by a Policy subclass providing an implementation of the abstract methods in the Policy class.

In order for an applet (or an application running under a SecurityManager) to be allowed to perform secured actions, such as reading or writing a file, the applet (or application) must be granted permission for that particular action.

In the Policy reference implementation, the policy can be specified within one or more policy configuration files. The configuration files indicate what permissions are allowed for code from specified code sources. Each configuration file must be encoded in UTF-8.

A user or an administrator externally configures the policy file for a J2SE runtime environment using an ASCII text file or a serialized binary file representing a Policy class. In a J2SE environment, the default system-wide security policy file java.policy is located at <JRE_HOME>/lib/security/ directory. The policy file location is defined in the security properties file with a java.security setting, which is located at <JRE_HOME>/lib/security/java.security.

Examples of policies :

The following policy grants permission a.b.Foo to code signed by Roland:

grant signedBy "Roland" {
permission a.b.Foo;
};

The following grants a FilePermission to all code (regardless of the signer and/or codeBase):

grant {
permission java.io.FilePermission ".tmp", "read";
};

The following grants two permissions to code that is signed by both Li and Roland:

grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.util.PropertyPermission "user.*";
};

The following grants two permissions to code that is signed by Li and that comes from http://java.sun.com:

grant codeBase "http://java.sun.com/*", signedBy "Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission java.io.SocketPermission "*", "connect";
};

The following grants two permissions to code that is signed by both Li and Roland, and only if the bytecodes implementing com.abc.TVPermission are genuinely signed by Li.

grant signedBy "Roland,Li" {
permission java.io.FilePermission "/tmp/*", "read";
permission com.abc.TVPermission "channel-5", "watch",
signedBy "Li";
};

• Access Controller (java.security.AccessController)

The AccessController class is used for three purposes :

1. to decide whether an access to a critical system resource is to be allowed or denied, based on the security policy currently in effect,
2. to mark code as being “privileged”, thus affecting subsequent access determinations.
3. to obtain a “snapshot” of the current calling context so access-control decisions from a different context can be made with respect to the saved context.

• SecurityManager ( java.lang.SecurityManager )

Each Java application can have its own security manager that acts as its primary security guard against malicious attacks. The security manager enforces the required security policy of an application by performing runtime checks and authorizing access, thereby protecting resources from malicious operations.
Under the hood, it uses the Java security policy file to decide which set of permissions are granted to the classes. However, when untrusted classes and third-party applications use the JVM, the Java security manager applies the security policy associated with the JVM to identify malicious operations. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. In cases where the SecurityManager detects a security policy violation, the JVM will throw an AccessControlException or a SecurityException.

In a Java application, the security manager is set by the setSecurityManager method in class System. And the current security manager is obtained via the getSecurityManager method.

If you wish to have your applications use a SecurityManager and security policy, start up the JVM with the -Djava.security.manager option and you can also specify a security policy file using the policies in the -Djava.security.policy option as JVM arguments. If you enable the Java Security Manager in your application but do not specify a security policy file, then the Java Security Manager uses the default security policies defined in the java.policy file in the $JAVA_HOME/jre/lib/security directory.

• SecurityManager versus AccessController

To understand the relationship between SecurityManager and AccessController, it is sufficient to note that SecurityManager represents the concept of a central point of access control, while AccessController implements a particular access control algorithm, with special features such as the doPrivileged method. By keeping SecurityManager up to date, we maintain backward compatibility (e.g., for those applications that have written their own security manager classes based on earlier versions of the JDK) and flexibility (e.g., for someone wanting to customize the security model to implement mandatory access control or multilevel security). By providing AccessController, we build in the algorithm that we believe is the most restrictive and that relieves the typical programmer from the burden of having to write extensive security code in most scenarios.

We encourage the use of AccessController in application code, while customization of a security manager (via subclassing) should be the last resort and should be done with extreme care. Moreover, a customized security manager, such as one that always checks the time of the day before invoking standard security checks, could and should utilize the algorithm provided by AccessController whenever appropriate.

Java Applet Security

Currently, all Java 2 SDK system code invokes SecurityManager methods to check the policy currently in effect and perform access control checks. There is typically a security manager (SecurityManager implementation) installed whenever an applet is running; the appletviewer and most browsers, including those from Netscape and Microsoft, install a security manager.

A security manager is not automatically installed when an application is running. To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java Virtual Machine with the new “-Djava.security.manager” command-line argument (which sets the value of the java.security.manager property), as in

java -Djava.security.manager SomeApp

or the application itself must call the setSecurityManager method in the java.lang.System class to install a security manager.

It is possible to specify on the command line a particular security manager to be utilized, by following “-Djava.security.manager” with an equals and the name of the class to be used as the security manager, as in

java -Djava.security.manager=COM.abc.MySecMgr SomeApp

Trusted applets

An applet can be considered trusted, based on the following factors:

1. Applets installed on a local filesystem or executed on a localhost.
2. Signed applets provide a way to verify that the applet is downloaded from a reliable source and can be trusted to run with the permissions granted in the policy file.

The Java 2 platform requires an executable applet class to be packaged into a JAR file before it is signed. The JAR file is signed using the private key of the applet creator. The signature is verified using its public key by the client user of the JAR file. The public key certificate is sent along with the JAR file to any client recipients who will use the applet. The client who receives the certificate uses it to authenticate the signature on the JAR file. To sign the applet, we need to obtain a certificate that is capable of code signing. For all production purposes, you must always obtain a certificate from a CA such as VeriSign, Thawte, or some other CA.

A trusted applet is executed as a normal application (it follows the policy file).

Untrusted applets

Here is a list of the security restrictions that Java 2 technology environments normally impose on applets running in a browser:
1. An applet can utilize only its own code and is not allowed to load libraries or define native methods.
2. An applet cannot read or write files on the host that is executing it.
3. An applet can make network connections only to the host from which it was downloaded.
4. An applet cannot start any program on the local host.
5. An applet is restricted from reading the following system properties: java.home, java.classpath, user.name, user.dir, user.home

Java WebStart Security

When you launch one of the applications shown in the Java WebStart desktop, the classes needed to run that application are downloaded from the Web server.
This behavior is similar to that of an applet. However, once downloaded, the classes are stored locally. This allows for a faster startup on subsequent uses of the application. Better yet, each time you try to run that application, the system checks to see if any updates are available
on the Web server, and if any updates exist, just the needed changes are downloaded. This ensures that the application is always ready to run, even if your computer is not connected to the network, while also ensuring that the most up-to-date version possible is used. All this occurs with no need for an installation phase.

JWS also allows defining security attributes for client-side Java applications and their access to local resources, such as file system access, making network connections, and so on. These security attributes are specified using XML tags in the JNLP descriptor file.

The JNLP descriptor defines the application access privileges to the local and network resources. In addition, JWS allows the use of digital signatures for signing JAR files in order to verify the application origin and its integrity so that it can be trusted before it is downloaded to a client machine. The certificate used to sign the JAR files is verified using the trusted certificates in the client keystore. This helps users avoid starting malicious applications and inadvertent downloads without knowing the originating source of the application.

When running an application that requests unrestricted access to the local machine, the user will be initially presented with a dialog that explains the origin of the application or vendor and allows the user to grant additional privileges to the application. Furthermore, when an application requires the use of a local machine’s resources and does not have a signed JAR file, Java Web Start will allow the user to explicitly grant the application the access via a Security Advisory dialog. For example, if a client Java application needed to be able to paste information into the Windows OS clipboard facility, a dialog box similar to the one shown in the next figure would appear.

Security Advisory dialog for application attempting to access the clipboard

Additional dialog windows will appear when an application attempts to access the local resources of a client machine, such as the filesystem, as displayed in the next figure.

Security Advisory dialog for application attempting to access the filesystem

Users can grant applications access to the local machine in the following areas:

1. Storing the current state of the application on the local machine
2. Viewing the contents of local files
3. Saving files to the local machine
4. Opening files to the local machine
5. Reading/writing to random access files on the local machine
6. Printing from the local machine

JNPL file

The root element is tagged as <jnlp>, which contains the four core sub-elements: information, security, resources, and application-desc.

To enforce security, the <security> element is used to specify the required permissions. The security element provides two permission options: <all-permissions/> to provide an application with full access to the client’s local computing resources, and <j2ee-application-client-permissions/> to provide a selected set of permissions that includes socket permissions, clipboard access permission, printing permission, and so forth. Example 3-19 is a JNLP file that shows putting all the elements including a <security> element setting with all permissions.
Example of JNLP file showing <security> elements

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="file:///c:/testarea/jnlp/">
<information>
<title>My Signed Jar</title>
<vendor>Core Security Patterns</vendor>
<homepage href="http://www.sec-patterns.com/signed" />
<description>Java Web start example</description>
</information>
<offline-allowed/>
<security>
<all-permission/>
</security>
<resources>
<j2se version="1.2+" />
<jar href="SignedClientApp.jar"/>
</resources>
<application-desc main-class="SignedClientApp" />
</jnlp

Bibliography:

Mikalai Zaikin SCEA 5 study guide
Java Web Start
Java Security Management Tools
JavaTM Web Start version 1.5.0 – Frequently Asked Questions (FAQ)
Java^TM 2 Platform Security Architecture (V 1.2)

Lately I decided to pass the SCEA 5 certification. This post will only enumerate the books and articles that I will use for passing the first examen (CX-310-052).

• Books

Sun Certified Enterprise Architecture for J2EE Technology Study Guide (Sun Microsystems Press)

(this can help for the section 1, 7 and 8 )

Sun Certified Enterprise Architect for J2EE Study Guide

(this can help for the section 1, 7 and 8 )

(Update 20-09-09) Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition; It’s in the “Rough Cuts” section, so it’s not quite ready (you can follow the blog of one of the authors to have updated information: http://humphreysheil.blogspot.com/)

• Articles

Choosing among JCA, JMS, and Web services for EAI (this can help on section 3 )

JSF for nonbelievers: Clearing the FUD about JSF (this can help on section 5 )

• Sites

SCEA 5 study guide by Mikalai Zaikin (covers section 1, 2, 7 and 8 )

Sun’s Java EE 5 Tutorial (i think that it covers all the sections beside the section 7 concerning patters)

For instance this is all i have, but I will update the blog if i find another sources.