Friday, October 20, 2017

Java EE Component Model

1 Component-Based Development

The Java EE platform supports component-based development
  • component-based development is based on the principle of loose coupling
  • loosely coupled systems are easy to test and maintain

2 Java EE Components

A Java EE component is a group of classes and interfaces that implements a single functionality

  • a component is assembled into a Java EE application, with its related classes and files
The java EE specifications define different types of components:
  • Application clients and applets are components that run on the client.
  • Java Servlet, JavaServer Faces, and JavaServer Pages (JSP) technology components are web components that run on the server.
  • EJBs components (enterprise beans) and Entity classes are business components that run on the server.

3 Java EE Component Characteristics

  • State and properties
  • Encapsulation by a container
  • Access to components through proxy
  • Support for local and distributable component interactions
  • Components references obtained from a Java service

4 Component State and Properties

A state is data that a component keeps across multiple method calls
  • components are stateful or stateless
  • stateless components are suitable to be distributed on different hosts
A property is a component feature that clients may read or write
  • a property is modelled with an accessor and mutator methods pair
    • for example, the name property is represented by the getName and setName methods
  • a property may be represented by an instance variable

5 Encapsulated Components

Java components are encapsulated by a container which
  • manages the component lifecycle
  • isolates the component from other components

6 Component Proxies

Java components, such as EJB, are utilized through a proxy. An EJB client does not hold a direct reference to an EJB instance but it references a proxy on an instance, even if the client and the EJB are located on the same Java Virtual Machine

  • you should never use the new operator to instantiate the component
  • the proxy is provided by the container, this allows the component to be managed by the container
  • call on proxy’s method are intercepted by the container which provides container-based functionalities
Java interfaces are used to define the methods that are made available by a component
  • the component’s proxy implements the same interface of the component
  • Java EE 6 proxy mechanism does not require all types of component to define an interface

Interfaces as Contracts

Java EE application components interact through interfaces:

  • two component implementations are programmed against the other’s interface
  • a component cannot make calls on methods of another component implementation

7 Distributable and Local Component Interactions

The application developer indicates whether component interaction is local or distributable

  • for local interaction, components interact in the same JVM
  • for distributable interaction, components located in different JVM communicate by RMI

A distributed component model has advantages and drawbacks

  • RMI adavantage is location transparency, which implies fault tolerance and load sharing between hosts
  • RMI drawbacks are the overhead needed to marshalling data, network latency and more complex exceptions

Location transparency means that a component may be deployed in multiple host and as long as the component's client can reference to the component by its name, the client is not concerned with the physical location of the target component.

Note: application server's clustering allows to accomplish fault tolerance and load sharing between servers without RMI's distributed objects. Application server clustering is an advanced features and is not required by Java EE specification.

8 How to locate Java EE components

In tha Java EE component model a component must find a way to get a reference to another component interface, without using the component implementation. There are three ways to locate a component:

  • the java naming service
  • a component context
  • dependency injection

9 Naming Services in the Component Model

The application server provides the JNDI: a repository of components accessible by name.

Using a naming system involves three steps:

  1. when application is deployed, a component X is registered with the naming service.
    Component X implements interface I.
  2. a client performs a lookup using the central naming service.
  3. the naming service supplies an object that may be an instance of component X or proxy for component X.
    The client calls methods on component X using interface I.

Application Components' Naming Environment

Application clients, EJBs and web components have access to a JNDI naming environment

  • the application component’s naming environment allows application assemblers to customize the component’s business logic through standard deployment descriptors, without the need to change the application component’s source code
  • the container implements the application component’s environment, and provides it to the component as a JNDI naming context

10 Java Naming and Directory Interface (JNDI) API Lookups

The JNDI service enables lookups for:

  • Java EE components
  • external resources
  • objects in the component environment

Using JNDI API as a Resource Locator

A resource is a program object that provides connections to systems, such as database servers and messaging systems (a JDBC resource is also known as data source).

