Programming restrictions on EJB - JavaWorld August 2000
Tutorial Details:
Programming restrictions on EJB
Programming restrictions on EJB
By: By Sanjay Mahapatra
Learn to write reliable and portable EJB 1.1 components
nterprise JavaBeans (EJB) is a specification and architecture for the development and deployment of distributed server-side, transactional, and secure business application components. The EJB architecture is the basis and core of the Java 2 Enterprise Edition (J2EE), which defines an entire standardized application development architecture as well as a deployment environment. In this architecture, application developers focus on encapsulating the business logic and business rules and leave the infrastructural service-related issues or plumbing to the application container and server.
Further, the runtime properties of the application components pertaining to transactions, persistence, security, and so on are customizable in the deployment environment, using the highly flexible declarative approach. The architecture defines a container and server model -- the container is the environment in which application component instances live and execute, while containers are in turn housed within a server. The J2EE platform thus provides a simplified development model, industrial-strength scalability, support for legacy integration, flexible deployment, application server and vendor independence, and generally tends to make proprietary application servers and proprietary distributed object frameworks almost archaic.
EJB roles and responsibilities
The EJB specification defines several standard roles and responsibilities as listed below:
EJB Server provider provides the EJB application server, and it is an expert in distributed transaction management, system services, and so on.
EJB Container provider provides the runtime environment for the EJB components' instances as well as the deployment tools. EJB Server/Container providers are typically OS vendors, database vendors, and application server vendors. The EJB server and EJB container are assumed to be provided by the same vendor because no interfaces between them have been defined in the specification -- both in the current EJB 1.1 (final version) as well as the EJB 2.0 public-draft version, which is currently under review.
Bean provider , or EJB developer, develops EJB components that contain business logic and business functionality. The EJB developer provides for each EJB component: the EJB implementation containing all obligatory component-container contract methods, such as ejbCreate() , ejbRemove() , and so on, as well as the business methods; the Home interface; the Remote interface; and helper classes if necessary. The Home interface provides the signature for the methods that create, remove, and find EJB instances. The Remote interface defines the signatures for the business methods.
Application Assembler takes a set of EJB components developed by the Bean provider and assembles them into a complete J2EE application.
Deployer is an expert in the target production environment in which the application is to be deployed. The deployer installs the application components on the application server and configures their transactional, data persistence, and security aspects. Thus, you can declaratively address and manage complex issues such as transactions, concurrency, persistence, and security.
Systems Administrator is responsible for the server's configuration and administration, runtime monitoring, and load balancing.
Application Client/User Interface developer is responsible for the user interface and presentation logic.
The focus of this article is on the Bean provider/EJB developer and the programming restrictions that apply to the EJB components' implementation code.
Restrictions on EJB components
The EJB developer must not program any systems-level services into the EJB component implementation code. EJB component providers/developers should be aware of and strictly follow certain restrictions in the interest of developing reliable and portable EJB components.
The following is a list of Java features that you should avoid , hence restricting their use in your EJB components' implementation code:
Using static , non final fields. Declaring all static fields in the EJB component as final is recommended. That ensures consistent runtime semantics so that EJB containers have the flexibility to distribute instances across multiple JVMs.
Using thread synchronization primitives to synchronize multiple instance execution. By avoiding that feature, you allow the EJB container flexibility to distribute instances across multiple JVMs.
Using AWT functionality for keyboard input/display output. That restriction exists because server-side business components are meant to provide business functionality that excludes user interface and keyboard I/O functionality.
Using file access/java.io operations. EJB business components are meant to use resource managers such as JDBC to store and retrieve application data rather than the file system APIs. Also, deployment tools provide the facility for storing environment entry elements (env-entry) into the deployment descriptor, so that EJB components can perform environment entry lookups in a standardized manner via the environment-naming context. Thus, the need to use file system-based property files is mostly eliminated.
Listening to or accepting socket connections, or using a socket for multicast. EJB components are not meant to provide network socket server functionality; however, the architecture lets EJB components act as a socket client or RMI clients and thus communicate with code outside the container's managed environment.
Using the Reflection API to query classes that are not otherwise accessible to the EJB component due to Java's security rules. That restriction enforces Java platform security.
Attempting to create or obtain a class loader, set or create a new security manager, stop the JVM, change the input, output, and error streams. That restriction enforces security and maintains the EJB container's ability to manage the runtime environment.
Setting the socket factory used by the URL's ServerSocket, Socket, or stream handler. By avoiding that feature, you also enforce security and maintain the EJB container's ability to manage the runtime environment.
Starting, stopping, or managing threads in any way . That restriction eliminates the possibility of conflicts with the EJB container's responsibilities of managing locking, threading, and concurrency issues.
By restricting your use of features 10-16, you aim to plug potential security holes:
Reading or writing a file descriptor directly.
Obtaining security policy information for a particular code source.
Loading native libraries.
Accessing packages and classes that the usual rules of Java make unavailable.
Defining a class in a package.
Accessing or modifying security configuration objects ( Policy , Security , Provider , Signer , and Identity ).
Using the subclass and object substitution features of the Java Serialization protocol.
Passing the this reference as an argument or returning the this reference as a result. Instead, you must use the result of the getEJBObject() available in SessionContext or EntityContext .
Java 2 Platform Security policy
The restricted features listed above are, in fact, standard and powerful features of the Java programming language and the Java 2 Standard Edition (J2SE). The EJB container is allowed to make some or all of the restricted features from the J2SE unavailable to the EJB components -- by using the J2SE security mechanism rather than by subsetting the J2SE API set.
The Java 2 Platform Security policy for the standard EJB container of the EJB 1.1 specification defines the security permission sets that concur with the programming restrictions on EJB components. According to the policy, several permissions such as java.io.FilePermission , java.net.NetPermission , java.io.reflect.ReflectPermission , and java.lang.security.SecurityPermission are denied in order to enforce the programming restrictions listed earlier.
Some EJB containers may not enforce the restrictions with the expectation that the EJB developer will either adhere to the programming restrictions or violate them at his or her own risk. EJB components that violate those restrictions, by relying on fewer or more permissions than the standard set, will at the very least not be portable across EJB containers. In addition, indeterminate and unpredictable runtime problems could lie hidden in the code. That's all the more reason for EJB component developers to be aware of those programming restrictions and take special care to adhere to them.
Any violations of those programming restrictions within the EJB implementation code will not be detected at the time of compilation since those features are, after all, an integral part of the Java language and J2SE.
Those restrictions apply to EJB components as well as helper/access classes used by the EJB components. J2EE applications are packaged using the Java Archive (jar) file format into a file with an .ear extension (ear stands for Enterprise Archive). The ear file is the standard file format for delivering an application to the deployer. The ear file consists of EJB components in one or more ejb-jar files, and possibly library jar files on which the ejb-jars may depend. All code in that ear file is considered application code and is subject to the programming restrictions and permission sets.
A future version of the specifications might mandate the ability/facility to customize the security permissions via the deployment tools. That way specific permissions may be granted to a component based on merit and requirements in a standardized way such as permission to read a file in the file system. Some EJB container/server products may currently provide, within their deployment tools, the facility to grant fewer or more permissions with respect to the stan
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Programming restrictions on EJB - JavaWorld August 2000
View Tutorial: Programming restrictions on EJB - JavaWorld August 2000
Related
Tutorials:
 Explore the
