Composite Controls with ICEfaces and Facelets

I've been interested in ICEfaces for a while now, and been pleased to see how the adoption is coming along.
One thing I've noticed is how many AJAX and Rich-client frameworks impress with cool widgets but make things complicated through excessive use of Javascript or poor integration at the back-end. I think there's danger in choosing a framework for it's widgets, and there's a risk that people look at ICEfaces purely as a JSF rich component set, not as a complete framework, which it truly is.
Being built on the JSF framework, ICEfaces is a first-class citizen in the JEE world and integrates well with just about any other Java framework. (It can even play nice with a surprizing amount of other JSF component frameworks, like Apache My Faces.)
On top of this, their IDE integration is top notch, supporting just about anything in common use today. After using Eclipse for a while now, I've recently moved to NetBeans due to my new role. Thank goodness the ICEfaces IDE support module is there!
Recently I have had the pleasure of re-aquainting myself with ICEfaces. I finally got the job I've been hoping for since my first brush with JSF a few years back. I'm now a UI architect and it's fantastic to have the company respecting my opinion that ICEfaces/Facelets/JSF is the way to go for enterprise rich internet application (RIA) development.
I even got the opportunity to take my new team on an ICEsoft training course to get them excited about the possibilities. The people at ICEsoft have a great, open approach. They are interested primarily in productivity, and gave all kinds of ideas in how to best use their framework and how to best utilize other tools to be productive. In two days they were saying things like "that's so cool", "this is how web app development should be" and "I'm never going anywhere near Struts again". In ICEfaces, you hardly ever have to think about the request and what values it's sending. You're thinking in terms of components and objects and services - that's the way OO development should be.
I thought that I knew what there was to know about the whole gamut, but there was even a revelation for me: How to make re-usable AJAX enabled components using Facelet composites. I thought I would have to be making new JSF controls and digging into writing TagLibs, Javascript and writing JSF lifecycle event handlers. But I was completely surprized just how easy it is to make a re-usable components that combines the power of Facelets with the coolness of ICEfaces AJAX components. (Perhaps I'll blog on this some time. I had a cool widget up and running in about half a day, and then spent a little more time to extend it.)

Well that's it for now. Take my advice, the next time you think about doing a Java Web App, evaluate ICEfaces. (And don't just look at the component showcase, evaluate the whole framework.) You may find it very enlightening.

Alberta Board Game Developer Gathering

The game mentioned in the last post has been playtested, tweaked and enhanced.
"That Flipping Property Game" will be presented to a group of discerning Board Game Designers over the August long weekend at the first "Alberta Board Game Developer Gathering" sponsored by The Sentry Box in Calgary.
Several Alberta-based designers will be attending with their polished prototypes to share ideas and shape their new game designs.
I'm much looking forward to it!

New Boardgame in the works...

This year I had one of 'those' ideas - one that you just HAVE to pursue.
The premise of the idea was: "What would a Euro-game version of Monopoly be like?"

The answer is a lot more like a Euro game than Monopoly, but it does have properties for sale! ;)

Watch this space...

All Faces: Java Server Faces, ICEFaces and Facelets in Weblogic Workshop 10.1

It's been a while since I last looked at JSF seriously. The projects I work on day-to-day for the last little while have been Swing and Struts-based.
However, I recently had good reason to delve back in where I left off quite a while ago, and frankly, not much seems to have changed.
Probably the most significant progress is in visual JSF development and AJAX support. We're seeing more developed components and better integration. However, out of the box support for getting up and running with different JSF configurations is still sparse. I feel that things could be a lot smoother with smarter tools support.
JSF is still struggling for dominance over a legacy created by Struts adoption, and an uphill battle against burnt fingers and mis-information about the framework.
I agree with Rick Hightower, that, once configured, you can be more productive and will find things more intuitive than Struts. However, if the goal is to make things as smooth as, say, ASP.NET 2.0, there is still some way to go.

I'm personally rooting for ICEFaces, who have made a fair bit of progress in the year since they Open-Sourced their JSF AJAX framework. ICEFaces is J2EE AJAX 'done right'. The Javascript is managed by the framework, giving a Java programmer the ability to control the state of the UI eficiently and dynamically from the server, using 'AJAX push'.

