ADF best practice to give webservice calls

I need to know what are the best practice of integrating SOA architecture in ADF application. I mean i do not want the usual way of directly interacting with database from VOs or EOs.

I have webservices deployed in a different server which i need to invoke from ADF application running on WLS.

Lets say suppose our project architecture is as follows:

1. Design and code the web service endpoint interface. : The first step in creating a web service is to design and code its endpoint interface, in which you declare the methods that a web service remote client may invoke on the service.

2. Write a configuration file : We have to write a configuration file with few details like Service name, namespace, package name, target namespace etc . This file will help us to generate a WSDL file.

So here for point no 6 i need the clarification like from which layer(Model or ViewController) its the best to invoke the proxies and hit the webservice. If from model then what are the different ways and if from Viewcontroller then what are the different ways.

It is always good idea to call web services from Model layer since it is part of business service component.

Putting web services call in view controller layer i.e. managed bean need to be last choice for particular
validation scenario apart from that we can use web services as data control for directly deriving GUI fromweb services which is also good practice.

I want some body to explore the best practices of how to show webservices data using VO Object in table and form format.
If VO has few thousands records and if we need one field value from webserices based on input of one of VO attribute thenwhat would the best implementation.

* I want some body to explore the best practices of how to show
webservices data using VO Object in table and form format. *
* If VO has few thousands records and if we need one field value from
webserices based on input of one of VO attribute then *
* what would the best implementation. *

Nive coincidence as this is exactly the topic of my next Oracle
Magazine article that publishes in the July / August edition. So in
brief (as a sneak preview) here are your options

Below is my current thinking for this matter:
==================================
Option 1: I recommend this integration for all developers who
primarily work with ADF Business Components as their business service
and who need to integrate Web Services (e.g. as a look up). By using a
programmatic View Object (and entity if you need the WS to be
updateable through ADF BC) you expose a single Data Control to teh
application developer. ADF BC more or less neglects the fact that you
are talking to a Web Service.

Option 2: This is an easy to use declarative option that is good for
simple Web Services that don't require you to intercept WS data
queries and submission. Its good for accessing weather report
services, stock quotes and similar. I would not recommend this for
complex services like Siebel Web Services. If you have a choice
(meaning you have developers that understand Java) I would forget
about this option and go for the more complex option 3

Option 3: This actually uses the JAX-WS proxy client to access the
remote Web Service, allowing you to interact with the client / service
communication.

Best practices
===================================
1. Integrate services on the model layer and expose them through a
DataControl (ADF BC, POJO DC)
2. Always create a wrapper object to access the WS proxy client. Never
work directly against the client so your custom code survives re-
generating the client
3. When using programmatic view objects in ADF BC to access the Web
Service, still make sure you use a POJO as an abstraction layer
instead of coding the WS proxy client access directly into the VO Impl
class.
4. Consider caching strategies for fetched data (this is what a POJO
layer is also good for)
5. Treat the access layer (POJO, VO, EO) as an abstraction layer that
encapsulates the service call. If you can write generic (abstract)
framework extension classes as a vehicle for fellow developers to
implement best practices. This also includes to think about
parametrization of the WS proxy client access

Keep in mind that no Web Service is designed for a specific client. In
the ADF Business Components case this means that probably the WS
doesn't provide an API for query pagination or getEstimatedRowCount.
If you own the Web Service and you know the clients accessing it, try
to provide additional information.

Nice overview Frank.
I have been involved with various customers that need to call web
services from their ADF app.
My experience with these customers fits nicely with your
recommendations.

The problem is that the ADF wizards seduce developers to ignore your
recommendations.

The typical process these customers go through:
- they start with option 2: so easy
- they quickly discover that it doesn't work for more complex web
services, and that they lack control
- they move to option 3 (without abstraction layer)
- that works better, unfortunately along the way some of the
back-end web services change which turns out to have a dramatic
impact on all layers. They need to redo their pages and data
binding. So, they add the abstraction layer on top of the generated
proxies.
- if the web services are transactional, and need to deal with
larger data sets, they find themselves adding a lot of plumbing code
to implement caching, handle pagination and implement business
rules. They are also forced to add lots of Execute and
ExecuteWithParams method activities in their task flows to prevent
looking at stale data since ADF auto-caches inside the ADF binding
layer. (btw, reusing the same page def for multiple pages can
prevent that in many cases)
And wasn't ADF meant to provide all that out-of-the-box, well yes,
if you use ADF BC...
- so they end up with option 1. A great option, at my current
customer we moved from option 3 (with abstraction) to option 1, and
developer productivity has increased signifcantly (while we got a
lot of novice ADF devs added to the project!).

So I believe that option1 is really the way to go. Option 3 (or 2)
is only applicable when you are calling very simple read-only web
services.

However, the problem with option 1 is that it requires in-depth
knowledge of ADF BC to create the required programmatic base
classes.

Together, these samples provide a good start, but on every project I
find myself mixing,matching (and upgrading to R11) these samples,
removing and adding some functionality, based on specific
requirements of the customer.

