Raible Designs

[CSS 2006] Snow in Keystone

Looks like a good day for skiing...

[CSS 2006] Day 3

This morning, I gave both my talks back-to-back and was done by noon. After lunch, I attended Scott Blum's Taming AJAX with GWT. It was a good talk with some impressive demos. I definitely need to dig into GWT more - it looks like very cool technology. I can't help but think it's the "widget framework" that JSF was supposed to be.

I was planning on heading back to Denver tonight, but it started snowing and Julie said they expect 10" in East Denver. Who knows if it'll actually snow that much (the weatherfolks are often wrong), but I don't want to be on the roads.[Read More]

[CSS 2006] To ESB or not to ESB?

Do you have to have an ESB to have a SOA?

I'm sitting in Denise Hatzidakis's talk titled "To ESB or not to ESB" as requested by Mick Huisking. Dinese is the Chief Technologist at Perficient, Inc.. It's interesting, on her opening slide she has a @perficient.com e-mail address, as well as an @us.ibm.com address.

"SOA stands for Same Old Architecture"

This talk focuses on using an ESB and how to build it. There's a lot of ESB products out there. An ESB is not about a product - it's about what kind of connectivity you need between your systems.[Read More]

[CSS 2006] Using Maven 2 to get control over your Development Process

This afternoon I attended Hermod Opstvedt's talk on Using Maven 2 to get control over your Development Process. Most of it was review for me, but I took some notes anyway. About halfway through, I quit taking notes and just listened. The most interesting part for me was seeing how the Maven Embedder works. Since Maven doesn't currently allow you to create archetypes from existing projects the embedder seems like a good workaround. I'd rather code in Java rather than XML any day. [Read More]

[CSS 2006] Day 1

Today, I woke up early and made it to the conference in time for breakfast and John Soyring's Keynote. While I didn't stay tuned in the whole time, it looked like he had some good slides and he was definitely an eloquent speaker. It did turn into an IBM sales pitch at times, but overall it was pretty good. One thing I didn't know is apparently Wayne Kovsky (the conference organizer) , used to have John's job at IBM. John "provides global business leadership for a multi-billion dollar annual revenue portion of the IBM software business" - so apparently he's doing pretty well.

After Soyring's talk, I attended Bill Dudney's Introducing Cayenne presentation. I didn't listen as good I should have (notice the timestamp on the AppFuse 1.9.4 Release), but I did learn that the Demo Gods were having a case of the Mondays. After lunch, my Seven Simple Reasons to use AppFuse talk started at 1:00. It was the first time I'd presented the talk, so I didn't know how long it'd go. The first demo worked, the second one bombed. I shoulda typed @spring.validator type="required" instead of @spring.validator required="true". Oh well.

This afternoon, I went to Mike Bowler's Ruby for Java Programmers talk. I was a bit late, but it was an excellent presentation. I'd recommend it to anyone. That raps up Day 1, tomorrow I hope to hit Event Driven Architecture with Apache ActiveMQ and POJOs and To ESB or Not to ESB.

The Colorado Software Summit in Keystone

This week I'm speaking at the Colorado Software Summit in Keystone, CO. I love this conference because it's so close to home (only an hour drive) and because it's so relaxed. The organizers, Wayne and Peggy Kovsky, do an excellent job of organizing the show. I've never felt more cared for as a speaker, including the fact that they plan and communicate with speakers for the preceding 6 months to the show. Not only that, but it's in one of the most beautiful places in the world. Check out the view from our condo this morning.

If there's any sessions you'd like me to attend and blog about, let me know!

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.