Last Friday we discussed a number of topics, but the only technical subject that came up was the naming for the BAM API. I’ll discuss that first. As you may know, we’ve been working on BAM for sometime now and even given a few talks on it. We’re using it extensively for the internals of the dynamic clustering implementation, but originally we were planning on making it a public API for games, finance, and other messaging based applications. That’s still the goal, but the other work on Resin 4.0 has pushed back the time line for the release of BAM at the user level.

After attending this week’s SF Java Meetup on Scala, I started comparing Scala’s actors and BAM agents/services. There are a lot of similar concepts, but this started us thinking about whether we shouldn’t rename the A in BAM, which currently stands for agent, to actor. Well, BAM can handle the duties of an actor, but it actually makes more sense to think of the building blocks as services. So it may turn out that like many architectural/standard acronyms, the letters of BAM won’t actually stand for anything. Anyway, we decided that our interfaces will have the prefix Bam*, while abstract classes will not. And the word “agent” is going away…

As for the non-technical points we touched on, probably the most relevant is the reorganization of the documentation. We’ve got a lot of docs, but they’re a bit scattered, so we’re planning on refining them and putting them into a book-like structure. There’ll be three parts to the book: an administrator guide, a developer guide, and a cookbook. As you may have noticed, we’re moving to a completely WebBeans-based configuration model. If you saw my post from last week, you know that tooling for WebBeans should be extremely useful and straightforward. Because of this, we may decide to create a doclet that outputs documentation of our configuration directly from the code!

A couple of other small topics came up this week as well. Many of you may know that we’ve been sending out a Caucho monthly email newsletter since last September, but we never actually had a formal way to sign up for it. We’ll this week we’ll be changing that by allowing you to sign up on the site and to view the past newsletters. Just keep checking the front page of caucho.com and you’ll see it as a new tab. The last thing that came up was our training course. The second class will be here in just over a week! There’s still a couple spots left, so if you’ve been putting off signing up, now it the time to do it. This week I’ll be putting in a few updates and polishing the material, so it should be a good one.

With Resin 4.0’s WebBeans support, we can finally modularize and cleanup features like security, JMS, clustering and remoting. Since the WebBeans-style XML configuration selects a component based on package and classname, our XML configuration for security exactly matches our classes. For example, <sec:IfNetwork> is com.caucho.security.IfNetwork. Our JavaDoc can even serve as XML documentation and as Emil’s post shows, we can enable Eclipse to display those tags automatically.

JavaDoc is available for com.caucho.security, as well as documentation for Resin 4.0 security.

Since examples make configuration clearer, I’ve put together three typical security configurations:

• IP address protection: restricting admin pages to the local network
• Hiding pages from all browsers, like WEB-INF
• HTTP basic authentication for quick and dirty password protection

(more…)

The new WebBeans spec defines a way to configure beans using a neat XML trick where you place the Java package name for a bean into a namespace. Both Scott and Gavin King have written about this, so I won’t rehash the details. One concern of those looking at this approach is that tooling won’t be easy to write to resolve the package names from XML namespaces.

Lately I’ve been working on the Resin plugin for Eclipse, so I thought I’d give it a shot to write some basic IDE facilities for WebBeans. Here’s a screenshot using an example from Gavin’s blog:

You can see that it was pretty easy using Eclipse’s built-in Java and XML analysis tools to extract the class name of the tag under the mouse pointer and then pull the Javadocs from the class. Now, this plugin is pretty fragile and it doesn’t do a lot yet, but for a guy who doesn’t know much about Eclipse (i.e. me ;-)) to whip this up in a couple days means that tooling for WebBeans XML shouldn’t be difficult.

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

One of the coolest new features of Resin 3.1.5 is embedding. Basically with a few simple lines of code, you can embed Resin into any existing Java application. More than that though, you can take advantage of Resin IoC/WebBeans even within the embedded environment. Let me give you an example…

Let’s start with simple embedding:

package demo;

import com.caucho.resin.*;

public class EmbeddedResin {
  public static void main(String[] args)
    throws Exception
  {
    ResinEmbed resin = new ResinEmbed();
    HttpEmbed http = new HttpEmbed(8080);
    resin.addPort(http);

    resin.addWebApp(new WebAppEmbed("/", "ROOT"));
    resin.start();
    resin.join();
  }
}

This basically starts up a new Resin within this application listening to port 8080 and serving up a webapp whose root is at “ROOT”. The resin.start() call starts the instance while the resin.join() waits for it to finish. Depending on the application, you may want to separate those calls.

So that’s very cool, but now what if I have a bean that I want to inject somewhere. Let’s say this FooBean:

package demo;

public class FooBean {
  public String hello()
  {
    return "Hello from the world of Embedded Resin!";
  }
}

I can actually do annotation based injection into a JSP for example:

<%@ page import="javax.webbeans.*,demo.*" %>
<%! @In private FooBean _foo; %>

<%= _foo.hello() %>

All I have to do is add a call to resin.addBean() to the example above:

package demo;

import com.caucho.resin.*;

public class EmbeddedIoC {
  public static void main(String[] args)
    throws Exception
  {
    ResinEmbed resin = new ResinEmbed();
    HttpEmbed http = new HttpEmbed(8080);
    resin.addPort(http);

    resin.addBean(new BeanEmbed(new FooBean()));

    resin.addWebApp(new WebAppEmbed("/", "ROOT"));
    resin.start();
    resin.join();

  }
}

It’s pretty cool to me that you can drop a random bean into the embedded Resin, then just have it show up somewhere in a JSP. I bundled this example up here. Just run “ant compile”, then “ant run” to use it.