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 My Next (Post-Book) Project
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 The Power of Properties
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.
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 The Business Logic Wars
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 SOA What?