I’ve started working with Metro 1.1, the new, high-performance web services stack from Sun. Metro packages up Sun’s reference implementation of JAX-WS (Java API for XML Web Services), JAXB for bindings and WSIT (Web Services Interoperability Technologies) into one comprehensive package. I’m sure I’ll be posting more about my experiences later.
Principles of OpenID
OpenID was created by Brad Fitzpatrick, the founder and technical whiz behind LiveJournal, one of the more popular blogging sites. Through his experiences building and operating a world-class blogging engine, he became painfully aware that the necessity for users to create separate login accounts for every web site they frequented was a severe impediment for users. He created OpenID in an effort to provide a single sign-on system that could be shared across otherwise unrelated web sites.
Since its original inception, an active community of technology companies, user companies and open-source developers has formed around the OpenID specification. Participants of this community actively critique the OpenID specification, propose enhancements and help guide OpenID’s evolution.
As the OpenID specification has evolved, a set of basic principles has been established:
- OpenID should provide a single sign-on that can be used with multiple web sites.
- OpenID should support de-centralized identity verification.
- Nobody owns OpenID.
- Nobody controls OpenID.
- No single point of failure.
- OpenID should be a simple and light-weight sign-on service.
- OpenID should be easy to use and deploy.
- OpenID should be free.
- OpenID should be an open standard that changes based on community needs.
These principles are important, because they have a major impact on the directions in which the OpenID community works to evolve and improve OpenID.
The first, and most obvious, principle simply expresses the basic intent of OpenID, which is to provide a single sign-on system that can be used across multiple web sites. The basic concept for OpenID is that users can possess one or more identities, which function for people in much the same way that domain names function for web sites. Think of an OpenID identity as a personal URL. Some examples of OpenID identities are:
joeschmo.myopend.com
opened.aol.com/eve123
The next principle is that verification of OpenID operates in a de-centralized manner. Again, in much the same way that domain names are supported. The OpenID community believes (and so do I) that the public will not accept a cross-site identity scheme owned and controlled by any single company.
This is why other technologies, notably Microsoft Passport (which has also been marketed under several other names), have never been able to gain widespread acceptance. De-centralization of identity verification also provides another benefit – it ensures that there is no single point of failure for OpenID identities.
The OpenID community believes very strongly that the user should control their online identity, and that includes the choice of what company or web site will provide verification for their identity. With an identifier like “joeschmo.myopenid.com,” the identity is “joeschmo” and “myopenid.com” is an OpenID Provider, i.e. — a web site that provides the service of verifying that identity for other web sites.
Another principle is that OpenID provides a light-weight authentication service. Essentially, OpenID verification allows a user to claim, and then prove, that they own a particular identity. It does not natively support stronger claims, such as:
- Identity “joeschmo” really belongs to an individual named “Joe Schmo.”
- Identity “joeschmo” belongs to a person aged 21 years or older.
- Identity “joeschmo” belongs to a person with a good credit rating.
- Identity “joeschmo” belongs to a male.
There may eventually be other services built on top of OpenID that support these stronger assertions about an individual. But all OpenID does is verify that an individual does, in fact, own their identity, i.e. — their own personal URL.
The other principles have to do with ensuring that OpenID becomes available to as many people as possible. To support this, OpenID should be free, easy to use and easy to deploy. In fact, OpenID is already supported in numerous development languages, including .NET, Perl, Ruby, Java and many others.
Finally, the evolution of OpenID is regulated in an open manner by the OpenID community. There is no single company that directly controls the fate of the OpenID standard. There is an active, extremely vocal and widespread community that is intent on both enhancing the OpenID standard and ensuring that its evolution continues to adhere to the basic principles that have been established.
Reading a Resource from a JAR File
There are times when it can be convenient for static files (such as text files, configuration files, images, etc.) to be packaged with a library. In the Java world, these types of files are referred to as resources and the libraries are known as jar files. The simplest way to ensure that a jar file can reference the resources it needs is to physically bundle them into the jar file itself.
The question then becomes: How can the code within a jar file reference a resource file?
Reading a Resource File
It’s actually pretty simple, as illustrated in Listing 1. Java provides several ways to read a resource file, of which the simplest is to use the getResourceAsStream method provided by Java’s Class class. This method accepts the name of the resource as a parameter and returns an InputStream reference for the resource (or null if it cannot find the resource). Content can be easily read from the file using a BufferedReader object.
The name provided to the getResourceAsStream method can be an absolute or relative pathname. If relative, it is interpreted relative to the package path. For example:
| Type | Path | Expected Location | |
| Absolute | /myapp.properties | /myapp.properties | |
| Relative | myapp.properties | /com/keenertech/experiment/myapp.properties | |
The leading “/” causes the getResourceAsStream method to look for the resource at the top level within the jar file. With the relative pathname, the file is expected to be located at the same level within the jar file as the class itself.
Note that the ClassLoader class also has a getResourceAsStream method which can be used to read resources, but it only supports absolute paths. In general, the Class version of the method is more frequently used.
Listing 1 – Displaying A Resource File
package com.keenertech.experiment;
import java.io.*;
import java.util.*;
public class ResourceExperiment
{
private void displayResource(String strName)
{
try
{
BufferedReader objBin = new BufferedReader(new InputStreamReader(
this.getClass().getResourceAsStream(strName)));
if (objBin != null)
{
String strLine = null;
while ((strLine = objBin.readLine()) != null)
{
System.out.println(strLine);
}
objBin.close();
}
else
{
System.out.println("Error: Unable to retrieve InputStream");
}
}
catch (Exception e)
{
System.out.println(e);
}
} // End Method
public static void main(String[] args)
{
ResourceExperiment objRes = new ResourceExperiment();
objRes.displayResource("/myapp.properties");
} // End Method
} // End Class
Reading a Properties File
Well, that was a great way to read, and display, a resource file, but it would be nice to actually use the properties defined in the myapp.properties file. Listing 2 shows how the properties can easily be processed from a configuration file packaged as a resource. This technique can be a great way to set default parameters for a class.
Listing 2 – Reading Properties From a Resource File
private void readPropertyFile(String fileName)
{
try
{
Properties objProperties = new Properties();
objProperties.load(this.getClass().getResourceAsStream(fileName));
strHostName = objProperties.getProperty("hostname");
// .....more properties as needed.....
}
catch (Exception e)
{
System.out.println("ERROR: Could not read properties file\n");
e.printStackTrace();
}
} // End Method
To read the properties from the file, create an instance of the Properties class, then call the object’s Load method with an InputStream that references the resource, as shown below:
objProperties.load(this.getClass().getResourceAsStream(fileName));To get a value for an individual property:
strHostName = objProperties.getProperty("hostname");Conclusion
In Java, static resources can safely and effectively be bundled with compiled classes within easily distributable jar files. Storing such resources within the jar files ensures that the resources will be available to classes when needed, i.e. — it is very difficult for the resources to become separated from the code when they are bundled with it. In turn, resources can be easily referenced by Java code, so there’s no penalty, in terms of access cost, in bundling resources within jar files.
Santa Clause Traditions
My wife, Sally, is Scottish. I mentioned to her in passing one day that, when I was a kid, my parents would leave milk and cookies out on the kitchen table so Santa could have a snack when he showed up. She looked at me with a horrified expression, then exclaimed, “Milk and cookies! That’s terrible!” She shuddered. “Santa’s a man, not a boy! In Scotland, we leave whiskey out for the poor fellow ’cause he needs something to warm him up on his journey.”
QuickStart Rails
I decided to create some brief “Quick Start” presentations with the expectation that there might be opportunities to present them as “fillers” at other events. No sooner did I finish the first one, “Quick Start: What Is Rails?”, than I found myself presenting it internally within AOL twice in two weeks. The PDF of the presentation is now available online. Check out the Presentations web page for other available presentations.
JRuby Speed Test
JRuby has come a long way in the last two years. There’s been a ferocious amount of work put into re-implementing Ruby in Java, complicated by the fact that there has never been a written specification for the Ruby language.
There has also been some intense cooperation between the JRuby development team, the original Ruby developers and the Rails core team. The goal was to make JRuby a viable platform for fielding Rails applications. Further, by allowing easy access to legacy Java code, the hope has been that JRuby would provide an easy mechanism to allow Rails and Java applications to live happily together, or to provide an easy way to transition from Java to Rails (in much the same way that C++ was an easy transition from C).
In recent speed tests that have been publicized on the web, it appears that JRuby is now generally faster than Ruby. Check out this blog post for more information.
JRuby has clearly evolved into a viable platform for fielding Rails applications. I expect to see some changes in the Rails landscape over the next year, as Rails expands away from so-called “green-field” applications and becomes more of a player in corporate development efforts. This will, in turn, be a key factor in helping Rails jump the “adoption chasm” and become a more widely used technology.
Winning an iPod Touch
I just won the new 8GB iPod Touch at an AOL offsite event (for best team scores in bowling if you can believe it). Within 8 hours, I had it filled with music, i.e. – more than 700 songs. Truly an impressive device … expect some posts about it later.
AOL Brown Bag Presentation
I will be conducting my presentation, “Using Rails to Create an Enterprise App: A Real-Life Case Study,” as a Brown Bag presentation at AOL on November 27th, 2007.
Yes, It’s Confirmed
I will be be doing the December presentation for the Washington DC Ruby on Rails User Group. The meeting will be held December 13th at George Washington University, from 7:00 PM to 8:30 PM.
December DCRUG Meeting
Still waiting for final confirmation, but right now it looks like I’ll be presenting at the December meeting of the Washington DC Ruby on Rails Users Group. The meeting will be held at George Washington University. The topic is going to be “Leveraging OpenID in Rails.”