activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: NMS Provider for Tibco EMS?
Date Wed, 03 Oct 2007 17:36:06 GMT
On 10/3/07, semog <> wrote:
> 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
> anything
> 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
> that?

Seems like a headache..  I think your project should only build if
folks explicitly build it.  lets get your stuff in ASAP and then we
can refactor the whole project/solution stuff so that they are more
separated from each other.  Yes, it makes building everything more
complicated since you have to run multiple builds but the upside is
that you only have to build what you need and have actual dependencies
on.  Also it will make versioning each module independently possible.

> 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
> useful
> 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
> class
> out from the ActiveMQ project into a shared area.  I had to copy the
> DateUtils
> 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'd like like the NMS module to hardly ever change I want to release a
1.0 soon of it, and hope we never have to do a 1.1.  A stable
interface definition like that will encourage folks to do more
implementations of it.  So, because of that.. I'd rather not put
implementation helper classes there.

I don't mind copying code across.  Yes, code duplication sucks.. but
to end users un-needed dependencies suck more.  So I'm all for what
you've done.

> 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
> returns
> the appropriate ConnectionFactory instance.  For example, if the following
> is used, then TIBCO will be selected:
> tibco:tcp://myserver:7222
> I can automatically take advantage of the TIBCO failover protocol like so:
> tibco:tcp://primary:7222,tcp://backup:7222?transport.useLogging=true
> 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
> ActiveMQ
> 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,
> the
> 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.
> This
> 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.
> The
>   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
> code,
>   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.

+1000 Awesome.. we just did not know a good way to do the dynamic
implementation discovery stuff in .NET.  Btw I would not mind if the
activemq urls looked like activemq:tcp:// with the generic NMSFactory.

I figure if you want to use a tcp:// looking URLs then you will use
the ActiveMQConnectionFactory,


> 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
> as
> 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