A list of resource that can be located using the JNDI

  • database datasource
  • JMS ConnectionFactory
  • JMS Destination
  • Component environment variable
  • JCA ConnectionFactory for connections to legacy systems

The Context Interface and the InitialContext Object

Context and InitialContext

  • The Context interface is the basis for a naming operation
  • The InitialContext object implements the Context interface and allows to perform JNDI lookups
  • A lookup operation results either in an object or in a subcontext.

Sample code for JNDI lookup demonstrating the use of a context and a subcontext

 Context initialContext = new InitialContext();
 Object obj = initialContext.lookup("java:comp/env/my-resource");
or
 Context initialContext = new InitialContext();
 Context subcontext = initialContext.lookup("java:comp/env");
 Object obj = subcontext.lookup("my-resource");

Configuring the InitialContext Object

  • the InitialContext object is configured by the container when it is instantiated within the context of a Java application server.
  • the InitialContext object requires explicit configuration when it is instantiated in a stand-alone application outside of an application server host.

Narrowing and Remote Objects

JNDI lookups for nonremote objects only require casting to correct type

@WebServlet("/SampleServlet")
public class SampleServlet extends HttpServlet {

   private DataSource dataSource;

   public void init() throws ServletException{
      InitialContext ctx = new InitialContext();
      dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/my-datasource");
   }
   ...
}

JNDI lookups for remote objects require narrowing to correct type

Context initialContext = new InitialContext();
Object object = initialContext.lookup("java:comp/env/ejb/HelloEJB");
HelloEJB helloEJB = (HelloEJB) javax.rmi.PortableRemoteObject.narrow(object, HelloEJB.class);

11 Using Component's Context to Locate Components

A Java EE component's context object represents the environment where the component lives

  • examples of context are: the EJBContext (SessionContext and EntityContext) and the ServletContext
  • a component context is automatically supplied by the container
  • a component context can be used for simplified JNDI lookups
@Resource private javax.ejb.SessionContext sessionContext;

// PortableRemoteObject.narrow is not required for remote component
public void myMethod() {
    HelloEJB helloEJB = (HelloEJB) sessionContext.lookup("HelloEJB");
}

EJB components reference an EJBContext object:

  • which gives access to security information, transaction control and resource lookup
  • performs lookups in the java:comp/env JNDI sub-context for EJB references and resources
  • lookups with java ee component context are simpler that lookups with JNDI context
  • even when looking up EJB 2.1 Remote Home references is not required to narrow the object

12 Using Dependency Injection to Locate Components

Dependency injection uses Java annotation to locate components

  • dependency injection can replace JNDI lookup code
  • an annotated variable is assigned a value by the container
  • in a managed component, an @EJB annotated field is assigned with an EJB reference
  • J2EE 1.4 components can be injected in Java EE 5 or 6 components

example:

import javax.ejb.*;

@Stateful
public class MySessionBean implements MyInterface {
  @EJB private HelloEJB helloEJB;
}

dependency injection in Java EE 5 and Java EE 6 components

  • dependency injection introduced in Java EE 5, received enhanced support by Java EE 6
  • dependency injection only works in managed components (servlet, JSP, EJB) POJO still require JNDI lookup code.
  • in the Java EE 5 platform, annotations and dependency injection replace the need for most deployment descriptors.

13 Asynchronous as Compared to Synchronous Communication

Two Java application components can interact in two differnt ways: synchronously or asynchronously

  • Synchronous Interaction:
    • follows the request-response pattern
    • the client requests for component's operation and bloks waiting for the operation to complete
    • the client gets a direct response from the called component
  • Asynchronous interaction:
    • follows the request-notification pattern
    • the client requests for component's operation but does not block
    • when done the client gets a deferred response
  • Asynchronous interaction advantages compared to synchronous interaction
    • suitable for operations that take a long time to complete or requiring high guarantee of service
    • reduce coupling between components