I think the ADF community would greatly benefit from an up-to-date
sample application with reusable base classes working against a POJO
layer that supports ALL features (well almost all, some are DB
specific) that are standard with ADF BC based on tables. Including:
- various paging modes
- view criteria and model-based search
- model-based LOV's
- Merging queried data with modified and new data.
- RowMatch qualifiers for in-memory filtering
- Refresh after insert/update
- Locking

Would be great if Oracle and ADF EMG can somehow join forces to make
this happen. And the final step would be to extend the standard ADF
BC wizard with this POJO option...

The current project my team has been working on uses a fair bit of
web services to integrate to other systems, so I'd just like to
share what we've been doing so far. Whether they are best practices
or not would be up to discussion. Please feel free to comment and
discuss on the approach.

Current Approach
One of the simpler services that we use is, to call an exposed web
service to retrieve a list of Rate Codes. This then gets displayed
in a ADF table for the user to select.

We use jDev generated WS proxies to connect to the web service.
There is also an additional WS handler that takes care of the web
service security. The host/port information of the endpoint is
stored in a DB table. We build a programmatic VO that converts the
Rate Code web service object into a RateCodeVO and expose it through
the AM. So the web service is consumed on the model layer rather
than on the view controller.

Some other alternatives that we have explored

Generating a data control directly from the web service, and
using the service directly on the page.

Exposing the web service directly from the AM as a client
interface method. (Skip the programmatic VO)

Calling the web service from the BackingBean, then binding the
value to the page.

Why we picked this approach

It shields the view controller (to a certain extent) to
changes in the web service, if there are changes in the service
signatures, the web service objects, the impact to the
ViewController is not high.

The ViewController does not care about the underlying
technology in the model, it only interacts through the DataControl
layer. It also makes it easier to maintain as we know the
ViewController will only interact with our Model layer. Because
we make use of different web services to different other
systems, this approach does not require the developers working
View layer to know/care about the data source.

In the end, we pick ease-of-maintainance of the codes over (perhaps)
efficiency.

On the topic of "If VO has few thousands records and if
we need one field value from webservices based on input of one of
VO attribute then what would the best implementation."

Currently, what my team does is maintain a stale copy of the value
as part of our DB record. We also store the timestamp of when this
value was last updated, and provide an option to the user to refresh
the value of the single record in the UI.

Another approach that you can consider, is by changing the web
service to accept a list of, say, 500 values from your VO, and
return a list of 500 results, then you can batch up your web service
calls.

I just came across this thread while researching web service data controls. Thanks everyone for the great discussion and links. Our 11g application decision for which initial design and build out done 5 years ago was to use normal BC view objects for data display but any data updates were to go through a web service call that usually involved refreshing a form a table afterwards to see the results of the call. We used service proxies, at first called from the doDML method of the entity to try and fake the user/developer that a normal commit was being performed. That proved too complex to implement and confusing for developers to maintain so most of the service calls now are done in backing beans. It would be better if they were in the AM but most are not. (lots of different developers and staff changes over time so developers leaned towards examples of what was simple and easy to implement). We use a proxy factory to wrap the proxy and allow us to change the end
point based on a configuration file and also inject performance logging
for each web service call. I've recently been investigating web service data controls because I've never used one and doing this declaratively sounded intriguing. I was able to get one implementation working this week but I wouldn't say it was simple. I have these concerns

I haven't discovered how to inject performance logging for every web service data control nor how to display the actual web service request/response xml for debugging (other than to step into the ADF code and evaluate methods).

I'm also not sure yet how to configure the end point for different environments (dev/qa/production).

Cryptic errors are displayed directly to the user and I don't know how to catch those and display more appropriate user friendly messages when a call fails (as in a communications error or web service error in the header with no payload).

These things were easy to do in java when calling a proxy. The declarative approach seems difficult to add extra plumbing. It sounds like the programmatic view object technique would be a good option but I haven't explored that yet. As already stated, a complete example would be very beneficial. Since this thread is over a year old does anyone have additional insight or know of some better examples. Also does anyone have answers to my 3 concerns above?

On Wednesday, March 21, 2012 7:15:56 AM UTC-6, Sanjeeb wrote:

Hi,

I need to know what are the best practice of integrating SOA architecture in ADF application. I mean i do not want the usual way of directly interacting with database from VO or EOs.

I have webservices deployed in a different server which i need to invoke from ADF application running on WLS.

Lets say suppose our project architecture is as follows:

1. Design and code the web service endpoint interface. : The first step in creating a web service is to design and code its endpoint interface, in which you declare the methods that a web service remote client may invoke on the service.

2. Write a configuration file : We have to write a configuration file with few details like Service name, namespace, package name, target namespace etc . This file will help us to generate a WSDL file.

So here for point no 6 i need the clarification like from which layer(Model or ViewController) its the best to invoke the proxies and hit the webservice. If from model then what are the different ways and if from Viewcontroller then what are the different ways.

Don, for the point3, getting the cryptic errors, extending the DCErrorHandlerImpl, will help you to avoid such errors. It happened to me while I was working with MBeans, which used to throw weird exceptions,

after keeping my custom class by extending DCErrorHandlerImpl, I could avoid propagating it to the UI. Hope it works for you.