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
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.
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
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:
- 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.
- 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
- 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
- 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.
--
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).
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
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:
Hi EverybodyWe 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 dependentWebservice 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
--
--
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
"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)."
--
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 partialEJB 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.ThanksDonovan