1 2 Previous Next 25 Replies Latest reply on Jun 5, 2006 10:51 AM by Arvinder Singh

    EPR format for JMS

    Mark Little Master

      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?

        • 1. Re: EPR format for JMS
          Mark Little Master

          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.

          • 2. Re: EPR format for JMS
            Arvinder Singh Novice

            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


            • 3. Re: EPR format for JMS
              Arvinder Singh Novice

              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.

              • 4. Re: EPR format for JMS
                Mark Little Master

                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.

                • 5. Re: EPR format for JMS
                  Mark Little Master

                  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.

                  • 6. Re: EPR format for JMS
                    Mark Little Master

                    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.

                    • 7. Re: EPR format for JMS
                      Arvinder Singh Novice

                      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.

                      • 8. Re: EPR format for JMS
                        Mark Little Master

                        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.

                        • 9. Re: EPR format for JMS
                          Arvinder Singh Novice

                          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.

                          • 10. Re: EPR format for JMS
                            Mark Little Master

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

                            Thanks,

                            Mark.

                            • 12. Re: EPR format for JMS
                              David Dossot Newbie

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

                              3.
                              ...
                              10. Durable

                              parameter.

                              • 13. Re: EPR format for JMS
                                Mark Little Master

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

                                • 14. Re: EPR format for JMS
                                  Mark Little Master

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

                                  1 2 Previous Next