The ADF framework strongly suggests if not dictates a certain application architecture. Through ADF BC (Business Components) – the predominant business service implementation with ADF – applications will typically interact directly with the database, over JDBC Database Connections from a shared connection pool. Developers who create the ADF BC Entity Objects and View Objects will be quite aware of the data model and the database implementation. They will usually write SQL. And the result of their work is substantially coupled with the database. Transactions across multiple data source are very hard to implement in that typical ADF BC scenario because ADF BC talks to a single database and typically controls its own transaction.
When ADF applications are developed in an environment where an enterprise architecture has been laid down, and decoupling is an important objective and service orientation is mandated – then this typical implementation of the business service using ADF BC connecting directly to the database may not be desirable or even allowed.
On one of my projects, we are currently in the situation where we try to determine the guidelines for the implementation of the business service. Note that we are not necessarily trying to determine a single approach that has to be used under all circumstances. However, we do want to select the primary method as well as guidelines that describe when and how to deviate from that primary choice.
Our architecture is SOA enabled – using service orientation to create decoupling and reuse. The data services represent various data areas that could be implemented in different databases – or even in stores that may not even be relational databases. However, that is theoretical: currently all data is contained in a single Oracle Database.
We will be using a service bus – probably a combination of SOA Suite and OSB – to expose data services and composite services. In addition to the ADF application, we will have external Portals, B2B Web Services and BPM processes that consume the data services.
In our evaluation that is to result in a preferred business service implementation for newly built ADF applications, we have six different approaches to compare:
1. Web Service proxy (JAX-RS with some library to be selected) to interact with a RESTful Web Service exposed on the ESB; this proxy is mapped to a POJO layer that is published through the POJO Data Control
2. almost the same as the previous option, this one for a SOAP WS: a Web Service proxy (JAX-WS) to interact with a SOAP Web Service exposed on the ESB; this proxy is mapped to a POJO layer that is published through the POJO Data Control
3. An EJB Client (regular JEE EJB Client) implemented with a POJO model that is published through the POJO Data Control; this client interacts with a stateless EJB that is published on the ESB; an alternative option is to have the EJB client interact directly with an EJB (a stand alone ADF BC application deployed and exposed as EJB, outside the context of the ESB)
4. The ADF EJB Data Control that interacts directly with an EJB exposed on the ESB (or a stand-alone EJB, potentially implemented using an ADF BC Application Module)
5. The ‘regular’ ADF approach with a local ADF BC Application Module that connect directly to the database; this ADF BC Application Module is automatically exposed as Data Control in the ViewController project. Note: this same ADF BC Application Module can be exposed as Web Service (SDO) or as EJB that the ESB consumes and makes available as service.
6. Programmatic ADF BC Entity and View Objects, based on a Web Service Client (JAX-WS); to the developers of the ADF UI, this will look just like option 5. The work that the model developers have to do is very similar to option 1 – yet it is a little bit more and a bit more ADF BC specific
7. Programmatic ADF BC Entity and View Objects, based on an EJB Client; to the developers of the ADF UI, this will look just like option 5. The work that the model developers have to do is very similar to option 3 – yet it is a little bit more and a bit more ADF BC specific
new picture:
I have started a discussion on the ADF EMG group to compare experiences with these various options: https://groups.google.com/forum/?fromgroups=#!topic/adf-methodology/GKgKgALg0N8. Some interesting reactions have been posted – including a lengthy expose by Frank Nimphius and some real world experiences from other projects. Also the ADF Insider video on option 6:http://www.youtube.com/watch?v=L-7ePh0Nbf4 .
earlier illustration:
We are evaluating these options on a number of criteria. Chief amongst these: compliance with the architecture (or at least with the objectives of the architecture). Additionally: development productivity, degree of framework integration (as opposed to working against the framework), run time overhead, exception handling, validation and exception handling, transaction management (across multiple data stores) and support for JHeadstart based development. One consideration is the degree to which a solution has been adopted in the market: even if an approach looks great on paper – we do not want to be the first to adopt; we want to be able find earlier experiences and supporting resources for our preferred method.
Resources
There are a lot of resources available on most of the options discussed here and on the process of evaluating these options. For example the recent discussion on the ADF EMG is very relevant: https://groups.google.com/forum/?fromgroups=#!topic/adf-methodology/9NPM6J64f0E .
Some example of programmatic ADF BC on top of Web Services are mentioned in this thread:
– 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
– Andrejus Baranovskis – a use case for ADF BC with no Database Connection – http://andrejusb.blogspot.nl/2012/03/use-case-for-adf-bc-with-no-database.html
– Frank Nimphius in Oracle Magazine (August 2012) – Service, Please! – http://www.oracle.com/technetwork/issue-archive/2012/12-jul/o42adf-1653060.html
– ADF Samples Repository – Programmatic Business Components – http://java.net/projects/smuenchadf/pages/ADFSamplesADFBC#Programmatic_Business_Components
– Middleware by Link Consulting – How to create a ViewObject based on a Web Service – http://middlewarebylink.wordpress.com/2012/05/24/how-to-create-a-view-object-based-on-a-webservice/
Not too many resource can be found on the use of the EJB Data Control or the combination of creating an EJB Client and publishing that as a POJO Data Control – which makes them less attractive.
