Avrom’s Java EE and Oracle ADF Blog

After my current book project is put to bed (right around the end of 2008, hopefully), I’m hoping to work on something I’m very excited about: A multipurpose “make-it-easy” framework extension for ADF 11g. Continue Reading »

Most ADF BC users are traditional Oracle developers–Forms or PL/SQL developers–who are relatively new to Java and Java EE (some, at this point, have lots of Java expertise, but even those usually have still more experience with an older Oracle technology). Because of this, when they miss out on one of the greatest powers of Java, reusability, they often don’t realize, or at least appreciate, what they’re missing out on. So the fact that ADF BC doesn’t openly encourage designing custom code for reusability gets missed.

But this is emphatically not to say that ADF BC doesn’t enable reusability, or even that it’s not documented. It’s just not called out in ways that would encourage a novice, or even intermediate, ADF BC developer to take advantage of it. Continue Reading »

What is a backing bean? Getting a consistent answer can be harder than you might think. For example, the NetBeans JSF tutorial claims that the two terms are synonyms. And NetBeans had its origin at Sun, so they ought to know, right? On the other hand, the official Java EE 5 Tutorial says that a backing bean “is a JavaServer Faces managed bean that is associated with the UI components used in a particular page.” That suggests that backing beans are a proper subclass of managed beans. And that’s straight from the horse’s mouth, at java.sun.com.

I think that the distinction made by the Java EE tutorial–that a backing bean is a particular sort of managed bean distinguished by its association with a particular page’s components–is a very useful one. But the tutorial also states that “A typical JavaServer Faces application couples a backing bean with each page in the application.” And that is where we part company.

Continue Reading »

In an enterprise application, there are lots of choices about where to put business logic–validation rules, value calculation, and so on. You can put it in the database, in the server-side web application (and there, you have a decision about whether to put the code in the model or the controller), or as Javascript running on the client. Where should you choose to put your application’s business logic?

That’s a great question to ask in a bar full of developers of mixed backgrounds, if you like bar fights. SQL programmers will say you should put your business logic in database triggers, where it’s most secure and robust. Heavy-duty Javascript types will say that, at the least, business logic needs to be redundantly implemented in Javascript, to improve client interaction and reduce server round trips. And people from the Java EE community will tell you that the database is for data and that RIAs give you performance almost as good as Javascript without the security concerns, and that you should take the compromise (and the best-structured, most extensible option) and put the business logic into the middle tier.

I have my own very strong opinion on where to put business logic, but it isn’t any of the above. It’s this: It depends. Continue Reading »

Web services are great. They allow for loose coupling between applications that use different technologies, are developed and hosted by different organizations, are asynchronous with one another, and so on…all for the low, low price of encoding the request, sending the request over HTTP, deserializing the parameters, serializing the result, sending the result over HTTP, and decoding the result. Well, OK, not that low a price. But what you get for it is pretty impressive.

Sevice-Oriented Architecture (SOA) is the idea of structuring entire applications around web services. Business service implementations are deployed entirely separately from one another and from view/controller implementations, and published as web services. Applications that need to retrieve, analyze, or change data contact the web services to do so. Lots of people love SOA. I’ve even met a fair number who love SOA so much that they think it’s the only reasonable architecture for enterprise applications.

Now, don’t get me wrong here. I’m not anti-SOA. Continue Reading »