‹#›
1
2
The Idea: Unified Remote Data Provider for ADF
Application development of today requires advanced frameworks that enable to create rich UI applications and be free in working with remote databases through Internet.
Let's see how these two demands can be fulfilled for the Oracle Application Development Framework.
Here are the facts that already exist today:
- ADF is a basis framework, which accumulates all aspects of application development; it includes ADF Swing which allows to create rich User Interface applications
- Oracle surveys show that high percentage of business applications are developed as rich desktop-style applications with ADF and Swing
- web services have become a standard for program communications over Internet
These facts have led to the idea:
To create the web service that performs data source operations for ADF in remote database.
ADF should access this web service in the lowest model level, so that this routing would be transparent for the upper levels of framework
As the benefits we expect:
- ADF model layer gets unified interface for working with remote data providers
- ADF upper layers – including ADF Swing - inherit remotability from the model layer
So, we get both demands fulfilled – ADF together with web service data source allow to build rich UI Swing applications accessing remote databases through Internet.
3
Basic Role of ADF Business Components
Now let's see which existing ADF features allow the WSDS solution to be realized.
For the beginning, here is a picture taken from ADF Developer's Guide.
It shows overall ADF architecture.
Important is the basic role of ADF Business Components. It is a core framework, which is recommended by Oracle for building database-centric business services.
JDeveloper builds applications based on ADF Business Components, with User Interface of different types, including Swing.
4
ADF BC: Programmatic Data Source Mode
By default, ADF BC provide data interchange with database by mean of JDBC calls.
However, this default behavior can be changed because API clearly defines methods in every class, which implement data source functions. We need to override these methods in order to create our own data source processing.
The WSDS solution goes right this way - we create extended BC classes with programmatic implementation of data source methods. All JDBC requests to database are replaced by requests to the web service data source.
The solution is suitable for several latest versions of ADF or BC4J - since those where data source methods appear in Business Components API. For example, in our company we use production framework based on BC4J version from JDeveloper 9.0.3.
5
ADF BC and Web Service Data Source: Overall Picture
The WSDS solution has 4 main program units:
1st element: MyViewObjectImpl class
This is an entity-based programmatic view object according to ADF Developers's Guide.
It represents query results making calls to WSDS Client for creating data collection.
2nd element: MyEntityImpl class
Its role is to handle DML operations in programmatic mode.
WSDS Client is called for processing in remote database.
3rd element: WSDS Client
It's a bridge to the web service.
The class provides methods for the above My-objects to fulfill their needs in data source operations and conducts SOAP interchange with remote web service.
4th element: Web Service Data Source
It's a port to the database.
It executes incoming data source operations against underlying database
Now let's see these components in detail. We will move from ADF needs for data processing, so we will also see how ADF defines necessary operations in the web service.
6
MyViewObjectImpl: Programmatic View Object
The class inherits basic ADF behavior from oracle.jbo.server.ViewObjectImpl class and is responsible for managing programmatic data collection.
For that, it overrides data source methods, they are:
- executeQueryForCollection()‏
- hasNextForCollection()‏
- createRowFromResultSet()‏
- getQueryHitCount()‏
1st method - executeQueryForCollection() - is the most important, because it performs all actions needed for receiving results of the query by mean of WSDS client.
Preparing request to WSDS client, the method takes from ADF all necessary properties that define the expected rowset. Here are the request parameters and appropriate ADF methods used:
- query SQL statement
     is constructed from getQuery(), getWhereClause(), getOrderByClause() mtds
