EPR format for JMS

[marklittle]

We need to define an EPR format for JMS destinations. Obviously more information needs to be encoded with this than just your typical host/port pair that you may find on WS EPR encodings.

Although JMS caters for p2p and publish/subscribe functionality, which we will obviously need to support, we have to do this within the bounds of the overall JBossESB model. No implementation specific features (JMS specific features in this case) should escape their respective boundaries. So ignoring p2p versus pub/sub for now (I'll post a separate forum entry on those soon), we still need to come up with some EPR definition that is compliant with JMS in general and can also be modified to cope with any implementation specific enhancements (e.g., differences between JBossMS and JBossMQ).

The basic format of the EPR (since it is based on WS-A) is a URI. So something like jms://foo.bar as a start, with additional information encoded within the ReferenceParameters. (Yes, we can encode a lot of information within a URI if we really want to, but I'd prefer to keep the base URI as minimal as possible - open to discussions though).

Anything that gets put in the ReferenceParameters (e.g., jndiProviderURL?) needs to be verified IMO. So it seems to me that we're also looking for a schema to define the overall JMS EPR content. Maybe such a schema already exists?

[marklittle]

Just a quick addendum: we did some work on JMS over SOAP back in OASIS BTP days. I'll see if I can dig that out because it may be relevant.

[arvinder]

I think we should expose just core connection details on the uri, so for the example below, @host is only required if this is an incomming endpoint that binds to some external system. So for example, if we were to smb mount something externally, it could be


smb://<share-name>@

so from http://www.w3.org/TR/2005/WD-ws-addr-core-20050215/, we could say for jms

wsa:EndpointReference>
 <wsa:Address>
 jms://<destination-name>:<destination-type>@<host>
 </wsa:Address>
 <wsa:ReferenceParameters>
 // the jms related properties, e.g
 jndi provider url
 connection factories
 ..
 </wsa:ReferenceParameters>
</wsa:EndpointReference>

What are the opinions on using name spaces as opposed to

<EndpointReference>
 <Address>
 jms://<destination-name>:<destination-type>@<host>
 <Address>
 <ReferenceParameters>
 // the jms related properties, e.g
 jndi provider url
 connection factories
 ..
 <ReferenceParameters>
</EndpointReference>

For each EPR, perhaps should add another plugin parameter - say a set of interceptors, therefore when a request passes through the EPR, these set of intercetors are run. I'm am going to read up more on WS-A

[arvinder]

If we deploy a JMS EPR that binds to an external jms server/system,
we may or may not need to include thirdparty drivers/libs, so this could
possibly imply a classloader related parameter as part of the format.

Having said that, if we want to hot deploy EPR's (like we can hot deploy
*-ds.xml's), we may not be able to get away with just dumping an EPR xml
file into the deploy folder, but rather an archive possibly with dependant classes/jars if required.

Anyway .. food for thought further down the line.

[marklittle]

WS-A is fairly straightforward and is powerful enough for what we need. Obviously take a look at http://www.w3.org/TR/2006/PR-ws-addr-core-20060321/ and http://www.w3.org/TR/2006/PR-ws-addr-soap-20060321/. But you may find this useful as well: it's relevant to the context aspect of our ESB and is integral to us maintaining a loosely coupled approach to stateful and stateless interactions.

[marklittle]

I think the concept of interceptors to fire is a slight diversion in this entry, but it is related to the dispatchers concept and, ultimately, to the service contract definition language/description that we need to define: for a start, what the service expects, or what the client is using in terms of non-functional aspects, like transactions and security, will obviously dictate what dispatchers (aka interceptors or filters) will need to be fired in order to construct the right message context. Anyway, as I said, a slight distraction in terms of JMS, but worth mulling over. I'll stick something down into another discussion topic tomorrow so we can at least track this separately.

[marklittle]

One last entry for tonight: maybe the starting point is defining precisely *what* information we need to have in order to make use of a JMS. Someone want to take a stab at that? Then we can define a schema that will at least allow us to do run-time validation of the EPR once we decide how to format it.

[arvinder]

The reason I mentioned running a set of interceptors, was to support processing a message entering the EPR, before it gets dispatched.
Say for instance we have a jms message comming into an EPR from an external system, we may want to convert that jms message into either something generic, or to type X depending on how you configure that EPR - before we use the dispatcher to dispatch it onto the Bus or whereever it is going.

Anyway, you are right this is a diversion, I'll try to set aside some time to populate the wiki with details like this.

[marklittle]

I think you might be confusing EPR with service (or client). The EPR (endpoint reference) is simply the address of a client or service; at a coarse level it defines how the message should be sent (protocol) and potentially interpreted at the far end (via ReferenceParameters). To all intents and purposes, think of EPR as a URI (there was some debate during our work in the WS-A standards process as to whether or not we should just use a URI).

If I'm right, and you are thinking of the EPR as the service (or client) itself, then you're right about the interceptors, but as I said, that's where the dispatchers come in: they are ESB-specific interceptors. Of course there may be interceptors that fire within the messaging infrastructure implementation itself. But I always saw this combination of dispatcher/implementation-interceptor setup as part of the contract definition. I'll try and put my thoughts down elsewhere, so we can track this.

[arvinder]

I have added some updates to the wiki regarding the endpoints in general - added more protocols and more detail for the jms endpoint w.r.t EPR definition, feel free to edit etc.

[marklittle]

Can you add a link to the specific wiki page(s) here, just to make to easier to navigate?

Thanks,

Mark.

[arvinder]

Sorry, they are placeholders/skeletons, but its a small start

Endpoints
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossESBEndpoint

JMSEndpoint
http://wiki.jboss.org/wiki/Wiki.jsp?page=JmsEndPoint

[ddossot]

Concerning the JMSEndpoint (http://wiki.jboss.org/wiki/Wiki.jsp?page=JmsEndPoint), I think we could also use a:

3.
...
10. Durable

parameter.

[marklittle]

OK, but what are the semantics, or is this something that only makes sense for the JMS transport?

[marklittle]

BTW, I meant "semantics as they apply to ESB". I know what durable is in the context of JMS ;-)