Manuel Teira wrote:
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:
don't see why not
- 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.
Currently the C++ broker can run as a daemon and broker. There is no
option to load it into another container. What C++ container are you
thinking off?
The daemon does have things like stop etc.
- 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?
There is work currently on active/active clustering, however what you
describe can be achieved with what we have. The is a plug-in store
module for the broker that can be used and if you use something like
Cluster Suite included as part of RHEL, or vertius or something like
that the above pattern can be configured.
- 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.
There is an in process transport that is used for some of the tests, if
you want to see this exposed as a feature, make some more noise...
- 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?
no idea - maybe someone else on list has tried, I expect it should not
be that much work to get it building on Solaris -- Andrew is the one to
hit up on that. The store might be
a bit more complicated, you might want to consider doing an impl of the
store interface for ODBC.
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".
from discription items would be
- create Actice/Passive scripts for your env
- build project on Sun -- and implications of that. should not be that
bad as Linus and Sun are both posix.
- port a store module, or just impl a ODBC interface for the store
interface.
Thanks a lot for reading so far.
not an issue.
Carl.
