Best practices for ADF Frontend on top of OSB or SOA Suite

1,796 views
Skip to first unread message

Lucas Jellema

unread,
Jan 21, 2013, 10:36:01 AM1/21/13
to adf-met...@googlegroups.com, gver...@gmail.com
Hi all,


On our current project, we have a requirement to build our ADF front-end on top of Business Services exposed on the Oracle Service Bus (OSB). An interesting challenge, because the default database-oriented ADF architecture cannot be used, and there are a number of other candidate architectures to choose from.

Please also see following blogpost which describes what we are trying to achieve: http://technology.amis.nl/2013/01/20/adf-interaction-with-business-service-an-ongoing-discussion/

 Basically, we have two decisions to make:
1. Are we going to build our ADF frontend on top of OSB Web Services (JAX-RS OR JAX-WS), or OSB EJB Services?
2. What would be the best practice to build the ADF app on top of the Business Service? This basically is the same discussion as started in this EMG thread: https://groups.google.com/forum/?fromgroups=#!topic/adf-methodology/9NPM6J64f0E. Very valuable comments and resources.

We identified the following generic solutions:
   (a) Use (EJB or WS) Data Control directly
   (b) Use a client (EJB or WS or JAX-RS) with a POJO layer and a POJO datacontrol
   (c) Use a client (EJB or WS or JAX-RS) and programmatic Business Components on top of that client (so we can use ADFBC data control like always)
 
We are very interested in other EMG members' real life experiences with above solutions.
* Did you ever build an ADF app on top of OSB or alike service provider? What are your experiences?
* Did you ever choose between EJB and Web services, and which one of those is now your favorite, and why?
* Probably many ADF developers went from (a) to (b) once, but did you ever change your solution from (b) to (c)? Or (c) to (b)? Why?

And of course we are interested in all opinions on this topic. We're also trying to note down advantages and disadvantages:

 Web Services Protocol:
+ technology independent protocol
+ loose coupling
- xml overhead

 

EJB Protocol:
+ best performance (we think)
+ best transaction support
- rmi has some coupling between client en server (Client jar)
- complexitywith remote EJBs


And for the complete solutions:

Data Control solution:
+ fastest, easiest (when starting)
- any service change directly impacts your data control and thus ViewController
- no room for custom control of the service

 

Client + POJO + POJO DC solution:
+ service change doesn't (necessarily) impact the data control
- still loses changes to Data Control meta data (validations, UI hints etc) when regenerating Data Control
- POJO DC lacks many ADF BC DC features (e.g. pagination)

 

Client + POJO + Programmatic BC solution:
+ use all of ADF BC's built-in features (caching, validation)
- some ADF BC behavior has to be overridden

Just a quick setup, if you could comment and add your own experiences to this list, that would be greatly appreciated.

kind regards,

Gerben Vermoen and Lucas Jellema

Grant Ronald

unread,
Jan 22, 2013, 4:27:33 AM1/22/13
to adf-met...@googlegroups.com
This is a question that is coming up more and more often so Frank recorded an ADF Insider which talks about some general points on service integration.ďż˝ Of course, the caveat is that the is no "one size fits all" but there are some general recommendations

http://www.youtube.com/watch?v=L-7ePh0Nbf4

Regards


On 21/01/2013 22:30, Jakub Paw�owski wrote:
Hi Lucas,

Very interested question. Currently I have the same dilemma - I'd like to wrap ECM RIDC services and don't know which way to choose - POJO DC or no database BC. It's a general question - What is the best way to create service based ADF application. I heard about working system wilth following stack (little UML :)):

DB --O >-- OSB with DB adapters --O >-- WS proxy (clitnt) --O >-- ADFm --O >-- ADF RC


BC are more powerful, easy testing etc... but the other site you will use additional layer (framework) with a lot of code (and unfortunately - bugs). Additionaly you need to implement an extra code to customize BC behavior. Note, that Franks example in Oracle Magazine ("Service please") is very simple and don't cover a lot of issues.

Meybe someone from Oracle writes recomended approach. I'll track this discussion with attention.

Kuba


