Overview

Search

Documentation

Community

Developers

Components

Related Projects

Use Case

Think Lingo + support for JMS/JBI so it can be easilly deployed in any Spring app such as in Tomcat.

You are either a developer using spring (which is most people these days) or you are developing a web app. You need to work with some external service - or provide a service.

So the idea is - you use POJOs. The only issue now is

  1. which annotations do you use
  2. do you want to completely hide the middleware, or let bits to show through (e.g. bits of JMS / JBI APIs)
  3. how to integrate with pooling stuff

There now follows the various flavours of this approach

Status

Type Status
plain POJO Complete. See Spring
EJB3 Pitchfork or JBoss or maybe OpenEjb one day
JMS Lingo does some of this - no JMS DI yet
JSR 181 XFire, ServiceMix, SpringWS kinda maybe one day?
JBI Nothing yet
REST REST POJOs

Flavours of POJO

There's lots of flavours - pure POJO, EJB3, JSR 181, SCA, Seam/Web Beans etc.

Here's a few examples

Pure POJO - no annotations

This is a classic pure Spring Remoting option

public class Cheese {
  public String doSomething(int x) {.... }
}

EJB 3 annotations for lifecycle

Its basically AnDI where @PostConstruct and @PreDestroy is used for lifecycles and @Resource used to indicate mandatory injection points.

JMS annotations

Allow services.methods to be bound to destinations

public class Cheese {
  @Queue(name="foo.bar', persistent=true)
  public String doSomething(int x) {.... }
}

Allow forJMS injection along with pooling/transaction stuff

public class Cheese {
   @Resource Destination orderQueue;
   @Resource  Session session;
   @Resource MessageProducer producer;

  public String doSomething(int x) {
     // lets send a message
     Message message = session.createTextMessage("Hey " + x);
     producer.send(message);
  }
}

JSR 181/JAX-WS

Adds web services specific stuff to help map stuff to WSDL So typical JSR 181 / JAX WS stuff

@WebService(name = "Foo", targetNamespace = "http://acme.com")
public interface BFServiceV2 {

    @WebMethod(action = "login")
  public String doSomething(int x) {.... }
}

JBI Annotations

Could reuse JSR 181 annotations where they make sense then add JBI specific injection (like JMS ones)

public class Cheese {

  // a few different ways we could map JBI exchanges to POJOs

  public void doSomething(InOut exchange) {
     Message in = exchange.getInMessage();
     Message out = exchange.createMessage();
     ...
	 exchange.setOutMessage(out);
     exchange.done();     
  }

  // in only
  public void process(Message in) { ... }
  public void process(MessageExchange exchange, Message in) { ... }
 
  // in out
  public void process(Message in, Message out) { ... }
  public void process(MessageExchange exchange, Message in, Message out) { ... }
}

Deployment Model

The development model outline previously is obviously of paramount importance to the application deleveloper. The other half which is very important too is the deployment model. We want to target the web application developers just like spring has. This means that our solution needs to be able to run in any web application container. It also means that it needs to able to be packaged in .war.

Further more, I think we need to ride the spring wave and allow all deployment configuration to be done using the web application's spring configuration file. The hard part here will be how do we make servicemix configuration and wiring of components so simple and easy that folks do not get put off by the added complexity? For example, folks like using AXIS because they could create .jws files and they would be exposed as web services without much more effort. We need to aim for that level of simplicity. It seems that most of the deployment/wiring information is being included as part of the annotation on the POJO's, so servicemix deployment model would need to use this automagically wire together BCs with the SEs.

Optionally, I think the container should support being configured with a hot deployment directory that would accept standard JBI deployment artifacts.