Dynamic Proxy API
Explore the
Dynamic Proxy API
|
Integrate security infrastructures with JBossSX
Integrate security infrastructures with JBossSX
|
Java security evolution
and concepts, Part 5
Java security evolution
and concepts, Part 5
|
Integrate EJBs with CORBA
Integrate EJBs with CORBA
|
Container-managed relations for the
21st century
Container-managed relations for the
21st century
|
Sun boosts
Sun boosts enterprise Java
|
Jini Starter Kit 2.0 tightens Jini's security framework
Jini Starter Kit 2.0 tightens Jini's security framework
|
Add concurrent processing with message-driven beans
Add concurrent processing with message-driven beans
|
Smartly load your
properties
Smartly load your
properties
|
Good
ideas
Good
ideas
|
Object-relation mapping without the container
If you follow the latest developer buzz then you\\\\\'ve likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming).
|
Declarative Programming in Java
Declarative Programming in Java
What makes EJB components special is the declarative programming model through which we can specify the services such as security, persistence, transaction etc., that the container should provide. An EJB only implements
|
Turn EJB components into Web services
Summary
Web services have become the de facto standard for communication among applications. J2EE 1.4 allows stateless Enterprise JavaBeans (EJB) components to be exposed as Web services via a JAX-RPC (Java API for XML Remote Procedure Call) endpoint, al
|
Aspect-Oriented Annotations
Aspect-Oriented Annotations
Annotations are one of the new language features in J2SE 5.0, and allow you to attach metadata onto any Java construct. Meanwhile, Aspect-Oriented Programming (AOP) is a fairly new technology that makes it easier for you to en
|
The power of table-oriented programming
The power of table-oriented programming
When object-oriented programming languages began to be used in enterprise applications, designers had problems fitting the object-oriented model with the relational model. In the object-oriented model, data is enca
|
An Introduction to Java Object Persistence with EJB
The 'impedance mismatch' between relational databases' tabular orientation and object-oriented Java's hierarchical one is a perennial problem for which the Java world has several good solution offerings. This article, the first in a three-part series, wil
|
Understanding MIDP System Threads
Describes the multi-threaded aspects of the J2ME application environment. Understanding the interactions between systems threads, user-interface and application threads will help in avoiding MIDlet deadlock.
|
Introduction To Enterprise Java Bean(EJB). WebLogic 6.0 Tutorial.
Introduction To Enterprise Java Bean(EJB). WebLogic 6.0 Tutorial.
Welcome to EJB Section
(Learn to Develop World Class Applications with Enterprise Java Beans)
(Online WebLogic 6.0 Tutorial)
Introduction To Enterprise Java Bean(EJB)
Enterprise
|
developing a Session Bean and a Servlet and deploy the web application on
JBoss 3.0
developing a Session Bean and a Servlet and deploy the web application on JBoss 3.0
Writing Stateless Session Bean and Calling through Servlet
Previous Tutorial Index Next
In this lesson I will show you how to develop a Stateless Session Bean and
|
New Technical Articles: 64-bit Programming on Solaris 10 OS for x86 Platforms
Four technical articles describe the new Sun Studio 10 software's 64-bit programming features on the Solaris 10 OS for x86 and AMD64 platforms. Important issues regarding the AMD64 ABI (Application Binary Interface), debugging, migration to 64-bits, and p
|
|
|
|