W dniu poniedzia�ek, 21 stycznia 2013 16:36:01 UTC+1 u�ytkownik Lucas Jellema napisa�:
Hi all,


On our current project, we have a requirement to build our ADF front-end on top of Business Services exposed on the Oracle Service Bus (OSB). An interesting challenge, because the default database-oriented ADF architecture cannot be used, and there are a number of other candidate architectures to choose from.

Please also see following blogpost which describes what we are trying to achieve: http://technology.amis.nl/2013/01/20/adf-interaction-with-business-service-an-ongoing-discussion/

�Basically, we have two decisions to make:


1. Are we going to build our ADF frontend on top of OSB Web Services (JAX-RS OR JAX-WS), or OSB EJB Services?
2. What would be the best practice to build the ADF app on top of the Business Service? This basically is the same discussion as started in this EMG thread: https://groups.google.com/forum/?fromgroups=#!topic/adf-methodology/9NPM6J64f0E. Very valuable comments and resources.

We identified the following generic solutions:

�� (a) Use (EJB or WS) Data Control directly
�� (b) Use a client (EJB or WS or JAX-RS) with a POJO layer and a POJO datacontrol
�� (c) Use a client (EJB or WS or JAX-RS) and programmatic Business Components on top of that client (so we can use ADFBC data control like always)
ďż˝

We are very interested in other EMG members' real life experiences with above solutions.
* Did you ever build an ADF app on top of OSB or alike service provider? What are your experiences?
* Did you ever choose between EJB and Web services, and which one of those is now your favorite, and why?
* Probably many ADF developers went from (a) to (b) once, but did you ever change your solution from (b) to (c)? Or (c) to (b)? Why?

And of course we are interested in all opinions on this topic. We're also trying to note down advantages and disadvantages:

�Web Services Protocol:


+ technology independent protocol
+ loose coupling
- xml overhead

ďż˝

EJB Protocol:
+ best performance (we think)
+ best transaction support
- rmi has some coupling between client en server (Client jar)
- complexitywith remote EJBs


And for the complete solutions:

Data Control solution:
+ fastest, easiest (when starting)
- any service change directly impacts your data control and thus ViewController
- no room for custom control of the service

ďż˝

Client + POJO + POJO DC solution:
+ service change doesn't (necessarily) impact the data control
- still loses changes to Data Control meta data (validations, UI hints etc) when regenerating Data Control
- POJO DC lacks many ADF BC DC features (e.g. pagination)

ďż˝

Client + POJO + Programmatic BC solution:
+ use all of ADF BC's built-in features (caching, validation)
- some ADF BC behavior has to be overridden

Just a quick setup, if you could comment and add your own experiences to this list, that would be greatly appreciated.

kind regards,

Gerben Vermoen and Lucas Jellema

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
ďż˝
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

-- 
Grant Ronald
Director of Product Management
Oracle Application Development Tools
Author: The Quick Start Guide to Fusion Development: JDeveloper and Oracle ADF.

fnimphiu

unread,
Jan 22, 2013, 4:53:55 AM1/22/13
to adf-met...@googlegroups.com, gver...@gmail.com

As Jakub states it, ADF BC with all its framework glories looks tempting to use for Service integration. The sample I provide in the article Jakub mentions indeed is simple and this kind of unveils the downside of using ADF Business Components for service integration with a SOA business model: You need to core ADF BC to change the framework behavior for the use with Web Services.Its all doable, though requires a good understanding of ADF BC, patience and time.

ADF Business Components - IMO - makes sense to use if your overall ADF model is based on the ADF Business Components DC. You can justify to wrap the WebService call using ADF BC with the gain that application developers don't need to rethink but continue working with the ADF BC active model.

However, in Lukas original post, he indicates that he wants to build ADF UI based on SOA services, which I think is a use case that doesn't requir ADF BC. If you are mixing database sources and WS sources and want to expose a consistent API to the application developer then ADF BC is (IMO) the better option. However, for a pure service approach I would recommend using SOA and JAX-WS / JAX-RS means.

Before you shout "model driven LOV" and "ViewCriteria", keep in mind that these two features become available in 12c for the POJO Data Control as well. The argument of implicit commit also no longer appears a unique feature of ADF BC given that the ADF lifecycle methods can be handled in POJO DC as well (11g R2 and 12c).

