activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From semog <>
Subject Re: NMS Provider for Tibco EMS?
Date Wed, 03 Oct 2007 17:20:27 GMT

Hiram Chirino wrote:
> Cool!  Please make sure you attach the Apache License headers on all
> your source files before you attach them to the issue.

I added the header to all of the files that I added.  I didn't change
in the comments, so it should all fit in.

Hiram Chirino wrote:
> I would this it in a separate build module / and VS project to since
> it does add the new tibco dependency.  We should probably separate the
> other modules too so that they are independently versioned.  The base
> NMS interfaces has been looking stable and I don't think it should
> need many releases at all.

Yes, I added it as a separate VS project, and it is included in the main
solution.  What I have been thinking about doing is creating a "mock"
version of the TIBCO.EMS.DLL that could be included with the Apache
distribution.  This DLL would just be a stand-in so that the project can
compile/link successfully. For those that actually use TIBCO, they will
just drop in the real assembly, and be good to go.  What do you think of

As I was working on the TIBCO implementation, I found that there was a
generally useful interface hidden down in the ActiveMQ implementation.  The
ITrace interface and Tracer class are a generic interface that should be
used across implementation to provide convenient and standard reporting
regardless of which provider is being used.  I moved this interface into the
NMS project.

I found that the Dispatcher.cs class in the ActiveMQ project was also a
class.  I would have liked to move this into a common shared code area.  It
didn't make sense to move it into the NMS project, so I ended up copying it
into the new TIBCO project.  This makes the code harder to maintain, because
now there are two copies of the Dispatcher class and any bug fixes will need
to be made in two places.  I don't really like that, but the TIBCO project
needs to be completely stand alone and not have any dependencies on the
ActiveMQ project.  We should also discuss/consider moving the DateUtils
out from the ActiveMQ project into a shared area.  I had to copy the
functions into the TIBCO project as well.  :(  The MSMQ project also has a
dependency on the ActiveMQ project.  The MSMQ MessageConsumer class could be
re-factored to use a common Dispatcher class.

I also added a new NMSFactory.  This new class is the single starting
point for selecting the back-end provider based upon the connection URI.  A
static method called CreateConnectionFactory takes a URI parameter and
the appropriate ConnectionFactory instance.  For example, if the following
is used, then TIBCO will be selected:


I can automatically take advantage of the TIBCO failover protocol like so:


To use the MSMQ provider, the URI is prefixed with 'msmq:' scheme.  Any
existing URIs that are prefixed with 'tcp:' or 'stomp:' will use the
provider.  The NMSFactory will parse the URI and dynamically select
the correct provider.  I used reflection to load and select the appropriate
ClassFactory implementation to eliminate run-time dependencies.  Currently,
list of providers is hard-coded, but it would be a simple matter to load the
mapping of scheme to provider implementation from a configuration file. 
is modeled after the JMS implementation that uses the META-INF configuration
to dynamically load transport implementations.  There are several advantages
to this:

* It gives a single starting point to load up the NMS library.
* It leverages the flexible syntax of URIs.  Client applications do not need
  to perform any parsing of the URI to figure out which provider to use. 
  provider information is embedded in the URI.
* If we add the external configuration of class factories, then additional
  providers can be dynamically added without having to touch any source
  either in the NMS Library, or in any client code.
* It simplifies compile-time reference dependencies.  A client application
  only needs to reference NMS.DLL.

Hiram Chirino wrote:
>> has really started to diverge from the main trunk.  I have logged several
>> bugs, and contributed patches for them, and they are all included in my
>> codebase.  One of the more significant changes is the changing of
>> namespaces
>> [AMQNET-31], and a corresponding change made was changing the name of the
>> assembly files.  I changed the assembly names to include 'Apache' at the
>> beginning (e.g., NMS.DLL is now Apache.NMS.DLL, NMS.ActiveMQ.dll is now
>> Apache.NMS.ActiveMQ.dll).  This became important to differentiate the
>> Apache
>> assemblies from the TIBCO assembly.  The new assembly is named
>> Apache.NMS.TIBCO.DLL.
> Seems odd.  Would NMS.TIBCO.DLL been hard to differentiate?  I'd hate
> to go changing assembly names at this point.  Lots of assembly names
> don't seem to prefix the assembly with the organization.  I think we
> should just follow suite.

I can change this part back.  At the time it seemed to make sense.  When I
saw NMS.TIBCO.DLL and TIBCO.EMS.DLL sitting right next to each other, it was
a bit confusing.  When I added the Apache prefix, things became very clear
to which company produced the assembly.  I can remove the Apache prefix from
the assembly names, though.

Hiram Chirino wrote:
> How about you send us a diff.   Hopefully there are JIRA issues
> associated with the major changes to the current stuff.  And then a
> zip of the new tibco module..  Attach the stuff to your issue.

OK.  I will work on packaging everything up today.  Thanks for your help.

- Jim Gomes

View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message