Alternatives

Owned by Richard Olrichs
Last updated: 15 May 2015 by Wilfred van der Deijl

Before we go on to describing the functionality of the XML Data Control and how this product can be used. It might be wise to look at the alternatives, why is there a need for a new product? How are ADF Developers currently working with XML within ADF? And why would we want to change this current fashion?

For using XML in ADF, or more specifically calling web services from ADF, there are roughly 3 current methods in use for doing this. The first one is make use of the default ADF Web Service Data Control, provided by Oracle and shipped with the product. An alternative approach is the use of programmatic ADF Business Components and last but not least there is the option of creating Bean Data Controls on your custom POJO model.

ADF Web Service Data Control

In ADF there is an ADF Web Service Data Control for calling web services. This is a standard ADF feature / component, that in a declarative way can call simple web services. For example, stock and weather reports and such. However, this is less practical for calling more complex web services, it is not great in dealing with complex payloads and it does not allow you to manipulate the data after calling the web services.

 For more details, also see Frank Nimphius his article in the Oracle Magazine of july/august 2012. To quote Frank: “SOAP-based Web services and Oracle ADF can be integrated in several different ways. Oracle ADF’s Web Service Data Control feature is easiest to configure at design time, but it does not provide much control of a service’s runtime behavior, nor of the exchanged data. Thus, using Web Service Data Control is best for simple interactions only.”

 We were gunning for the same declarative working and easy set up as the ADF Web Service Data Control has, however, it would be unacceptable to not manipulate any data in an easy way or to handle complex payloads that come from our BPM tasks or web services.

Programmatic Business Components

An alternative for the ADF Web Service Data Control can be the use of Programmatic Business Components (ADF BC). This is a good option for applications that already use ADF BC, to benefit from the knowledge developers already got with BC as well as BC features as master-detail relations and model-driven LOVs.

 This solution uses the standard Java-API (JAX-WS), supported in JDeveloper to generate Proxy classes based on the WSDL location. Oracle recommends to use the pattern of a Java Bean wrapper around these Proxy Classes. Resulting in a stable API for ADF BC to communicate with and decouple the ADF BC layer from the Web Service.

 This options seems less obvious when the project does not already use ADF BC. This will force you to introduce ADF BC in your project, while you actually want to work with ADF on a web service. It forces the developer to keep in mind ADF BC specific subjects such as Application Module pooling, passivating/activating and more.

Another disadvantage is that the Entity and View Objects have to be manually created based on the resultset of the Proxy Service generated by JDeveloper. Keep in mind that a web service is usually not specific for one client, which may result in unwanted resultsets.  Next to that the needed ADF BC Framework (Java) code, can become very complex and hard to maintain. ADF BC is built for a database driven model layer and re-implementing all of these database features in a web service environment can be a challenge or simply impossible. Things like commit, rollback to savepoint, row locking, database cursor handling, entity fault-in selects, make it very hard to implement all ADF BC features in a non-database environment. Most of the time you end up with a limited implementation and a developer needs to know which methods of all ADF BC classes can be invoked and which will fail.

POJO Bean Data Control

A different alternative to the ADF Web Service Data Control is an POJO Bean Data Control. This is a Data Control based on a POJO (‘Plain Old Java Objects’) model. As with the Programmatic Business Components, this uses the Proxy Classes generated by JDeveloper based on a WSDL location.

This method seems to be the current de facto standard within ADF. JDeveloper supports the creating of out of the box Proxy Services based on the web services and a lot of ADF developers are already comfortable with creating Bean Data Controls on a Managed Bean in ADF.

 The developer needs to create mapper classes to map the data from the proxy service to the POJO objects and back. This does not require extensive knowledge of Java or ADF and is relatively simple. However, since these mapper classes are strongly tight to the implementation in the proxy classes, the developer needs to redo a lot (if not all) of his work when the service changes her interface, namespace or structure. 

Although the Java code is not necessary complex, there is still a need to write Java, meaning there is a possibility of developers making mistakes. Code tend to have bugs and the more code we write, the harder the application gets to maintain.