Here my arguments for using the POJO DC for Luka's usecase

1. Services are (usually) not made with ADF BC in mind. This means that WS exposed methods will not 100% map to ADF BC requirements
2. Unlike for PL/SQL programmatic view objects, services are based on entities, which makes it difficult to create generic and parameterizable base 
    classes for max. reuse
3. JAX-WS proxy client is required using ADF BC and using the WS DC. So for ADF BC this appears as additional overhead

In terms of practical experience: I am working with a group within Oracle that uses ADF BC on top of ADF BC because they need dynamic view object and entity object creation (which also seems to be an argument pro ADF BC). However, its a look of work for them to change the ADF BC framework so that it dispatches all requests to the WS.

my 2 cents.

Frank

Lucas Jellema

unread,
Jan 22, 2013, 9:06:28 AM1/22/13
to adf-met...@googlegroups.com, gver...@gmail.com
Hi Frank,

Thanks for your two cents (actually worth quite a bit more). Our case really is a mixed case, with a number of taskflows using the 'traditional' ADF BC approach using a database connection and executing SQL to query and do DML directly against a database schema (traditional CRUD style application, data and even table oriented) and another portion of taskflows that will primarily support human tasks that are part of business processes (BPM based). These taskflows will have user interfaces that are far less CRUD and much more functionality driven with far less 1:1 mapping to database objects (and possibly even accessing other enterprise sources than just the database).

Thanks to the various replies to this discussion thread (and earlier experiences from several of my colleagues), we start to develop a preference for the JAX-WS/POJO-wrapped inside ADF BC approach. Our largest reservation at this point is the mapping of a nested service response (a message that may contain for example master with details and perhaps even details of the details) to ADF BC. JAX-WS and our POJO-model and also the POJO DC would do well with such nested collections. However, we are not as confident about an easy approach with Entity Objects. So we will first investigate that particular area before making our final decision.

We also would like to learn more about how and where data is cached when we use the combination of JAX-RS, custom POJO layer and programmatic ADF BC. Is caching our own responsibility or does the ADF BC framework do the caching for us? Is data copied from our POJOs to RowSets that fall under the standard ADF BC cache-management? Does the notion of the Shared Application Modules work in the same (cross session) way as with 'normal' ADF BC?

Can we make use of the fact that the integration layer between the application and the data services is our own and create a cross-session (L2) cache (perhaps even cross node, using Coherence? )

The extended support in ADF 12c for the POJO Data Control sounds very interesting. Do you know whether our current issue with the POJO Data Control - where meta data associated with the data control tends to get lost when we re-generate the DC for example when there is a change in the POJO definitions - is also resolved in 12c? Given our project's timelines, we cannot afford to wait for 12c , so we will proceed with either the POJO DC (on top of JAX-WS) or the ADF BC layer (programmatic, on top of JAX-WS).

Our tentative conclusion would be that using EJBs

kin regards,

Lucas

Lucas Jellema

unread,
Jan 22, 2013, 9:12:54 AM1/22/13
to adf-met...@googlegroups.com, gver...@gmail.com
Thanks Kuba for your reply. Good to learn that more of us our dealing with this challenge. It seems that Frank's response and some of our earlier experiences as well as the investigations we are currently conducting help us make up our minds.

It looks like wrapping the JAX-WS client and POJO-layer inside ADF BC will be our preferred approach. The final decision is pending as we need to determine if we can map a nested, multi-level service response to multiple (nested) Entity Objects. We also want to understand how the caching of data is managed in the ADF BC + our own POJO model situation (at least as good as we understand data caching in vanilla ADF BC).

One of our considerations against the POJO DC is that (with 11gR1 at least) we lose most of the meta data (UI Hints, validations etc). created for the POJO DC whenever we have to regenerate it (which is quite often).

kind regards,

Lucas



On Monday, January 21, 2013 11:30:10 PM UTC+1, Jakub Pawłowski wrote:
Hi Lucas,

