Over the last couple of weeks, I’ve been getting oriented with Jigsaw, seeing the progress they’re making and wondering how this work will affect our Java EE world. Though I still have a few questions remaining, I’ve found the high-level concepts to be very impressive. Moreover, the language-level approach that Jigsaw is taking is well-suited to integration with Java CDI. As you may know, Caucho is a major supporter of the Java CDI spec and we’re working on our own implementation, called CanDI. In this blog post, I’ll talk about the cool parts of Jigsaw and sketch a proposal for how Jigsaw and CDI might work together in the future.

(more…)

There’s been a lot of hype around OSGi over the last year or two in the enterprise space. Last year even Caucho dallied with adding OSGi support to Resin, though we’ve abandoned the idea in the meantime. In this post, I’ll tell you what’s cool about OSGi, why we were initially attracted to it, why we eventually dropped it, and what we did instead. The more I talk to enterprise developers who’ve actually used OSGi, the more I hear this same story.

Update: Rob Harrop informed me that there is an emerging specification called RFC-66 for enterprise web/OSGi integration.
(more…)

As a quick introduction to pomegranate (I’m crushed for time today), here’s a quick diagram that shows the basic module structure for a typical pomegranate configuration.

Pomegranate is designed to solve the module versioning and classloader issues from an enterprise-application perspective. Although we’re doing a bit of classloader magic behind the scenes, the developer perspective is fairly simple and clean:

1. remove jars from your .war
2. drop them in Resin’s project-jars directory
3. declare jar dependencies in Maven .pom files
4. import them to your web-app with WEB-INF/pom.xml or in your resin-web.xml

Pomegranate resolves the module versions, and builds a classloader graph for the web-app. The module graph looks like the following:

I’ve written some notes trying to understand and explain from a management perspective why service oriented architectures works, as a motivation to understand the Resin 4.0 architecture. To make the ideas concrete, the end of the post shows the bare-bones hello world example for an osgi/web-app service.

While services can improve application organization, they can also improve the programming team coordination. From a management perspective, services organize the application around staffing resources, and organize team communication. Since the PHBs often can’t keep track of the engineering details, services also let engineers explain to management what they’re working on.

Organizationally, services can improve team communication because each service defines a programming boundary between team members. Like a legal contract which defines the requirements and responsibilities between two businesses, a service clarifies the expectations of the service developers and service users. A manager can put both teams in a meeting, let them argue about the service definition, and then let them get back to work, confident that they know how they’ll communicate. A team consisting of Draco, Hermione, Luna and Harry, you could assign a service to each, put them in a room to define their service contracts (APIs), and manage progress based on the service contract. If Harry and Draco start arguing, you can pull out the service contract to resolve the problem and modify it if needed.

(more…)

Since OSGi bundles mainly provide services, for example authentication or JMS, you’ll need to configure the service to point to the user database or JMS queue destinations. Naturally, I’d recommend using WebBeans as the configuration format because it’s a Java standard, compact, and powerful. The official spec JSR-299 is on the JCP website.

Configuring a service generally involves creating a Java instance of the service class, configuring any properties, and registering the service with the OSGi and WebBeans, so it’s available to any application that needs the service.

To specify the class, the latest WebBeans draft uses a combination of an XML namespace and the XML element name, letting you instantiate any Java object an a minimum of verbiage. So the namespace xmlns:r=”urn:java:com.caucho.server.security” and the XML name r:XmlAuthenticator, would create an instance of Resin’s XML authenticator “com.caucho.server.security.XmlAuthenticator”.

<r:XmlAuthenticator xmlns:r="urn:java:com.caucho.server.security">
  <r:password-digest>none</r:password-digest>
  <r:user name="harry" password="quidditch"/>
</r:XmlAuthenticator>

The best part about the syntax is the removal of all overhead tags, so the configuration concentrates on the object itself. The only extra tag is the “xmlns:r” to specify the namespace. Otherwise, all the names are critical to the class and its properties. In other words, the new WebBeans syntax avoids annoying tokens like: <bean>, “class”, <property>, <name>, <value>, etc. It’s clean and simple.

With 3.2.1, we’ve started working on our OSGi integration with Resin and based on that work, it looks like we’ll have a slight different approach to OSGi than most everyone else. Since OSGi was originally designed for embedded applications, the design is slightly different than the requirements for an application server.

From our perspective, OSGi provides two benefits:

1. a jar versioning and dependency system
2. a service registration system

You might have noticed that posts slowed down here after my talk at JavaZone, which is because I took some time off to see Scandinavia. But I’m back now and getting ready for even more upcoming events! Just a quick review:

1. San Francisco Java Meetup - I’ll be speaking here again, this time about Resin’s OSGi container implementation, as well as general OSGi issues along with fellow Java Meetup regular, Andrew Headrick. This is just one week away on Monday, Oct 6 at 6:30. The signups are full right now, but keep an eye on the page in case anyone drops out…
2. Resin Administration Training - There are still a couple of spots left for this course, so sign up ASAP to guarantee your seat. I’ll be teaching this at Marakana’s facility in San Francisco on October 22-24. It should be an action packed 3 days!
3. Silicon Valley Code Camp - This informal, but highly technical conference is growing by leaps and bounds. With already over 500 signups, I expect the Code Camp to be a ton of fun and very successful. I’ll be speaking on Quercus and BAM, so stop by for those and the other speakers’ talks on Nov 8 & 9 at Foothill College.
4. Devoxx - You might know this as JavaPolis or briefly JaVoxx, but the newly renamed Devoxx is still the same great conference that attracts developers from all over the world. It will be held Dec 8-12 in Antwerp, Belgium. I’ll be giving a talk there and Caucho is a plugin partner, so look for us on the convention floor as well.