Deployment descriptors are the recommended place for declaring component environment. The component can use some other mechanism to specify or lookup its environmental attributes. Keeping them in DDs makes it easier for assembler/deployer to change env properties without the need to modify the code.

The application component's naming environment is available at "java:comp/env". This is the root of the naming environment tree.for EJB references recommended context is java:comp/env/ejb i.e. references should be named as ejb/Ejb1 ...Environment is specified as env-entry, ejb-ref, resource-ref, message-destination-ref as the case may be.

3/22/2005

JCA is an architecture for integrating J2EE servers with EISs.EISs are accessible thru adapters that they provide. This is similar to drivers e.g. Oracle JDBC driver for accessing oracle database. These adapters are known as resource adapters in JCA parlance. JCA defines contracts that exists between J2EE server and these resource adapters. JCA contract ensures that a resource adapter would be pluggable in any J2EE server. JCA also specifies how these resource adapters are to be packaged and deployed (rar file). Actual implementation classes for the contract are specified in the deployment descriptor.

"An application server vendor extends its system only once to support the connector architecture and is then assured of connectivity to multiple EISs. Likewise, an EIS vendor provides one standard resource adapter and it has the capability to plug in to any application server that supports the connector architecture."

To be more precise, JCA SPI is the contract between the Server and the Resource Adapter. JCA CCI is the contract between the Application and the Resource Adapter. SPI allows Server to manage Connections, Transactions and Security. CCI allows application to connect and fetch records from underlying EIS in a platform independent way. However, Resource Adapter providers are not required to satisfy CCI. They must comply with SPI.Moreover, CCI is not targeted towards Application, it is meant for use by EAI tools as it ensures seamless integration of different EISs. The CCI would be typically used in non-managed scenario where there in no Server and client has to manage everything.

Sun has just released a JCA Connector for JDBC drivers. This connector can plug any JDBC driver and then can be used as a JCA compliant resource adapter in any J2EE server.

"Many of the APIs that make up the J2EE platform include an SPI layer that allows service providers or other system level components to be plugged in. This specification does not describe the execution environment for all such service providers, nor the packaging and deployment requirements for all service providers. However, the J2EE Connector Architecture does define the requirements for certain types of service providers called resource adapters. Future versions of this specification will more fully define the J2EE SPI."

3/19/2005

'final' is used for defining constants. Constants always have pre-determined specific values. No point in having a constant with a default value which you do not know unless you open language manuals. So we agree that a final variable(so to say) must be explicitly initialized.This is in contrast with non-final member variables where explicit initialization is not required. Don't forget that a variable must be initialized before use. Non final member variables are by default initialized. Local varibales are not default-initialized.

So we have to find a way to ensure that our final varibales are always explicitly initialized before use.

Instance final variables -This can be done in constructors, instance blocks or inline. This ensures that the variable always initailized before use.

Class final variables -These are not owned by instances. So there is no way you can ensure that these are initialized before use except it initializing it inline or thru static block.

Local final variables -Only one way, assign a value before use. Not very different from non-final local variables except that the former is a constant.

J2EE defines standards for developing, building and deploying multitiered enterprise applications. The runtime environment of J2EE applications are provided by Containers which is typically a part of the J2EE server where the application is deployed. J2EE also defines what services the container must support for the application to make use of. J2EE is thus a specification for both container and the application.

The runtime environment provided by containers includes JRE for the J2SE that the J2EE container/server supports.

The J2EE specification describes a minimum set of facilities that all J2EE products (servers) must provide. Most J2EE 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 J2SE on extensions to Java APIs. A J2EE product may not add classes to the Java programming language packages included in this specification, and may not add methods or otherwise alter the signatures of the specified classes.However, many other extensions are allowed. A J2EE product may provide additional Java APIs, either other Java optional packages or other (appropriately named) packages. A J2EE product may include support for additional protocols or services not specified here. A J2EE product may support applications written in other languages, or may support connectivity to other platforms or applications. In short, if the application doesn't depend on extensions provided by a J2EE server, it would be deployable (as per specification) in any other J2EE compliant server. On the other hand, J2EE servers must pass the Compatibility Test Suite to be labelled J2EE compliant.

The J2EE API specifications define the contract between the J2EE application components and the J2EE platform. The contract specifies both the runtime and deployment interfaces.

The J2EE Service Provider Interfaces (SPIs) API specifications define the contract between the J2EE platform and service providers that may be plugged into a J2EE product. The Connector APIs define service provider interfaces for integrating resource adapters with a J2EE application server. Resource adapter components implementing the Connector APIs are called Connectors. The J2EE Authorization APIs define service provider interfaces for integrating security authorization mechanisms with a J2EE application server.

Java 2 Platform, Standard Edition (J2SE) platform for applications development on desktops and servers. It also serves as the foundation for J2EE and JWS.

J2SE consists of the J2SE class library, JVM (platform specific byte code interpretor), and other development tools and APIs (which are shipped with JDK).

The J2SE application programming interface (API) defines the prescribed manner by which an applet or application can make requests to and use the functionality available in the compiled J2SE class libraries

The JRE provides the Java APIs, Java virtual machine, and other components necessary to run applets and applications written in the Java programming language. And this JRE is also the foundation of the J2EE runtime environment.