Very interested question. Currently I have the same dilemma - I'd like to wrap ECM RIDC services and don't know which way to choose - POJO DC or no database BC. It's a general question - What is the best way to create service based ADF application. I heard about working system wilth following stack (little UML :)):

DB --O >-- OSB with DB adapters --O >-- WS proxy (clitnt) --O >-- ADFm --O >-- ADF RC


BC are more powerful, easy testing etc... but the other site you will use additional layer (framework) with a lot of code (and unfortunately - bugs). Additionaly you need to implement an extra code to customize BC behavior. Note, that Franks example in Oracle Magazine ("Service please") is very simple and don't cover a lot of issues.

Meybe someone from Oracle writes recomended approach. I'll track this discussion with attention.

Kuba


Lucas Jellema

unread,
Jan 22, 2013, 10:10:25 AM1/22/13
to adf-met...@googlegroups.com, gver...@gmail.com
Hi Dimitrios,

Thanks for your clear, well articulated response. It is encouraging to read how the ADF BC on top of JAX-WS/POJO approach allowed you to leverage ADF BC as with the regular JDBC based way of working. Your logic is similar to ours - again, an encouragement.

Can you say something about the mapping between a coarse grained service response (with multiple nested levels of business objects) to EntityObjects and nested EOs linked through Associations? There seems to be a challenge.

Did you do anything special in order to cache the data retrieved from web service calls?

kind regards,

Lucas



On Monday, January 21, 2013 5:29:57 PM UTC+1, Stasinopoul...@gmail.com wrote:
Hello Gerben and Lucas,

We had the same concern on a project where we had to consume  WS  and provide a fully functional application.
We chose to go for Programmatic BC (option c) for the following reasons:

  1. We were quite confident and experienced with ADF BC and overriding a few methods in the BC was not an issue since we would use all the features.
  2. We had more control over which information to populate in the attributes. There was an intermediate layer that was returning some calculated values. This approach decoupled a bit more our BC from WS clients
  3. At the time of the project, we wanted to use the Web Service Data Control directly as it seemed a more straightforward approach but we faced the following issue http://dstas.blogspot.co.uk/2012/05/web-service-data-control-with.html
  4. In terms of development, it might have cost us some more time to have it running ( this is debatable ) but it was in our area of expertise and we were able to use all the features we wanted from BC such as validations etc..
Regarding changes on the WS part.. as mentioned previously, we created an intermediate layer that was reconstructing some parts of the results. We did this in order to keep our BC as intact as we possible could. Additionally the WS were returning a lot of information that we did not want to use in our application and thus we had to filter it before populating anything. 
In the end, we structured our BCs in the way we wanted for this application and we had the flexibility to keep them intact from some changes in the WS part. All we had to do is work with the intermediate layer and handle the changes in order to keep the BC intact.

In the unlikely event of dramatic changes in the WS, we had to re factor many things in all layers. 

However, we would have done the same thing if there was no WS at all and everything was from the DB directly. The more changes in the DB/WS the more impact in the application.

Overall, the application was successful and was developed quite quickly. After developing the programmatic BC, the rest of the application was developed without any problems and we used a lot of the ADF features such as  Trees, Tables and dml operations.

my two cents..

Regards,
Dimitrios.

Brian Huff

unread,
Jan 22, 2013, 12:43:37 PM1/22/13
to adf-met...@googlegroups.com, gver...@gmail.com

Here's one MAJOR warning about performance...

I have an app that is a mix of web services (for write/update) and standard database calls for read-only data controls... by default ADF uses 'optimistic' row locking. Which is fine for most web apps, but all select statements use SELECT FOR UPDATE which causes a row-level lock.

If you have web service VOs and database VOs going for the same data PERFORMANCE REALLY SUCKS. A LOT. My web services were taking on the order of 5-50 minutes to update rows that were being viewed by others.

I had to dig and dig to find the optupdate flag which has a more 'enlightened' row-locking philosophy:

http://docs.oracle.com/cd/E24382_01/web.1112/e16182/bcstatemgmt.htm#BABHBIAB
http://andrejusb.blogspot.com/2011/01/optupdate-locking-mode-in-adf-11g-ps3.html

