Before you begin
Consider using the dynamic query service (available with Integration Server) when any of the following are true:
If you have a query that has a high frequency of execution you should define it as a finder or select method and consider using SQLJ as a deployment option for best performance. The dynamic query service always uses JDBC and must parse and process the EJB query at runtime.
If you need security control over which queries a user can execute, you need to define the queries as finder or select methods and use EJB method authorization. The dynamic query service does not have fine grain security control at this time. You can control who is permitted access to the remote query bean and the local query bean, but once authorized a user can execute any valid query and return any data in the server.
Why and when to perform this task
The dynamic query API is a stateless session bean. Using the dynamic query API is similar to using any other J2EE EJB application bean.
The default JNDI name for the query bean is as follows, but your system administrator can change this name:
com/ibm/websphere/ejbquery/Query
The system administrator might need to install the query.ear application into the application server. The WebSphere product install does this only for the default server.
Note: The query.ear file is located in the <WAS_HOME>/installableApps directory where <WAS_HOME> is the location of the WebSphere Application Server.
The query bean has both a remote and a local interface to support both remote and local clients.
To use the local interface or bean methods on the
remote interface of the query bean, you must configure your server to use
the following:
Application Classloader Policy = SINGLEUsing a value of MULTI may result in your application being unable to find the local interface for the query bean home.
The following Jar files comprise the query service:
Jar | Location | Usage |
---|---|---|
query.jar | server - AppServer/lib | query parser |
qjcup.jar | server - AppServer/lib | auxillary classes for parser |
querybean.jar | server - installedApps | query session bean |
querymd.jar | server - AppServer/lib | auxillary classes for parser |
queryws.jar | server - AppServer/lib | adapter classes for runtime |
qryclient.jar | client | client stubs and classes |
Steps for this task
The results of the query are returned for remote clients as:
com.ibm.websphere.ejbquery.QueryIteratoror for local clients as:
com.ibm.websphere.ejbquery.QueryLocalIterator
If you want to return remote EJB references from the query, or if the query statement contains remote methods, you must use the query remote interface.
If you want to return local EJB references from the query, or if the query statement contains local methods, you must use the query local interface.
Calling the next() method on the iterator returns an intance of com.ibm.websphere.ejbquery.IQueryTuple, which contains the actual data values or object references. The iterator also contains the following methods:
getFieldName( int i) getFieldsCount( );
For more details, see the following articles:
The WebSphere Sample Gallery contains a complete working example of the dynamic query service.
Security Considerations. WebSphere does not have security access control for CMP and CMR fields. You must therefore secure the query bean methods executeQuery(), prepareQuery(), and executePlan(), and the create() method on the query home; otherwise, any user is able to perform a dynamic query and retrieve data from your application.