How to Build J2EE Applications Using Novell Technologies: Part 1 How-To Article NOVELL APPNOTES

How to Build J2EE Applications Using Novell Technologies: Part 1 How-To Article NOVELL APPNOTES J. Jeffrey Hanson Chief Architect Zareus Inc. [email protected] 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. Contents: • Introduction • Java and J2EE Application Technologies • The Four Tiers • Web Services and the Services Framework • Getting Started • Conclusion To pics Java application development, J2EE Products Java 2 Enterprise Edition Audience developers Level intermediate Prerequisite Skills familiarity with Java programming Operating System n/a To ols none Sample Code no May 2002 83 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). www.novell.com/appnotes 84 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. May 2002 85 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. www.novell.com/appnotes 86 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

Load more