Web service performance is now consistently under 5 seconds... still high IMHO, but its a DEV box and I'm not gonna do any more tuning until UAT.

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).



--

Brian 'Bex' Huff
Chief Software Architect
Bezzotech - THE Premier Oracle ECM Solution Provider
Email: b...@bezzotech.com
Mobile: +1.612.227.6057
Twitter: @bex

Designing a Content Management or Enterprise 2.0 strategy? This may help:
 http://bezzotech.com/library.html

Chris Muir

unread,
Jan 22, 2013, 9:18:28 PM1/22/13
to adf-met...@googlegroups.com
Hi Brian

Thanks for sharing.

Of course it does beg the question, what's the use case of building a
solution where you have both ADF BC objects and web services going to
the same database infrastructure? There's an unwritten assumption
IMHO that if you were to combine these services in one ADF app it's
because you are accessing data from disparate data sources, not the
same data source. If the web services are going straight to the same
tables as your ADF BC objects, why not just use ADF BC in this case?

I can understand you might want to provision the web services for
other consumers, but in context of your ADF application why not leave
those web services for the external consumers to use exclusively and
leave ADF at its sweet point of sitting on the ADF BC objects?

In no way a criticism, just wondering how you've got to where you're
at? What architectural decisions & use cases have led you to this
solution?

Regards,

CM.

Brian Huff

unread,
Jan 22, 2013, 10:27:01 PM1/22/13
to adf-met...@googlegroups.com

Wasn't my design... I would have preferred to not use web services for ANYTHING. They insisted on web services for anything that changed data so it could all be audited in one place. Direct database calls were allowed for read access only. And thank god for that or this app would have been impossible to develop in the time frame allowed ;-)

Chris Muir

unread,
Jan 22, 2013, 10:33:29 PM1/22/13
to adf-met...@googlegroups.com
Damn those irrational customer requirements ;-) Thanks for the update.

John Flack

unread,
Jan 23, 2013, 9:08:48 AM1/23/13
to adf-met...@googlegroups.com
I'm thinking about something similar to Brian, but haven't gone beyond the experimental stage.  I have a read-only application, but the queries can get quite complex with sub-queries and use of Oracle Locator (sub-set of Spatial).  An ADF BC view object can't build these queries without adding custom Java code to help it.  And I need to expose the parameters of the query and return results in a web service so that outside parties can call it, as well as my own ADF Faces application.  Being better with PL/SQL than with Java, I built a REST web service in PL/SQL that builds and executes the query, returning results in XML.  I exposed it via the APEX Listener.

I can access it with ADF using the URL Service Data Control - since I was able to write an XML Schema to describe the query results.  Nice thing about it is that while the first front-end I'll build will be ADF Faces, I can later write an ADF Mobile application against the same web service - client hasn't asked for that, but I KNOW they will.

So the heart of the application is done, but then I'm going to need lookup tables and maybe a few administrative pages.  This is stuff that need not be exposed as web services.  Plain old ADF BC will be fine, and easy - very straight-forward.  Therefore - mixed application - some web services, some ADF BC.

fnimphiu

unread,
Jan 23, 2013, 10:56:50 AM1/23/13
to adf-met...@googlegroups.com
I think that generally speaking "usecase matters". I think that using WS and ADFBC to work against the same database schema when used from a single application is a SOA anti-pattern as there is no real reason I can see here: USE ADF BC or WS in this cae is my opinion. The same problem you would run into calling PL/SQL from a VO performing a select for update.

To Lucas use case: If taskflow is a boundary, then you don't need ADF BC to access the WS as the DC goes with the taskflow and not separate.

In regards whether ADF BC automatically cashes programmatic entities accessed from a VO, I don't know. I would assume that YES it does. But then, you override all ADF BC framework CRUD and query methods ... So this may be an area to test, though I think its becomming a developer task to fetch new data or have the data used in cache. Maybe someone has time for a test ;-)

Frank

Lucas Jellema

unread,
Jan 24, 2013, 12:45:49 AM1/24/13
to adf-met...@googlegroups.com
Hi John,

