Seam on JBossESB

[burrsutter]

There has been plenty of speculation on how the worlds of Seam and SOA might come together. Gavin and I recently met (in the real world) to discuss this topic and came up with at least one possible concrete actionable idea.

The objective of Seam integration into the JBoss ESB is to allow a Seam component to behave as a service. A service for JBoss ESB is implemented as a custom action which can be the service itself or simply act as a proxy to the local/remote business service. The business_service quickstart illustrates this concept of using an action as a proxy to an EJB3 stateless session bean deployed on the AS.

The proposal here is to have an "out of the box" action that will provide Seam integration to get the creative juices flowing.
The possible jbossesb.xml:

<action class="org.jboss.soa.esb.actions.SeamProxy" name="MySeamComponent"/>

The name here should be available to the action (SeamProxy) so that it can be mapped to the @Name of Seam (the action performs the JNDI lookup internally).

We are also proposing a new Action interface called -MarshalledActionProcessor with a single method signature that looks something like:
public Object process(Object[] objects) throws ActionProcessingException;

The purpose of this interface is so that the Seam team can implement something that deals with "objects" instead of Messages. It will be our (ESB team) job to transform the Message into an object array on the way in and back to a Message on the way out.

Now, this isn't the final design, just a starting point to kickoff the debate.

[burrsutter]

Seam also needs us (ESB) to handle some form of context identifier between service invocations. Think of this as a cookie for a typical web-based application.

The use of a Message header/property could do the trick but the interface method signature I proposed earlier doesn't address this requirement.

[marklittle]

Do you mean a session identifier?

[tfennelly]

Do you mean a session identifier?

I'd suspect that it could be more than a session-id. Seam supports the notion of at "conversation context", which exists within the context of a session. You can have multiple conversations running in parallel within a single session. It tracks this using a conversation-id. So, I'd suspect they need something that they can map to something like "session-id:conversation-id". Not sure what Gavin/Burr has in mind - perhaps they've no intention of supporting anything beyond an equivalent of a session-id.

[marklittle]

Context is the best place for this information. Not sure at the moment whether that is a 4.2 or a 5.0 item though. If not 4.2 then we can fudge it in WS-A, but that leads to backward compatibility problems when we eventually do it right. Anyway, I'll wait to hear from Burr.

[burrsutter]

We (Gavin and I) didn't discuss the distinction between having a conversational context id vs a session id. I'm guessing that it is more a session id and he manages the "conversation" on his side of things.

I've sent him a link to this thread to see if he'll comment.