- query parameters - are taken from the method arguments
- number of rows in range - returned by getMaxFetchSize() method
- jdbc fetch size for WSDS - the value from getFetchSize()‏
In return, the method gets from WSDS client:
- total count of rows in the query
- two-dimensional array of values representing requested rowset used as new programmatic data collection
For further fulfilling its model functions, the new class overrides row manipulation methods - insertRow() and removeCurrentRow() - which results should be reflected in programmatic data collection.
ADF Developer's Guide contains detailed description for programmatic view object in the chapter "27.8 Using Programmatic View Objects for Alternative Data Sources".
7
MyEntityImpl: Posting Changes Programmatically
The class inherits basic ADF behavior from oracle.jbo.server.EntityImpl class and is responsible for data changes in programmatic mode.
This new class provides alternative implementation for data source dependent methods, replacing default JDBC processing with calls to WSDS client.
Here are the affected methods:
- postChanges()‏
- doSelect()‏
- doDML()‏
- lock()‏
1st method is an explicit point to call if DML operation isn't invoked by ADF as result of Transaction.commit(). So, it should be called in programmatic mode from the application's new “commit” processor, we will see this later.
2nd method is used to refresh entity content from the database, in fact, it's a query that is processed by ExecuteQuery operation discussed before.
3rd method defines new WSDS operation - "ExecuteDML".
Programmatic mode is based on Entity and Attribute states provided by ADF. These states define DML action and its parameters, including modified attributes and their new values. Getting names from static definitions, we construct the entire SQL statement. Together with new attribute values, this statement enters  into parameters to WSDS client.
4th method prevents default JDBC call for locking the row in database. In programmatic mode, we just ignore this call because we don't manage database transactions from the client.
8
WSDS Client: Bridge to the Web Service
The client's purpose is to call web service operations on behalf of certain user.
To protect transmitted content during its movement through Internet, secure HTTPS protocol is used.
User credentials are sent in every request. For that, application security provider (EnvInfoProvider) should be available for getting user name and password at runtime.
The class extends the stub generated by JDeveloper from the web service WSDL file. This stub contains all necessary commands for creating SOAP requests, sending them to the web service, and parsing returned responses.
In previous slides we've detected that ADF programmatic mode requires two data source operations for the web service to be a data provider:
- ExecuteQuery (query, params, fetchSize, rangeSize)‏
- ExecuteDML (statement, params)‏
The client has methods to call these web service operations following the rules defined in the web service WSDL file.
Another responsibility is to convert data presentation between ADF and SOAP.
For that, all transmitted values are supplemented with type-indicators, which are well-known for the client and the web service.
9
Web Service Data Source: Port to the Database
The purpose is to perform requested operations in the local database on behalf of specified user.
User name and password are placed in every request. The web service starts any operation by getting JDBC connection to the database, assuming that the user is registered and his rights are defined.
To protect transmitted content during its movement across Internet, secure HTTPS protocol is used.
The web service is implemented as stateless document-literal style service.
Being a data source for ADF, the web service has two operations: ExecuteQuery and ExecuteDML. Request to each operation includes SQL statement, its parameters together with type-indicators, and other properties for making JDBC call to the database.
The web service converts data between SOAP and JDBC types using accompanied type-indicators.
ExecuteQuery operation returns fetched rowset together with its metadata including column names and types.
ExecuteDML operation returns optional result – primary key of inserted row.
10
Transaction Processing: Site Autonomy
Describing the web service, we have noticed that it is stateless. In case of DML operations, this means that each request determines completed transaction, and  the web service finishes its processing by commit or rollback depending on result of DML command in database.
Such behavior conforms to SOA principles of “autonomy” and “loose coupling” which declare service relationship with minimum dependencies and full service control over the encapsulated logic.
We've seen before that MyEntityImpl class which invokes DML requests to WSDS, overrides lock() method in super class. It's done to ignore row-lock request to database when client application makes first change in the row. As result, no transaction is started in database. Otherwise, web service should support transaction (or session) states between client requests.
ADF Swing framework provides client-side transaction status in the data binding objects. Transaction state methods are used for managing visual states of UI data-bound components. For example, buttons of JUNavigationBar object which control commit, rollback, insert and delete operations become enabled or disabled depending on current transaction state.
Client application invokes commit action by calling postChanges() method in MyEntityImpl object. For rollback action, the rowset can be simply refreshed from the database. In both cases, current transaction state should be changed to “off” by appropriate call to ADF bindings framework.
11
How To Switch into WSDS Mode
Assuming that all WSDS components are installed, existing ADF Swing application can be changed into the new mode in few actions.
1) Business Components project:
- each EntityImpl class should extend the new MyEntityImpl class
- each ViewObjectImpl class should extend the new MyViewObjectImpl class
- bc4j.xcfg file: remove all JDBC-related elements
2) View project:
We need to replace default JDBC processing for DML operations.
In simple case, the two necessary changes have to be made.
First, “commit” action should call MyEntityImpl.postChanges() method for the modified row.
Second, “delete row” action should invoke “commit” for the deleted row.
12
Usage Experience: 1+ Year of Success
Our company's business is based on information from the highly distributed sources. The area of responsibility includes Russia, Ukraine, Baltic States, and other countries, which entered the former USSR in the past. Since the covered territory is too large, a number of remote offices have been created in order to get closer to the sources of information.
Central office is located in Latvia. There is a place of the central database. Our leading IT specialists are situated there also. All existing technology solutions were created initially in the central office. We are working with Oracle products for more than 10 years.
Our company's everyday activity requires rich UI desktop applications for managing stored data of complex structure. Therefore we made a choice of Swing UI since the time when JDeveloper declared its JClient framework, later ADF Swing.
 
Until recently, these Swing applications were able to work only in the central office, because existing approaches required high quality and costly communication lines.
The role of remote office was limited. Obtained information was just sent to the central office by e-mail. Central office should have a staff of operators for inputting the received data into database. In other words, information technology, which is based on accumulated experience, was started only here, in the central office.
The WSDS solution allowed us to deliver the same technology into every remote office. Now the process can be divided for gaining better efficiency. Initial input into database is done exactly at the site where information appears. Depending on staff qualification degree, finishing operations can remain for experts in the central office or even be relayed to those in remote office.
Currently, WSDS applications are installed in offices located in 5 countries. These are applications of two types: (1) ADF Swing desktop clients and (2) batch Java procedures. In the latter case, WSDS client is used explicitly - not within ADF Business Components - for transmitting SQL statements to the web service. One example of batch procedure is remote loading of source (XML or Excel) documents into the database.
13