'J2EE/docs' 카테고리의 글 목록

'J2EE/docs'에 해당되는 글 6건

Paging in J2EE: Manage Large Result Sets Efficiently

2005. 4. 8. 19:50

Paging in J2EE: Manage Large Result Sets Efficiently


http://www.devx.com	Printed from http://www.devx.com/Java/Article/21383

Paging in J2EE: Manage Large Result Sets Efficiently

Learn how to manage paging for unbounded queries over large result sets—without blowing up your server. Strike the right balance between resource utilization and response-time requirements to satisfy your user demands.

by
Lara D'Abreo

Pagination is the simplest and most common way to break up large amounts of data into more manageable chunks. Pagination is a key part of Web site design, both from the UI perspective (to manage limited screen real estate) and from the server perspective (to process large result sets efficiently, without causing resource spikes or servicing delays). In J2EE, efficient pagination (and good UI design) are essential for handling large query result sets in a resource-pooled environment.

Specifically, the following conditions make pagination necessary:

Screen real estate is limited. Your JSP/client UI may have insufficient space to display the entire results at once and your user may not be able to find what he or she wants quickly in a very large data set.

Your resources are pooled or constrained. Result sets are too large to be managed reasonably within your connection and memory limitations.

Paging Strategies That Work

Basic querying and paging strategies can start out simple but quickly lead to disaster if you fail to consider query evolution and data growth. Open-ended or unbounded queries that perform well over small test data sets may degrade sharply against real data. If you don't manage your precious DBMS and memory resources, your problems will only compound under load.

Efficient data retrieval and paging is a trade-off between memory usage and response-time requirements. Broadly speaking, most roll-your-own J2EE paging mechanisms fall into two basic categories:

Cache based: Results are cached for fast access in subsequent pages.

Query based: Results are fetched from the DBMS on demand as the user pages.

Cache-based approaches cache the query results over and above what the database provides, in an intermediate tier (on the HTTP session, in the server using a Stateful Session Bean or in a home-grown cache). Subsequent page requests hit the cache rather than the database. Such cache-based mechanisms are memory intensive and work well for low-volumes, recurring queries, and small to medium-sized result sets. The cache-hit rates are high and the I/O overheads are low, yielding good response times.

Query-based approaches don't use caches. They deliver pages on demand, direct from the DBMS to the client. They service additional pages by issuing more queries to the DBMS rather than pulling data from a cache. These approaches discard or skip unwanted rows from previous or future pages using low-level JDBC functions and context information from the last fetched page. Query-centric paging is memory efficient but requires additional round trips to the database, leading to slightly slower response times overall.

More sophisticated mechanisms adopt a hybrid approach. They constrain cache sizes by caching a fixed number of pages ahead, maintaining bounded cache windows, and using efficient query mechanisms and offline threads to backfill the results transparently to the client.

Caching vs. Query Trade-offs

Cache-based approaches are fast, but they have a few pitfalls. For example, unbounded or open-ended queries for large result sets can lead to uncontrolled memory growth as the results are serialised and cached. Large result sets take a long time to service and take up valuable connection and session resources. Whenever a connection is consumed for long periods of time, the number of connections available in your J2EE shared connection pool is effectively reduced. To cope with high load, your system should aim to service your requests as quickly as possible. If your requests take a long time to process, your overall throughput will drop. You don't want to occupy your resources with long-lived queries, because you won't have any connections and threads left to do anything else.

Long-lived queries can also lead to connection timeouts if your query takes more time to execute than your preset JDBC connection time limit allows. Avoid this in cache-based strategies by narrowing or constraining your search criteria so that your DBMS queries (and results) are bounded.

Caching is most beneficial when the cached data is hit repeatedly. However, if your user searches are consistently yielding distinct results, your caches can't be reused across requests. Worse, if the user rarely pages beyond the first page, your caching within the session is for naught. You should carefully manage caches so that they don't grow too large and they expire promptly when they're no longer required.

Hybrid or query-based approaches are more reliable than cache-based alternatives. They have slightly slower response times but can scale transparently for large result sets and high request volumes. An unbounded query will take a long time to execute but won't exceed your memory constraints or take too long to execute. The DBMS connection is relinquished once the required data (usually the first one or two pages) has been fetched. This means that the connection is held for the bare minimum before being returned to the connection pool. The only downside is that additional context information must be passed back and forth on your page requests.

Table 1 lists the issues you need to consider when deciding on a paging approach.

Conditions for Pagination	Cache-based Approach	Hybrid/Query-based Approach
Is your result data bounded or unbounded?	Applicable for fixed or bounded result sizes; search criteria is fixed or constrained	Applicable for unbounded results sets (such as searches with loose criteria) since the implementation inherently limits result size
How big are your result sets?	Good for small to medium-sized	Good for medium-sized to large
What are your response-time requirements?	When response time is critical	When response time is less critical
How often is the query issued? Do you fetch the same data repeatedly, or is your result data different for each request?	Applicable for when the same data is requested repeatedly	Applicable for when the search criteria and results vary from request to request
How volatile is your (static vs. dynamic)? What are your requirements?	Unchanging or static data can be serviced reliably from caches	If data is dynamic, query every time to return the most up-to-date data

Table 1. Cache-based vs. Hybrid/Query-based Paging Strategies

Query-based Paging Strategies

The key to implementing efficient query-based paging is to limit the I/O to the database so that you fetch only the exact page(s) that you need. Simple approaches query for the entire result set and then iterate over it until they reach the target page, or they use JDBC to fetch from a given row, for example by using the JDBC method ResultSet::absolute(). This guarantees that the only data they serve to the client is the requested page. The ValueListHandler pattern from Sun Microsystems adopts this approach. But beware, you may not incur the cost of serializing redundant data into the application server but the DBMS will have to assemble your results temporarily so that it can move/cursor to the target start row.

One way to guarantee that you never assemble or read redundant data is to manipulate the WHERE clause on your search query to explicitly exclude data that you don't need. In other words, you narrow the query to the requested page. This approach requires that you pass additional context information back and forth on your page requests. This is so that the paging mechanism can adjust the queries automatically to account for data that's already been fetched.

Your page query should be carefully constructed to account for the following:

Paging direction: Forward/next or back/previous

Search criteria: Whether entered by the user or as part of your normal business use case

The target page: Return rows for the requested page only

Page size: Number of rows in a page

Paging direction is important if you want to be able to scroll both forwards and backwards across your result data. Caching as you go can provide back functionality. However, this works well only for static data. If your data is volatile, your cache data may be out of date by the time you page back. The only way to guarantee correct results is to issue another query to fetch the previous page of data. For cacheless paging, this means using SQL ORDER BY and WHERE clauses. If one or more ORDER BY columns specify the forward paging order, you can page backwards by reversing the ORDER BY directions in conjunction with the appropriate WHERE clause.

Basic business data searches usually entail some sort of dynamic WHERE clause construction so that user-entered criteria may be incorporated in the query. With query-based paging, the WHERE clause includes the search criteria as well as additional semantics to narrow the result set to the correct page. Use row identifiers to limit and qualify your page (see Figure 1). A row identifier uniquely identifies a row in a result set and consists of one or more columns from the result set. Think of it as a logical index into you result set.


Figure 1: Query-based Paging Using Row Identifiers

Typically, your row ID can be a primary key. However, depending on the data, it may be a combination of primary key columns and/or other columns. A page is denoted by a start and end row ID pair: the first row and last row in the page, respectively. To page forward (next), adjust the query to fetch all rows where the row ID is greater than the last row ID of the current page. To page back, query for all rows where the row ID is less than the first row ID of the current page.