14 Asynchronous Messaging

A Java application server provides a messaging service for asynchronous component interaction

  • a component uses the JMS API to sent a message to another component or external resource
  • a message-driven bean comsumes JMS messages

15 Java EE Roles

The roles related to application developement are:

  • application component developer
  • application assembler
  • application deployer

Application component developers build Java EE components and resource adapters:

  • the output of this role is compiled classes and XML incomplete deployment descriptors
  • the artifacts output from this process can be uses in any java compliant system by any vendor
  • the web component developer packages the components into a WAR file
  • the enterprise bean developer packages the components into a EJB JAR file
  • the application client developer packages the components into a JAR file

Application assemblers take Java EE application modules developed by different sources and assemble them into applications:

  • resolve cross-references between components
  • the artifacts produced are packaged in EAR application files
  • note that tools can replace the role of assembler in packaging components

Application deployers deploy (installs) the Java application EAR file into the Java application server:

  • resolve references to external resources
  • configure the runtime environment of the application

16 Configuring and Packaging Java EE Applications

A Java EE application is packaged into one or more standard units to be deployed to any Java platform compliant application server. Each unit contains java components and an optional deployment descriptor that describes the content.

16.1 Packaging Applications

How to deliver Java EE Applications

Java EE applications are distributed as: Java ARchive files (JAR), Web ARchive files (WAR), Enterprise ARchive files (EAR).

  • WAR and EAR files are standard JAR files with a .war or .ear extension

How to assemble Java EE Applications

It is possible to create a number of different Java EE applications using the same components, by assembling (packaging) Java modules into archive files

An EAR file contains Java EE modules and an optional deployment descriptors: see figure below

Figure 5-1 EAR File Structure

                                           Assembly Root
                                                 |
     -----------------------------------------------------------------------------------
     |               |                  |                       |                      | 
WAR module      EJB module      ClientApp module      Resource Adapter module      META-INF/
                                                                                       |
                                                                                  application.xml  
                                                                optional glassfish-application.xml or jboss-app.xml

Deployment descriptors (DD)

  • deployment descriptors are XML files
  • they describe in a declarative way the interaction between components and between components and its container
  • beginning with Java EE 5, deployment descriptors are optional: developers can use in-code annotations to configure components.
  • if both DD and in-code annotations are present, deployment descriptors override annotations
  • information within a DD can be changed without the need to change the source code
  • information contained in a DD are read at runtime by the application server

deployment descriptors can specify:

  • transaction management strategy
  • authorization requirements
  • mapping to other components
  • access to external resources
  • configuration variables

There are two types of deployment descriptors:

  • Java EE deployment descriptor
    • a Java EE deployment descriptor is defined by Java specifications and is used to configure deployment settings of any Java EE compliant application server
  • Runtime deployment descriptor
    • a runtime deployment descritor is an extra nonportable descriptor, used to configure Java EE application server vendor specific parameters
    • for example: the GlassFish application server deployment descriptors are named according the convention glassfish-<moduleType>.xml

Java EE application module

    a Java EE module is made up of one or more components for the same container type and an optional deployment descriptor for that type of module.

Java EE application modules are of the following types:

  • EJB modules: contain enterprise bean classes and an optional deployment descriptor, are packaged in a JAR file with .jar extension
  • Web modules: contain servlet classes, web files such as HTML and CSS and an optional deployment descriptor, are packaged in JAR files with a .war extension.
  • Application Client modules: contain class files, optional deployment descriptor, are packaged as JAR files with a .jar extension.
  • Resource adapter modules: contain all Java interfaces, classes, native libraries and an optional deployment descriptor, are packaged as JAR files with a .rar extension.
16.2 Packaging Enterprise Beans

Enterprise beans can be packaged in EJB JAR and (since Java EE 6) in WAR modules

Packaging Enterprise Beans in EJB JAR Modules

