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 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.
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.
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
Martijn,
I had planned on sending you an email to tell you about JHeadstart’s inability to make use of two different BC4J packages. I realized it Monday night as I drove home. I think it is a very simple addition to the JHeadstart generator extensions:
– define an additional Service Level property, similar to persistenceBase, something like Entity Objects persistence Base
– change in the JAG XSLTs the way the eoDOC variable is derived
We might be able to trick the JAG by copying the EO-xml files to the same directory as the VO-xml files, but to me that is a dirty solution and I am not sure how BC4J will react. So I suggest we concentrate on this small change in the generator.
Lucas
Lucas,
After some struggling with the wizards I finally succeeded to use an enterprise entity objects package in another project.
This are the steps for JDeveloper 10g in more detail:
– open a new Business Component project …
– … define entity objects without view objects and appmodule
– add a new Business Components Archive – Deployment Profile and deploy it
– open a second Business Compontents project …
– … do not define any entity objects, view objects or appmodule!
– add the middle-tier archive of the first project as a project library in the second project
– right-click on .jpx file in the System Manager and select Import Business Components …
– … navigate to the Business Components .xml file in the middle-tier archive
– once again right-click on the .jpx file and select New Default Data Components …
– … select the package name of the second project and select entity objects of the first project
– … now create view objects and appmodule to be used in the second project
Now remains the question: how to continue with JHeadstart?
When right-clicking the appmodule the New JHeadstart Application Structure File is grayed out.
JHeadstart cannot store JHeadstart properties in the read-only entity objects .xml files (and it should not be 😉
Can we fake JHeadstart by copying the .xml files from the first project to the second project?????
kind regards,
Martijn