This mechanism works fine for single-column, simple row IDs and ascending forward paging order, but searches are rarely that simple. In some cases, the row ID is a combination of columns and normal forward paging direction is a mixture of ascending (ASC) and descending (DESC) ORDER BY columns. The trick is to ensure that all your ORDER BY columns are included in the WHERE clause (including the row ID columns) and all the row ID columns are included in the ORDER BY, adjusted for forwards (paging next) and backwards (paging back) ordering.

Row-ID-based Paging Algorithm

Take a basic query example that selects three columns, col1 (VARCHAR), col2 (INTEGER), and col3 (TIMESTAMP), from table foo. To fetch the first page, issue the following SQL:



SELECT 	col1,

col2,

		col3 

FROM 	foo 

WHERE  	col1=? 

ORDER BY 	col2 ASC ,col3 DESC

In this example, the search criteria supplied by the user is applied to col1. The row ID is comprised of col1 and col2, and the normal forward paging order is defined as col2 ascending and col3 descending.

JDBC provides a function to limit the number of rows returned for a query, Statement::setMaxRows(int max). To fetch the first page, simply issue the basic query and set the max rows to your page size. Use this for every paging query as it guarantees that you fetch only one page of data for any given request. For optimum performance, use Statement::setFetchSize(int rows) to set the fetch size to match the page size. This guarantees that the page will be fetched in one low-level IO request between the driver and the DBMS.

To fetch the next page, adjust the WHERE clause to exclude the first page by fetching all rows that match the search criteria and that are logically greater than the last row ID of the first page. The row ID part of the WHERE clause is constructed from the specified row ID columns (col2 and col3) for the query, and the row ID values are substituted from the first page.



Fetch the next page:



SELECT 	col1,

col2,

		col3 

FROM 	foo 

WHERE  	col1=?  AND 

		( (col2 >  ?  )  OR  (col2 = ?  AND col3 <  ?  )  )  

ORDER BY 	col2 ASC ,col3 DESC

To fetch the previous page, flip the ORDER BY's to fetch backwards and adjust the WHERE clause to exclude unwanted rows by fetching rows that are logically less than the row ID of the first row of the current page.



Fetch the previous page:



SELECT 	col1,

col2,

		col3 

FROM 	foo 

WHERE  	col1=?  AND ( (col2 <  ?  )  OR  (col2 = ?  AND col3 >  ?  )  )  

ORDER BY 	col2 DESC ,col3 ASC

In your Java code, ensure that you reorder the results to normal forward ordering before serving the page to the client.

This paging algorithm works seamlessly for very large result sets and arbitrarily complicated or unbounded queries, provided you use the JDBC Statement::setMaxRows() function and construct the WHERE and ORDER BY clauses appropriately. For optimum performance, insure that your WHERE clause columns are indexed.

Put Query-based Paging into Practice

Once you have established your basic query-based paging algorithm, put it into practice by creating a generic, reusable paging component that can be used for any arbitrary simple or complex query. Your paging framework should provide a clear interface, a simple API, and it should encapsulate the low-level internals of the paging implementation and algorithm. It should handle data fetching, transport, row IDs and parameter passing, query manipulation, as well as simple search criteria parameter substitution.

One way to set up this framework is to adopt a configuration-driven or declarative approach in which you pre-define the search as a logical paginated view in a properties file and supply the actual search parameters at runtime with the request. In your configuration file, you can make the view explicitly identify the row IDs, ORDER BY columns, and any other information deemed necessary for your paging implementation. To issue a search, the caller doesn't have to do any fancy SQL footwork. It just identifies and loads the desired view using the view's unique identifier and then issues the search/fetch request along with any user-supplied criteria.