Sounds like a fine approach. I probably would not dare to use the URL Data Control directly and use a POJO client for the RESTful service, then publish that client as POJO Data Control - to have more control and flexibility. Perhaps that is an unjustified reluctance to relinquish (data) control...;-)

In our case we would probably have the OSB publish those RESTful services - regardless of whether the Database does all the work anyways or whether we would use the Database Adapter and compose the responses inside the OSB.

kind regards,

Lucas

Lucas Jellema

unread,
Jan 24, 2013, 12:53:02 AM1/24/13
to adf-met...@googlegroups.com, gver...@gmail.com
Dear Dimitrios,

This is a wonderful overview of your considerations and conclusions. They sound remarkably similar to our own - with you actually have done it. Thank you so much for taking the time to write this down and sharing that information. We will gratefully make use of it.

As far as I can tell, your logic makes perfect sense. If your initial assumptions were validated during the project as well, then I believe you have picked a fine approach - one we are highly likely to mimic. Of course with this approach it does not really matter if the business service is SOAP/XML exposed on the OSB and accessed through a JAX-WS proxy or a RESTful service consumed with JAX-RS from some other provider or any Java-to-POJO client for whatever backend. Which makes it even more attractive.

By the way: Do I understand correctly that you did not use Entity Objects in your application?

kind regards,

Lucas

On Wednesday, January 23, 2013 5:20:27 PM UTC+1, Stasinopoul...@gmail.com wrote:
Hello All,

@Lucas,

Please find below a more detailed description of our approach with all the questions and dilemmas we faces along with our decisions.

Web Service : We had to consume a WS which served a very general purpose providing too much information for our application. There was a big hierarchy and we did not want to inlcude all this information in our data control. For the simplest reason, that the user will never (a big word, I know) see this info, so there was no need to use them.

So, the immediate thought was to use the Web Service Data Control with out of the box,  however, as mentioned previously we had this issue with the complex types. So that was ruled out. Then we went to POJO data Controls which eventually was ruled out since we could not use ADF UI as we wanted with the declarative way. We saw that we had to make more development in the front end to have our functionality working ( e.g. tree tables).

Then we thought about programmatic BC, which again had a complexity in order to provide proper associations and caching.

Given those thoughts, we sat down and discussed the following dilemma:

Where should we shift the complexity: In the front end throught POJO data controls, or in the Model by providing an internal framework that will play the role of the 'mediator' between the jaxb and our BC.

Please allow me to express some of our thoughts back then:
Given the fact that ADF is a declarative environment, going for th POJO Data Control will add up complexity for new comers to the ADF world and this means longer learning curve time. Not to mention the time spent to explain what and why we did in order to have this functionality ( Keep in mind that new screens will always come up as requirements and changes in the UI is a constant thing... whether we like it or not.). Additionally, we will have to write more code in order to have some of the features ADF BC provide in the declarative way (validations etc..).

On the flip side, going for Programmatic BC implies, strong understanding of how the framework works and additional time of development prior to actually delivering a screen... Which can be painful to some Managers when there is no visual progress.. (totally understandable and it certainly makes sense). However, going with this approach we will have the following benefits (again this was our opinion and it does not necessarily makes it correct or the best) :
Shift the complexity to the model, which in our opinion, would not have to change more often than the UI changes..
Require only a small part of the development team to maintain it (One person could do as well imho).
Provide a solid documentation of what to override where for any new comers. This will provide consistency in development and easier code review.
Let the development proceed with BC only, in the declarative way, leveraging all the offerings of ADF UI.
In case we would have to re-generate the JAXB, we had pretty good chances to keep our Programmatic BC intact. Of course, this is debatable and not certain.

Given the above thoughts we concluded to give it a go with Programmatic BC.

Lets get our hands dirty.
First, we wanted to strip out the information from the WS and adjust it to our needs. So we created a bunch of classes that would parse the result of the WS call and create an hierarchy of our own.

Consider the following example: the wsdl would return A-->B-->C-->D and we wanted A-->D (yes, we had to add some additional attributes in order the assocs to work properly). All the intermediate information was not needed to us and there was no point in having them in our BC. So eventually, we had one class (lets say FacadeClass) with references to other instances. Why we did that? We wanted to have the less code possible in our BC for all the aforementioned reasons. So yes we had to create several classes for that matter.

