|ADF best practice to give webservice calls||Sanjeeb||3/21/12 6:15 AM|
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.
3. Generate WSDL file.
4. Generate Proxies :By giving the WSDL location we can generate proxy clients from Jdeveloper.
5. Deploy the webservice : We deploy the Webservices build in step 1 in a different server(sps. Tomcat ).
6. Invoke Webservice from client : From ADF view or model we can invoke respective proxy clients methods that got generated in step 4.
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.
Looking forward to hear from you all soon.
|Re: [ADF EMG] ADF best practice to give webservice calls||Hasamali Saiyed||3/21/12 8:08 AM|
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 from
web 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 then
what would the best implementation.
|Re: [ADF EMG] ADF best practice to give webservice calls||Sanjeeb||3/21/12 10:10 PM|
Thanks Hasim and Soumik for your valuable inputs.
Yeah i know its the best practice to give webservice calls from Model but i need to know different approaches for achieving the same.
We can expose the webservices as datacontrol and use them but by doing so we would be ignoring many ADf out of box features like ADF query component,Graphs etc.
|Re: ADF best practice to give webservice calls||fnimphiu||3/22/12 7:19 AM|
* 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
Option 1 - Programmatic View Object (entity)
Option 2 - Web Service DataControl
Option 3 - Pojo DataControl and JAX WS
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
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
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.
|Re: [ADF EMG] Re: ADF best practice to give webservice calls||Steven Davelaar||3/23/12 5:06 AM|
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.
There are a few sample implementations on the web :
- Jobinesh Blog, Building Programmatically managed business components - Part 1 (11.1.2): http://jobinesh.blogspot.com/2011/06/building-programmatically-managed_25.html
- Jobinesh Blog, Building Programmatically managed business components - Part 2 (11.1.2): http://jobinesh.blogspot.com/2011/06/building-programmatically-managed.html
- Steve Muench Undocumented sample (11.1.1): ADFBC Application With No Database Connection
- Steve Muench Undocumented sample (10.1.3): Entity and View Object Based on Web Service
- JHeadstart blog: How to use web services, TopLink, POJO's and other data providers as a business component (ADF BC) (10.1.3): https://blogs.oracle.com/jheadstart/entry/how_to_use_web_services_toplin
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
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...
|Re: [ADF EMG] Re: ADF best practice to give webservice calls||agawish||3/23/12 10:57 PM|
Great resources, I'd like to add one more resource, a recent post by Andrejus http://andrejusb.blogspot.com/2012/03/use-case-for-adf-bc-with-no-database.html that gives a step by step to move into option 1 gracefully
|Re: [ADF EMG] ADF best practice to give webservice calls||darrel chia||3/26/12 6:14 PM|
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.
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
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.
|Re: ADF best practice to give webservice calls||Don||8/24/13 10:03 PM|
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
|Re: [ADF EMG] Re: ADF best practice to give webservice calls||Grant Ronald||8/26/13 11:23 PM|
Did you check out this video we recorded?
-- Grant Ronald Director of Product Management Oracle Application Development Tools Author: The Quick Start Guide to Fusion Development: JDeveloper and Oracle ADF.
|Re: [ADF EMG] Re: ADF best practice to give webservice calls||svishal.raj||8/26/13 5:58 PM|
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.