If one does not need JMS messaging, one should not
depend on any JMS library. Same for Rendezvous and
other supported communication protocols.
On the other hand, it should be easy to add new
messaging protocols as long as they are "close enough"
to the supported ones. (Basically that would mean that
the protocol supports fields in one way or the other.)
To achive these goals, it would be nice to move the
Converters into seperate runtime projects extending a
base/core runtime project (which in turn becomes
"abstract" in a way that it is next-to useless without
the support of at least one runtime project).
The structure I'm thinking about is the following:
messageforge-runtime-core:
contains the field definition classes
and maybe an abstract Converter class (maybe together
with a Factory that is able to create a real converter)
messageforge-runtime-rv:
contains only the ConverterTibrv (which extends the
abstract Converter and registers with the Factory)
messageforge-runtime-jms:
contains only the ConverterJMS
messageforge-runtime-(whatever)
