ADF Best Practice to Give Webservice Calls - ADF Enterprise Methodology Group _ Google Groups

ADF best practice to give webservice calls Options

« Groups Home

ADF Enterprise

Methodology Group

6 messages - 5 new - Collapse all - Report discussion as spam

Sanjeeb Mahakul View profile More options Mar 21, 6:15 pm

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 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.

Regards,

Sanjeeb

Reply Reply to author Forward Report spam

hasim View profile More options Mar 21, 8:08 pm

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.

The old Google Groups will be going away soon. Switch to the new Google Groups.

Home

About this group

Edit my membership

Sponsored links

Barracuda Backup Service

Double the Storage for Same Price!

From €40/200 GB/Month. Free Eval

www.barracudanetworks.com

Expert Cognos resources

Leading Cognos resource specialist:

Cognos 8, Datastage, Planning, TM1

www.eu-solutions.co.uk

Oracle Training Courses

London, Manchester & Leeds

Contact us for best prices

www.datrixtraining.com/

See your message here...

Discussions+ new post

Gmail Calendar Documents Photos Sites Groups Search More [email protected]

ADF best practice to give webservice calls - ADF Enterprise Methodo... http://groups.google.com/group/adf-methodology/browse_thread/thread...

1 of 5 3/24/2012 8:14 PM

Thanks,

Hasim

On Wed, Mar 21, 2012 at 8:15 AM, Sanjeeb Mahakul

<[email protected]>wrote:

- Show quoted text -


Sanjeeb Mahakul View profile More options Mar 22, 10:10 am

Thanks Hasim and Soumik for your valuable inputs.

Hasim,

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.

Regards,

Sanjeeb



fnimphiu View profile More options Mar 22, 7:19 pm

* 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

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


2 of 5 3/24/2012 8:14 PM

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.

Frank


Steven Davelaar View profile More options Mar 23, 5:06 pm

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-manage...

- Jobinesh Blog, Building Programmatically managed business components -

Part 2 (11.1.2):

http://jobinesh.blogspot.com/2011/06/building-programmatically-manage...

- Steve Muench Undocumented sample (11.1.1): *ADFBC Application With No

Database Connection

<http://java.net/projects/smuenchadf/sources/samples/content/ADFBCAppW...>*

- Steve Muench Undocumented sample (10.1.3): *Entity and View Object

Based on Web Service


3 of 5 3/24/2012 8:14 PM

<http://java.net/projects/smuenchadf/sources/samples/content/EntityAnd...>*

- 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

- 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...

Steven.

On 22/03/2012 15:19, fnimphiu wrote:


--

Steven Davelaar| Consulting Solutions Architect

Oracle Webcenter | FMW Architecture Team (A-Team)

Tel +31 30 669 8113 | Mobile +31 6 55 33 24 28

A-Team Webcenter Blog <https://blogs.oracle.com/ATEAM_WEBCENTER/> |

JHeadstart

<http://www.oracle.com/technology/products/jheadstart/index.html>


Amr Gawish View profile More options Mar 24, 10:57 am

Steven,

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-dat...

that

gives a step by step to move into option 1 gracefully

Best Regards,

Amr Gawish

Senior Oracle Middleware Consultant

<http://www.amr-gawish.com> <http://blog.amr-gawish.com>

<http://www.twitter.com/agawish>

<http://www.linkedin.com/in/agawish>

<https://plus.google.com/113754637895846356137/about>

On Fri, Mar 23, 2012 at 3:06 PM, Steven Davelaar <[email protected]



End of messages

« Back to Discussions « Newer topic Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy


4 of 5 3/24/2012 8:14 PM

ADF Best Practice to Give Webservice Calls - ADF Enterprise Methodology Group _ Google Groups

Documents

Transcript of ADF Best Practice to Give Webservice Calls - ADF Enterprise Methodology Group _ Google Groups