Novell is now a part of Micro Focus

How to Build J2EE Applications Using Novell Technologies (Part 1)

Articles and Tips: article

J. Jeffrey Hanson
Chief Architect
Zareus Inc.
jhanson583@aol.com

01 May 2002


This AppNote is the first in a series that will outline a platform and methodology for developing applications on NetWare with the Java 2 Platform Enterprise Edition (J2EE) using a service-oriented architecture. This AppNote introduces the technologies for the series and tells how to get started by enabling NetWare to respond to HTTP requests with static documents and dynamic scripts generated by Java Server Pages (JSPs) and servlets.


Topics

Java application development, J2EE

Products

Java 2 Enterprise Edition

Audience

developers

Level

intermediate

Prerequisite Skills

familiarity with Java programming

Operating System

n/a

Tools

none

Sample Code

no

Introduction

This is the first of a series of AppNotes that will outline a platform and methodology for Java 2 Platform Enterprise Edition (J2EE) application development on NetWare using a service-oriented architecture.

This AppNote introduces the technologies for the series, including Java Messaging Service (JMS), servlets, Java Server Pages (JSP), Enterprise JavaBeans (EJB), and so on. It also introduces some J2EE enhancement technologies, including Novell eDirectory/ LDAP, Java Management Extensions (JMX), Jini, and JavaSpaces. It presents a complete, service-oriented platform for developing, deploying, and managing applications and services, using proven design patterns. These applications and services can be deployed and used within multi-tier client/server environments, peer-to-peer environments, fat-client environments, and X Internet environments.

Note: For an interesting take on X-Internet, see "My View: X Internet" at http://www.forrester.com/ER/Marketing/0,1503,214,00.html.

Java and J2EE Application Technologies

