Some time ago I got a question in a comment if the Oracle Unified Method (OUM) is or will contain any software components like we used to have with CDM (like CDM RuleFrame and Headstart).
The answer is no. And the reason is as follows.
CDM was restricted to Oracle Designer/Developer and the usage of the Oracle Database with that. OUM is not based upon any specific tool set, just simply because there are that many that (currently) it simply is impossible to do so. Maybe someday, when we "fused" all our products into one consistent tool stack, who knows ... But I don't see that happing in a future near me.
On the other hand, I hope we will be able to add some technology and even tool specific guidance to OUM for some of the tools we have.
Friday, June 19, 2009
Oracle BPM and Java objects
Why using Java for business objects?
When creating business objects for Oracle BPM (10.1.3), I have a couple of compelling reasons for basing them on a Java class model. The reasons being:
Oracle BPM leverages CUnit (and PUnit), both being proprietary testing frameworks. When you base your business objects on Java, this also offers the opportunity to test your objects using the de facto standard unit testing framework JUnit.
BPM business objects can only be used by BPM. A Java class model can be reused almost anywhere, including BPEL, and (obviously) Java applications.
How using Java for Business Objects?
Just follow the instructions for catalogueing components in your catalog. To leverage the extra functionality that BPM business objects offer (including creating object presentations), create a BPM business object for every top-level object type that you need, as an heir of the Java class. Don't do them all, only the ones you need the extra functionality for.
I put the Java objects and BPM objects in the same catalog, and name the BPM objects after the Java classes, post-fixed by "BO", for example CustomerBO for the Customer Java class.
Finally, to ease synchronization between JDeveloper (or your preferred IDE) and Oracle BPM, after first-time catalogueing, generate the jar file with the Java classes directly to the lib folder of your BPM project.
When creating business objects for Oracle BPM (10.1.3), I have a couple of compelling reasons for basing them on a Java class model. The reasons being:
- Ease of migration
- Testing
- Reuse
Oracle BPM leverages CUnit (and PUnit), both being proprietary testing frameworks. When you base your business objects on Java, this also offers the opportunity to test your objects using the de facto standard unit testing framework JUnit.
BPM business objects can only be used by BPM. A Java class model can be reused almost anywhere, including BPEL, and (obviously) Java applications.
How using Java for Business Objects?
Just follow the instructions for catalogueing components in your catalog. To leverage the extra functionality that BPM business objects offer (including creating object presentations), create a BPM business object for every top-level object type that you need, as an heir of the Java class. Don't do them all, only the ones you need the extra functionality for.
I put the Java objects and BPM objects in the same catalog, and name the BPM objects after the Java classes, post-fixed by "BO", for example CustomerBO for the Customer Java class.
Finally, to ease synchronization between JDeveloper (or your preferred IDE) and Oracle BPM, after first-time catalogueing, generate the jar file with the Java classes directly to the lib folder of your BPM project.
Subscribe to:
Posts (Atom)