Raible Designs

Clustering OSCache

For the past few days, I've been tuning and configuring OSCache in a clustered (WebLogic) environment. While setting it up was fairly easy, there was some fundamental concepts that took me a bit to figure out.

First of all, I chose to use JavaGroups instead of JMS. The primary reason behind this was it was easier to configure, but I also discovered that if you use JMS - you have to have a unique "cache.cluster.jms.node.name" property in your oscache.properties file on each server. This means to use OSCache with JMS, you have to build two different EARs. At least that's my impression. If you've figured out a better way to do this, please let me know.

In the application I'm working on, there are 4 different caches: one for Hibernate, and several other ones we've created with OSCache and Spring. For the past week, I developed a feature where we cache a user's account information across the cluster. The feature is more like an HttpSession than a cache b/c it's designed to replicate an authentication token (similar to a session id) across all the master servers.

After much head pounding, I discovered that OSCache doesn't update other nodes in a cluster for inserts and updates. It only broadcasts flushes. After understanding how OSCache works, it was much easier for me to code the solution (sans OSCache). If you'd like to see OSCache support replicating a cache across a cluster, vote for CACHE-96.

Lots of Java activity in San Francisco

The last 24 hours here in San Francisco have been quite interesting. Yesterday, I had lunch with a group of AppFuse users. They work for a company a few blocks from my training class. Chipotle was on the way, so I grabbed a burrito on my route and had a great time talking with them about the various open source tools that AppFuse uses, as well as what's on the roadmap. Thanks for the cookies John!

After class yesterday, I had a Guinness with an AppFuse user that recently put a high-volume site into production. He said it's held up surprisingly well and AppFuse greatly simplified his ability to deliver the project on time. In fact, most of the features the client wanted were already built-in.

Last night was another hotbed for Java talk - from web frameworks to TSSS in Vegas. Matt Filios and I had dinner and drinks with Mike "wanna play poker" Cannon-Brookes, Crazy Bob, Patrick Linskey, Geoff Hendrey (I hope I got the name right) and a number of other guys whose names escape me. It was Mike's birthday, so I left early to avoid the chaos that Crazy Bob and Mike always seem to stir up.

To top it all off, this morning I ran into a couple of folks that read this blog. I was getting breakfast at a local bagel shop - when a guy came up to me and asked "Is your name Matt"? I answered yes, and we talked briefly about my trip out here. It was kinda wierd being recognized, but kinda cool at the same time. It was good to meet you Nadeem.

I'm heading home from this wonderfully warm place tonight, but I'm sure I'll be back in the near future.

RE: Is Ajax gonna kill the web frameworks?

James is asking "Is Ajax gonna kill the web frameworks?" From my personal experience, I can definitely say that Ajax is going to give web frameworks a run for their money. However, I doubt it's going to completely replace web frameworks. There's many companies out there that aren't willing to commit to developing a JavaScript-only UI - not even Google. GMail has a non-javascript version that's used when you disable JavaScript in your browser.

That being said, I'd much rather work on a project that embraces and uses Ajax over a web framework. However, even if you decide to use Ajax, doesn't the same framework proliferation problem still exist? DWR, Scriptaculous, Prototype, AjaxTags, AjaxAnywhere, Rico, Dojo, JSON-RPC - which Ajax frameworks are the best ones to use? If one of these projects joins Apache, will it become the de-facto Ajax framework like Struts did?

Rocky Mountain Software Symposium

This afternoon, the Rocky Mountain Software Symposium returns to Denver for the final show of the year. Of course, this conference is better known as No Fluff Just Stuff, Denver. Lucky for me, I'll be presenting all my sessions tomorrow so I'll at least get one day this weekend to relax. It looks to be a good show, with lots of interesting sessions. Here's mine:

• 8:45 - 10:15 AM: Test-Driven Development with Spring and Hibernate
• 1:45 - 3:15 PM: Developing Web Applications with Spring and Ajax
• 3:30 - 5:00 PM: Spring's AOP and Transaction Frameworks

After the presentation class I attended last week, I think all these should be renamed. Unfortunately, I didn't have time to re-organize the presentations, but if I could change the titles, they'd be something like this.

• Write better code faster with Spring and Hibernate, use AppFuse to simplify both
• Make your webapps suck less by using Ajax
• Use Spring AOP and Transaction Frameworks, because they're so damn easy

Update: PDFs of my presentations, as well as the Ajax demo is available from Equinox's downloads section. Make sure and view the README if you want to run the demo and see how to view the Ajax features.

Editing Java webapps instead of edit/deploy/reload

For the last few years, I've always done Java webapp development the hard way. Yeah, I'm the guy that makes Dion cringe (although I'm pretty sure he's not referring directly to me). I edit a class/jsp/xml file and run "ant deploy reload". Then I wait a few seconds for my context to reload in Tomcat. Luckily, I do mostly test-first development, so it's rare that I have to open my browser to test stuff. However, with the power of CSS and Ajax, manual testing in a browser is becoming more and more useful (although Selenium may solve that).

I've long resisted the power of the IDE, b/c I've always trusted Ant and felt confortable with the command line. However, I'm ready for a change. I'm ready to start developing Equinox and AppFuse-based applications using the edit/save/auto-reload cycle. So how do I get started? Where's the instructions for setting up my IDEs to work this way?

I prefer to use Eclipse and IDEA for development - so I'll likely try to get this working in both. If I get it working, I'll make sure and provide good documentation so others can do the same. I'm also willing to make any changes in project structure to make this happen; modifying build.xml (or pom.xml) to accomodate shouldn't be too difficult.

Simon begins "The Journey"

It's pretty cool to see that Simon is going to begin a quest to find the best web framework to fit his needs.

Struts, WebWork, Stripes, Spring MVC, Wicket, Tapestry, JSF, etc, or even rolling your own. With so many J2EE web application frameworks to choose from, how do you decide which one to use? Several articles (e.g. JavaServer Faces vs Tapestry) and presentations (e.g. Comparing Web Frameworks) already exist, but they generally concentrate on a small subset of the available frameworks.

This can be a daunting task, but it sounds like he's got a good plan:

Clearly this is a massive task so, to reduce the scope, I'm going to focus on what it takes to build a read only web application. If I were to hazard a guess, I'd say that the 80-20 rule applies. 80% of a web application is read only and 20% is interactive (e.g. HTML forms, AJAX, etc). Of course, this is changing with technologies like AJAX, but we're still on the upward curve. Traditionally, that 20% is the most complex and is an area where many web application frameworks claim their unique selling points. For this reason, I may iterate over the evaluation process to take into account how the frameworks help web developers build interactive webapps. For now, I'm going to look at whether the frameworks make doing the 80% easy.

Notice that Simon has added a couple frameworks that I haven't worked with: Stripes and Wicket. It should be interesting to see his findings. Not every framework is designed to do the same thing, so it'll be cool to find out which one Simon thinks is the best for read-only applications.

Pictures from the Colorado Software Summit

Here's a few pictures from the last few days - including a few shots while driving up yesterday. One thing that's interesting about this conference is there's a huge contingent of Tapestry users and enthusiasts.

[CSS] The Zen of Open (Observations of a New Bear) by Simon Phipps

Simon used to work for IBM, on a video conferencing product. In 1994, Simon would fly all over the world to tell everyone about it. The last 10 years have brought many changes. When Simon used to travel in 1994, he needed cash and travellers checks, airline tickets, telephone kiosks and sent mail through the regular ol' postal system. Fast forward to 2004, and we have ATM cards and a "global identity card" (a Visa card), e-tickets, GSM mobile phones and e-mail. We're now in the participation age.

If we were massively connected:

Security would no longer concern only boundaries. Before the participation age, security was a matter of "how do I keep you out". Now it's "who are you can you prove that". It's all about digital identity now.

Software would have nowhere and everyone to run. Service orientation is how software is build today. Simon believes it'll happen through REST-based services, rather than by employing web services.

Software pricing should not track ephemera [definition]. We're now switching to value-based pricing.

Markets would become conversations (from The Cluetrain Manifesto). This idea led Simon to start blogs.sun.com.

Closed-room development would be insufficient. The old way was lock smart people in a room and slide pizza under the door - and then charge others admission fees to watch them work. Software that's developed out in the open gets better and better b/c you can get all the experts working on it. This is called Open Source. The initial objective of Open Source was to undermine companies like Microsoft and Sun - but now it's the best way to write software in a connected society.

Open Source in a Nutshell: a community of developers, sharing a code commons, create "wealth" from the commons, enriching the commons in the process. The "craft guilds" have been rediscovered in a sense. Open source is not communism, but more like Connected Capitalism.

There are a number of different open source licenses:

• Class A: "Unrestricted", create any work, no restrictions on licensing. BSD-style license, with the gold standard being the Apache License.
• Class B: "File-based", files derived from commons must use license B, files added may use any license. Mozilla-style, CDDL v1.
• Class C: "Project-based", all files in project must use license C if any files use commons files, GPL.

According to Simon, the best license is the one that gives the most freedom to the most people. Class A licenses promote freedom to innovate, but do not protect the commons. Class C licenses promote constant growth of the commons but limit the freedom of the developer to use their own innovation however they want. Class B licenses balance both freedoms protecting and enriching the commons but leaving innovators free to use their work in any commons.

The overlooked corners of open source: it's not licenses, there's no more limelight needed for those. However, there is a problem now - and that's license proliferation. There's too many licenses, we need fewer so it's easier to choose. We need better motivational models: how do we leave room for the motivations of diverse contributors?

The overlooked corner of open source is Governance. Apache is a good example of how Governance should be done. Bad governance is the primary vector for disease in open source. If the only way to contribute back is to go through one company that chooses committers, the project is likely doomed.

Software Patents happen, get over it. "Parallel Filing" means Corporations own patents on pretty much anything they touch. If you don't, your competitor will. The nature of US law means all must play. Using patents defensively is a routine element of corporation-to-corporation interaction. Software patents are a zone on the continuum - even their detractors have to deal with them. Until world trade is reformed, software patents happen.

So how do you protect yourself?

• Patent Grants: Research specific patents and give a broad usage grant to open source use.
• Compulsory licensing: Blanket grant of patents, restricted to licensed code. This is the strategy that Sun has used with OpenSolaris.
• Non-Assert Covenants: Covenant not to assert rights against bona fides community.

Simon believes all 3 approaches are needed to protect ourselves from software patents. He believes that #2 and #3 should be mandatory for standards bodies and open source projects.

Summary: The next phase of F/L/OSS is upon us. The Virtuous Cycle of open source needs a health check. We need to reduce license proliferation by dealing with its causes. We need to leave room for the motivations of all contributors. Don't sacrifice the freedom of developers for an ideology. Governance best practice needs an advocate.

F/L/OSS Alone is not enough for freedom - we need standards. Open standards set end users free to choose. Development and deployment are not the same thing. Standard Formats + Open Source = Freedom.

Software Patents demand multiple defenses. We need to lobby the governing bodies of our countries and put a stop to patents.

[CSS] Apache Geronimo Architecture and Community by Bruce Snyder

The main reason that Geronimo was started was to have a BSD-style licensed Java application server. The other two open-source application servers are JOnAS and JBoss, both of which are LGPL. The advantage of having a BSD/Apache licensed container is that companies can put it into their products, or develop products with it - w/o worrying about licensing issues. Bruce says IBM just validated the goals of Geronimo with their WebSphere Community Edition.

Geronimo's architecture is designed around GBeans - which are services that are pluggable inside of the kernel. To learn more about GBeans, see Jeff Genender's article "Integrate third-party components into Geronimo". The GBean is an IoC container in itself. Bruce is now showing a GBean Descriptor for ActiveMQ. There are only a few main elements in this XML file: multiple <dependency> elements and <gbean> elements. The dependency element refers to a JAR and the idea was borrowed from the Maven project.

Bruce, the poster-boy for Maven 2 only made it 15 minutes before he mentioned Maven.

For more information about integrating ActiveMQ in Geronimo, see Sing Li's article "Magic with JMS, MDBs, and ActiveMQ in Geronimo".

Deployers vs. Builders: Deployers are J2EE specific, Builders are Geronimo specific. The Geronimo Deployer is JSR-88 compliant and handles both deployment and distribution. Personally, I'm a little disappointed that Geronimo doesn't support hot-deploy out-of-the-box, but I can understand their desire to be spec-compliant first, and developer-friendly 2nd. After all, it is an IBM product.

Geronimo's deployer is currently a script that you can pass arguments into. There is also a webapp console (developed and donated by Gluecode) that's based on portlets. It uses JetSpeed under the covers and looks to be a pretty slick little webapp. Bruce started up Geronimo and showed us the console UI - it appears Geronimo's default footprint is about 20 MB.

Custom Assemblies: One of the nice things about Geronimo is that it's so configurable. Because of it's architecture, you can easily create custom assemblies. Here's a few examples:

• Tomcat + Derby + Jetspeed + ActiveMQ
• Jetty + Apache DS + ActiveMQ + OpenEJB
• Jetty + JOTM + Derby + OpenEJB
• Tomcat + ActiveMQ + Spring Kernel + ServiceMix

The Geronimo Kernel and GBeans make all of this possible. This is pretty cool IMO, especially with the whole Agile Java EE movement. Bruce thinks this is real future of Geronimo: the stacks that can be created with it. He expects the innovation and ideas in this area will come from the community and what users want.

Geronimo Community: Made up of many different open-source projects: MX4J, ActiveMQ, Tomcat, ActiveCluster, HOWL, JOTM, TranQL, Derby, Jetty, ServiceMix, OpenEJB. Rather than re-creating everything (the ol' NIH syndrome), the Geronimo team has tried to embrace and re-use other open source projects as much as possible. Many of the committers on the aforementioned projects are Geronimo committers or founders.

Bruce's favorite quote: In open source, we come for the code, we stay for the people.

Project Status: Now a top-level Apache project. Has officially passed J2EE 1.4 certification tests. The official 1.0 release date is "when it's done it's done", but the developers are hoping to finish by ApacheCon.

[CSS] Mule - A Detailed Look at an Enterprise Service Bus by Tom Bender

Below are notes I took while attending Tom Bender's talk on Mule at the Colorado Software Summit:

SOA: A collection of services with well-defined interfaces and a shared communication model is called a service-oriented architecture.

ESB: Provides a light weight, loosely coupled, event-driven SAO with a highly distributed universe of naming routing destinations across a multi-protocol message bus.

Four Tenets of SAO (as proposed by Don Box):

• Boundaries are Explicit
• Services are Autonomous
• Services share Schema and Contract, not Class
• Compatibility is based upon Policy

Properties of an ESB: Light Weight, Loosely Coupled, Event-Driven, Transactional, Securable, Distributed Network Topologies, Abstract Endpoints, Intelligent Routing, Message Transformation (inbound/outbound), Multi-Protocol Message Bus.

One of the main differences between application servers and ESBs is appservers are traditionally integrated with a hub-and-spoke architecture. ESBs, on the other hand, use a distributed integration architecture.

Mule - What is it?

Ross Mason is the founder and primary developer of Mule. From its homepage:

Mule is an Enterprise Service Bus (ESB) messaging framework. It is a scalable, highly distributable object broker that can seamlessly handle interactions with services and applications using disparate transport and messaging technologies.

Mule is an event-based architecture. Actions within a Mule network are triggered by either events occurring in Mule or in external systems. It's a light-weight messaging framework that's highly distributable and very pluggable (i.e. for multiple transports and protocols). Mule supports Web Services using Axis or Glue.

A Closer Look at Mule

The basic building block is a "UMO Component". This component is used to wire applications together - it's basically a POJO that can optionally implement interfaces if it wants to hook into lifecycle events. An application communicates with the UMO component through a channel (i.e. TCP/IP or JMS). This channel talks to a message receiver that works with a connector that's backed by a transformer and formats it for the UMO component (whoa, that's a mouthful - and that's only inbound!). When going to the receiving application, the process starts from the UMO component, goes though the outbound router - and plows through the whole transformer » connector » message dispatch » channel » application process again. Here's a diagram of this process that I found on Mule's website:

Mule supports many different endpoints: POP3/SMTP, JMS Topic or Queue, HTTP, File, VM (w/in the JVM), SOAP, RMI and EJB. Each of these have their own URI prefix.

I tuned out for the rest of Tom's talk (sorry Tom). The whole ESB topic is pretty dry IMO, but Tom seemed to do a good job of keeping the audience interested.