According to the J2EE blueprints (available online at http://java.sun.com/blueprints), the goal of J2EE is to define a standard of functionality that helps businesses develop and deploy custom applications quickly. J2EE should also enable businesses to easily refine and enhance custom applications to improve their value, and to integrate custom, scalable applications with existing enterprise information systems simply and efficiently. These are lofty goals, indeed.

J2EE APIs

J2EE certainly provides a toolbox that is comprehensive enough to realize these goals. For example, the following APIs are provided by the J2EE platform just for enabling access to existing enterprise information systems:

  • JDBC. API for accessing relational data from Java

  • Java Transaction API (JTA). API for managing and coordinating transactions across heterogeneous enterprise information systems

  • Java Connector Architecture. API for building adapters and connectors to legacy applications and data sources using a standard set of contracts

Other domains within a distributed application environment have similar coverage from the J2EE platform and the Java 2 Platform Standard Edition (J2SE).

Other Java Technologies

Other technologies have also been introduced to the Java programming arena and will be used within our platform. This section briefly introduces them.

JMX

The Java Management Extensions (JMX) is an optional J2SE package that introduces a standard, open technology for application and service management. JMX defines APIs and technologies for building distributed, modular and dynamic components and frameworks for managing devices, applications, services, and networks.

JMX provides a simple, standard way to empower Java objects with statistical monitoring capabilities. This is known as "instrumentation". JMX instrumentation is designed to be totally independent from the management infrastructure and, thus, has very few constraints. This allows a resource to be managed by any management utility or system.

The JMX architecture is built on a three-level model allowing subsets of the specification to be used individually. The three levels are:

  • Instrumentation level - gives instant statistical monitoring and manageability to any Java object

  • Agent level - defines containers that provide management services which can be dynamically extended by adding instrumented resources

  • Manager level - defines management components that can operate as agents for distribution and consolidation of management services

Jini

Jini is an open architecture defining network-centric services. The Jini architecture specifies a way for Java-based, task-driven services to be published on a network and a way for clients to discover and use these services across any type of remote procedure call (RPC) technology such as RMI, CORBA, or SOAP.

JavaSpaces

JavaSpaces is a Jini-based service defined by Sun Microsystems. The JavaSpaces model defines persistent object-exchange areas in which remote processes can coordinate their actions and exchange data. In a distributed application, the JavaSpaces technology acts as a bridge between providers and requesters of resources that facilitates the exchange of tasks, requests, and data in the form of Java objects. JavaSpaces technology provides process integrity by empowering developers with the ability to create and store persistent objects.

Service-Oriented Architecture

A service is much like a software component in that it is a reusable software entity that embodies a discrete piece of logical functionality. A service-oriented architecture (SOA) defines tools and technologies that allow the construction of remotely discoverable and callable services from a set of interacting objects and components. An SOA defines its services using abstract interfaces or contracts that are implemented using any programming language.

Platform Kernel

Our platform kernel provides fundamental functionality to all of the other platform components. All of the platform components work within a structured environment managed by the kernel. The kernel is responsible for creating and maintaining platform components and other platform elements such as the JMX server and the service manager. The kernel is the core of our platform. The kernel enables services to be dynamically added and removed and provides inter-service communication.

Service Container

The service container controls and administers the services registered with the platform. It acts as the liaison between the services and the kernel. The service container is responsible for the lifecycle of the services, publishing the services to a given registry, monitoring the services, and service persistence.

Platform Management

Our platform is built on JMX, which allows all management tasks to be handled by any JMX-compliant tool or service. A management portal can be used to load, initialize, change, and monitor applications or services and other distributed components within our platform. Users who are familiar with any JMX-enabled tool are immediately comfortable using the management tools and technologies defined by our platform. A JMX-enabled management portal can allow users and applications to query the state of the platform modules and even change them during runtime.

The Four Tiers

A problem exists in distributed application development when presentation components, business logic components and data access components are embedded in only one or two layers. This design does not encourage proper development team efficiency. To avoid this problem, our platform is designed to provide a proper separation of concerns for distributed development teams. Our platform embodies a four-tiered, enterprise services model.

Client Tier

The client tier supports a variety of client types such as Web browsers, mobile devices, fat clients, and Web services. Views are generated for each client type using HTML documents, dynamic HTML generated with JavaServer Pages, XML, Java applets, and so on. Fat clients can maintain their own views, but use the same business logic as thin clients.

Web Tier

The Web tier acts as a multi-client request dispatcher that interacts with business logic to perform tasks and invoke services. This tier uses servlets and JSPs to deliver view scripts (HTML, HDML, XML, and so on) to the client tier. The Web tier coordinates the flow of an application. Domain specialists work within the Web tier to structure the flow of each application. A client device usually interacts with the Web tier using a request/response communication protocol such as HTTP. The request defines the action to be taken the JSP or servlet generates the response.

Business Tier

The business tier defines business-logic components as Enterprise Java Beans, data access objects (DAO), message-oriented middleware (MOM) components and Java Beans. Business-logic components registered in the business tier are automatically presented as Web services and domain services and are grouped and ordered to form a service framework. The automatic service generation of this service framework allows a developer to concentrate on business logic without regard to how the logic might be accessed.

The service framework within the business tier is the backbone of our platform. The service framework exposes a pluggable design that allows enterprise developers to aggregate and use services to perform domain specific operations.

EIS Tier

The enterprise tier provides integration and access to all services and data that exist in enterprise applications and systems including relational databases, directory services, and legacy systems. Access to applications and data sources is facilitated using data access objects (DAO). DAOs present common interfaces to interested parties, such as the service framework, regardless of the type of system or application they are representing.

Web Services and the Services Framework

"Web Services" is the term being used to describe some of the technologies for solving the problems of integrating applications across the enterprise and disparate businesses that do business over the Web. Web Services are also being described as the concepts and technologies for delivering services and content to any Web-enabled client or device. Here is a simplified attempt at defining Web Services generically: Web Services are URI addressable resources that use existing Internet infrastructures and protocols to allow applications, services and devices to discover them, connect to them, and execute their business logic using remote method calls.

Web Services are currently concerned with four basic challenges:

  • Service Description

  • Service Implementation

  • Service Publishing, Discovery and Binding

  • Service Invocation and Execution

Current technologies are solving these challenges in a number of ways:

  • Describing Web Services using the Web Services Description Language (WSDL).

  • Using XML as the common language for Web Service communication. XML is ubiquitous throughout all aspects of Web Services. Web Services can be implemented in any programming language that can read and write XML and can be deployed on any Web-accessible platform.

  • Publishing Web Services in a registry to be discovered later by interested parties accessing the registry. One type of registry provides a directory service for Web Service providers and their services. This registry provides information categorized by industry-type, product-type, service-location, service binding, etc. Taxonomies are used to enable searches on this information. One implementation of this registry is based on the Universal Description and Discovery Integration (UDDI) specification. Another type of registry also acts as a repository where Web Services entities such as business-process schema are stored. A current example of this type of registry is the electronic business XML (ebXML) Registry and Repository.

  • Invoking Web Services over an existing Internet protocol such as HTTP or SMTP using the Simple Object Access Protocol (SOAP).

For business services registered with our platform, SOAP listener, responder services, and WSDL files are dynamically generated. This allows external Web services to communicate with any business service that is exposed by our platform.

Once a business service has been registered with our platform and its SOAP listeners, responder components and WSDL file have been generated; the platform publishes the WSDL file to a given registry. The service is then started and is available for Web service requests.

External Web services are accessed using dynamically generated DAOs. The Web service DAOs enable any business service deployed in our platform to integrate with an external system that exposes Web services.

Getting Started

The first step in implementing our platform is to enable the NetWare environment to respond to HTTP requests with static documents and with dynamic scripts generated by JSPs and servlets.

Novell delivers the Apache Web Server and the Tomcat servlet and JavaServer Pages (JSP) container with NetWare 6. Tomcat enables the Apache Web Server with Java servlet functionality and opens up the NetWare platform to Java and the J2EE environment. Tomcat offers three different configuration options:

  • Standalone container. All requests are delivered by Tomcat. This includes static documents and dynamic scripts. This configuration eliminates the need for a separate Web server.

  • Out-of-process container. This configuration defines two memory spaces: one for the Web server and the Java plug-in, and the other for the JVM and the servlet container. This allows the Web server and servlet container to be distributed across different address spaces and/or machines.

  • In-process container. The servlet container runs in the same memory space as the Web server.

In this AppNote you will learn how to configure your Tomcat environment for an in-process container.

Note: Novell highly recommends that you configure a separate Apache/Tomcat application environment for development, testing, and deployment. By creating a separate environment, you minimize the possibility of interfering with the NetWare 6 management infrastructure, which also uses Apache and Tomcat.

Create an Instance of Apache for Development, Testing, and Deployment

To facilitate the process of loading a separate instance of Apache, you need to create two NCF files: one for starting the separate Apache instance and one for stopping it.

To create the startup file, open any text editor and enter the line:

Load address space = apache apache.nlm

Save the file to the sys:/apache directory as startapache.ncf.

To create the stop file, open any text editor and enter the line:

Unload address space = apache apache.nlm

Save the file to the Apache directory as stopapache.ncf.

Configure an Additional Instance of Tomcat

You also need to configure an additional instance of Tomcat dedicated to your development and deployment environment. This separate instance of Tomcat will be configured to take advantage of Tomcat's auto-configuration to deploy Web Archive (WAR) files.

Edit the adminserv.conf File

To configure an additional instance of Tomcat, open any text editor and edit the adminserv.conf file located in the sys:/apache/conf directory. Comment out the port 80 configuration. This will free up port 80 for your instance of Apache to listen on it. Save the file.

Create a New NCF File

To prevent potential conflicts, you should create a new NCF file with a different name. This new file will be used to bring up the new instance of Tomcat that will be associated with your second Apache that you will use for development.

Edit the server.xml File

Edit the server.xml file located in the sys:/tomcat/33/conf directory. Open the file and search for 8009 and replace it with 8019. Search for 8007 and replace it with 8017. Search for ApacheConfig forward All ="True" and uncomment this line. Save the file.

Edit the workers.properties File

Edit the workers.properties file in the sys:/tomcat/33/confjk directory. Change the entry located under "DEFAULT ajp12 WORKER DEFINITION" from port 8007 to port 8017. Change the entry located under "DEFAULT ajp13 WORKER DEFINITION" from port 8009 to port 8019. Save the file.

Edit the tomcat33.ncf File

Edit the tomcat33.ncf file located in the sys:/tomcat/33/bin directory. Change the reference to nwserver.xml at the end of the last line to server.xml. Save the file as my_tomcat33.ncf.

Edit the httpd.conf File

Edit the httpd.conf in the sys:/apache/conf directory. Open the file and go to the bottom of the file. Add the following line to the bottom of the file:

include sys:/tomcat/33/conf/auto/mod_jk.conf

Save the file.

Reinitialize the System

At this point, you need to stop and restart both Tomcat and Apache to reinitialize the system. Here are the steps for doing this.

  1. Type "java -exit" at the server console. This will unload all currently loaded instances of Tomcat.

  2. Unload all instances of Apache on the server by typing "unload Apache" at the server console.

  3. Type "my_tomcat33.ncf" at the server console to bring Java back up along with your instance of Tomcat.

Bring Apache back up by typing "startapache.ncf" at the server console.

Test the Configuration

You can test the configuration by executing the following steps:

  1. Open a browser window and enter either the IP address of your server or its hostname and then type "/examples" after it. This should bring up the Tomcat examples page.

  2. Select the JSP category. A page that contains several JSP examples should display.

  3. Select the date JSP and click "execute". A page should display that shows date information.

Your installation is complete. Web applications (.WAR files) containing static HTML, images, JSPs, and servlets can now be placed in the sys:/tomcat/33/webapps directory and executed.

Conclusion

J2EE provides an infrastructure and implementation support for distributed systems development. However, it does not enforce proper architectural designs. This leaves complex architectural decisions up to each individual development team. More often than not, this results in proprietary architectures that are burdened with unmanageable upgrade paths and maintenance headaches. The platform being presented in this AppNotes series allows for maximum customizability, powerful upgrade potential, and minimized maintenance.

A properly structured, service-oriented platform allows enterprise application developers to focus on their areas of expertise. This ensures more robust results with a faster time-to-market. Additionally, enterprises that build their applications on a service-oriented platform will be properly positioned to accommodate the rapidly changing enterprise environment.

For Additional Information

For more information about the technologies introduced in this AppNote, refer to the following resources:

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates