EDN: ESRI Developer Network
ArcGIS Server offers developers a rich, standards-based set of components for building and deploying geospatial applications. For the Java developer the ArcGIS Server’s Software Development Kit (SDK) includes :
The ADF components are tightly integrated into common development environments such as Eclipse and Sun Java Studio Creator to enhance the developer experience and boost productivity.
Figure 1: ArcGIS Server 9.2 Software Development Kit's Enterprise ADF Java Component
ArcGIS Server's Enterprise ADF supports development of J2EE applications powered by Enterprise JavaBeans (EJB) technology by providing out-of-the-box EJBs ready to use, ready to deploy across a wide variety of J2EE 1.4 certified application servers and completely integrated with ArcGIS Server Manager for point click ease.
Enterprise ADF includes a suite of server-side components aimed at providing interoperability, mission-critical support, and secure infrastructure to enable customers take advantage of their existing investment in ArcGIS Server. It also enables business to interface their existing applications to other business. The out-of-the box EJBs provides the framework to build and deploy GIS-enabled J2EE applications and services to meet a variety of needs using a variety of clients by exposing ArcGIS Server Object functionality. GeoSpatial EJBs give you access to many capabilities including: Map, Geocoding, Querying, and solving Network problems. Enterprise ADF is wholly based on the Sun J2EE standard and is written entirely in the Java Language. It uses the Java Connector Architecture to connect to ArcGIS Servers.
Enteprise ADF gives Java programmers a framework to build and deploy GIS-enabled J2EE application using the EJB technology. Number of enhancements have been made to ADF to include support for programmers using the EJB technology. They include:
Java EE (previously known as J2EE) is based on the concept of containers and components. EJB is the cornerstone api in the Java EE specification. EJBs are Java components that live and operate within a Java Enterprise Edition (Java EE) application server, a server that provides the EJBs with all of the essential services that allow them to perform and scale to appropriate standards for mission critical, industrial-strength, and highly secure enterprise infrastructures. EJBs are pure Java components, designed and written to the Java EE EJB specification. This specification ensures that EJBs abide by a standard set of rules, enabling them to be portable across all Java EE-based application servers and across all operating systems that support the Java platform. The ultimate goal of EJB has been to develop components separately and allow them to be used together in the server. The container isolates the enterprise bean from direct access by client applications. When a client application invokes a remote method on an enterprise bean, the container first intercepts the invocation to ensure persistence, transactions, and security are applied properly to every operation a client performs on the bean. The container manages security, transactions, and persistence automatically for the bean, so the bean developer doesn't have to write this type of logic into the bean code itself. The enterprise bean developer can focus on encapsulating business rules, while the container takes care of everything else.
Figure 2: EJB as a foundation layer for all your business services
The container isolates the enterprise bean from direct access by client applications. When a client application invokes a remote method on an enterprise bean, the container first intercepts the invocation to ensure persistence, transactions, and security are applied properly to every operation a client performs on the bean. The container manages security, transactions, and persistence automatically for the bean, so the bean developer doesn't have to write this type of logic into the bean code itself. The enterprise bean developer can focus on encapsulating business rules, while the container takes care of everything else
As part of the specification, EJBs must not make native calls into native libraries, such as Windows DLLs or UNIX shared objects. This is especially critical in the case of the ArcGIS Server architecture, since ArcObjects, the library of components that make up ArcGIS, is highly "native" in nature, whether it be native to Windows or to UNIX. Another equally important restriction for EJBs is that they are not allowed to create or manage their own threads. Because thread management can often be complex and platform-specific, the EJB container better handles this implementation detail. This becomes a key issue when properly programming EJB applications to work with ArcGIS Server. This is where the Java EE Connector Architecture comes into picture. Java EE Connector Architecture (JCA) is a Java-based technology solution for connecting application servers and enterprise information systems (EIS) as part of enterprise application integration (EAI) solutions. ArcGIS EJBs take advantage of this standards-based architecture to ensure connectivity between application servers and Arcgis Server.
While there are many advantages provided by the use of EJBs for executing the business logic for enterprise systems, the focus here is on two of the main benefits. First, EJBs are important because they adhere to tested and proven computing standards. This is key for interoperability and portability of enterprise applications. No matter what the specific business process the EJB is performing, everyone can be sure that other EJBs from various providers, running either locally or remotely, will work together in an enterprise system because they adhere to the same rules and standards. They are built in pure Java, which, in itself, is a standard computing platform and language. The application servers that host these various EJBs and EJB containers are designed and built to the Java EE standard as well. This ensures that EJBs can be ported from one application server environment to another without too much overhead and without any rewriting or recompiling of source code. Second, EJB technology enables development of business objects and system-level services as separate and distinct entities among the various members of an enterprise maintenance staff. EJBs provide other advantage and this topic is beyond the scope of this discussion but for the purpose of completeness we shall enumerate them: one source for business logic, accessibility by many types of clients, easily distributable, reliable, high perfoming, declarative security support. For a detailed understanding of what EJBs are, go to http://java.sun.com/products/ejb/
Figure 3 (below) shows a typical J2EE architecture most Java programmers are familiar with. Servlets and JSP hosted in the web tier handle presentation logic and behave as controllers / dispatchers (using servlet). The business tier primarily holds business objects modeled as EJBs that talk to a relational database. Today, a number of EJBs use an object-relational layer to shield the business object layer from changes in the backend database. More recently, EJB 3.0 using JPA is trying to simplify the development of Java EE applications using data persistence based on a standard model for object-relational mapping.
Figure 3: Typical J2EE Architecture
In order to understand usage of EJBs in a GIS, let us shift our attention to figure 4. The only difference you as a programmer might see is that the EJB applications not only talk to relational database to access relational data, but also a server capable of serving spatial data. Using J2EE Connector architecture the EJB components establish connectivity to Enterprise Information Systems in the backend. ArcGIS Server ships with needed resource adapter that comply with the J2EE connector specification.
Figure 4: Typical J2EE Architecture in the GIS Space
The Java EE architecture decouples the many tiers of its application configuration in such a way that all the members of an enterprise development team are free to focus on their specific roles and tasks, without any dependency on the system architecture. An EJB programmer can focus solely on the business logic, or main process, that the EJB will be responsible for performing. The EJB programmer will not need to be concerned with writing code to handle transaction management, threading, object pooling, security, or scaling of that EJB. In fact, the EJB specification prohibits this. These concerns are the responsibility of the application server designers and vendors who build these services, using standard APIs for transaction management, database connectivity, security, scaling, and so on. For a comprehensive listing of of the rules and restrictions for EJBs, go to http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html.