By now, we already have our data in the hierarchy we wanted. The only thing left was to actually populate them properly which is well documented online. It does not really makes a difference whether is a WS or PL/SQL or something else.

Caching: In our case, we had to call the web service only per user action (press a button). On every other case, we were working with the same fetched data.
We kept the facade class in our ApplicationModule and we used it from our View Objects in order to get the details. So every detail View would get the related list of objects. for instance: List aList=facade.getDetail1() .
So the only worry we had was passivation/activation. For that reason, we used an external library that we representing our class in an xml format and thus it could be stored in the db.

I am sure there are better implementations for that matter and I would really like to hear them.
Kindly note that this is not a proposal of how to do things but it is an approach we followed and it worked for us and for that specific project. Every project has its own needs and certainly there is not one solution for everything.
 At that time, this approach worked for us because we could document it properly for any new comers in the project and we could have a few people (or one) that could work/maintain it. The benefit was that we could use ADF out of the box and we avoided any additional complexity in the front end, which imho is a very good thing since the model does not change that often and it can be reused in many screens.

Again, I would really like to hear different approaches in creating Programmatic BC.

I hope this answers some of your questions.


Regards,
Dimitrios.

dstas.blogspot.com

On Monday, January 21, 2013 3:36:01 PM UTC, Lucas Jellema wrote:

Lucas Jellema

unread,
Jan 24, 2013, 12:55:35 AM1/24/13
to adf-met...@googlegroups.com, gver...@gmail.com
Hi JP,

Thanks for sharing your experience. It sounds logical - so that is helpful overview.

I have one question: why did you decide on using EJB on the consuming end, and not just have an JAX-WS proxy with POJO layer and publish with POJO DC?

kind regards,

Lucas

On Wednesday, January 23, 2013 3:59:17 PM UTC+1, Juan Pablo Vadell wrote:
Hi Everybody

We faced a similar situation, using about 20 services, some directly exposed on the web, and some others over OSB.

Our approach was over the schema definition (xsd).

1. We built a module for serializing/deserializing the xml, using the jaxb utility tool to generate java objects from the xsd.
2. Built the web service module, generating the wsdl using the same xsd. 
The wizard does not allow this action, but we overrode it using code generated on step 1.
3. Built the web service client module, using the wsdl, and again manually forcing the use of the step 1 output.
4. Built a business module, using EJB, exposing the web service operations. We also test this approach with an AM, but in our case there was no data base interaction... the data base interaction was through OSB. So... we chose the EJB approach, exposed as DC. 
You can also look up the EJB instead of expose it as BC, but it is not a good practice.
It adds a lot of java coding.
5. Adf web tier module, using all the other modules.

Now, our experience:
Jaxb dependent
Webservice implementation: it works with jaxb-ws and with spring-ws.
Webservice client implementation: it works with jaxb-ws and with spring-ws.
Business module: it works with EJB or BC programmatic AM.

The same java classes used for all modules, on the other hand an xsd change would impact everywhere in the project (Awful Truth anyway...)

JP

Carlos Miranda | Ayi & asociados

unread,
Jan 24, 2013, 8:25:00 AM1/24/13
to adf-met...@googlegroups.com, gver...@gmail.com
Hi Lucas,
I m in the same team with JP...

The answer is probably philosophical

On my opinion a ws-proxy cannot technically be included as source code. It is just generated code.
We have intended to reduce that generated code, taking out the WS-POJOS to an XSD-JAVA proyect. So, we keep proxy just for communication.
Have a dependency on the consuming end over generated code scare me a little, because we have found some problems to maintain the others modules after regeneration. Placing it behind the business logic worked much better for us.

And now, the EJB... philosophical again.
The only tecnology that gives you a reasonable encapsulation is java.
The EJB is, in my opinion, the more flexible and standard node on the stack.
You can perform many ws operations (including compensation and differents ws calls) on the same EJB operation, and it is more real business approach.

In addition, the POJOs XSD-JAVA are finally exposed, by exposing EJB as DC. The only difference is that they are not auto-generated.

