There are already numerous ADF applications that have been developed these latest years, mostly using Business Components in the model layer.
With the increased need of SOA processes and mobile applications based on web services, there is a big and growing need of exposing the same functionality via web services.
According to the documentation “the same application module can support interactive web user interfaces using ADF data controls and web service clients”.
Based on my latest experience I cannot agree to this statement to be always true or functional or effective or a good practice.
In real life applications there are big pitfalls depending on the custom code already implemented in the middle tier to support the web user interface. Some of these:
- CurrentRow; the current row is not preserved during web services operations. Any code related to the current row (viewObject.getCurrentRow()) will not generally return the expected result.
- DBSequence; A common method to populate primary keys in ADF entities in ADF 11g was to use the DBSequence attribute type or a custom equivalent. This is a problem in web services methods when creating such records, since we cannot know the id of the records to be created so we cannot find the records in order to perform any action before it is returned to the client.
- ListOfValues; ADF Business Component models developed to support rich ADF user interfaces usually include lists of values (LOVs) defined in ViewObjects to facilitate validation and interactive selection. The only usage of these LOV definitions when the same AMs are used in web services would be to validate the input value. Yet, is it always worth to incur the LOV validation performance cost to carry one value selection? Especially in choice lists where all rows are fetched, are not cached and where a simple SQL validator could be much more efficient?
- based on recent experience, list of values have some issues in SDO as we have found in JDeveloper 11.1.1.7
- Their value cannot be set to null even if they are optional
- A LOV dependent to other attribute is not revalidated on update of the attribute.
- A LOV dependent on an attribute coming from an associated entity fails validation since the associated attributes are not populated in time
- Security; Security in ADF user interfaces is quite different than in web services. Any existing code in Business components referring to ADFContext or SecurityContext, will fail.
- LifeCycle; The user interface lifecycle and Partial Page Rendering (PPR) allow dependencies to attributes and rows to be refreshed or recalculated according to the user actions. This is not the case when they are used in web services.
- Tuning; Tuning application modules for user interface usage and for web service usage is quite different than in web services. i.e. pooling configuration (passivation – activation) does not have a meaning in web services since everything happens in a single HTTP transaction.
A re-usability idea would be to extend existing Business Components in order to override the functionality and make it more usable for Web Services as needed. This causes even more problems:
- In overridden ViewObjects, attributes, even when overridden cannot change their names, or order, or remove an associated LOV list.
- The accessors of the parent ViewObject have strange behavior (when there is a reference to another ViewObject, then the create method of the view row is invoked every time, essentially duplicating the parent (!)
Finally, the generated ADF code for Application modules exposed as web services is not very helpful; the default ViewObject operations that can be exposed (Create, Merge, Update, Delete) do not provide adequate hooks to implement custom logic. (E.g. to perform something after the Create operation of a master/deetail is executed but before the data is posted). And we observed certain behaviors that quite possibly are SR candidates – for example when using the default methods, the entity validations are not functioning as expected. When an entity validation fails, the value is not set, yet, an error is not thrown.
Therefore, In general, my opinion is that ADF Business Components developed to support user interface applications should not lightly be assumed to be automatically suitable for web services. A careful assessment is needed, as the effort to override typical user interface supporting functionality is too much.
If the entities and associations are well designed, they can be reused in order to create new view objects, view links and new application modules in order to expose as web services. This, in my opinion, is the proper level of reuse.
- Workaround for disclosed af:query issue on ADF 12.2.1 - December 2, 2016
- Reusing ADF Business Components to develop web services - September 11, 2015