An EJB JAR file can be used more than once in different applications

To deploy enterprise bean JAR module to Java EE application server, you can do it in two ways:

  • package one or more EJB module into a Java enterprise application archive and deploy the EAR file to the application server
  • deploy the standalone EJB JAR file to the application server.

Figure 5-2 Structure of an Enterprise Bean JAR

              Assembly Root
                    |
     -------------------------------
     |                             | 
.class files                   META-INF/
                                   |
                             ejb-jar.xml  
             optional glassfish-ejb-jar.xml or jboss-ejb3-jar.xml
Packaging Enterprise Beans in WAR Modules

You can package the enterprise beans within a web application's web module in two ways:

  • package the EJB .class files within the WAR module by including the classes into the WEB-INF/classes directory
  • bundle the EJB JAR module within the WAR module by including the JAR file into the WEB-INF/lib directory

A WAR module that holds enterprise bean, does not require the ejb-jar.xml deployment descriptor, the ejb-jar.xml is optional and, when present, is located in the WEB-INF directory

EJB JAR modules bundled in a WAR module are not considered EJB modules

  • the EJB modules are equivalent to EJB located in the WAR's WEB-INF/classes directory
  • the environment namespace of EJB are scoped to the WAR module

Example: a web application with a shopping cart stateless enterprise bean, a credit card processing stateless enterprise bean and a servlet for the front-end.

The servlet uses both CartBean and CreditCardBean. The layout of the WAR module is as follows:


WEB-INF/classes/com/example/cart/CartBean.class
WEB-INF/classes/com/example/web/StoreServlet
WEB-INF/lib/cc.jar
WEB-INF/ejb-jar.xml
WEB-INF/web.xml
16.3 Packaging Web Archives

A web module is the smallest deployable web resource unit.

  • a web module contains web components and static web files. The static web files also called web resources and include: CSS files, JS files, images files, audio and video files.
  • a web module is also defined as web application in the Java specifications.

In addition to web components and web resources, a web module contains other files like server-side utility classes (for example the shopping cart enterprise bean) and client-side utility classes.

A web module has a standard structure:

  • the top-level directory is the document root of the web application, where static files are placed
  • the document root has a subdirectory named WEB-INF which contains:
    • deployment descriptors: for example the web.xml and ejb-jar.xml files
    • the classes subdirectory: with servlets, enterprise beans and JavaBean class files, utility class files
    • the lib subdirectory: with JAR files of library required by server side components

The document root and the WEB-INF/classes directories can contain subdirectories specific to the application.

You can deploy a web module with its file structure unpacked or packaged in a WAR JAR file.

  • This web module is portable because it can be deployed in any web container

The runtime deployment descriptor

  • The runtime deployment descriptor is not required and, if present, is located in the WEB-INF directory.
  • The runtime deployment descriptor may contain the following information:
    • the context root of the web application
    • the mapping of application's resources names to application sever resources
    • the mapping of application's security roles to users, roles and principals defined in application server

Figure 5-3 Web Module Structure

                                      Assembly Root
                                           |
                          ----------------------------------
                          |                                |
                       WEB-INF                  web pages and static content
                          |
        ---------------------------------------               
        |                 |                   |
     web.xml             lib/              classes/
glassfish-web.xml         |                   |
                    library files   server-side .class files  
16.4 Packaging Resource Adapter Archives

A Resource Adapter Archive (RAR) file contains XML files, java classes and other objects for Java Connector Architecture (JCA) applications.

  • a resource adapter is deployed on an Java application server like other applications
  • a resource adpater can be deployed as a standalone file or as part of an Enterprise Archive (EAR) file
  • the adapter is always available to all applications that make a lookup

The RAR file contains:

  • a JAR file with the class files for the implementation of the resource adapter
  • an optional META-INF directory with a standard ra.xml deployment descriptor and optional application server specific deployment descriptor

No comments :

Post a Comment