Monday, August 27, 2012

Planning an Enterprise Scale ADF Implementation?

There are tons of resources out there that follow the same standard MVC architecture by using the "Fusion Middleware Application" template provided by JDeveloper 11.x. But is this sufficient for a large scale enterprise application or portal? No ... I don't think so. I highly recommend that you structure the overall project by using workspaces, projects, and libraries. By organizing application specific artifacts (BC Model, taskflows, templates, java utilities, project properties) into shared libraries will increase productivity amongst your team and provide the modularity your project needs to be successful today and in the future when you start enhancing the applications with new developers rolling on.

I typically structure my applications to use a SharedBC and SharedViewController project. I create a deployment profile for each and deploy them on a network shared folder as an "ADF Library JAR File."

Now any developer can create a "File System" resource in their Resource Palette.

After that you should be able to see your deployed libraries when you expand the resource.

If you want you could also set the dependency on the shared VC from the build output of the shared BC and deploy just one ADF Shared Lib. So it just depends on how you modular you want your components to be. Now the shared code is packaged and ready to be consumed by other applications in your enterprise. This will allow your development team to be more productive and allow them to only change code in fewer places. I suggest you start on a small scale to make sure everyone understands the capabilities and the benefits of this before things get a little hairy. I would put together a few POCs using this method and do a write up explaining why and how to use this.

In future posts I'll go into setting up extended base classes in your model application, ADF logging, controller utility examples, binding examples, and some tips and tricks in Skinning/Templating.


  1. Hello Kyle,

    Came across your blog from LinkedIn.Good work.

    WRT your topic here , yes I agree.For the sake of modularity , it is better to have shared jars.In our project , we have about 15-20 independent ADF applications which are deployed as libraries(jar files).

    We also have a common application which houses all our common EO's,VO's,Taskflows,web services etc and each project in this application is ultimately deployed as a jar.

    All these are ultimately consumed by our webcenter portal project(Main application which handles our menu structure,navigation etc).

    What are your thoughts on cyclic dependency between jars ? I know it is a bad practice.

    1. So sorry for the late response. My comments are coming into my SPAM in my email and I don't check in the admin section too often.

      To answer your question:
      1. If your shared libraries (15-20) have common code then I would deploy each to a Shared Resources or Reusable JAR folder. Then take those shared common jars and deploy them as a shared library on the server. So you're not cluttering your application deployment.

      Does this make sense?

  2. I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well.

    oracle fusion financials online training