Suggested Topic : Tree Bindings

It has lot of scope to explore. Constructing Tree Models, Using Binding APIs to perform CURD, Behaviour in Self Referential View Link VOs..

I’ve linked this post and the next few tunings posts to the Oracle Wiki page:

http://wiki.oracle.com/page/ADF+Business+Components+Examples

Cheers,

CM.

I agree, the BRE is a fine alternative and one I didn’t discuss.

Fundamentally, it falls under the “Middle Tier” solution, since BRE does run in the middle tier. But there are a few differences from the middle-tier solutions I mentioned above.

The biggest ones are the ones you mentioned, and these are definitely advantages over other middle-tier options: You can change rules without an application redeployment, and the interface is simple enough that you don’t need to be a DB developer, or any kind of developer for that matter, to implement new ones, allowing the analysts who design the rules to implement them too.

The downsides:

1) To actually use the business rules, you have to assert “facts” (either a particular sort of JavaBean or a particular XML message) and recover results, including the error messages (if any). ADF won’t let you do that declaratively, so, like the database case, you’re going to be writing some Java code to invoke the business rules. I think that in most cases, it’s substantially less code, and less nasty code, than getting ADF to play well with DB trigger errors, but it’s not trivial.

2) The BRE does not come as part of ADF; it comes as part of the SOA suite. That means you’re going to have to pay for it. If you have highly volatile business rules and/or really need your business users to be able to change them (or need the SOA suite for some other reason, like wanting to develop SOA applications), it’s worth it. If not… well, you need to consult your budget.

I was wondering why you’re not mentioning the Oracle Business Rules Engine to enable business rule integration in a java application without being a DB developer.

Isn’t this a good alternative as well?
It’s still a little bit fuzzy regarding the ability to change rules at run time with a fancy look & feel which is business friendly.

Kind regards,
Nathalie

So, I want to distinguish two sorts of inputs/outputs. Both are important to document, but they should be documented in different ways.

One sense of inputs/outputs (which applies only to “full” services) is user inputs/browser outputs, business rules governing them, etc. Obviously, developers using the services need to know about these, but so do the users. I think user documentation of these inputs and outputs should suffice for most purposes.

The other sense of inputs/outputs that needs to be documented is really only of interest to developer consumers of the service, but it’s rather more limited. It’s just the inputs that the consuming application needs to pass to the service, the outputs it can expect in return, and the changes to the entity caches that the behavior translates into. The inputs and outputs that the application needs to pass/can expect can be documented just as you would write Javadoc (though obviously you can’t take direct advantage of the Javadoc engine to do so).

JAR files…I agree that versioning is the current weakest point of the methodology. But I don’t think it’s a deal-killer. For one thing, I think that, if you think of the deployed libraries as internal *releases* (in a very fast-cycle, Agile sense), and really use the centralized network instance of the JAR (which will always be the latest release, definitionally) as much as possible, then this sort of versioning won’t be a huge issue.

But I’m still not 100% sure that this is the best way to manage it. Here’s another possibility:

Each application, or service that relies on other services, has, in its build script (and I *strongly* recommend using build scripts, at least for deployment for a variety of independent reasons–though that’s a topic for a different post) which actually checks the latest version of the needed applications out of the source control system into a temporary area, compiles and JARs them, and copies them into the WEB-INF/lib area of the app, so that the built project will always have the latest version of all relevant libraries.

Since the deploy script will call the build script first, this version will also get into the deployed application. (This, obviously, is *not* treating the libraries as having fast production cycles, but rather requires a synch between libraries and apps at each phase: development/testing/production, which is less than perfect; that’s why I prefer the original methodology for this).

One impact of any of these systems is that, to take advantage of a new release of the service, the applications that use the service will need to be redeployed. I’m looking into the possibility that BC and Task Flow libraries don’t actually need to be deployed with the service but can just be added to the J2EE container’s shared classpath (I don’t yet know whether this is true); in that case a simultaneous deployment (via build script) to both the container shared classpath and the shared network location will assure that the latest release version is being used at both design-time and run-time (requiring only a JDev/container bounce to take effect, respectively).

Wow. That was a long reply. It was a very good pair of questions.

You can't keep a good idea down… Time and technical issues may have conspired to prevent Avrom…

Time and technical issues may have conspired to prevent Avrom Roy-Faderman from doing his “Extreme Reusability” presentation at the OpenWorld Unconference Methodoloy Symposium, but that material has been repurposed and is now available on Avrom’s bl…