Hello all.
I'm developing a C++ enterprise application, actually a revamp of an
already running solution. Briefly speaking, it's an architecture where
every component is exposing input and output channels, and the whole
application is deployed as a combination of such components, where a
configuration file defines the components to instantiate, and how to
connect their channels. Some components are basically data sources,
other are able to process messages, and some other are just sinks, that
are commonly able to send a response to a foreign system.
Some of the requirements for the new version are high availability,
load sharing (clustering in fact) and bulletproof persistence for the
messages streamed into the channels. So, I think that the best way to
achieve this, will be to have a central component to manage all the
channels (we could call them queues, actually), as all the new features
could be centralized into this component: persistence for the messages,
load sharing (as different machines could be running against a broker)
and high availability (if the brokers could work in a master-slave mode).
As during the last years, I've also involved in some java
developments, I had the oportunity to know the Apache ActiveMQ product.
So, my idea is to have something in the C++ domain, that was able to
perform the same basic tasks than the ActiveMQ message broker.
Excuse for this long introduction, but I think that having a clear idea
of what are my needs and vision, would be better to know if qpid (the
C++ broker, particularly) is a suitable product to meet them. So, the
questions:
- The first question is about deploy posibilities. Since I would like
the broker to be a component of my server, is there any problem into
having it embedded into some kind of service container, to meet my
architecture? Or does it need to be deployed always as an standalone
process? My idea is to wrap it into one of my service containers,
exposing start/stop semantics, to be able to have the broker deployed as
part of my main server.
- My idea of HA / Load Sharing is borrowed from what I've learn in the
ActiveMQ world (their JDBC master/slave). I would like to have a master
broker (active), in some of the deployed servers, with all the clients
(producers and consumers) in all the servers (or external clients),
using this broker. If some problem arises with this server, some of the
slave ones will adquire the master role (this could be made relying in
some RDBMS locking scheme). The clients will use a failover schema to
cycle between the different existing brokers, until they find a working
one. This way, we will have HA /Load Sharing. Is this scenario, or
something equivalent, possible with qpid? Of course, we will need a
message store that could be seen by all the clustered brokers,
presumably located in a HA RDBMS solution.
- About the RDBMS storage, my idea will be to create a message store
relying in a ODBC driver. Do you think it's feasible? Or is there any
need for the store that a RDBMS could not meet?
- Another interesting feature will be to be able to have some kind of
direct communication for clients running inside the same process of the
active broker. This is also inspired in the activemq vm tranport,
avoiding a socket communication for in-process clients. This way, every
in-process client would use a failover connector, where one of the uris
will be the in-process one, and the other some regular socket ones to
the other brokers in the cluster.
- The environment to develop / run the solution will be the Solaris
Operating System, using the Sun Studio 12 compilers suite. Is there any
problem with that?
Other than using qpid, I'm considering to develop myself a solution. But
I think that it will be better to contribute to qpid for the missing
parts, if you think that they could be implemented and if this meets the
goals of the project. This is why I sent this mail to the developers
list, because I would like to know the implications of my needs in terms
of development efforts. Things like "yes, you just need to implement the
interface AAAA", or "yes, it can be done, but the class BBBB should be
extended to support this or that".
Thanks a lot for reading so far.
Best regards.
--
Manuel
