The purpose of this article is to provide an introduction to and overview of the Java 2 Platform, Enterprise Edition (J2EE). It's important for you to realize that J2EE is a standard for developing enterprise application, not a product. So long as both sides obey the J2EE contracts, applications can be deployed in a variety of container environments. The J2EE goal is to give customers choice of vendor products and tools, and to encourage best products to emerge through competition. The only way this would ever happen is if the industry as a whole were bought-into J2EE.
The foundation for J2EE is Java.
The J2EE architecture is based on the Java. What's exciting about Java is that it enables organizations to write their code once, and deploy it in any Java-compliant platform. A feature of all Java applications is their independence from the underlying operating. This platform independence is achieved by executing the code in a virtual machine, known as the Java Virtual Machine (JVM), which abstracts the code from the operating system.
J2EE is a Java application. Your J2EE components are transformed into bytecode and executed by a JRE (Java Runtime Environment) at runtime consuming services from the runtime such as garbage collector and language independence. Even the containers are typically written in Java, that is, the runtime environments that provide qualities of services necessary for enterprise applications to the J2EE components that are hosted in, such as transactions, security, object pooling, naming services and persistence services.
The J2EE programming model defines containers and components that executes inside containers consuming its services. The Java 2 Enterprise Edition application server facilitates development of distributed applications by providing a number of containers that provide services to the applications deployed within them. The type of services provided to the application by the container include security, transactions, object pooling and naming services. The availability of such services enables the application developer to focus on implementing business and presentation logic.
These are the containers specified in the J2EE programming model:
- Client container: The client container is installed separately on the client and manages the runtime environment for fat client applications. J2EE application client containers provide standard services to the client application, including remote object discovery and remote method invocation, thus allowing the application client to access business logic on server side components such as EJBs, and also providing access to other resources.
- Applets: These components are lightweight client components that execute in the container with restricted access to system resources. Typically in a Web browser or handheld device.
- Web container: It provides services to the web components (Java Server Pages and Java servlets). The provided services are: a transport mechanism between the Web server and the web container, receive requests and send responses to web applications, session management and virtual hosting mechanism.
- EJB container: The EJB container is responsible for managing the life cycle of the Enterprise Java Beans deployed within it and providing threading and transaction support to them. The container also provides a caching mechanism to optimize access to EJBs. Enterprise Java Beans (EJB) are server side components that execute in the EJB container of an application server. Their purpose is to implement business logic and model business data.
- Web Services container: The Web Services container is responsible for components that comprise standards such as Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Universal Description. Discovery and Integration (UDDI), Web Services Invocation Framework (WSIF), Web Services Inspection Language, Web Services security, Workflows and business processes, Web Services gateway, Java API for XML-based Remote Procedure Calls (JAX-RPC), JSR-109, which standardizes how Web Services are deployed into a J2EE container and XML technologies.
- Java Connector Architecture (JCA) container: The JCA container provides a pluggable and configurable bridging mechanism for J2EE applications to access Enterprise Information Systems.
Web Services standards are still evolving within J2EE and are currently being integrated into the specification. However, the importance of Web Services as an integration technology has not been overlooked by J2EE vendors and many, including IBM and J2EE with Sun ONE, provide varying levels of support for the standards.
Java Technologies and Web Services is organized into Java Web Services Developer Pack, Java API for XML-Based RPC, Java API for XML Registries, Java API for XML Processing, Java Architecture for XML Binding, SOAP with attachments API for Java, XML and Web Services Security.
Nowadays there are many proprietary solutions such as Apache SOAP, IBM Web Services Toolkit, GLUE from "The Electric Mind" and JAXM from Sun.
In J2EE, the Component Model is Enterprise Java Beans specification. EJB are components that allow applications to communicate across multi-tier client and server environments. The EJB comes into play when there is a need for distributed objects to communicate each other across either the client-server barrier or the server-server barrier.
The EJB component model enables the application developer to work on business aspects of the solution without having to focus on transaction management, security, persistence of data or the life cycle management of the object itself. These features are part of the Application Server.
There are three type of EJB:
- Entity Beans for accessing and persisting application data.
- Session Beans for managing application session (statefull or stateless).
- Message-Driven Beans for handling asynchronous messages received from JMS message queue.
The Java Virtual Machine allows an application to have multiple threads of execution running concurrently. Every thread has a priority. Threads with high priority are executed in preference to threads in lower priority.
There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated and started. The other way to create a thread is to declare a class that implements the Runnable interface. That class then implements the run method. An instance of the class can then be allocated, passed as an argument when creating Thread, and started.
The thread synchronization and communication is done using the integrated key work synchronized and mechanisms such as wait and notify. That is when one thread needs to consume some services from other service which is busy, the former calls wait() until the latter is free which then calls notifiy() to wake up one of the waiting threads.
If you want a task to be run at some time in the future or repeatedly at regular intervals, you can schedule it with the java.util.Timer class. This is more efficient than spawning separate sleeping threads yourself. Timer uses one Thread to track the entire schedule.
Objects which need to be thread-safe, which preserve their state consistently, must use the synchronized key word in the operations invoked in a thread environment.
Accesing Directory Services.
In Java you can use JNDI to encapsulate retrieval of business objects. JNDI, the Java Naming and Directory Interface, simplifies the process of acquiring any named resource, regardless of its backing store such as RMI Registry, Corba Naming Service, File System, Directory Services, and whatever and enables to Java to take advantage of information in a variety of existing naming and directory services such as LDAP,NDS, DNS and NIS. This is very important in networks because allows to share variety of information about users, machines, networks, services, and applications. JNDI provides methods for performing standard directories operations, such as associating attributes to objects and searching for objects using these attributes.
Sharing classes in Java.
Applications may need to refer to or share other classes or JAR files. In Java, you do this using an environment variable named CLASSPATH. The default class path is the current directory. You can set the CLASSPATH environment variable to one or more different directories.
The Java 2 Enterprise Edition defines a standard model for packaging and deploying enterprise applications. Java components are assembled into modules, which may then be deployed into a J2EE application server. The modules may also be packaged into an enterprise application module, allowing the entire application to be deployed as a single unit. Each module also includes a deployment descriptor; the purpose of this XML file is to describe to the runtime container how the module should be deployed. For example, in the case of Enterprise Java Bean Module: it contains the deployed Enterprise Java Beans and the client side stubs required for remote method invocation and an EJB deployment descriptor. The EJB module is deployed as a Java archive (.jar) file. In the case of Web Module: it contains Java Server Pages, Java Servlets, Struct class, HTML pages and images. The module also includes the Web deployment descriptor, and is assembled as a Web archive (.war) file. In the case of Application Client Module: it contains the fat clients that interact with J2EE server applications. They are packaged as application client modules using the Java archive (.jar) file format. In the case of Resource Adapter Module: it contains the system-level software driver that enables a J2EE application to connect to Enterprise Information Systems (EIS). The resource adapter module contains the Java classes and native libraries required to implement a Java Connector Architecture (JCA) resource adapter to an EIS. The module is assembled as a Resource adapter archive (.rar) file. As with all other module types, the resource adapter module also incorporates a deployment descriptor.
Control over the evolution of the Java 2 Enterprise Edition and other Java technologies is retained by the Java Community Process (JCP). This is an open organization whose members' prime responsibility is to guide the development and approval of Java technical specifications. Sun collaborated with other vendors of e-Business platforms, such as BEA, IBM, and Oracle, in defining J2EE with the initiative named Java Community Process (JCP) to solicit new ideas to improve J2EE over time. The Java Community Process also considers submissions for enhancements to the Java technologies from non-members.
Microsoft.NET is product suite that enables organizations to build smart, enterprise applications.
Microsoft .NET is built upon the underlying operating system and products which made up DNA, including the Windows Operating System and COM+. The OS and COM+ environments have been significantly enhanced and extended to support the new features which have been added on top.
The key values .NET itself provides are as follows:
- Encapsulates the Windows operating system and its Quality of Service mechanisms within industry standard protocols such as those involved in Web Services and Web applications.
- Provides a runtime environment for application software with services like garbage collection, exception management and namespace support.
- Provides enhanced programming language independence and a new programming language - C#.
- Provides a rich Framework of pre-built classes that perform functions many applications need.
The Common Language Runtime as the foundation of Microsoft.NET.
The Common Language Runtime (CLR) is the heart of the .NET Framework and provides a runtime environment for .NET applications. The CLR is similar in function to the Java Virtual Machine (JVM) and provides a fundamental set of services that all programs can use. The Java bytecode can be interpreted as well as compiled, and it is the only language that the JVM runs. The Common Language Runtime has ability to compile managed code once and run on any CPU and operating system that supports the runtime. The CLR runs Intermediate Language, which is created from any .NET programming language, such as C#.
In the .NET Framework, managed code is the code which follows the Common Language Specification (CLS). The managed code gets compiled into the Microsoft Intermediate Language (MSIL). The Common Language Runtime provides a just-in-time compiler that compiles the MSIL into the machine language and then runs it, because all programs use the common services in the CLR, no matter which language they were written in. The Common Language Runtime follows the Common Type System (CTS), which is a master set of data types. Due to the Common Type System, managed code written in various languages can interoperate with programs written in another CLR language.
These are the qualities of services provided by the Common Language Runtime:
- Garbage collection
- Cross language integration
- Base Class Library Support
- Thread Support
- Exception Manager
- IL to Native
- Class Loader
The design patterns provided by Microsoft for .NET for enterprise applications describe an n-layer model that is not specific about what the layers contain, but rather extolls the benefits of layered design.
The Presentation layer provides the user experience. For thin clients, it consists of Active Server Page.NET (ASP.NET) components executed under Internet Information Services (IIS).
The business layer provides reusable objects that perform discrete business functions. These are accessed by the Presentation layer to perform these functions and provide business context views of resources and other applications.
The business layer contains objects running under the .NET Common Language Runtime, known as "managed code" and COM+ components which do not run under the CLR, known as "unmanaged code".
The placement of these components in the business layer does not imply location. They may or may not run on the same machine as the Web or application server or the fat client. They may run on dedicated application machines or even on the same machines as the resources they utilize.
This layers hosts components such as: COM+ objects, .NET Classes, Web Services and .NET Remoting objects.
This layer hosts every component that access to external resources. This can include databases, files, and interfaces to other systems.
These components isolate the access code into a single location and abstract the data representation and access patterns from the business objects to minimize the impact to business objects of changes in data structure or providers.
Connectors are objects or collections of objects that access specific resource technology, as opposed to business objects which abstract business functions.
In addition, the .NET Framework provides components for building Web Services with these standard protocols and services:
- Simple Object Access Protocol (SOAP)The .NET Framework supports both RPC and Document style SOAP.
- Web Services Discovery Language (WSDL)
- Universal Description, Discovery, and Integration (UDDI)
In addition to using automated features of Visual Studio .NET to facilitate creating Web Services, Web Services can also be created in a less convenient, but more flexible manner. The .NET Software Development Kit (SDK) contains several tools for working with Web Services.
- soapsuds.exe. The soapsuds tool generates runtime assemblies capable of accessing a remoting service provider given a XSD definition.
- wsdl.exe. The wsdl tool generates Web Services and Web Service client proxies based on a WSDL definition.
- disco.exe. The disco tool searches a specified Web server for Web Services discovery documents and saves them locally. Typically, disco.exe is used to discover Web Services and then wsdl.exe is used to generate client code to access the service.
All these tools are built based on classes provided by the .NET Framework. Therefore, all the same functionality is available at runtime and may be used within an application for dynamic Web Services discovery and consumption.
In Microsoft.NET the component model is COM+. It has many similarities to J2EE EJB component model. Both component models have special environment in which the components run (EJB calls them Container, and COM+ calls them Contexts). A component developer can specify how a particular component should behave by modifying specific attributes that define the component's behavior within an environment. For example, you can define the transaction behavior by simply modifying the configuration files without modifying the component's implementation. This feature is commonly known as "attribute base programming". COM+ also adds built-in support for versioning. This component model supports transaction services, message queues, and directory services. These features are part of the Windows Operating System.
A process in Microsoft.NET can create one or more threads to execute a portion of the program code associated with the process. Every thread has a priority. Threads with high priority are executed in preference to threads in lower priority.
Multithreading in Microsoft.NET is implemented using two ways. One is to create an instance of the class Thread, named worker thread, as the thread executor which uses a delegate instance of ThreadStart to specify the program code executed by the thread, that is, receives the delegate instance as an argument in the Thread constructor. The other way is using asynchronous delegates, and the idea behind is create a delegate instance to some method a call the asynchronous mode associated to the former method, these one will call a thread from the thread pool. The original thread, which submitted the request, is free to continue executing in parallel.
The thread synchronization and communication is done using the integrated key work lock and instances of the classes Monitor and Mutex which provides methods for performing operation for waiting and notifying threads status and events.
For running tasks at some time in the future or repeatedly at regular intervals, you can schedule it with the System.Threading.Timer class which uses callback methods for the task logics. The tasks don't execute in the thread that created the timer; they execute in a thread supplied by the pool thread.
Accessing Directory Services.
In Microsoft.NET means connecting to Active Directory, either using Lightweight Directory Access Protocol (LDAP) or Active Directory Service Interface (ADSI). The primary and recommended API for Active Directory is ADSI. ADSI sits on top of LDAP and also provides the easiest access to Active Directory through LDAP. Native ADSI allows access to Active Directory by exposing objects stored in the directory as COM objects. You then manipulate directory objects using the methods on one or more COM interfaces. ADSI providers contain the implementation of ADSI objects for a particular namespace, with the main one being the ADSI LDAP provider. By implementing the required interfaces, ADSI providers translate these interfaces to the API calls of a particular directory service. Using objects that lives in the namespace System.DirectoryServices provide you access to the Active Directory services.
The .NET deployment is different from the Java 2 Enterprise Edition. Assemblies are deployment units and are basic building blocks used by the .NET Framework. When an application is compiled in .NET, the output of the compilation produces an assembly which can be either an executable file (*.exe) or a dynamic link library file (*.dll).
An assembly consists of four elements:
- Assembly metadata
- Type metadata
- IL code
Assemblies are self-describing through metadata called a manifest. The manifest contains the assembly's identity and version information, a file table containing all files that make up the assembly and the assembly reference list for all external dependencies. The self-describing nature of assemblies overcomes the dependency on the registry and therefore simplifying deployment. The Common Language Runtime uses the manifest at runtime to ensure the proper version of a dependency is loaded.
The .NET Framework provides a robust scheme for versioning assemblies. By versioning assemblies, multiple versions of a same named object, in the same namespace, may be loaded into memory at the same time. This capability provides backward compatibility in cases where an application was built with one version of an assembly and does not work with follow-on versions of that assembly. This also virtually eliminates the possibility of back-leveling an assembly, a common problem with traditional Windows applications.
Assembly versioning is most transparent and effective when an assembly is strong named and installed into the Global Assembly Cache (GAC). The .NET Global Assembly Cache is a repository for commonly used assemblies. Unless specified by configuration and policy files, the .NET assembly loader loads generically specified assemblies from the Global Assembly Cache before searching and loaded same named assemblies from other locations. The Global Assembly Cache requires assemblies to be strong named and may contain multiple versions of the same assembly or same versioned assemblies with different culture information.
Analogies between Microsoft.NET and J2EE.
|Features ||J2EE ||Microsoft.NET|
|Type of technology. ||Standard ||Product|
|Middleware Vendors. ||30+ ||Microsoft|
|Interpreter. ||JRE ||CLR|
|Dynamic Web Pages. ||JSP ||ASP.NET|
|Rich Client API ||Swing ||WinForms|
|Middle-Tier Components. ||EJB ||.NET Managed Objects and COM+|
|Operating Systems ||Win32, Solaris, Linux, OS X, many others Operating System. ||Win32|
|Distributed Transactions ||JTS ||.NET Distributed Transactions|
|Message Queuing ||JMS ||MSMQ|
|Program Packaging ||Jar Files (.jar) ||Assemblies (.exe and .dll)|
|DataBase access. ||JDBC, SQL/J ||ADO.NET|
|Web Services ||JAX Pack API ||Built-in .NET SOAP classes and Microsoft SOAP Toolkit|
|SOAP, WSDL, UDDI ||Yes ||Yes|
Interoperability between Microsoft.NET and J2EE is still a promise; the possibility for the interoperation in an enterprise architecture space does exist. This possibility is based on the interoperability of Web Services and it is supported by the formation of Web Services Interoperability Organization (WS-I). WS-I is an open industry organization to promote web services interoperability between platforms, operating system and programming languages. The organization works across industry and standards organizations to respond to customer needs by providing guidance, best practices, and resources for developing web services solutions. The WS-I membership includes Microsoft, IBM, Oracle, BEA System, SilverStream, Borland and just everyone else in the application server arena.