Best regards, Tocarli


2013/1/24 Lucas Jellema <lucasj...@gmail.com>

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
 
 



--

Saludos cordiales, Carlos


Lic. Carlos Miranda | Ayi & asociados

JEE | ADF Technical Team Leader

 

 Cel: +54 351-3053863

Antonio del Viso 658 . Córdoba . Argentina  X5001AHN . +54 351 4711900

Av. Corrientes 640 . 3º piso of. 38 A . Buenos Aires .  Argentina  C1043AAT . +5411 43286538

carlos....@ayi-asociados.com | www.ayi-asociados.com 


Jang-Vijay Singh

unread,
Jan 25, 2013, 4:42:45 AM1/25/13
to adf-met...@googlegroups.com
Hi Lucas,

Quoting one of your earlier posts:
"Our case really is a mixed case, with a number of taskflows using the 'traditional' ADF BC approach .....another portion of taskflows that will primarily support human tasks that are part of business processes (BPM based). .....(and possibly even accessing other enterprise sources than just the database)."

For the second case - human task based task-flows -  why do these necessarily have to be any different?
Yes, they (can) have the additional human task payload as one of the data sources - it is the data that the process engine would pass to the UI or would want the UI to send back, in addition to an outcome.
Other data sources, based on your requirement might as well be ADFbc or web services. (for data that doesn't need to be part of the human task payload) .

For the group, if you did a like to like comparison (actual UI functionality to be delivered):
How would you compare these (in a UI based exclusively on web services versus ADF BC)
- time and effort required (including maintenance of proxies, ease of change)?
- runtime performance?
- features you can actually develop. 

When comparing the above, would you rather use web services in exceptional scenarios (integration, multiple secondary data sources) or as a general rule - in UI development?

I am not considering the ADF BC's SDO web services in the above - mostly referring to ones developed from scratch using the SOA Suite.

JV


--

Gerben Vermoen

unread,
Jan 25, 2013, 4:49:37 PM1/25/13
to Donovan Sherriffs, adf-met...@googlegroups.com
Hi Donovan,

Thanks alot for sharing your experience on this subject, we highly appreciate that. I noticed  your contribution to the discussion is not shown in the EMG thread, so I hope it'll be added on my reply. (I'm brand new member of the EMG too)

You're mentioning that you favor EJB over WS because of the maintainability and speed; do you have any number on the performance difference between EJB and WS?
How was your service landscape designed in this particular case, few coarse grained services vs. many fine grained services? 

Thanks for the not before mentioned argument of upgrading, the POJO DC approach certainly has an advantage there over programmatic BC.

kind regards,
Gerben Vermoen


2013/1/25 Donovan Sherriffs <dsher...@gmail.com>
Hi Lucas,

I though I would just chip in because I have worked with some of these methods and felt some major pain: (two of the systems mentioned are running in production on is still in development)

Never tried option a because it has never seemed like a very good idea to me.

I have built an ADF application on top of OSB and it worked quite well with POJO DC but it was a major development overhead (when any service changes, caching, UI tweaks, hints etc). There are a few ADF UI tricks like when to refresh etc that you learn which make everything more manageable  (caching was custom built).

-- Comments below based on writing an full system not directly speaking to the DB things change if it is only partial 
EJB is by far my favored method over web services at the moment because of the maintainability and speed but this comes from a purely development perspective. For loose coupling and future proofing (ie you want to change front end to another technology blah...) maybe you want to make the other choice.

I also favor the programmatic BC implementation over the POJO data control from experience it makes for less complex development (fight complexity on the model layer is less time consuming than working with random PPR and rendering problems for me) over time. But note that I have only build a small system using programmatic BC so I am not 100% sure on the performance and caching aspects because the screens where not used often and the performance was adequate. 

With Programmatic BC and POJO Data controls upgrading to a new version is more complicated because subtle changes in the framework can effect you badly. With traditional ADF you are shielded to a degree.

But as a general rule I suppose writing a application with traditional ADF and exposing what you need to the ESB with SDO/ EJB has always seemed a sensible approach.

Thanks
Donovan


Reply all
Reply to author
Forward
0 new messages