Having worked with Weblogic 10 for the last little while, I have been impressed with the complete toolset, including the development environment which allows easy integration with Weblogic server on the desktop. Weblogic Workshop is a custom version of Eclipse which includes advanced support for JSF authoring. BEA now includes ICEFaces support within the IDE. However, I ran across a couple of gotcha's which you may be interested in knowing.

ICE Faces support is available as a facet for a Dynamic Web Application in Weblogic Workshop 10.1
Read BEA Dev2Dev introductory article here.
All really good stuff.

Integrating with Facelets involves jumping a couple more hurdles:

BEA support at present is for ICE Faces 1.5.3. It can be added as a Facet to a Dynamic Web Project.
This is not compatible with later versions, and so when integrating facelets, you will have problems if you use the latest downloads from ICE Soft. Make sure you use the icefaces-facelets.jar from the 1.5.3 release if you are using Weblogic Workshop 10.1
The next logical step for BEA would be to include facelets as a project facet dependent on the ICEFaces facet.

Another thing that wasn't immediately apparent to me, is that icefaces-facelets.jar is a complete implementation of facelets, so you don't need to include jsf-facelets.jar in your project. Use icefaces-facelets.jar instead of the default implementation.

Once you get Facelets and ICE Faces configured correctly, you will probably want the IDE to help you with the TAG syntax. However, you will find that you will have little code-completion context help if you use the XHTML format preferred by Facelets.
Eclipse in general is not much help here. MyEclipse has made an effort to correct this oversight. However, all is not lost if you're using Eclipse WTP or Weblogic Workshop.
The trick is to use JSPX format to declare your namespaces. This will introduce code completion for your ICEFaces components, but Facelets tags will still be ignored. You need to get hold of the TLD taglib file for Facelets and place it into WEB-INF/tld.

You can get the Faclets TLD tag-lib file here:
jsf-ui.tld

And here's the final result:

Hope this helps!

CJUG Presentation about Facebook on October 10th

I guess I've been camping too much this Summer to blog!

I presented at CJUG this month on F8 - The Facebook Developer Platform for Java.
I'm being lazy, and so I'll redirect you to the Facebook Event where I posted links for those of you dying to get your apps developed and registered on Facebook.

Two-Way SSL in Weblogic for Developers

I've been scratching my head, throwing my hands up, even questioning my abilities as a developer for the past few working days trying to work out SSL.
And not because the theory is over my head, or because I couldn't find information on the subject - but because I was asked to simulate an existing production environment in development. A Two-Way SSL (or Mutual Authentication) setup, to be specific. A configuration that takes SSL setup to the limit!

If you need a primer on this subject, the theory and an example using Weblogic's demo setup is laid out clearly in this excellent article:
http://monduke.com/2006/06/04/the-fifteen-minute-guide-to-mutual-authentication/

Usually in development environments you can cut corners - but not with security. In fact I discovered it is more of a challenge for a couple of reasons:
1) Just about everyone who writes about it assumes you're setting it up for real and skips over the details if you don't want to get involved with a signing authority like Verisign - or, like the article above, you're using a test CA that has already been set up.
2) You have to simulate all the parts - including the bits the Verisigns and Thawtes usually take care of.

So to try to do the noble thing and save one or two of you that may be tortured with the same task, I am going to reveal the secrets of setting up Two-Way SSL using Java and Weblogic Tools using a Self-Signed CA certificate for development environments.

The tools we need for the job are:

• Java keytool
• BEA's modifed keytool: ImportPrivateKey
• BEA's CertGen - Certificate Generator

All these tools do similar things and it's the subtle differences that'll kill ya. Be warned - you may be safer playing with a chainsaw! ;)
(I have a hunch there may be a way you can do this with just Java keytool, but I'll try to crack that one later on. If I do I'll post the solution here.)

I'm assuming, of course, that you've got Weblogic installed. For the record I'm using 9.2 and you should be somewhere in that vicinity too.
Note: Before you start, run setDomainEnv in the bin directory of your server domain.
e.g. on Windows:

path_to_bea\user_projects\domains\my_domain\bin\setDomainEnv.cmd

1. Use CertGen to Generate Server Private Key and Certificate
   What we need at the outset is for everyone to trust us. We're all going to trust each other here because I say so. That's what the selfsigned switch is all about. In the real world, we trust each other because we mutually trust a Certificate Authority (CA) like Verisign. Here we're saying "I am the CA".
   
java utils.CertGen -selfsigned -certfile MyOwnSelfCA.cer -keyfile MyOwnSelfKey.key -keyfilepass mykeypass -cn "My Own Self CA"

   You should see this response in the command window:
   

   Generating a self signed certificate with common name My Own Self CA and key strength 1024



2. Create the Identity Keystore
   CertGen created a unique and secret Private Key for the server we're using and the Self-signed Root Certificate for us. But Java wants them packaged up neatly into a keystore.
   The one thing Java keytool doesn't do is import a ready-made private key...
   Drat!
   Fortunately BEA are a smart bunch and created a utility to help.
   And just to make sure there was no confusion about what it does, they called it ImportPrivateKey.
   Told you they were smart, didn't I?
   
   Now run this:
   java utils.ImportPrivateKey -keystore MyOwnIdentityStore.jks -storepass identitypass -keypass keypassword -alias trustself -certfile MyOwnSelfCA.cer.pem -keyfile MyOwnSelfKey.key.pem -keyfilepass mykeypass
   
   

   Imported private key MyOwnSelfKey.key.pem and certificate MyOwnSelfCA.cer.pem
   into a new keystore MyOwnIdentityStore.jks of type jks under alias trustself
   



3. Import the Certificate into a new Trust keystore
   If you read the Monduke article from above, you'll know the name of the game is trust.
   When the client asks the server for a connection, the server will only allow access if it trusts the signer of the client's certificate. This is going to be the "My Own Self CA" and to make it happen we need our trusty MyOwnSelf certificate packed up into a separate keystore called the Trust Keystore. When the client presents it's certificate, this is where the server will look to see if it trusts the signature of the CA.
   keytool -import -trustcacerts -alias trustself -keystore TrustMyOwnSelf.jks -file MyOwnSelfCA.cer.der -keyalg RSA

   (Replace with equivilent ImportPrivateKey command?)
   
   Here's the tool's response:
   

   Enter keystore password: trustpass
   Owner: CN=My Own Self CA, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=My
   State, C=US
   Issuer: CN=My Own Self CA, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=M
   yState, C=US
   Serial number: ...
   
   Trust this certificate? [no]: yes
   Certificate was added to keystore
   



4. Configure WLS with Identity and Trust stores
   
   Now we have an Identity Keystore for Server to Client communication (to supply certificates to the client) and a Trust Keystore for Client to Server communication (to accept certificates supplied by the client). We now need to tell Weblogic to use them.
   
   In the Weblogic Admin Console jump to the Keystores page and choose "Custom Identity and Custom Trust"
   
   Enter the locations of your Identity and Trust keystores, the passphrases identitypass and trustpass respectively, along with the alias in the SSL tab (I used 'trustself' above). The Private Key password in this example is 'keypassword'.
   
   When you've saved and activated your changes in the admin console, check the Weblogic command output window to verify that your Identity and Trust keystores were loaded with no problems.


5. Test One Way SSL
   Under the SSL tab, make sure Two Way Client Cert Behavior is set to "Client Certificates Not Requested".
   
   This is important - make sure you have these entries in your config.xml file in the config directory of your domain:
   

   <client-certificate-enforced>false</client-certificate-enforced>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<server-private-key-alias>trustself</server-private-key-alias>


   
   If any are different, edit and save the config.xml to match, and then restart the Weblogic server.
   
   Now browse to https://localhost:7002/console
   (Assuming defaults.)
   
   
   
   All being well, the server should present the client with a certificate.
   However, the client has no reason to trust our Self-Signed Certificate yet, so it will throw up a dialog. (Also the name doesn't match that of the server. This isn't too important in a development environment - but something you'd definitely fix for production.)


6. Install the Server Certificate on the Client
   To have the client trust the server permanently, we need to Install the certificate. Hit install and follow the instructions. When you next go into the Certificate Management screen you will see the "My Own Self CA" listed under "Trusted Root Certification Authorities"
   


7. Test Two Way SSL without Client Certs required

Now go into the WLS Admin Console and switch the
Take a look at the WebLogic server console output:



NO_CERTIFICATE



The only way we got to the page was because we set Weblogic to ignore the fact that there was no client certificate. For truly secure Two-Way SSL where only authorized clients can talk to our server, we need to put a certificate on the client to send and require that the server check it.


8. Create a client certificate using the Self-certified CA certificate
   
   Now we basically need to set up the opposite situation on the client that we did on the server. But, of course, there are some crucial differences. Wouldn't be any fun otherwise...
   
   It's time to generate the certificate for the client. This time we want the Certificate to identify the client machine (usually the user of the machine - you can set up one client certificate per user and have more than one on a machine if you need to), AND we want to ensure that the Client is linked to the Trusted CA Root Certificate we fabricated earlier. (This is why the ou (operating unit) of the client certificate must match the identity of the Trusted CA Certificate - in this case "My Own Self CA".)
   
   java utils.CertGen -certfile MyClientCert.cer -keyfile MyClientKey.key -keyfilepass clientkeypass -cacert MyOwnSelfCA.cer.der -cakey MyOwnSelfKey.key.der -cakeypass mykeypass -cn "My Client" -e "my.own@self.com" -ou "My Own Self CA"
   
   

   Generating a certificate with common name Client User and key strength 1024 issued by CA with certificate from MyOwnSelfCA.cer.der file and key from MyOwnSelfKey.key.der file



9. Bundle up the Certificate and Key into a Format the Browser will like (it's PKCS12 if you have to know)
   
   Having the client certificate in bits won't be much appreciated by the browser, so we need to package it up - like a identity keystore, but in a different format that browsers like.
   
java utils.ImportPrivateKey -keystore MyClientCert.p12 -storepass clientpass -storetype pkcs12 -keypass clientkeypass -alias clientcert -certfile MyClientCert.cer.pem -keyfile MyClientKey.key.pem -keyfilepass clientkeypass



10. Import Trusted CA Certificate and Client Certificate into Browser
There are essentially two pieces to the pie. First you need to import the Root CA Certificate so the browser trusts certificates sent from the server.Locate the MyOwnSelfCA.cer.der file that was made in the very first step, and import it into your browser as a Trusted Root Certification Authority (Tools > Options > Content > Certificates in IE)If using IE doesn't make you go weak at the knees, the easiest thing to do now is double-click the certificate file you just made. (MyClientCert.p12) IE will launch it's import certificate wizard and you'll be ready to roll.

If you want to make life hard for yourself, then I'll assume you know how to import client certificates in your favourite browser and move on...


11. Test Two-Way SSL
    The moment of truth:
    Browse to https://localhost:7002/console
    
    This is what should happen:
    1. Client request to server
    2. Server response - sends certificate signed by "My Own Self CA" and requests a certificate from the client
    3. Client examines certificate - decides to Trust it since it has the CA certificate for "My Own Self CA"
    4. Client sends its certificate to the server, again signed by "My Own Self CA"
    5. Server finds up "My Own Self CA" in its Trust store and decides to trust the client
    6. Server sends requested resource back to the client in encrypted form
    7. Client deciphers the encryption and displays the result - in this case the Weblogic Admin Console login page.
    
    

Cambrian House - Beyond IdeaWarz

One of the early criticisms of the Cambrian House IdeaWarz system is that anyone can post an idea in a few words, but how do you really sift the good ideas from the bad?
A popularily contest between ideas in the voting system, while being a loose indicator of gut reaction to an idea, is obviously full of flaws.
The idea may sound good, but how realistic is it? It is technically feasible? Is there a market? Is it actually original? Is it a shallow idea in embryo, or has the submitter put a lot of thought and research into it?
Some ideas on a napkin may sound like they've been done before. Is this a reason not to pursue it? Perhaps if something moderately successful was re-done better, it would be hugely successful? This is often the case in the real world. (Think: Google)
To achieve commercially viable projects, the idea has to go through many more trials and refinements to get it into a viable state. It's a process. Anyone who has realized an idea knows this. The ability to comment on Ideas in IdeaWarz is an informal way of challenging an idea and helping to refine it. But it's obviously not enough.

I made some suggestions to Cambrian House and hopefully they'll implement something along these lines.

After a little consideration, this is how the process could work:

Idea Submission
Putting down the essence of an idea in just a few words, along with some background on where the inspiration came from is a fine place to start. But sometime early in the submission process, the idea needs to be qualified for feasibility. I think that once an idea is submitted and passes the first gate of suitability (i.e. it's not offensive and meets the guidelines, and it's generally suitable for the CH Crowdsourcing model), it can enter IdeaWarz and get some feedback.
At the same time, Cambrian House should solicit some refinement of the idea from the submitter to enter the second gate.
(Along the lines of "Thanks for your idea. It has entered our initial feedback system IdeaWarz. We want to know more. Please log in and fill out the Self-Grading Justification Form to enter the next stage of the process.")

Self-Grading Justification
The submitter of the idea should now be asked to justify their idea by writing a concise description of the idea and self-grading it in the following areas:

1. Suitability for Crowdsourcing on CH


2. Originality


3. Potential Market


4. Commercial Viability

The self-grading process is not just intended to be a score out of 10. A paragraph or two on the fit in each of these areas is needed. For example, an idea that's not wholly original is not a bad idea for the model if a large market exists to be tapped into. And a product that's targeted at a smaller market with high saturation is often better than a mass market product that has high competition or low saturation. An acknowledgement of the potential challenges an idea may face and how this can be overcome adds strength to the idea.
Once the submitter of the idea has put a mark on their idea, it is then opened to the community to agree or disagree with the ratings, by adding their own ratings and comments. Do they think the idea is as marketable as the author does? Maybe there's an application of the idea that the author hasn't considered?
Discussing and brainstorming the idea in this way will help to mould it and may open other possible markets that were not originally conceived of.

Doing this would weed out weak and unsuitable ideas pretty quickly. The idea can stay in embryo on IdeaWarz but would never pass that stage if it cannot be solidified.
Why keep it on IdeaWarz? Why not just remove it?
Because ideas breed ideas. A weak idea can provoke a stronger more refined one. Keep the think tank full!
(I think it should generally be at the submitter's discretion to remove an idea. This is a function that is currently missing at Cambrian House.)

Solidification
So now that we have an idea that has some substance, we enter stage 2: Solidification. Here we get to be more critical of an idea. Cambrian House users can now start to contribute to ideas that have been justified by their submitter. It's an open forum where others can rate the idea according to their own perspective, challenge the ratings given by the submitter and contribute suggestions. At this point we're starting to prove the idea for its potential and build support and dedciation to it. Hopefully by the end of this process we'll have a focused group of people willing to contribute to the project.

Test the Market
Now it's time to go to market trial. The first task of the focus group (or CrowdSource Project group) is to produce a marketing site to promote the idea as a product. This then is made available to be judged by Cambrian House users. What do you think of this idea? Why do you think it would succeed or fail? Would you buy this product?
If the feedback at this stage is good, we release the product to the world. If pre-orders meet an specified goal within, say, 2-4 weeks, you then have 6 weeks to build it. (Of course, if the incentive is strong from the CrowdSource Project team, they can go ahead and build it to see 'if they will come').

Final Note
For CrowdSourcing to work you need the buy-in of a group of developers who are dedicated to the success of a project. The interaction involved in the development of the idea is also going to be key in getting the commitment and motivation of a group to 'get the job done', I feel.

Cambrian House gains momentum

Cambrian House is getting attention in the Web world at the moment.
There are now over 1000 ideas posted (the validity of their potential as original ideas that fit the CrowdSourcing model is yet to be determined), but what it does represent is that the site is getting attention.

The jury is out on whether the IdeaWarz concept is actually putting the best ideas to the top of the Leaderboard. (That is: most viable for the Cambrian House model to implement and turn a profit.)
I think it's clear from going through them that some ideas are just not feasible, while others are not original, others very vague and some just irrelevant.
A better rating system is definitely required, although at the moment I think it's all about creating awareness and traffic, not creating profitable ideas.

I think that to keep the momentum going Cambrian House needs to show some real progress on some ideas to prove the participation in the CrowdSourcing concept is more than just passing curiosity - and ultimately pay out some real rewards for a successful project implemented.

Anyway, in the meantime, I've put my ideas on the right for you to click on and support at your whim. --->