A view is just a logical window across one or more physical DBMS tables and views. A paginated view is a view that contains additional discriminating information (such as row IDs) that enables it to be paged. Configure your paginated view in a properties file and define the forward paging direction (ORDER BY's) and row ids.

The following steps walk you through the creation of a paging component. For a complete package of all the required Java classes, download the source code.

Step 1. Create/configure your paginated view



# Example view

example.view=foo

example.pagesize=5

example.where=col1=?

example.rowids=col2 ASC,col3 DESC

Step 2. Create a class to represent your view, PageDefn

Create a Java class (PageDefn) to represent your paginated view. You can either load it from your properties file or create it on the fly in your code. Configuration is the preferred approach, as the caller doesn't have to know about the view internals or table meta-data. Your PageDefn contains all the information relevant to your paginated view and is responsible for handling the SQL construction details:



public class PageDefn extends ViewDefn {



	public interface PageAction {

		public static final int FIRST = 0;

		public static final int NEXT = 1;

		public static final int PREVIOUS = 2;

		public static final int CURRENT = 3;

	}



	protected int pageSize;

	protected ColumnDesc[] rowIds;





	public PageDefn() {

		super();

		rowIds = null;

		pageSize = 50;





	}



	public PageDefn(String viewname) {

		super(viewname);

		rowIds = null;

		pageSize = 50;

	}



...



}

Step 3: Create a paging data access object (DAO)

Create a special-purpose PagingDAO (see Listing 1: PageDefn.java) that supports parameter substitution and uses Prepared statements. Prepared statements are faster than normal queries as they can be pre-compiled by the DBMS. Your PagingDAO executes the paging query and handles the results. The actual SQL construction is delegated to the PageDefn. This separation of concerns allows you to evolve the PageDefn and its subclasses to support more sophisticated query configuration independently of the DAO.

Ensure that your DAO closes all database resources (ResultSets, Statements, and Connections) once the query has been executed. Put your close code inside a FINALLY clause so that your resources will close even when an exception is thrown.

Step 4. Create a PageContext and Page command

Create a PageCommand class to encapsulate your page request and hold the results. Client servlets and actions will use the PageCommand to interact with your paging framework. Your command should provide methods to do the following:

Specify the target view (PageDefn)

Supply optional search criteria (query parameters)

Specify the page action (FIRST, CURRENT, NEXT, or BACK)

Access the page results

In addition, your PageCommand should encapsulate any context information required by the paging implementation to support your paging algorithm. Create a context object that holds your paging request action and results, and encapsulates your paging internals:



public class PageContext implements Serializable {



	protected Object page; // results

	protected Object firstEntry; //  first row ID 

	protected Object lastEntry; // last row id

	protected int action; // paging action

	protected PageContext prevContext; // previous context state





	public PageContext() {

		this.page = new Object[0];

		this.firstEntry = null;

		this.lastEntry = null;

		this.action = PageDefn.PageAction.FIRST;

	}



	public Object[] getPage() {

		return ((Collection) page).toArray();

	}



	public void setPage(Object page) {

		this.page = page;

	}



	public int getAction() {

		return action;

	}



	

	public void setAction(int action) {

		this.action = action;

	}

}

Ensure that your PageContext object is Serializable, as it will be passed on the wire back and forth between the Servlet and middle tiers.

Create your PageCommand class to encapsulate your paging requests, and include the PageContext as a member variable:



public class PageCommand extends ViewCommand {



	protected PageContext context;



...



}

The PageCommand class is just a data transfer object (DTO) that conveys request parameters and holds page results. Page data and row-IDs are held inside the PageContext object. The caller doesn't have to know about the PageContext attribute directly except to remember to re-use it across page requests for a given read request.

Step 5. Create a PagingService

Create a specialized paging service (see The COR Pattern Puts Your J2EE Development on the Fast Track for more information on COR services and configuration) for handling PageCommand requests. It will process PageCommands and pass them to the PagingDAO for processing:



public class PageService implements Service {



	

	public Command process(Command command) throws ServiceException {

		if (!command.getClass().equals(PageCommand.class)) {

			return null;

		}



		PageCommand pcmd = (PageCommand) command;



		PageContext context = pcmd.getContext();

		PageDefn desc = (PageDefn) pcmd.getDefn();



		// Get A DAO    

		PagingDAO dao = PagingDAO.get();

		// Issue Query, results are set into the context by the DAO

		try {



			dao.executeQuery(desc, context, true);

			return pcmd;

		} catch (DAOException e) {

			throw new ServiceException(e);

		}



	}



}

Step 6. Exercise your Page command!

To fetch the first page, create an instance of PageCommand, load your target view, set any user-supplied parameters and page action, and issue the command to the CORManager. The CORManager will transparently route the command to the PageService to handle:



// load view and set user supplied criteria

PageDefn d = PageDefnFactory.getPDF().createPageDefn(bundle,view);

d.setParams(new Object[] { criteria });

PageCommand cmd = new PageCommand(d);



// fetch the first page

cmd.setAction(PageDefn.PageAction.FIRST);

cmd = (PageCommand) CORManager.get().process(cmd);



// process results

PageContext context = cmd.getContext();



// Process results

Object[] rows = cmd.getContext().getPage();

if (rows == null) return;

for (int i = 0; i < rows.length; ++i) {

	System.out.println("ROW(" + i + ") " + rows[i].toString());

}



// cache context to be reused for subsequent pages..

getServletContext().setAttribute("context",cmd.getContext());

To fetch the next page, insure that you reuse the PageContext from the previous request. The PageContext contains all the information the paging mechanism needs for qualifying your queries. If you're managing the paging from the servlet tier, cache the PageCommand/PageContext object on the HttpSession so that you can reuse it when the user pages forward or back:



// Create PageDefintion

..

PageDefn d = PageDefnFactory.getPDF().createPageDefn(bundle, view);



// Retrieve context from ServletContext

PageContext c = (PageContext) getServletContext().getAttribute("context");



// Create Page Command  

PageCommand cmd = new PageCommand(d,c);

cmd.setAction(PageDefn.PageAction.NEXT);

cmd = (PageCommand) CORManager.get().process(cmd);



// cache result on servlet context

getServletContext().setAttribute("context",cmd.getContext());

...

Current Page Number and Total Page Count

You may want to keep track of the current page number and the total page count. You can display this information to the user, as well as prevent paging past the first or last page. For query-based paging, the simplest approach is to use SQL to count up the total number of rows in the result using the SQL function COUNT(*) or COUNT(column name). You can derive the total number of pages by dividing the number of rows by the page size. You can issue the count query every time you request a page, but this may be too much. Underneath the covers, the DBMS will have to assemble your entire result set to count the results. As a compromise, issue the count query when the first page is requested. This way, the cost is incurred once per search/read request for the first page. In most databases, you will be able to append the COUNT(*) to your column list in your query for the first page. For the databases that don't allow this (like MySQL), issue a separate count query.

The first page will be slightly slower to fetch than other pages. However, your UI will be able to accurately show the total number of pages returned, as well as the current page number. If page count isn't important or the data is so volatile that the total page count isn't reliable, avoid the overhead altogether by skipping the count query.

To add page number and total page count support to your paging mechanism, extend the PageContext object to store and maintain page counts and extend the PagingDAO to issue an additional count query on receipt of a FIRST page request.

Paging in Perspective

Searching and querying over data is an integral part of most Web sites. Paging is an ideal way to manage limited server resources, large result sets, and congested UI real estate. The approach you chose, whether cache-based, query-based, or hybrid, depends on your use cases and data characteristics. Regardless, you should limit your memory and connection usage so that your paging architecture can scale efficiently to meet your performance targets.

Lara D'Abreo is an independent consultant with over 10 years experience in commercial product development in the US, Japan, and the UK. She's currently based out of Sydney, Australia and spends her time trying to make J2EE systems run faster.

DevX is a division of Jupitermedia Corporation

© Copyright 2005 Jupitermedia Corporation. All Rights Reserved. Legal Notices

Posted by 아름프로

트랙백 : 댓글

J2EE 1.4 Glossary

J2EE/docs

2005. 2. 11. 08:53

Glossary

J2EE v1.4 Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

abstract schema: The part of an entity bean's deployment descriptor that defines the bean's persistent fields and relationships.
abstract schema name: A logical name that is referenced in EJB QL queries.
access control: The methods by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints.
ACID: The acronym for the four properties guaranteed by transactions: atomicity, consistency, isolation, and durability.
activation: The process of transferring an enterprise bean from secondary storage to memory. (See passivation.)
anonymous access: Accessing a resource without authentication.
applet: A J2EE component that typically executes in a Web browser but can execute in a variety of other applications or devices that support the applet programming model.
applet container: A container that includes support for the applet programming model.
application assembler: A person who combines J2EE components and modules into deployable application units.
application client: A first-tier J2EE client component that executes in its own Java virtual machine. Application clients have access to some J2EE platform APIs.
application client container: A container that supports application client components.
application client module: A software unit that consists of one or more classes and an application client deployment descriptor.
application component provider: A vendor that provides the Java classes that implement components' methods, JSP page definitions, and any required deployment descriptors.
application configuration resource file: An XML file used to configure resources for a JavaServer Faces application, to define navigation rules for the application, and to register converters, validators, listeners, renderers, and components with the application.
archiving: The process of saving the state of an object and restoring it.
asant: A Java-based build tool that can be extended using Java classes. The configuration files are XML-based, calling out a target tree where various tasks get executed.
attribute: A qualifier on an XML tag that provides additional information.
authentication: The process that verifies the identity of a user, device, or other entity in a computer system, usually as a prerequisite to allowing access to resources in a system. The Java servlet specification requires three types of authentication-basic, form-based, and mutual-and supports digest authentication.
authorization: The process by which access to a method or resource is determined. Authorization depends on the determination of whether the principal associated with a request through authentication is in a given security role. A security role is a logical grouping of users defined by the person who assembles the application. A deployer maps security roles to security identities. Security identities may be principals or groups in the operational environment.
authorization constraint: An authorization rule that determines who is permitted to access a Web resource collection.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

B2B: Business-to-business.
backing bean: A JavaBeans component that corresponds to a JSP page that includes JavaServer Faces components. The backing bean defines properties for the components on the page and methods that perform processing for the component. This processing includes event handling, validation, and processing associated with navigation.
basic authentication: An authentication mechanism in which a Web server authenticates an entity via a user name and password obtained using the Web application's built-in authentication mechanism.
bean-managed persistence: The mechanism whereby data transfer between an entity bean's variables and a resource manager is managed by the entity bean.
bean-managed transaction: A transaction whose boundaries are defined by an enterprise bean.
binary entity: See unparsed entity.
binding (XML): Generating the code needed to process a well-defined portion of XML data.
binding (JavaServer Faces technology): Wiring UI components to back-end data sources such as backing bean properties.
build file: The XML file that contains one or more asant targets. A target is a set of tasks you want to be executed. When starting asant, you can select which targets you want to have executed. When no target is given, the project's default target is executed.
business logic: The code that implements the functionality of an application. In the Enterprise JavaBeans architecture, this logic is implemented by the methods of an enterprise bean.
business method: A method of an enterprise bean that implements the business logic or rules of an application.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

callback methods: Component methods called by the container to notify the component of important events in its life cycle.
caller: Same as caller principal.
caller principal: The principal that identifies the invoker of the enterprise bean method.
cascade delete: A deletion that triggers another deletion. A cascade delete can be specified for an entity bean that has container-managed persistence.
CDATA: A predefined XML tag for character data that means "don't interpret these characters," as opposed to parsed character data (PCDATA), in which the normal rules of XML syntax apply. CDATA sections are typically used to show examples of XML syntax.
certificate authority: A trusted organization that issues public key certificates and provides identification to the bearer.
client-certificate authentication: An authentication mechanism that uses HTTP over SSL, in which the server and, optionally, the client authenticate each other with a public key certificate that conforms to a standard that is defined by X.509 Public Key Infrastructure.
comment: In an XML document, text that is ignored unless the parser is specifically told to recognize it.
commit: The point in a transaction when all updates to any resources involved in the transaction are made permanent.
component: See J2EE component.
component (JavaServer Faces technology): See JavaServer Faces UI component.
component contract: The contract between a J2EE component and its container. The contract includes life-cycle management of the component, a context interface that the instance uses to obtain various information and services from its container, and a list of services that every container must provide for its components.
component-managed sign-on: A mechanism whereby security information needed for signing on to a resource is provided by an application component.
connection: See resource manager connection.
connection factory: See resource manager connection factory.
connector: A standard extension mechanism for containers that provides connectivity to enterprise information systems. A connector is specific to an enterprise information system and consists of a resource adapter and application development tools for enterprise information system connectivity. The resource adapter is plugged in to a container through its support for system-level contracts defined in the Connector architecture.
Connector architecture: An architecture for integration of J2EE products with enterprise information systems. There are two parts to this architecture: a resource adapter provided by an enterprise information system vendor and the J2EE product that allows this resource adapter to plug in. This architecture defines a set of contracts that a resource adapter must support to plug in to a J2EE product-for example, transactions, security, and resource management.
container: An entity that provides life-cycle management, security, deployment, and runtime services to J2EE components. Each type of container (EJB, Web, JSP, servlet, applet, and application client) also provides component-specific services.
container-managed persistence: The mechanism whereby data transfer between an entity bean's variables and a resource manager is managed by the entity bean's container.
container-managed sign-on: The mechanism whereby security information needed for signing on to a resource is supplied by the container.
container-managed transaction: A transaction whose boundaries are defined by an EJB container. An entity bean must use container-managed transactions.
content: In an XML document, the part that occurs after the prolog, including the root element and everything it contains.
context attribute: An object bound into the context associated with a servlet.
context root: A name that gets mapped to the document root of a Web application.
conversational state: The field values of a session bean plus the transitive closure of the objects reachable from the bean's fields. The transitive closure of a bean is defined in terms of the serialization protocol for the Java programming language, that is, the fields that would be stored by serializing the bean instance.
CORBA: Common Object Request Broker Architecture. A language-independent distributed object model specified by the OMG.
create method: A method defined in the home interface and invoked by a client to create an enterprise bean.
credentials: The information describing the security attributes of a principal.
CSS: Cascading style sheet. A stylesheet used with HTML and XML documents to add a style to all elements marked with a particular tag, for the direction of browsers or other presentation mechanisms.
CTS: Compatibility test suite. A suite of compatibility tests for verifying that a J2EE product complies with the J2EE platform specification.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

data: The contents of an element in an XML stream, generally used when the element does not contain any subelements. When it does, the term content is generally used. When the only text in an XML structure is contained in simple elements and when elements that have subelements have little or no data mixed in, then that structure is often thought of as XML data, as opposed to an XML document.
DDP: Document-driven programming. The use of XML to define applications.
declaration: The very first thing in an XML document, which declares it as XML. The minimal declaration is <?xml version="1.0"?>. The declaration is part of the document prolog.
declarative security: Mechanisms used in an application that are expressed in a declarative syntax in a deployment descriptor.
delegation: An act whereby one principal authorizes another principal to use its identity or privileges with some restrictions.
deployer: A person who installs J2EE modules and applications into an operational environment.
deployment: The process whereby software is installed into an operational environment.
deployment descriptor: An XML file provided with each module and J2EE application that describes how they should be deployed. The deployment descriptor directs a deployment tool to deploy a module or application with specific container options and describes specific configuration requirements that a deployer must resolve.
destination: A JMS administered object that encapsulates the identity of a JMS queue or topic. See point-to-point messaging system, publish/subscribe messaging system.
digest authentication: An authentication mechanism in which a Web application authenticates itself to a Web server by sending the server a message digest along with its HTTP request message. The digest is computed by employing a one-way hash algorithm to a concatenation of the HTTP request message and the client's password. The digest is typically much smaller than the HTTP request and doesn't contain the password.
distributed application: An application made up of distinct components running in separate runtime environments, usually on different platforms connected via a network. Typical distributed applications are two-tier (client-server), three-tier (client-middleware-server), and multitier (client-multiple middleware-multiple servers).
document: In general, an XML structure in which one or more elements contains text intermixed with subelements. See also data.
Document Object Model: An API for accessing and manipulating XML documents as tree structures. DOM provides platform-neutral, language-neutral interfaces that enables programs and scripts to dynamically access and modify content and structure in XML documents.
document root: The top-level directory of a WAR. The document root is where JSP pages, client-side classes and archives, and static Web resources are stored.
DOM: See Document Object Model.
DTD: Document type definition. An optional part of the XML document prolog, as specified by the XML standard. The DTD specifies constraints on the valid tags and tag sequences that can be in the document. The DTD has a number of shortcomings, however, and this has led to various schema proposals. For example, the DTD entry <!ELEMENT username (#PCDATA)> says that the XML element called username contains parsed character data-that is, text alone, with no other structural elements under it. The DTD includes both the local subset, defined in the current file, and the external subset, which consists of the definitions contained in external DTD files that are referenced in the local subset using a parameter entity.
durable subscription: In a JMS publish/subscribe messaging system, a subscription that continues to exist whether or not there is a current active subscriber object. If there is no active subscriber, the JMS provider retains the subscription's messages until they are received by the subscription or until they expire.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

EAR file: Enterprise Archive file. A JAR archive that contains a J2EE application.
ebXML: Electronic Business XML. A group of specifications designed to enable enterprises to conduct business through the exchange of XML-based messages. It is sponsored by OASIS and the United Nations Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport (U.N./CEFACT).
EJB: See Enterprise JavaBeans.
EJB container: A container that implements the EJB component contract of the J2EE architecture. This contract specifies a runtime environment for enterprise beans that includes security, concurrency, life-cycle management, transactions, deployment, naming, and other services. An EJB container is provided by an EJB or J2EE server.
EJB container provider: A vendor that supplies an EJB container.
EJB context: An object that allows an enterprise bean to invoke services provided by the container and to obtain the information about the caller of a client-invoked method.
EJB home object: An object that provides the life-cycle operations (create, remove, find) for an enterprise bean. The class for the EJB home object is generated by the container's deployment tools. The EJB home object implements the enterprise bean's home interface. The client references an EJB home object to perform life-cycle operations on an EJB object. The client uses JNDI to locate an EJB home object.
EJB JAR file: A JAR archive that contains an EJB module.
EJB module: A deployable unit that consists of one or more enterprise beans and an EJB deployment descriptor.
EJB object: An object whose class implements the enterprise bean's remote interface. A client never references an enterprise bean instance directly; a client always references an EJB object. The class of an EJB object is generated by a container's deployment tools.
EJB server: Software that provides services to an EJB container. For example, an EJB container typically relies on a transaction manager that is part of the EJB server to perform the two-phase commit across all the participating resource managers. The J2EE architecture assumes that an EJB container is hosted by an EJB server from the same vendor, so it does not specify the contract between these two entities. An EJB server can host one or more EJB containers.
EJB server provider: A vendor that supplies an EJB server.
element: A unit of XML data, delimited by tags. An XML element can enclose other elements.
empty tag: A tag that does not enclose any content.
enterprise bean: A J2EE component that implements a business task or business entity and is hosted by an EJB container; either an entity bean, a session bean, or a message-driven bean.
enterprise bean provider: An application developer who produces enterprise bean classes, remote and home interfaces, and deployment descriptor files, and packages them in an EJB JAR file.
enterprise information system: The applications that constitute an enterprise's existing system for handling companywide information. These applications provide an information infrastructure for an enterprise. An enterprise information system offers a well-defined set of services to its clients. These services are exposed to clients as local or remote interfaces or both. Examples of enterprise information systems include enterprise resource planning systems, mainframe transaction processing systems, and legacy database systems.
enterprise information system resource: An entity that provides enterprise information system-specific functionality to its clients. Examples are a record or set of records in a database system, a business object in an enterprise resource planning system, and a transaction program in a transaction processing system.
Enterprise JavaBeans (EJB): A component architecture for the development and deployment of object-oriented, distributed, enterprise-level applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and secure.
Enterprise JavaBeans Query Language (EJB QL): Defines the queries for the finder and select methods of an entity bean having container-managed persistence. A subset of SQL92, EJB QL has extensions that allow navigation over the relationships defined in an entity bean's abstract schema.
entity: A distinct, individual item that can be included in an XML document by referencing it. Such an entity reference can name an entity as small as a character (for example, <, which references the less-than symbol or left angle bracket, <). An entity reference can also reference an entire document, an external entity, or a collection of DTD definitions.
entity bean: An enterprise bean that represents persistent data maintained in a database. An entity bean can manage its own persistence or can delegate this function to its container. An entity bean is identified by a primary key. If the container in which an entity bean is hosted crashes, the entity bean, its primary key, and any remote references survive the crash.
entity reference: A reference to an entity that is substituted for the reference when the XML document is parsed. It can reference a predefined entity such as < or reference one that is defined in the DTD. In the XML data, the reference could be to an entity that is defined in the local subset of the DTD or to an external XML file (an external entity). The DTD can also carve out a segment of DTD specifications and give it a name so that it can be reused (included) at multiple points in the DTD by defining a parameter entity.
error: A SAX parsing error is generally a validation error; in other words, it occurs when an XML document is not valid, although it can also occur if the declaration specifies an XML version that the parser cannot handle. See also fatal error, warning.
Extensible Markup Language: See XML.
external entity: An entity that exists as an external XML file, which is included in the XML document using an entity reference.
external subset: That part of a DTD that is defined by references to external DTD files.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

fatal error: A fatal error occurs in the SAX parser when a document is not well formed or otherwise cannot be processed. See also error, warning.
filter: An object that can transform the header or content (or both) of a request or response. Filters differ from Web components in that they usually do not themselves create responses but rather modify or adapt the requests for a resource, and modify or adapt responses from a resource. A filter should not have any dependencies on a Web resource for which it is acting as a filter so that it can be composable with more than one type of Web resource.
filter chain: A concatenation of XSLT transformations in which the output of one transformation becomes the input of the next.
finder method: A method defined in the home interface and invoked by a client to locate an entity bean.
form-based authentication: An authentication mechanism in which a Web container provides an application-specific form for logging in. This form of authentication uses Base64 encoding and can expose user names and passwords unless all connections are over SSL.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

general entity: An entity that is referenced as part of an XML document's content, as distinct from a parameter entity, which is referenced in the DTD. A general entity can be a parsed entity or an unparsed entity.
group: An authenticated set of users classified by common traits such as job title or customer profile. Groups are also associated with a set of roles, and every user that is a member of a group inherits all the roles assigned to that group.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

handle: An object that identifies an enterprise bean. A client can serialize the handle and then later deserialize it to obtain a reference to the enterprise bean.
home handle: An object that can be used to obtain a reference to the home interface. A home handle can be serialized and written to stable storage and deserialized to obtain the reference.
home interface: One of two interfaces for an enterprise bean. The home interface defines zero or more methods for managing an enterprise bean. The home interface of a session bean defines create and remove methods, whereas the home interface of an entity bean defines create, finder, and remove methods.
HTML: Hypertext Markup Language. A markup language for hypertext documents on the Internet. HTML enables the embedding of images, sounds, video streams, form fields, references to other objects with URLs, and basic text formatting.
HTTP: Hypertext Transfer Protocol. The Internet protocol used to retrieve hypertext objects from remote hosts. HTTP messages consist of requests from client to server and responses from server to client.
HTTPS: HTTP layered over the SSL protocol.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

IDL: Interface Definition Language. A language used to define interfaces to remote CORBA objects. The interfaces are independent of operating systems and programming languages.
IIOP: Internet Inter-ORB Protocol. A protocol used for communication between CORBA object request brokers.
impersonation: An act whereby one entity assumes the identity and privileges of another entity without restrictions and without any indication visible to the recipients of the impersonator's calls that delegation has taken place. Impersonation is a case of simple delegation.
initialization parameter: A parameter that initializes the context associated with a servlet.
ISO 3166: The international standard for country codes maintained by the International Organization for Standardization (ISO).
ISV: Independent software vendor.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

J2EE: See Java 2 Platform, Enterprise Edition.
J2EE application: Any deployable unit of J2EE functionality. This can be a single J2EE module or a group of modules packaged into an EAR file along with a J2EE application deployment descriptor. J2EE applications are typically engineered to be distributed across multiple computing tiers.
J2EE component: A self-contained functional software unit supported by a container and configurable at deployment time. The J2EE specification defines the following J2EE components:

Application clients and applets are components that run on the client.
Java servlet and JavaServer Pages (JSP) technology components are Web components that run on the server.
Enterprise JavaBeans (EJB) components (enterprise beans) are business components that run on the server.

J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and "standard" Java classes is that J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE server or client container.

J2EE module: A software unit that consists of one or more J2EE components of the same container type and one deployment descriptor of that type. There are four types of modules: EJB, Web, application client, and resource adapter. Modules can be deployed as stand-alone units or can be assembled into a J2EE application.
J2EE product: An implementation that conforms to the J2EE platform specification.
J2EE product provider: A vendor that supplies a J2EE product.
J2EE server: The runtime portion of a J2EE product. A J2EE server provides EJB or Web containers or both.
J2ME: See Java 2 Platform, Micro Edition.
J2SE: See Java 2 Platform, Standard Edition.
JAR: Java archive. A platform-independent file format that permits many files to be aggregated into one file.
Java 2 Platform, Enterprise Edition (J2EE): An environment for developing and deploying enterprise applications. The J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multitiered, Web-based applications.
Java 2 Platform, Micro Edition (J2ME): A highly optimized Java runtime environment targeting a wide range of consumer products, including pagers, cellular phones, screen phones, digital set-top boxes, and car navigation systems.
Java 2 Platform, Standard Edition (J2SE): The core Java technology platform.
Java API for XML Processing (JAXP): An API for processing XML documents. JAXP leverages the parser standards SAX and DOM so that you can choose to parse your data as a stream of events or to build a tree-structured representation of it. JAXP supports the XSLT standard, giving you control over the presentation of the data and enabling you to convert the data to other XML documents or to other formats, such as HTML. JAXP provides namespace support, allowing you to work with schema that might otherwise have naming conflicts.
Java API for XML Registries (JAXR): An API for accessing various kinds of XML registries.
Java API for XML-based RPC (JAX-RPC): An API for building Web services and clients that use remote procedure calls and XML.
Java IDL: A technology that provides CORBA interoperability and connectivity capabilities for the J2EE platform. These capabilities enable J2EE applications to invoke operations on remote network services using the Object Management Group IDL and IIOP.
Java Message Service (JMS): An API for invoking operations on enterprise messaging systems.
Java Naming and Directory Interface (JNDI): An API that provides naming and directory functionality.
Java Secure Socket Extension (JSSE): A set of packages that enable secure Internet communications.
Java Transaction API (JTA): An API that allows applications and J2EE servers to access transactions.
Java Transaction Service (JTS): Specifies the implementation of a transaction manager that supports JTA and implements the Java mapping of the Object Management Group Object Transaction Service 1.1 specification at the level below the API.
JavaBeans component: A Java class that can be manipulated by tools and composed into applications. A JavaBeans component must adhere to certain property and event interface conventions.
JavaMail: An API for sending and receiving email.
JavaServer Faces Technology: A framework for building server-side user interfaces for Web applications written in the Java programming language.
JavaServer Faces conversion model: A mechanism for converting between string-based markup generated by JavaServer Faces UI components and server-side Java objects.
JavaServer Faces event and listener model: A mechanism for determining how events emitted by JavaServer Faces UI components are handled. This model is based on the JavaBeans component event and listener model.
JavaServer Faces expression language: A simple expression language used by a JavaServer Faces UI component tag attributes to bind the associated component to a bean property or to bind the associated component's value to a method or an external data source, such as a bean property. Unlike JSP EL expressions, JavaServer Faces EL expressions are evaluated by the JavaServer Faces implementation rather than by the Web container.
JavaServer Faces navigation model: A mechanism for defining the sequence in which pages in a JavaServer Faces application are displayed.
JavaServer Faces UI component: A user interface control that outputs data to a client or allows a user to input data to a JavaServer Faces application.
JavaServer Faces UI component class: A JavaServer Faces class that defines the behavior and properties of a JavaServer Faces UI component.
JavaServer Faces validation model: A mechanism for validating the data a user inputs to a JavaServer Faces UI component.
JavaServer Pages (JSP): An extensible Web technology that uses static data, JSP elements, and server-side Java objects to generate dynamic content for a client. Typically the static data is HTML or XML elements, and in many cases the client is a Web browser.
JavaServer Pages Standard Tag Library (JSTL): A tag library that encapsulates core functionality common to many JSP applications. JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization and locale-specific formatting tags, SQL tags, and functions.
JAXR client: A client program that uses the JAXR API to access a business registry via a JAXR provider.
JAXR provider: An implementation of the JAXR API that provides access to a specific registry provider or to a class of registry providers that are based on a common specification.
JDBC: An API for database-independent connectivity between the J2EE platform and a wide range of data sources.
JMS: See Java Message Service.
JMS administered object: A preconfigured JMS object (a resource manager connection factory or a destination) created by an administrator for the use of JMS clients and placed in a JNDI namespace.
JMS application: One or more JMS clients that exchange messages.
JMS client: A Java language program that sends or receives messages.
JMS provider: A messaging system that implements the Java Message Service as well as other administrative and control functionality needed in a full-featured messaging product.
JMS session: A single-threaded context for sending and receiving JMS messages. A JMS session can be nontransacted, locally transacted, or participating in a distributed transaction.
JNDI: See Java Naming and Directory Interface.
JSP: See JavaServer Pages.
JSP action: A JSP element that can act on implicit objects and other server-side objects or can define new scripting variables. Actions follow the XML syntax for elements, with a start tag, a body, and an end tag; if the body is empty it can also use the empty tag syntax. The tag must use a prefix. There are standard and custom actions.
JSP container: A container that provides the same services as a servlet container and an engine that interprets and processes JSP pages into a servlet.
JSP container, distributed: A JSP container that can run a Web application that is tagged as distributable and is spread across multiple Java virtual machines that might be running on different hosts.
JSP custom action: A user-defined action described in a portable manner by a tag library descriptor and imported into a JSP page by a taglib directive. Custom actions are used to encapsulate recurring tasks in writing JSP pages.
JSP custom tag: A tag that references a JSP custom action.
JSP declaration: A JSP scripting element that declares methods, variables, or both in a JSP page.
JSP directive: A JSP element that gives an instruction to the JSP container and is interpreted at translation time.
JSP document: A JSP page written in XML syntax and subject to the constraints of XML documents.
JSP element: A portion of a JSP page that is recognized by a JSP translator. An element can be a directive, an action, or a scripting element.
JSP expression: A scripting element that contains a valid scripting language expression that is evaluated, converted to a String, and placed into the implicit out object.
JSP expression language: A language used to write expressions that access the properties of JavaBeans components. EL expressions can be used in static text and in any standard or custom tag attribute that can accept an expression.
JSP page: A text-based document containing static text and JSP elements that describes how to process a request to create a response. A JSP page is translated into and handles requests as a servlet.
JSP scripting element: A JSP declaration, scriptlet, or expression whose syntax is defined by the JSP specification and whose content is written according to the scripting language used in the JSP page. The JSP specification describes the syntax and semantics for the case where the language page attribute is "java".
JSP scriptlet: A JSP scripting element containing any code fragment that is valid in the scripting language used in the JSP page. The JSP specification describes what is a valid scriptlet for the case where the language page attribute is "java".
JSP standard action: An action that is defined in the JSP specification and is always available to a JSP page.
JSP tag file: A source file containing a reusable fragment of JSP code that is translated into a tag handler when a JSP page is translated into a servlet.
JSP tag handler: A Java programming language object that implements the behavior of a custom tag.
JSP tag library: A collection of custom tags described via a tag library descriptor and Java classes.
JSTL: See JavaServer Pages Standard Tag Library.
JTA: See Java Transaction API.
JTS: See Java Transaction Service.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

keystore: A file containing the keys and certificates used for authentication.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (top)

life cycle (J2EE component): The framework events of a J2EE component's existence. Each type of component has defining events that mark its transition into states in which it has varying availability for use. For example, a servlet is created and has its init method called by its container before invocation of its service method by clients or other servlets that require its functionality. After the call of its init method, it has the data and readiness for its intended use. The servlet's destroy method is called by its container before the ending of its existence so that processing associated with winding up can be done and resources can be released. The init and destroy methods in this example are callback methods. Similar considerations apply to the life cycle of all J2EE component types: enterprise beans, Web components (servlets or JSP pages), applets, and application clients.
life cycle (JavaServer Faces): A set of phases during which a request for a page is received, a UI component tree representing the page is processed, and a response is produced. During the phases of the life cycle:

The local data of the components is updated with the values contained in the request parameters.
Events generated by the components are processed.
Validators and converters registered on the components are processed.
The components' local data is updated to back-end objects.

The response is rendered to the cl

Posted by 아름프로

트랙백 : 댓글

Enterprise JavaBeans (EJB) Architecture (White Papers)

J2EE/docs

2005. 2. 11. 08:51

Automatic Database Schema Generation in Sun Java System Application Server and J2EE 1.4 SDK

Enterprise JavaBeans[tm] Technology vs. COM+/MTS

Enterprise JavaBeans[tm] Technology vs. COM+/MTS - Industry Quotes and White Papers.

Posted by 아름프로

트랙백 : 댓글

Java Servlet & JSP (White Papers)

J2EE/docs

2005. 2. 11. 08:50

The Java Servlet API White Paper

The secret's out: Java[tm] technology isn't just for programming applets which run on the client side in web browsers, or for writing Internet applications.

JSP

This page lists content under White Papers for JSP

Posted by 아름프로

트랙백 : 댓글

J2EE Connector Architecture(White Paper)

J2EE/docs

2005. 2. 11. 08:47

White Paper

J2EE Connector Architecture

Integrating Java applications with existing Enterprise Applications

Executive Summary

The J2EE Connector Architecture, part of Java 2 Platform, Enterprise Edition (J2EE) 1.3, specifies a standard architecture for accessing resources in diverse Enterprise Information Systems (EIS). These may include ERP systems such as SAP R/3, mainframe transaction processing systems such as IBM CICS, legacy applications and non-relational database systems.

Today, the JDBC Data Access API provides easy integration with relational database systems for Java applications. In a similar manner, the Connector Architecture simplifies integration of Java applications with heterogeneous EIS systems.

This paper describes the 1.0 version of the Connector Architecture specification at a high level, including:

System contracts defined between the J2EE platform-based application server and the EIS resource adapter, providing security, connection pooling, and transaction management facilities.

Common Client Interface (CCI) between the EIS resource adapter and application components or tools.

Packaging and deployment of resource adapters in an application server environment.

The Connector Architecture Specification document contains detailed information
on the architecture. The specification and the latest information on the Connector Architecture can be found at http://java.sun.com/j2ee/connector.

Introduction

Most companies have enormous investments in Enterprise Information Systems (EISs) such as ERP systems, legacy systems, mainframe database and transaction processing systems. Today, leveraging these systems as part of a web-based, multi-tiered application is challenging. EIS vendors provide proprietary interfaces, with varying levels of support for enterprise application integration. Application server vendors have to build and maintain separate interfaces for different supported EISs, and application developers need to manage the system-level issues of security, transactions and connection pooling within the applications themselves.

Challenges in EIS integration

Integration with EISs presents many challenges.

The back end EISs are complex and heterogeneous. The application programming models vary widely between these systems, increasing the complexity and effort of application integration. Application development tools that can simplify these integration efforts are critical.

Transaction and security management add complexity to integration with back-end EIS systems.

The web-based architecture requires significant scalability in terms of the potential number of clients that can access enterprise applications.

J2EE Platform and Connector Architecture

The Connector Architecture addresses these challenges directly. The J2EE platform provides a reusable component model, using Enterprise JavaBeans and JavaServer Pages technologies to build and deploy multi-tier applications that are platform and vendor-independent. The J2EE platform shares the "Write Once, Run Anywhere" approach of the Java platform, and has significant industry support.

The Connector Architecture adds simplified EIS integration to this platform. The goal is to leverage the strengths of the J2EE platform -- including component models, transaction and security infrastructures -- to address the challenges of EIS integration.

The Connector Architecture defines a common interface between application servers and EIS systems, implemented in EIS-specific resource adapters that plug into application servers. The result is simplified enterprise application integration, using a scalable, standard architecture that leverages the benefits of the J2EE platform.

Figure: Using the Connector Architecture, each EIS only writes one Connector Architecture-compliant resource adapter, and each application server extends its system once to support integration with any number of EIS resource adapters and underlying EISs.

Developing a standard contract between application components, application servers and EISs reduces the overall scope of the integration effort. This delivers benefits for the entire Java development community:

EIS vendors only need to create one, open interface (implemented in the resource adapter) to the EIS. This resource adapter can be used with any compliant J2EE application server, and provides a standard interface for tool and Enterprise Application Integration (EAI) vendors. Maintaining a single interface reduces the development effort for the EIS vendor, who today must build point solutions targeted at individual vendors and certify individual systems for compliance.

Application Servers vendors (vendors of any compliant J2EE servers) only need to extend their systems once to support the system contracts defined by the Connector Architecture. Then they can simply plug in multiple resource adapters to extend the server, supporting integration with multiple EISs without any EIS-specific system-level programming.

Enterprise Application Integration (EAI) and development tool vendors use the Common Client Interface (CCI) to simplify access to EIS resources with a standard application-level interface.

Application component developers are shielded from the complexity of transaction, connection and security concerns when accessing data or functions in EISs and can concentrate instead on developing business and application logic.

The Connector Architecture is the product of the Java Community Process program, with the contributions of a wide range of tool, server, and EIS vendors.

Connector Architecture Overview

The Connector Architecture is implemented in an application server and an EIS-specific resource adapter. A resource adapter is a system library specific to an EIS and provides connectivity to the EIS. A resource adapter is analogous to a JDBC driver. The interface between a resource adapter and the EIS is specific to the underlying EIS; it can be a native interface.

The Connector Architecture has three main components:

System level contracts between the resource adapter and the application server.

Common Client Interface that provides a client API for Java applications and development tools to access the resource
adapter.

Standard packaging and deployment facility for resource adapters.

Figure: The Connector Architecture defines system contracts between the application server and the resource adapter. It also defines a client API between the resource adapter and application components. These contracts are described further in this paper.

The containers in an application server can be web containers (hosting JSP pages and Servlets) and EJB containers. The application server provides a set of services in an implementation-specific way. These services include transaction manager, security services manager and connection pooling mechanism. The Connector Architecture does not define how an application server implements these different services.

The application server vendor extends the server to support the system contracts defined by the Connector Architecture. The system contracts can be considered as a Service Provider Interface (SPI). The SPI provides a standard way for extending a container to support connectivity to multiple EISs.

The EIS vendor (or a third party ISV) creates a resource adapter for the EIS, using an EIS-specific interface to interact with the EIS itself and supporting the system contracts for the application server. In addition, the resource adapter provides a client API called the Common Client Interface, or CCI, defined by the Connector Architecture. Application development tools or application components use the Common Client Interface to interact with the resource adapter directly.

The resource adapter runs in the application server's address space and manages access to the EIS resources. A Connector Architecture-compliant resource adapter will work with any compliant J2EE server.

System-Level Contracts

The 1.0 version of the Connector Architecture provides the following system contracts, to be implemented by the resource adapter and the application server:

Connection management

Transaction management

Security management

For the 1.0 release these contracts cover the most pressing concerns for enterprise application integration: transactions, security, and scalability. In future versions of the specification, the system contracts will be extended to include support for Java Message Service (JMS) pluggability and thread management. The JMS pluggability will add support for asynchronous message-based communication.

The following sections offer brief overviews of these contracts.

Connection Management Contract

A connection to an EIS is an expensive system resource. To support scalable applications, an application server needs to pool connections to the underlying EISs. This connection pooling mechanism should be transparent to applications accessing the underlying EIS, simplifying application development.

The Connection Management contract supports connection pooling and management, optimizing application performance and increasing scalability. The Connection Management contract is defined between an application server and a resource adapter. It provides support for an application server to implement its connection pooling facility. The application server structures and implements its connection pool in an implementation specific way - the pool can be very primitive or advanced depending on the quality of services offered by the application server.

The application server uses the connection management contract to:

create new connections to an EIS

configure connection factories in the JNDI namespace

find the right connection from an existing set of pooled connections

The connection management contract enables an application server to hook in its services, such as transaction management and security management.

Transaction Management Contract

Transactional access to EISs is an important requirement for business applications. The Connector Architecture supports the concept of transactions - a number of operations that must be committed together or not at all for the data to remain consistent and to maintain data integrity.

In many cases, a transaction (termed local transaction) is limited in scope to a single EIS system, and the EIS resource manager itself manages such transaction. While an XA transaction (or global transaction) can span multiple resource managers. This form of transaction requires transaction coordination by an external transaction manager, typically bundled with an application server. A transaction manager uses a two-phase commit protocol to manage a transaction that spans multiple resource managers (EISs). It uses one-phase commit optimization if only one resource manager is participating in an XA transaction.

The connector architecture defines a transaction management contract between an application server and a resource adapter (and its underlying resource manager). The transaction management contract extends the connection management contract and provides support for management of both local and XA transactions.The transaction management contract has two parts, depending on the type of transaction.

JTA XAResource based contract between a transaction manager and an EIS resource manager

Local transaction management contract

These contracts enable an application server to provide the infrastructure and runtime environment for transaction management. Application components rely on this transaction infrastructure to support the component-level transaction model.

Because EIS implementations are so varied, the transactional support must be very flexible. The Connector Architecture imposes no requirements on the EIS for transaction management. Depending on the implementation of transactions within the EIS, a resource adapter may provide:

No transaction support at all - this is typical of legacy applications and many back-end systems.

Support for only local transactions

Support for both local and XA transactions

An application server is required to support all three levels of transactions. This ensures that application servers can support EISs at different transaction levels.

Security Contract

It is critical that an enterprise be able to depend on the information in its EIS for its business activities. Any loss or inaccuracy of information or any unauthorized access to the EIS can be extremely costly to an enterprise. There are mechanisms that can be used to protect an EIS against such security threats, including:

Identification and authentication of principals (human users) to verify they are who they claim to be.

Authorization and access control to determine whether a principal is allowed to access an application server and/or an EIS.

Security of communication between an application server and an EIS. Communication over insecure links can be protected using a protocol (for example, Kerberos) that provides authentication, integrity, and confidentiality services. Communication can also be protected by using a secure links protocol (for example, SSL).

The Connector Architecture extends the J2EE security model to include support for secure connectivity to EISs.

The security management contract is defined to be independent of security mechanisms and technologies. This enables application servers and EISs with different levels of support for security technology to support the security contract. For example, the security management contract can support basic user-password based authentication or a Kerberos-based end-to-end security environment. It can also support EIS-specific security mechanisms.

EIS Sign-on

Creating a new physical connection requires a sign-on to an EIS. Changing the security context on an existing physical connection can also require EIS sign-on; the latter is termed re-authentication. An EIS sign-on typically involves one or more of the following steps:

Determining a security principal under whose security context a physical connection to an EIS will be established.

Authentication of a security principal if it is not already authenticated.

Establishing a secure association between the application server and the EIS. This enables additional security mechanisms (example, data confidentiality and integrity) to be applied to communication between the two entities.

Access control to EIS resources

The Connector Architecture supports single sign on across multiple EISs. Single sign-on capabilities are useful in applications that need access to resources in multiple EIS systems. For example, an employee self-service application can give employees access to HR and Payroll records with a single sign on.

The Security Contract extends the Connection Management contract to support EIS sign re-authentication of pooled connections as necessary.

Common Client Interface

The CCI defines a standard client API for application components. The CCI enables application components and Enterprise Application Integration (EAI) frameworks to drive interactions across heterogeneous EISs using a common client API.

The target users of the CCI are enterprise tool vendors and EAI vendors. Application components themselves may also write to the API, but the CCI is a low-level API. The specification recommends that the CCI be the basis for richer functionality provided by the tool vendors, rather than being an application-level programming interface used by most application developers.

Challenges of Client Tool Integration

The heterogeneity challenges of EIS/application server integration also hold true for enterprise application development tools vendors and EAI frameworks. Typically, EISs provide proprietary client APIs. An application development tool or EAI framework needs to adapt these different client APIs to a higher abstracted layer. This abstracted layer raises the API to a common level on which tools and EAI vendors build useful functionality.

The CCI solves this problem by providing an API that is common across heterogeneous EISs. This avoids the need for tool and EAI vendors to adapt diverse EIS-specific client APIs. These vendors can use the CCI to build higher-level functionality over the underlying EISs.

Common Client Interface

The CCI defines a remote function-call interface that focuses on executing functions on an EIS and retrieving the results.The CCI is independent of a specific EIS; for example: data types specific to an EIS. However, the CCI is capable of being driven by EIS-specific metadata from a repository.

The CCI enables applications to create and manage connections to an EIS, execute an interaction, and manage data records as input, output or return values. The CCI is designed to be toolable, leveraging the JavaBeans architecture and Java Collection framework.

The 1.0 version of the Connector Architecture recommends that a resource adapter support CCI as its client API, while it requires that the resource adapter implement the system contracts. A resource adapter may choose to have a client API different from CCI, such as the client API based on the JDBC API.

JDBC API and Connectors

The relationship between the JDBC API and Connectors should be understood from the perspectives of application contract and system contracts.

The JDBC API defines a standard client API for accessing relational databases, while the CCI defines an EIS-independent client API for EISs that are not relational databases. The JDBC API is the recommended API for accessing relational databases while CCI is the recommended client API for other types of EISs.

At the system contract level, the connector SPIs may be viewed as a generalization and enhancement of JDBC 2.0 contracts.
Future JDBC specifications may align with the Connector SPIs by offering it as an option with JDBC 2.0 SPIs. Another option for application server vendors is to wrap JDBC drivers under the Connector system contracts.

Packaging and Deployment

The Connector Architecture provides packaging and deployment interfaces, so that various resources adapters can easily plug into compliant J2EE application servers in a modular manner.

A resource adapter provider develops a set of Java interfaces and classes as part of its implementation of a resource adapter. These Java classes implement Connector Architecture-specified contracts and EIS-specific functionality provided by the resource adapter. The development of a resource adapter can also require use of native libraries specific to the underlying EIS.

The Java interfaces and classes are packaged together (with required native libraries, help files, documentation, and other resources) with a deployment descriptor to create a Resource Adapter Module. A deployment descriptor defines the contract between a resource adapter provider and a deployer for the deployment of a resource adapter.

A resource adapter module may be deployed as a shared, stand-alone module or packaged as part of a J2EE application.
During deployment, the deployer installs a resource adapter module on an application server and then configures it into the target operational environment. The configuration of a resource adapter is based on the properties defined in the deployment descriptor as part of the resource adapter module.

Connector Architecture and Enterprise Application Integration

To illustrate the potential benefits of the Connector Architecture, this section provides two scenarios from different
perspectives.

Integrating an EIS with Multiple Tools and Servers

A software vendor provides an ERP system focused on mid-sized manufacturing companies. Its customers are starting to build multi-tier, Java applications and want to build tightly coupled integration between these applications and the vendor's ERP system.

Although the ERP vendor may publish an API, not all of the application server vendors support it. Also the ERP system's customers are using a number of different application servers, presenting a potential logistical problem for the ERP vendor.

Instead of building or certifying interfaces for each system, the ERP vendor creates a single resource adapter using the Connector Architecture. This resource adapter implements Connector Architecture specified connection, security, and transaction contracts. The vendor then makes this adapter available, and informs customers that they can work with any compliant J2EE application server. The ERP vendor also implements the CCI in its resource adapter, opening up access directly to client components, or to a wide range of application development or EAI tools.

Using the Connector Architecture significantly reduces the ERP vendor's development efforts, giving it immediate integration
and consistent operations with a wide variety of compliant J2EE tools and application servers

Business-to-Business Commerce Solution

The following scenario illustrates the use of the Connector Architecture in a Business-to-Business supply chain solution.

Wombat Corporation is a manufacturer implementing a B2B e-commerce solution that improves interactions with its suppliers. Like most manufacturers, Wombat has enormous investments in its existing EIS systems, including an ERP system and a mainframe transaction processing system.

Wombat buys a compliant J2EE application server (called B2B server in this example) that supports interactions with multiple buyers/suppliers using XML and HTTP/HTTPS. Wombat integrates access to its EIS systems using off-the-shelf resource adapters that plug into the B2B server. Wombat can deploy as many resource adapters as it has EISs to integrate. An application server can "plug in" multiple resource adapters for the systems required for an application.

This scenario illustrates an important point: the Connector Architecture is designed for creating tightly coupled integration -- typically integration within the enterprise. Operations between different companies, such as a manufacturer and its supplier, are generally loosely coupled; for this, XML messaging is more appropriate.

The Evolution of the Connector Architecture

The Connector Architecture is a product of the Java Community Process program, an open process used by the Java community to develop and revise Java technology and specifications. Sun's partners in the Connector effort are EIS vendors, development tool vendors, and EAI vendors. Key participants include BEA, Fujitsu, IBM, Inline, Inprise, iPlanet, Motorola, Oracle, SAP, Sybase, Tibco, and Unisys. To date the standard experiences strong industry support, as all stakeholders stand to benefit from its adoption.

The 1.0 release of the J2EE Connector Architecture specification does not address all of the interfaces and system contracts that could potentially be required. The goal of the 1.0 release was to address the most pressing needs in a way that would speed industry adoption of the standard. For example, the 1.0 release specifies three system-level contracts, described above. These are mandatory components of the interface. Future system level contracts may address thread management and messaging through Java Message Service (JMS).

The Common Client Interface (CCI) is optional in the 1.0 implementation. The Connector Architecture does not address the issue of meta data for data representation and type mapping, which will certainly be relevant in the use of CCI. This issue will be addressed in future versions.

Summary

Just as the JDBC API extended the Java platform to integrate relational databases, the Connector Architecture extends the J2EE platform to integrate and extend the EISs that manage valuable processes and data in the enterprise. The Connector Architecture enables scalable, simplified access to valuable enterprise resources, without compromising data integrity or security on the EISs.