Some thoughts on JSR 196

There are a few open source security framework out there that follow an SPI model for their security implementation. Acegi is one, Jetspeed security is another one. Both spring based frameworks follow an SPI concept, but the specifics are quite different from JSR 196. In the JSR 196 world, the javax.security.auth.container.AuthContextFactory is used to obtain context objects that encapsulate authentication modules and delegate to the ClientAuthModule or ServerAuthModule given the authentication context (ClientAuthContext or ServerAuthContext). Each authentication context is initialized according to a MessagePolicy that specifies what authentication guarantees the module is to enforce when securing or validating request and response messages within that context. A ServerAuthModule may delegate some of its security processing responsibilities to a LoginModule for JAAS authentication.

Regarding, the management of the authentication modules interaction, I found that comment in ServerAuthContext interesting:

Implementations also have custom logic to determine what modules to invoke, and in what order.

I could be nice to have policies or rules to manage that interaction...

Jetspeed Security - JAAS all the way...

I finally got some time to update Jetspeed security documentation. I still have a little bit of work to do, but I think this is a good beginning and it was badly lacking. Jetspeed 2 fully leverages JAAS for authentication (through the implementation of javax.security.auth.spi.LoginModule) and authorization (through the implementation of a custom java.security.Policy) and provides a flexible security framework with a set of coarse grained services for user management, role management, group management and permission management.


Jetspeed security SPI provides a pluggable authentication and authorization architecture. I found interesting some of the similarities with Acegi as pointed out by Keith Gary Boyce on Jetspeed user list.
For future releases, I am planning to investigate integration with JACC and with JSR 196. Additionally, Jetspeed provides some nice portlets that provide management features for the security framework.

It isn't about Free Software

I have been involved in the open source community for a little while as a volunteer contributor and can relate to some of the dynamics that Marc Fleury describes in his post... However, as I develop a better understanding of the OS community dynamics and of how the community operates I can't help but think, why isn't everyone jumping on the bandwagon?

Have you ever worked with a closed product that needed to be extended to address your business needs? Let's put it this way, I have never worked with one that did not need to... but very often given the closed nature of most software products, extending a product behavior results in numerous headaches for development groups. Most people tend to think about open source as Free Software. What a terrible misunderstanding of the promises of the OS movement! I have become convinced that the strength of open source isn't the source (code), it is the community. I hope that's what Johnathan Schwartz meant in his post on Free Software Has No Pirates. Opening a product source code provides many advantages and extends the boundaries of the virtual organization:

- It encourages the development of a strong community.
- It makes products more easily extensible for customers.
- It fosters innovation on top of companies' product offering.
- It provides a virtual engineering team much larger than any organization may ever dream of.
- It is closely aligned with the market, its trends and evolution.

So why are companies so reluctant to open their code up? I strongly feel that the value of most products is not in the hidden "secrets" kept behind their closed source. It is in the integration with other enterprise solutions, in the flexibility that it provides to their customers to address their business needs today and not in the next release... It is in engaging, trusting and leveraging the community to provide users with solutions that meet their needs.

Marc is right Open Source != Free Software, open source = community; its true value is in the community that it nurtures and empowering its user base...

Agora: A Community Network Visualizer

Wish you could get a better understanding of the dynamics of virtual communities? Who are the key members of the community, how do community members interact with each other? Well, here comes Agora... Stefano Mazzocchi sent an email to the Apache community demonstrating Agora and its usefulness in analyzing online communities. I must say, it is very nice. 3 years of data collected to give you an in-depth view of various communities' interaction. Here is an example of the Jetspeed development community from January 2003 to July 2005. I was curious to see how much I had contributed to the community so I decided to highlight my own name...



if you want to try the tools for yourself, go to the demo posted by Stephano. Or check the latest version of the application from MIT on their Welkin project home page.

Jetspeed 2 Build Process Clean Up - Step 2

Warning: Instructions on this post may become outdated, please be sure to visit Jetspeed 2's getting started for the latest documentation.

Step 2 of Jetspeed's build process clean up has been committed. As a result, a few things have changed when build the latest Jetspeed (2.0-M4-SNAPSHOT and above). A summary of the changes made can be found in Apache Jetspeed Jira.

Then new steps to get started are changed as follow:

If you are build off of Jetspeed 2 source code for the first time:

cd ${jetspeed-2-home} 
maven initMavenPlugin allClean allBuild 

If the Jetspeed 2 maven plugin is installed, then to build the portal and all its components run:

 
cd ${jetspeed-2-home} 
maven allClean allBuild 

If you are using the Hypersonic SQL database, start the production Hypersonic database by typing

maven j2:start.production.server 

Then run quickStart (in seperate window/terminal session):

cd ${jetspeed-2-home} 
maven j2:quickStart 

This will recreate the DB to deploy into. WARNING This will drop all the tables and data in the production database.

3. Start up Tomcat. With a browser, go to: http://localhost:8080/jetspeed

If you are creating a new Portal Application without the Jetspeed source:

In order to get started with a new portal application that will include a developer's specific portal customization, Jetspeed 2 provides as part of its Maven Plugin a goal that can get you started with your project. To do so:

1. Make sure that the following properties are set in your your ${USER_HOME}/build.properties file:

- org.apache.jetspeed.portal.name: e.g. testportal. The name of your new portal application. This will also be used as the artifactId for your project in the maven repository.
- org.apache.jetspeed.genapp.home: e.g. C:/tools/workspace/testportal. The location where your new portal application should be created.
- org.apache.jetspeed.genapp.groupId: e.g. testportal. The maven pom group id indicates the group location for your project in the maven repository.
- org.apache.jetspeed.genapp.name: e.g. My Test Portal. A friendly name for your new portal.
- org.apache.jetspeed.genapp.currentVersion: e.g. 1.0. The current version for your new portal application.

2. Once the above properties are set, make sure that the Jetspeed 2 Maven Plugin is installed on your local machine. You can install the Jetspeed 2 Maven Plugin as follow:

maven -DartifactId=maven-jetspeed2-plugin -DgroupId=jetspeed2
      -Dversion=2.0-M4-SNAPSHOT plugin:download 

where

- artifactId: The name of the Jetspeed2 plugin artifact deployed to the maven repository.
- groupId: The name of the group where the Jetspeed2 plugin is deployed in the maven repository.
- version: The version that you want to use. For this functionality, the version should be 2.0-M4-SNAPSHOT or above.

3. Run the Jetspeed2 plugin target for generating a new portal application:

maven j2:genapp.portal 

4. Go to the directory where you just created your new portal application and execute:

maven j2:portal.install 
maven j2:quickStart 

That's it, you are ready to get started with your new portal application.

Google Search on Your Cell Phone!

Maurice Sidi posted a blog on Google SMS. What a great idea! This is a very smart move and it sheds some more light on where the company is going. If this takes off, it could be huge! Think Google gets a lot of traffic today?

How does it work? Basically, you type a basic SMS message that you send to Google and get search results back. Remember those days where you would call 411 and forget to write down the number after being connected. Those days are over. Instead you get an SMS message and keep it for as long as you need it. Try it out for yourself.

1. Start a new text message and type in your search query

2. Send the message to the number "46645" (GOOGL)

3. You'll receive text message(s) with results

Want to learn more about it, check out Google SMS demo.

Jetspeed2 Build Process Clean Up

Using J2 in its current form requires an in-depth understanding of how J2 build internals operate.

As an example, an integrator wanting to get starting with J2 will want to start with the portal web application and customize it from there. It should be made easy for integrators to get started with the web application without requiring an in-depth understanding of the various sequences in the build process.

A typical implementation will want to create a project as described below:

\sample-portal
+---\etc             Contains the build dependencies
                     definition.
+---\portal-webapp   Contains the portal web application 
                     being built.
+---\src             Contains the portal initialization
                     source (db scripts, etc).

Building the portal in this structure should be possible by leveraging the deployed Jetspeed dependencies:

• Components: All libraries (jars) required for the runtime operation of the portal engine.
• Portlets: All web libraries (wars) required for the runtime operation of the portal engine.
  

Integrator using Jetspeed2 should be able to do so easily and to easily get (through dependencies) the latest versions of the release Jetspeed components (libraries as well as portlets).

The current maven-plugin and portal build implementation rely on the source build (target directories) rather than the dependencies for the assembly of the portal engine, making it more difficult to get quickly started and to keep up with enhanced components.

I started to work on cleaning up the build process with the objective on centralizing all deploy and install activities to the Jetspeed2 maven plugin. This should greatly simplify getting started with Jetspeed2. Work on this issue is being tracked on Apache Jetspeed 2 Jira.

The Business of Software

I just finished reading "The Business of Software" from Michael Cusumano. Overall a well written book on the fundamentals of the software industry. The book focuses essentially on the analysis of the business model for a software company. There isn't really anything striking new in Cusumano's analysis of software companies' business model, but the author does a good job in outlining the choices offered to software companies and how their business model will have to mature as companies and technologies mature.

Essentially, there are 3 choices for a software company:

• A pure product play (Some would argue that with the advance of open source and the broad adoption that it has been getting lately, that pure plays are getting much more difficult).
• A mix of products and services.
• A pure service play.
  

I found very interesting Cusumano's analysis of a typical enterprise software company revenue over the course of a five year business lifecycle. For every 1 dollar of product license fees, $2.15 dollars can be derived from services and maintenance. That's more than 70% of the cumulated company revenue. In many cases, services on sold products end up being a life insurance against bad economic times. This brings some prospective to the Professional Open Source buzz. After all, a typical software company already ends up generating 70% of revenues from maintenance and services over a 5 year lifecycle. When put in this context, the changes of business model though important, appear less radical that one may have initially perceived. For those doubtful of the viability of the open source business model, I think we get some empirical data making the case for it right there.

Cusumano goes on with his analysis and show how as companies mature, they tend to move towards more of a services model and provides excellent data to illustrate his argument. As we look at the growth of companies like IBM and Oracle, more and more of their revenues are coming from services. This clearly justifies their strategy behind open source where they can capitalize on their strength in services while maximizing the use of their R&D resources.

Finally, I particularly enjoyed Cusumamo's analysis of the factors that make software startup companies successful, with great examples to illustrate his point. Cusumano basically identifies 8 key criteria for assessing software start ups:

1. The quality of the management team.
2. Whether the market is attractive and has strong potential.
3. How compelling is the offering?
4. How much interest is the offering getting from customers?
5. Is the company credible?
6. What is the business model?
7. How flexible is the management team?
8. What is the payoff potential?
   

A great list that applies to most business activity.