Hi all,
Vincent Partington from Xebia has been blogging about J2EE performance problems he and his colleagues have encountered.
They have compiled a top 10 list. It is a very interesting read, as it is all very recognizable 
See http://blog.xebia.com/2007/04/30/ejapp-top-10-countdown-wrap-up/
(and TheServerSide.com as that is where I stumbled across the link to Vincents blogposts)
Never thought I would ever quote Denis Leary in a J2EE context but I’m dying for coffee-flavoured-coffee right now. Just one (damn strong) taste of coffee which strikes the tongue and keep you awake. I’ll try to explain
The immediate cause: InfoQ’s has published an interview with Gaving King about the evolution of Seam, Gavin’s version of a framework telling you how to build (web) applications. I’ve written about Seam before and at that time in my opinion the framework was based on some interesting ideas and principles but lacked simplicity mainly caused by hard to set-up working examples. Never looked at it again (although the intentions were there ….) and I’ll point out immediately I’ll probably won’t look at it right now. So what’s so interesting about the interview? Besides some nice food for thoughts about the implications of a fine grained AJAX approach on database load and some old insights about the effects of state management on clustered environments, not very much. Except for one small comment Gavin makes as a reply to someone commenting exactly what has hit me one year ago. Let me quote:
Comment: I haven’t gotten the time to try out the new Seam release but I hope that setting up a project has gotten easier.
Gavin King’s reply: seam-gen makes it *super* easy, at least for EJB3 on JBoss users. We will be working on expanding the functionality of seam-gen to support other usecases (JavaBeans+Hibernate, Tomcat, J2EE, etc).
And that answer shows exactly what is completely wrong with the so called enterprise edition of java: There is no simple straightforward one-way road for doing things! Choices, choices, choices and a lot more choices that make life easy to model but hard to implement. Isn’t the power of application frameworks that choices are made four you? I would expect a framework like Seam dictates me to take the EJB3 route and pave things in such a way I really start to like the usage of EJB’s. Gavin, seam-gen is okay the way it is, actually it is right what was missing in your initial try. Instead of focusing on other choices, focus on more/better/advanced code generation! Expand into real functionality and help developers by filling room instead of giving it. Another illustration from the exact same interview: the different JSF frameworks Gavin lists. They seem to talk with each other to guarantee smoothness. Gavin calls this maturity, I rather use the term abstemious. A small sidestep without going into a fully blown JSF discussion but isn’t it remarkable (that’s the right word for maturity!) within EE we need a standard (JSR 299) as a glue between two other standards (JSF and EJB) in order to deal with application components in a unified way.
Right now I see a lot of developers (technical designers, architects, name them) spending too much ineffective hours on the which framework to utilize and which standard to adopt question. (not even mention the effort that can be thrown away due to steep learning curves and unexpected showstoppers after the answer to this question once again has lead to unknown trails). One can argue technical design is all about decision making and deciding what to apply is part of it. But in my point of view, technical design is all about the decisions that need to be made in order to translate a business problem into a technical solution. It’s not about choosing frameworks for every layer we can think of. Why are we programming Java? Not because at the start of every project we reconsider it. Nope it’s because we know the language and we know the language is capable of building what is desired in a (cost) effective way. And maybe once in a while we enter some self reflective mode to find arguments that reach beyond the arguments needed to make choices in a project context. And once in a while we pick up innovations, jump on bandwagons and maybe leave the paths we’re walking. Simply because we (as in the average software developer) know that when we do this every day, we can not keep pace with those who don’t.
Why is it frameworks and standards are treat in a different manner? What makes the adoption of yet another framework or standard so tempting? The steps of changing seem to be relatively small. Due to the it’s all Java isn’t it and hey we have a new project so what the hack we’re here to learn aren’t we mentality, risks are not identified clearly. And as a result, unified application development is a farce and for every different twist, more glue is needed. And as soon as the need for glue is identified by more than one developer, new frameworks and standards arise.
Note, this blog entry is not meant to bash Seam nor the interview. It is meant to address a fundamental problem that has been floating around for a while and has been addressed in the past but seems to be persisting enough to get repeated every now and then. And Seam just functioned as a trigger (this time). Everyone who like to use Seam, go ahead, fine with me. If you do not mind, I’ll focus (projectwise) on a Spring based application design until Rails has really swallowed the way I think . But if you use Seam, stay with it at least the coming years (and so, stay with EJB3 and push Gavin to put all his energy in this choice instead of serving all other ways to technically layout an application).
A final thought: Is it a coincident Joel on software has published an article about choices (=headaches) on the exact same date as the interview publication? It probably is. But what Joel describes (15 ways to shut down your laptop) is exactly how we (as in the java community) build applications. Nuff said. Where’s my coffee?
Aspect Oriented Programming for me always has been something that is theoretically beautiful but in practice unfeasible to apply: A good idea that buried itself by bad examples and complex implementations. Until Google pointed me to this great article about AspectJ5 and its integration into the Spring Framework. Actually I was looking for some EJB3 related Spring material but I ended up reading probably one of the first articles that after finishing left me with a �yep, I really want to do AOP, even at home’-kind of feelings.
The whole idea is actually super simple. AspectJ has been extended with two very handy mechanisms: a run time (actually load time) weaving engine and support for aspects that are expressed in Java 5 annotations. Using AspectJ’s API we do not have to rely on a separate compiler but the process of aspect weaving can be initiated whenever we like. And that is exactly the trick Spring is using. Aspects are actually Spring managed instantiations that influence other spring managed beans. When Spring is loading bean classes, cross cutting aspects are weaved in like a breeze.So, I grabbed the latest Spring release (2.0), read some more background information and started right away. Within minutes an AspectJ based interception of a completely meaningless but spring managed hello world bean was up and running. Cool! Hello world never has been so enlighting. To make things a bit more practical, I tried to implement a typical architectural constraint like “Methods on classes belonging to the an applications data access layer may only be called through methods of classes belong to the service layer.”. Normally this constraint is written down by software designers in a plain ms-word or odf ‘thou shall not’-document, but using Spring AOP it can be expressed in a bit of xml (yep, Spring ….) and a Java class. ( I am not going to argue the semantic practicalities and implications of this constraint, for me it is just an example to express the �aha feeling’.) Okay, here are some interesting pieces of the class I wrote. Full details can be found in this posts attachment (acsa.zip). @Aspect public class SystemLayeringAspect { // ……define the pointcuts to identify different layers @Pointcut(”within(com.logicacmg..*.service.*)”) public void inServiceLayer() { }@Pointcut(”within(com.logicacmg..*.dao.*)”) public void inDataLayer() { }
add some thread local sugar for administrative purpose private static ThreadLocal tlServiceCount = new ThreadLocal() { protected Integer initialValue() { return 0; }
};
define the advice to register the usage of service method calls@Around(”inServiceLayer()”)public Object serviceUsage(ProceedingJoinPoint thisJoinPoint) throws Throwable {
tlServiceCount.set(tlServiceCount.get() + 1);
Object result = thisJoinPoint.proceed();
tlServiceCount.set(tlServiceCount.get() - 1);
return result;
}
and define the advice how to deal with data access calls @Before(”inDataLayer() && this(dao)”)public void dataUsage(Object dao) throws Throwable {
if (tlServiceCount.get() == 0) {
throw new ArchitecturalConstraintFailed(dao + ” can not be accessed directly”);
}
}
Note, the difference in the advice types. The service advice needs to work around the actual method call, the dao advice does its job only upfront.That’s it. simply plug it into your Spring application context after the and off you go. ApplicationContext context = new ClassPathXmlApplicationContext(”application-context.xml”);
ExampleService service = (ExampleService) context.getBean(”helloService”);ExampleHelper helper = (ExampleHelper) context.getBean(”helloHelper”);
ExampleService service = (ExampleService) context.getBean(”helloService”);
ExampleHelper helper = (ExampleHelper) context.getBean(”helloHelper”);
service.doSomething();
try { helper.helpABit();
} catch (ArchitecturalConstraintFailed afailed) {
System.out.println(”yep catched ” + afailed);
}
In the example used to test the architectural constraint, a dao is called through a helper bean. Calling the helper directly will result in a runtime failure, calling it through the service is no problem. Seems aspect orientation has finally been made easy. Although, one should be aware of the behaviour that aspects are honoured only by java classes that are loaded through Spring. So be careful with the new operator. But besides that, all I can advice is to have fun and make good use of it.
This years JavaOne was filled with JSF, Ajax and even more the combination of the two. On the Pavilion several commmercial vendors were selling their ajax enriched jsf components. The blueprint team showed us the petstore. Oracle showed us how to build custom ajax enabled jsf components. And so on.
In my previous post I noted the Google Web Toolkit hadn’t landed yet completely in my java wasted brain. After four days of conference my brain is still completely wasted with java (two very positive exceptions, I saw the Ruby on Rails framework running on a java VM using JRuby! and I saw some really Groovy things a java programmer can only dream about) but I found some spare time to play with google’s new toy. While the conference only had one presentation about GWT (compare it with all those ajax and jsf sessions) the rumours/facts (find out yourself) on the internet are spreading. And somehow nobody seems to write something really interesting about JSF.
Is there a reason. Yes ofcourse. First it is the hype. GWT is new so GWT should be cool! Second, al the Ajax/JSF things are actually well known already (otherwise it would be impossible to have such a huge coverage on the conference). But between the rumours/facts I could not find out when to use JSF and when to use GWT?
Using GWT you will run into two major drawbacks. The amount of javascript that need to be downloaded will increase (lineair?) with the complexity of the interface. The KitchenSink example application is relative simple but already needs a 100kb of (compiled/generated) code. The other drawback is that your UI is fully (and I really mean fully) decoupled from your server logic. It’s like a Swing or Flash app making RPC calls. And altough very beautiful (designwise) not always as handy and productive as wanted.
GWT also has a lot of advantages. And they are obvious. No more javascript hackery. No more browser problems. All is taken care of by the toolkit. Another major advantage will be the usage of bandwidth after the application has been loaded. It will be minimized to the necessary RPC calls in order to add business functionality to the application. Which at the end will increase user experience. Using this approach state can be managed on the client (and/or in the database). And finally, the support for browser history works wonderful well.
But the biggest advantage is the fact it is a one stop shop. And here the biggest disadvantage of JSF had been mentioned. JSF is just like GWT (and Echo2 and several others) a component oriented approach for building rich web applications but it will allow you to combine several techniques together. It gives you the possibility to mix javascript library x with library y. It’s like combining Swing and SWT on the desktop. Javascript libraries are becoming the assembly languages of the web. And combining assembly languages does not feel right. (By the way, using Tapestry or Wicket this same problem can occur)
So when to use JSF and when to use GWT? I can’t answer this question. When all those beautiful JSF components provided by one and the same component vendor are being used and nothing more (not even self written ones!) JSF still seems a good choice. But if you can accept the drawbacks of GWT, I probably would recommend to at least investigate the possibilities GWT is opening up. (Or take a serious look at Echo2!)
So what if you want to develop a rich portal application, let’s use the standards!
Standards are their to make live easy for you, right…..? 
I want to create a Portal application with a rich and easy to build interface, this leads me to the following standards JSR168, the portal standard and JSR127 the JavaServer Faces specification. First of all I want to find a portal that supports this standard and does not provide to much overhead. This lead me to the JSR168 Portal Jetspeed (http://portals.apache.org/jetspeed-1/). Jetspeed 1 also provides support for JSR168 under the codename Jetspeed Fusion.
Yes there are other alternatives like Exo and Liferay that do the job but these provide to much overhead for my “simple” requirementSo the most important step is done I found myself a suitable OpenSource Portal with JSR168 support. Now we need to install it and as always Apache provides a out of the box solution including Jetspeed and Tomcat 5.0.3. The next step should be easy we need to create a rich JSR168 portlet application using JSF technology. In my opinion this should be as simple as 1.2.3. We just need to include the JSF jar into your project and start developing the portlet following the JSR168 API. After that we can just create a war-file which will be automatically deployed by Jetspeed.How wrong can one be, standards are not their to work with each other out of the box one must create a bridge for these two standards to work together. In this case I need to use the Apache Portals Bridges project ( http://portals.apache.org/bridges/ ) for these two standards to work together. The bridge consists of a generic Portlet-class which forwards your actions according to your configuration in the portlet.xml. All in all it’s not the work that triggers me but the bridging method, is this also based on any standards?? Or will we have to build bridges to support bridges?? So why do we need a non-standard bridge, which by the way impacts your flexibility to code portlets, to couple two standards? Aren’t both standards all about presentation? And why isn’t the JSF standard not supported by JSR-168 (or the other way around)? JSR-286 seems to make some promises about a tighter integration but besides to late, it is still a long way to go.So, until then we’re struck with bridges and our history has learnt us how dangerous bridges can be
At the moment a college has asked me to think with him about a big contract. It’s mainly about the bigger things in development life and forced me to think about developing bigger applications than we have done until now. This fortunately fell together with the talk Duncan Mills had at Guru4Pro (see other article) which also made me look at things in a bigger picture.
I’ve mostly worked on applications that follow the MVC web-app stripe. The Oracle ADF framework can fill this in completely for me. However when we start to live in a less constrained world we have other stuff poking in. Webservices are asked for, ESB (Enterprise Service Bus) is a big bussword here. So i’m looking around for the framework (extensions) that can help me.
I’ve made a little list of things i want to do some research about:
- BPEL: BPEL can solve the *big* SOA problems like asynchronous calls and easy configuration and so on. BPEL processes are exposed as simple webservices. JDeveloper can generate stubs to call webservices, i’ve developed my own way to expose webservices (using Apache Axis) and to call them dynamically (using WSIF) or to do some registry stuff (UDDI4j). So this piece of the bigger picture should not be a big problem.
- JSF knowledge: Still have a lot to learn here. However my main problem, no templating in JSF, could be solved by something called Facelets. Have only heard of them, need to find out about them. Will it work with the Oracle ADF framework?
- Security: Okay as a developer i don’t care about security, but customers do. ACEGI pops up everywhere. Need to look into that. Will it fit in the Oracle ADF framework somewhere?
- And the big one i don’t have a clue about yet. How to integrate Oracle ADF to a Enterprise Service Bus. Still have some thinking to do. Just using Message Driven EJB’s probably won’t cut it. The ESB i’ve heard from was implemented using Oracle Interconnect. Yeah, another Oracle product, that should already be done by them, shouldn’t it? I don’t know yet.
So, these are my thoughts at the moment. However fortunately for the world there are a lot more people out there who are much more intelligent than me. And those people are you. I would like you to give me some pointers on my thoughts. Do you have experience with products that integrate into or work with the Oracle ADF framework for these this? Please leave a comment.
Links
A nice article about integrating BPEL and JSF (written by Chris Schalk)
As Okke stated earlier, Duncan Mills has made a visit to the Netherlands to speak on an event called Guru4Pro. Guru4Pro is a series of presentations given by knowledgable guru’s. The first of these presentations was given by Duncan Mills of Oracle. Duncan has been working in the field for 18 years in total, of which 14 years for Oracle. Duncan started on the support department but quickly switched to product development. Currently he is developing the ADF framework, the framework we use for application development.
The presentation was called ‘The rise (and rise) of the meta-framework’. The presentation gave a clear view into the world of frameworks and meta-frameworks. Duncan first started by explaining what a framework exactly is. His view is that every (competent) developer will build there own convenience libraries to make their own life easier. I personally like the comment “If your developers aren’t constantly developing their own libraries to make their job easier, you should fire them and hire others.” It make the point clear that deep down everybody should be thinking about extracting the ‘dumb’ and ‘easy’ stuff and letting libraries do that for you. However a library, or a set of libraries isn’t a framework…
A framework is a complete solution for a specific problem, a point solution. Good examples are Toplink, Hibernate, Struts, JSF, EJB, Spring, etcetera. Frameworks should be applicable for more than one solution, they should be flexible enough to solve the problem every time for each application you make. A good framework at least.
Duncan further stressed the criteria he feels a (good) framework should fill (i list here only a few):
- Coverage and depth: a framework should do everything you need. If it won’t (say your persistence framework cannot do updates) you won’t use it
- Documentation & User guidance: a good framework should just give you a set of API’s. If the framework is to succeed you need to explain the framework in documentation and it should provide guidance in the way to solve problems, the right way
- Infrastructure not generation: a framework provides the plumbing, it does not generate code. If you just generate code you’ll have problems during maintenance. Frameworks abstract and solve the problems
- Pluggability: the meta-framework should work with different frameworks. And it should work exactly the same
- And last but not least ‘a cool name’: has anybody heard of the Oracle MVC framework? No, but Spring rings bells. Spring is a cool name
After defining what a framework was, Duncan gave the term ‘meta-framework’ a meaning. A meta-framework is a framework that combines all kinds of frameworks to provide a complete solution. The meta-framework should integrate the frameworks and make sure they work together correctly. The developer using the meta-framework should be able to do things in a consistent way without bothering about the underlying frameworks.
Duncan gave an example using the Oracle ADF framework (the new one based on JSF) and Oracle JDeveloper 10.1.3. First he wizarded two kinds of datasources together. Nobody will be to overly impressed by an IDE that can give you a wizard that can generate your persistence layer. However he created a persistance layer based on Toplink and EJB 3.0 session beans, next to that he created another persistance layer based on Oracle Business Components. Next we went on to the UI. Duncan showed that using the meta-framework and abstractions that Oracle ADF gives the developer to possibility of using data sources as just a source of data without thinking about the implementation. He could drag-and-drop the Toplink and EJB based data on a JSF page the same way as the Oracle BC based data. After that he showed how to integrate those two sets of data and synchronize them. You could now browse the department data (via the Toplink and session EJB) and see the relevant employee list (via Oracle BC) and without much ado those two different data sources were combined. Personally i found this a really good demo, it was pleasing to see something else than the usual slick sales manager click-through. Duncan later told me he only thought up this demo a few hours before the presentation; he also thought it was good the show something closer to reality.
After the Oracle ADF demo the presentation went on over meta-frameworks. The only other framework that comes close to meta-frameworkness was Spring. Both Oracle ADF and Spring come close, but neither are there completely yet. Both meta-frameworks revolve around their key-ability to glue frameworks together. Oracle ADF used the ADF Model Binding layer and Spring uses the bean factory. Spring for example has better security support than Oracle ADF, but Oracle ADF has better tool support.
The last part of the presentation was about trends that are comming. The latest trend is that the standards are behaving differently and comming up to par with proprietary (not in the sense of ownership, but in the sense that it isn’t the standard) frameworks. JSF has come to replace Struts. EJB 3.0 is comming for Toplink and Hibernate. Duncan explained that when the standards are getting better, the frameworks will be getting thinner and thinner and finally will fade as a framework a become an implementation of the standard. Meta-frameworks are rising and will rise in the future.
One of the most enlightning things were the challenges Duncan named. He said that meta-frameworks have a few (few?) challenges ahead. One of the challenges is debugging. Debugging should be abstracted just as development is. Why should you be thrown in the framework source code when you only created a XML to configure something? You shouldn’t, Duncan formulated this very eloquently by stateing (cannot produce the exact quote but it was something like) ‘Frameworks have recognized the debugger, debuggers have yet to return the favour’. Dbuggers will have to become ’smarter’ or maintenance will be problematic.
Another challenge that we developer and i myself am constantly struggling with is State Management. At the moment the only problem i have with state management is the fact that i have a heck of a problem because users want to use that ‘back button’ in their browser. They also want to use the ‘Open in new window/tab’ functionality and have the application react correctly. With our applications it isn’t working. Fortunately the meta-framework developer has also recognized this problem and is working on it. This was one of my most pleasant surprises: They (they is Oracle here) actually have a (good) clue about the problems in facing when using their product (framework) and they are working on it!
As all presentations end, this one was also concluded with a refreshing drink and talk in the internal bar at LogicaCMG (yes, the cafeteria actually also has a small bar. Big plus for any employer)
A few collegaes and i also had the pleasure to meet Duncan before the presentation and the next day to talk about all sorts of stuff. We could talk freely about the pro’s and cons of the Oracle ADF framework and hear what Oracle is doing with it. Duncan is very knowledgable about the framework and is a real pleasure talking about it. You can really fell that he has a passion for the work he is doing and that he believes this is the right way to go.
I would like to thank Duncan again for his presentation and would recommend everybody to attent a presentation of Duncan if they can.
You can download the presentation here. It contains the slides including comments written by Duncan to explain the story fully.
PS. [shameless plug]Look at the Guru4Pro presentations. They are free to attend, you’ll like them.[/plug]
Links
Duncan Mills’s Weblog
The slides and comments of the presentation given by Duncan
Guru4Pro
Finally got around to doing something with the new Oracle JDeveloper version 10.1.3 that went production a little while back. I’ve written a little about my first impressions that i had with the Early Access, but now it’s time for the ‘real deal’.
As a test i recoded an little application we made for a customer. It is surprisingly big (1 page) and contains next to no functionality. Always a good idea to start simple. Creating the workspace and projects was a breeze as always. The wizards in JDeveloper take a lot of the tedious work out of your hands. The improved integration with CVS seems to be a lot better. (Waiting for a good solution to switch over to subversion; it seems you can totally rewrite the CVS client configuration to use subversion but that is a little out of my league for the moment) The main feature i like is the improved ‘Pending Changes’ screen. Next to the changed files it also lists files that are ‘candidates’ or more commonly known ‘that (*$&%(*&$ file i forget to add’. However i divert from my story.
Using the new faces-config.xml is quite like the old struts-config Page Flow Diagrammer as doesn’t require much getting used to. Just drag the pages and start double clicking 
. Something i needed to get used to was the managed-bean facility of JSF. The whole ‘inversion of control’ pattern i know needed to get acquinted with. It works quite good… however it is a mind turner. People that have used Spring in the past will probably have no problem, but it is a little tricky for those, like me, who haven’t used it before.
I followed some of the guidelines that Oracle describes in their developer’s guide (674 pages!!!!). It is a good document that explains a lot of things. First i set the following rules for myself:
1. Use JSPX pages. They are more structured (and convenient for me because i’m used to the UIX xml files)
2. Only use the ADF Faces tags (let’s stick to one library of tags)
3. Only use Faces tags, no ‘hacking’ of HTML code in between the tags (worked well in UIX)
The positioning of the UI components was quite intuative for me. But i’m used the UIX and that part really doesn’t differ a lot. You need to learn to use a different set of nodes (panelXXXX nodes for the XXXXlayout nodes, etc) but facets are the same as named children, so no difference there. Oracle quite literally just ported all their UIX UI Nodes to JSF UI Components so the panelPage has exactly the same facets as the pageLayout had named children.
Unfortunately here the power and convenience of UIX started showing. UIX has a templating mechanism that JSF lacks. I had the idea to ‘replace’ that templating mechanism with programmatically changing the UI Components in my backing bean. I had the idea of extending my backing beans from a common backing bean and in that common backing bean create the getter and setter for my Page component and changing it there. It would mean that in each page i only would have to add the binding for the af:page component and it would be configured correctly. That actually works! The base backing bean now sets some common facets and attributes for the af:page component (branding, appBranding and copyrightApp facets) and the afh:head component (title attribute). It makes for a layout that is the same in each page without having the copy-paste it. In my opinion JSF really has a fatal lack of functionality here.
On to my next favorite subject in applications, the menu. I’m a firm believer in the fact that you should create of menu once and not in each page. The ADF Developer Guide gives you an elegant solution for creating a Tree structure (based on the JSF DataModel object) that contains your complete menu. The af:page component has an attribute in with you can supply that tree and a facet with which you can specify how it should look. I’m currently trying to get that working in my base bean aswell. Here the lack of a templating mechanism comes up again. In UIX we would create a template for the PageLayout node and in that we would define our whole menu. Then the page would use that template as a reference.
I’ve heard some rumors that in the next version of JSF this will be addressed. I really hope so.
I next went on to doing some autorisation on the menu. In UIX we had the possibility of creating our own functions in expression language. We extensively used that (think of the function #{auth:hasRole( ‘ADMIN’ )} in the rendered attribute, how simple) but in the ADF Faces reference it states that there isn’t a replacement for UIX EL functions in JSF. I still need to check the ‘normal’ tag libraries because a little voice in my head says you can add EL functions there.
Finally i went on to the part that customers always find especially important: the look-and-feel. Here the real nightmare starts. The things you have to do in ADF Faces to get it right are…. well, i don’t even have words for it. First let me explain somethnig i found out the hard way: JSF has render kits and renderers for its components. The ADF Faces renderers have added the skinning functionality. Creating JSF renderers is a painfull proces. I cannot fathom why everything needs ids, families, types and all sorts of things. I have component A and want renderer B to render that component A. I don’t want to create a renderkit (well that is a good idea because you group renderers in a kit) and renderers that must link to families and types. What is that whole family idea? Next the actual renderer itself. What were they thinking when creating the ResponseWriter class? To start an element you must always give a UI Component? I just throw out null everywhere. To write an attribute you need three(?) parameters? The attribute name (ok, logical), the attribute value (ok, logical aswell) and the property name (HUH? what the heck is that?) So we first wrote a wrapper around that beast to fill all those ‘weird’ parameters with null or defaults. Then the road straightened out a little. Now the renderers make a little sense, basically the same as UIX
Next on to the beast they call skinning in ADF Faces. Never have i seen such a confusing thing. I’m personally quite favored to the Oracle libraries, but here they made a mistake. In order to change the skin of the ADF Faces components (technically you change the generated CSS file), you must edit a CSS file. That CSS file in the reincarnation of XSS files from UIX. In XSS files you had an XML file in which you defined styles and styles could be specifically added for browsers, platforms and/or locales. But now you must do the same in CSS using a syntax that is completely of the world. I already made my first SR (Service Request on the Oracle Metalink support site, formerly known as a TAR) about the problems you get when Oracle has a browser specific setting somewhere and you can only override generic settings in the CSS, but the specific settings overrule the generic ones. The nice thing is that if you go searching in the ADF Faces library you acutally find those XSS files back!!! So why not give us developers that same power? Now we need to do things in a CSS file for which CSS was never intended. Hopefully the guys (and gals) over at Oracle support can clear things up, possibly we can use something else than that CSS file….
Although it seem i’m only ranting about the negative things of the new framework i’m quite pleased about it. As a whole it still is quite a productive technology stack (or framework if you please), but after my current experiences with it, it cannot compare with the previous stack that contained Oracle ADF UIX. My admiration geos to the people of Oracle that came up with the UIX technology and my sympathies go out to them because they must now be marginally depressed by the way JSF replaced UIX.
However, only the future will learn if JSF can reach the same as UIX. We will certainly choose for the technology stack that contains JSF, but only because Oracle will not support or further develop UIX.
Now the only challenge left is to convince our customer to install a new OC4J to run the new version of the application
PS: First reply from Metalink: “Could you send us a testcase showing your problem?”. How typical. Quick reaction though…
Last friday and saturday LogicaCMG organised an internal RADRace. The man who made the assignment was nobody other than Ivan Verborgh, the man who makes the assignments for the international RADRace.
The assignment was to make a webbased application with which people could apply for a license plate. It had to contain at least:
- Multi-lingual screens
- A webservice for checking credit card codes
- Role based authorisation, different functions for different roles
- Wizard like registration process
- And of course lots of business rules
Last year we (Reza Ahmadi and I) entered using Oracle Designer and Oracle Forms (after realising we didn’t have enough knowledge of Oracle ADF) and had the pleasure to win.
This year we (Gideon Liem and I) entered using Oracle JDeveloper 10.1.2 and the Oracle ADF framework. We had prepared a kick-start application that contained a new look-and-feel (Using custom renderers in UIX) and some authentication method.
From there we built almost the complete application. In the end the following stack of technologies were used:
- Oracle Database 10g (as the big Datastore, we can use another database?)
- Oracle OC4J stand-alone (as the application server)
- A small SMTP server, called JES
- Oracle ADF Business Components (as the persistence layer)
- Oracle’s implementation of JSR-227 (as the binding layer, between the persistence and the view layer)
- Oracle ADF UIX (as the view layer layer)
- Apache Axis (as the webservice engine)
- Apache jUDDI (as the webservice registry)
- UDDI4j from Sourceforge (communication with the registry)
- Apache WSIF (communication with the webservice)
- Apache POI (generating Excel reports)
One of the things that were most difficult for us was the refactoring of the data. Ivan had prepared the challenge in a way that we got the data as two big denormalised tables. Part of the challenge was to normalise the data so you could use it for your application. It took us the morning of the first day and the first hour of the afternoon to get the database right.
After that the framework kicked in: generation of the persistence layer is really a breeze. When you just had the rule of thumb to code your screens on your tables (don’t think in Objects if you got tables… it makes sence to see the whole picture and combine the two). UIX pages are the view layer we used in projects the last year and we have become quite proficient with them. The binding layer makes it possible to get your model and just drag them tables into the screen and have them work. Most of the time we could do what building an application is about: building the business logic that matters… All else should be simple, easy and quickly done.
Rest us to say we had the pleasure to finish first in the contest. Unfortunatly our competitors that used JHeadstart had to drop out for the second day (for personal reasons), we would have really liked to compare their result with ours.
Runners up were: in second place a microsoft team using Microsoft .NET 2.0 (they also had a good working application) and in third place a Java based team that used LogicaCMG’s own open-source framework: ePlatform.
Photo’s
All the teams and the jury
We, Gideon (right; in white, red & blue) & Robert (left; in grey)
Design is essential
Evaluation by the jury
Success!
Links
Oracle Technology site, you can find the database, application server and JDeveloper here.
Apache, great products here
Sourceforge, also here
bloggingabout.net, another blog sponsered by LogicaCMG that contains a post from the microsoft competitors
ePlatform (on sourceforge), the ePlatform site
Just having ‘fun’ today exploring the new framework Oracle has launched a little time back. For some time Oracle JDeveloper 10.1.3 EA (Early Access) has been available. It boasts the new stack of technology for Oracle. The technology stack (for us) consist of:
- Business Components (ADF BC)
- JSR-227 (The binding layer)
- ADF Faces (Oracle’s JSD implementation
Nice to play with but it is giving me quick some headaches. JSF is quite different from Struts as we used previously and JSF resembles ADF UIX (Oracles view layer in JDeveloper 10.1.2) but works very differently.
As i’m just randomly rambling on now i’ll let you share my experiences and big bone-headed blunders.
First of all… The development environment has been revamped. I quite like it, but i’m kind of partial to JDeveloper (oppossed to some co-workers). Refactoring has been extended quite a bit and they included the one feature i liked from Eclipse: double clicking on a title expands that window…
Secondly i started lookign at Business Components, not much new here, anybody that has worked with ADF BC in 10.1.2 should have no problem jumping in here.
Now the changes started: JSF! or in other words: ADF Faces… Completely back to the drawing board for me. Everything works a little different. A button on a page can call a method, back where does that method go? For my own purposes i made a mental mapping between the Struts Action and the JSF backing bean. All the code for the page goes in there. Just double click on the button and a method will be made for you (reminded me of those visual basic editors ). Now the problems started: i wanted to get at my data… but where was it stored? UIX gave you a nice event context from with you could get everything. The event context of JSF contains about nothing… However the OTN Forums helped me along. You need to leverage the strengths of JSF to get a connection to the bindings layer. You need to create a managed property in your managed JSF bean that is filled with #{bindings}. A presto the magic happens.
So far so good… we have a working data layer (ADF BC) and a ready to go binding layer (using JSR-227) to go and build our application.
I’ll keep you informed.
