Organization of BC4J - Domain (EO) and Business (VO) package americas cup win 2682133k1

Organization of BC4J – Domain (EO) and Business (VO) package

A topic that seems to come up again and again is the issue of reusing BC4J packages across applications and projects. And along the same lines structuring the BC4J objects within a project in separate packages, one for Entity Objects and one for View Objects. Today the question arose again during the final day of the JHeadstart Workshop: Martijn wants to create an enterprise data model in BC4J, reflecting the Enterprise Data Model set up in the RDBMS. All (or at least most) business rules will be implemented in the Middle Tier – to take the load of the database and also allow developers not comfortable with PL/SQL to define and maintain the business rules. It is clear that this means that all applications that need to access – and manipulate – the database, need to go through the BC4J foundation layer. Martijn wants to define the Entity Objects – and their business rules – only once and share that definition between different projects. Each projects can create its own ViewObjects on top of these shared Enterprise Entity Objects.

Hans (Rabouw) wrote down the steps for setting up this shared BC4J model – and it probably is described on the internet many times over, though I could not seem to find them. This describes how to proceed (the steps were originally written for JDeveloper 9.0.3 but seem to apply to 9.0.4 and 10g (9.0.5.x) as well:

BC4j components can be defined in one JDeveloper project (A) and used in another (B). This is done as follows:

  • Create a BC4J package with the Entity Objects in Project A
  • Create a jar deployment profile in project A; this deployment profile should contain the BC4J files. (note that this can also be done using Ant)
  • Deploy the profile to a jar file

Move over to project B – the consumer of the enterprise data model:

  • Include the jarfile as project library in project B
  • Note: this project must already be a bc4j project before you can perform the next step, that means it must contain a BC4J package
  • Import the business components in project B.
  • This is done by right Mouse click on the projectB.jpr or projectB.jpx file and picking the option ‘import business components’ from the menu. Now you should select the bc4j_packagename.xml file of the BC4J package you want to import. This file is found in the jar file, by doubleclicking on the jar file; this will open the directories in the jar-file. Select the b4cj_packagename.xml file and the package is included in project B. The BC4J components can now be used in project B; they are read-only and cannot be changed in Project B. Changes are to be made in Project A that is also used to maintain the BC4J objects. After making a change in a BC4J object, the deployment profile should be used to redeploy the BC4J package to the jar-file; that will make the changes available to project B.

  • This task can be automated by specifying a deployment dependency in the project settings of Project B; this is a dependency on the deployment profile in project A. If Project B is built, project B is automatically built and deployed beforehand – if it was changed since the last deployment.

You can take it one step further and allow the BC4J objects to be maintained in both projects. It is slightly more complicated and you have to take care with JDeveloper Cache Refresh (see note below) as there may be some strange things happening. Ideally, you should just use one project for BC4J maintenance and ignore the steps below:
The BC4J objects appear in both projects. BC4J objects can be shared in the following way:

  • Create JDeveloper project A
  • Create JDeveloper project B
  • In project A: create BC4J package BC4J components such as Entity Objects and View Objects
  • In Project B: in Project Settings, Common/Dependencies mark the checkbox that specifies a dependency between Project B and Project A (that results in the directories of Project A being added to the Classpath of Project B; this is required for a successful sharing of the BC4J definitions).
  • Create a ‘dummy’ BC4J package (name is irrelevant as long as it is not the same the BC4J package(s) in Project A you want to share) in Project B; do not add any objects to this dummy package.
  • Right Mouse Button menu on Project B (jpr file): select Import Business Components; select the bc4j.xml file in the source directory for Project A and click on Yes when asked “Import as BC4J packageâ€?; now the BC4J definition files under Project A are imported in Project B. That means that we still have only one instance of every file (in the Project A directory structure); those files are referred to from both projects and can be manipulated by both projects
  • Changes in a BC4J object that are made in one project only become available in the other project when the JDeveloper cache is refreshed. This cache-refresh mechanism is not very clear and wellbehaved. The best way to ensure a good cache-refresh is by making changes to BC4J objects only if the other project is temporarily removed from the workspace. In that case you do not run a risk that changes made in the two projects somehow conflict or overwrite each other

Note: JHeadstart – the generation framework used by Martijn – does not support the use of different BC4J packages for Entity Objects and View Objects (neither release 9.0.4.x nor 9.0.5.1). Starting with the upcoming ADF JHeadstart release (planned for November 2004), I believe it will be possible to generate an application based on multiple BC4J packages.

For more information on BC4J (or ADF Components as it is called now) see: Tips on using Oracle’s J2EE frameworks, JDeveloper Java IDE, and XML technologies….

Also see the JDeveloper 10g On Line help: Importing Business Components Created by Someone Else

Steve Muench discussed this same topic in his weblog:
Difference Between Adding and Importing Business Components

2 Comments

  1. Lucas October 20, 2004
  2. Martijn Peters October 19, 2004