Thinking of how CDI can be integrated with JBoss ESB.  These notes are super rough right now, but I figure it's best to talk out loud early.  I hope to share some pseudo/mock-up code within the next two weeks to make this a bit more concrete.

I see four use cases (listed in order from obvious to crazy).

Consuming a service hosted in the ESB from within a Managed Bean

On the surface, this is pretty much meat and potatoes.  You have a managed bean and you want to inject a reference to a service hosted in the ESB.  So you might expect to see something like this:

public class MyBean {
   @Inject @ServiceName("CoolService")
   Service esbService;
   ...
}

Pretty straightforward, but what exactly do you expect esbService to do?  There are two possibilities:

1. Service is simply a client proxy to the ESB.  Calling a method on this class results in a message being sent over the ESB to the provider of the service.
2. Service is a representation of a response from a service.  What this means to me is that the @Inject processor actually invokes the target service during injection and maps the result to the instance being injected.  What's in the request message?  Good question, I have no idea.  Maybe there's another annotation that provides a reference to a bean or a literal value that is used as the request message.

The other thing to keep in mind here is the context management in CDI.  So if the Service reference is scoped to anything other than request, we are assuming that the target service is stateful.  This is not guaranteed in SOA by any stretch of the imagination, but could be relevant if a correlation or conversation identifier was associated with each call to the service.  Need to think about this more.

Providing a service on the ESB from a Managed Bean

Three ways I can see this happening:

1. The managed bean injects some type of registration interface from the ESB and uses it to programmatically register itself as a service.
2. The managed bean implements a producer method for an interface that the ESB expects for service registrations.  The CDI Extension implementation for the ESB would have to hunt for these.
3. The managed bean implements a specific interface or is annotated in some way so that the ESB CDI Extension picks it up.

Consuming and providing using Events

This is a pretty natural mapping for the ESB, which is inherently asynchronous and message-based.  Not too difficult to imagine how this will play out.  A bean would provide a service by observing events qualified with the service name that it's providing.  A bean would consume a service by firing events qualified with the name of the service to be consumed.

Using Weld as a Composed Service Model

I need to provide a lot more context for this to make any sense at all, but I'll try with a quick and dirty explanation now.  The current version of the ESB provides a service definition model based on the concept of an action processing pipeline.  This is basically just the traditional pipes and filters pattern, but it all happens within the context of a service.  A service is composed of the serial execution of one or more ordered actions.  The ESB creates instances of the action classes and handles the dispatch.

If you do the right amount of drugs, you can twist the ESB notion a bit to think of CDI as the compositional model.  CDI can inject the beans and service references into a managed bean that represents your service.   There is some notion of ordering here based on dependency resolution, but it's certainly not at the same level as the ESB action chain.  Maybe there's a clever way to define this with CDI.  Or maybe not.  Maybe it's just not part of the compositional model of CDI and we use other routing/orchestration technologies when that is necessary.

A few additional notes:

• I assume that we will need to provide an implementation of CDI Extension to do most/all of the above