Database integration to Mobicents SLEE
Vilius Panevėžys
as we all know databases are crucial resources in any real world telco solution.
Mobicents is doing nice steps to address this need by both documenting
possibilities (http://community.jboss.org/wiki/MobicentsJAINSLEEDatasources) and
introducing a JDBC RA implementation. Having to solve the same problem many
times prompts for a practical, universal and reusable solution. I will try to
briefly describe two of the most viable approaches to database integration that
we see and would like to hear any comments from the community and Mobicents SLEE
experts about pros and cons of each and possibly better alternatives. We came up
with those scenarios having IN services in mind, but they are not limited to that.
Main requirements for DB integration are
- decouple DB query execution from Event Router threads;
- present simple and convenient API reflecting data model semantics to be used
in Service Logic, e.g. getSubscriberInfo operation instead of executing
arbitrary SQL statements directly in SL.
- Performance.
Additional features:
- HA. Probably support provided by JBoss datasources is enough.
- Multiple queries on the same connection, transaction control.
Current Mobicents implementation of JDBC RA allows to execute a single query and
process the result set, then the connection returns to the pool. If there is a
need to execute multiple queries at once (where a query might depend on results
from the previous one), getting connection anew each time would be inefficient.
Transactions are also committed automatically after executing the request, while
there is sometimes the necessity to combine multiple queries into a single
transaction.
Now the alternative approaches for this problem.
1. Custom Database RA tailored for a particular data model
This satisfies main requirements: RA may freely manage its own thread pool as
well as implement a custom API based on Service Logic requirements and specifics
of the underlying data model. Moreover, as all interactions with database are
encapsulated inside this RA, it has complete freedom to manage connections and
transactions in any way needed.
Service (single SBB for brevity) communicates with the RA via a data
model-specific API
SL SBB <--- DMS API ---> DB RA <---> DATABASE
This is a simple, well known and tested approach. But what I don't like about it
is that you have to reimplement the RA every time to integrate a new data model
for another service either by reusing some stub like the current Mobicents JDBC
RA or by using some code generator and implementing the data model specifics on
top of that. Either way it is basically copy-paste programming which is the
weakest case of Reuse technology, because it is effective only in the short term
and causes an ever growing maintenance overhead in the long term.
2. Generic data model agnostic JDBC RA
In this case a generic JDBC RA (something similar to the current Mobicents JDBC
RA implementation) would be used. Such RA uses a separate thread pool to perform
SQL queries and passes back results as events, but does not know anything about
a specific data model. The function of presenting a convenient API related to
data model specifics would be delegated to a data integration child SBB.
SL DBB <--- DMS API ---> DI SBB <--- generic API ---> DB RA <---> DATABASE
The value of this approach is in the fact that such generic DB RA would be
reused with any service and any data model. Specifics of a given data model are
encapsulated in the Data Integration SBB, the RA is just a "dumb" gateway to a
database. Reusing the same identical component (DB RA) without any
customizations brings the advantages of Reuse like reduction of maintenance
effort, greater reliability, etc.
Alternative #2 looks superior from a purely theoretical point of view. However,
there is the problem of flexible transaction and connection management mentioned
above and some performance related considerations:
- if only a single query is allowed at once and a response to every single query
is routed as a new event, there is the obvious TPS (events) overhead in
scenarios where multiple queries are done, which is quite often the case (custom
RA would perform multiple interactions with DB and return a single response for
the logical data manipulation operation that was invoked).
- overhead of additional child SBB creation (we would need one or more Data
Integration SBBs per call per service). However, it should be possible to
encapsulate the data model specifics in some helper classes and just use that
lib in SL, avoiding adding a child.
Having in mind we are dealing with telco solutions, performance is key in
database integration as well - signalling and SL execution takes time, no
resources to waste here.
Thanks for attention, all and any comments very welcome.
--
Vilius Panevėžys
Elitnet
Eduardo Martins
to solve both the multiple db reads/writes need (with or without tx)
and also the need for a "customized" RA Type. My first thoughts for
such framework, the JdbcActivity would simply expose something like
execute(CustomStatement cs) and this CustomStatement impl class would
provide the RA a method to execute the db requests, which returns the
resulting event object (responsible for providing the event type id to
the RA). Now the CustomStatement may need some functionality from the
RA, such as the tx manager, this would be exposed through something
like a CustomStatementContext object, passed as argument to the
execution method.
The support for such framework would require the RA to fire any event
type, but SLEE 1.1 allows this to be acceptable in the XML descriptor.
The actual custom event types would be deployed by the SBBs. Wrt for
the SBB service logic, I believe this would feel like a custom RA
Type, without the hassle to manage the build of a RA extension.
Community feedback?
-- Eduardo
2011/8/12 Vilius Panevėžys <vil...@elitnet.lt>:
Carl-Magnus Björkell
ears. Something like a command pattern DAO object, combining in a
visitor pattern context object, right? If I've understood your design
suggestion correctly, this would allow the creation of library based
DAOs that could be instantiated by any Sbb, and then sent to the JDBC
RA for processing. I have no objections! :)
-Calle
--
Carl-Magnus Björkell
EmblaCom
On Aug 15, 2:28 pm, Eduardo Martins <emmart...@gmail.com> wrote:
> Hello Vilius, I believe we could come up with a very simple framework
> to solve both the multiple db reads/writes need (with or without tx)
> execute(CustomStatement cs) and this CustomStatement impl class would
> execution method.
>
> The actual custom event types would be deployed by the SBBs. Wrt for
> the SBB service logic, I believe this would feel like a customRA
> Type, without the hassle to manage the build of aRAextension.
>
> Community feedback?
>
> -- Eduardo
>
> 2011/8/12 Vilius Panevėžys <vil...@elitnet.lt>:
>
>
>
>
>
>
>
> > Hello everyone,
> > as we all know databases are crucial resources in any real world telco
> > solution. Mobicents is doing nice steps to address this need by both
> > documenting possibilities
> > (http://community.jboss.org/wiki/MobicentsJAINSLEEDatasources) and
> > to briefly describe two of the most viable approaches to database
> > integration that we see and would like to hear any comments from the
> > community and Mobicents SLEE experts about pros and cons of each and
> > possibly better alternatives. We came up with those scenarios having IN
> > services in mind, but they are not limited to that.
>
> > Main requirements for DB integration are
> > - decouple DB query execution from Event Router threads;
> > - present simple and convenient API reflecting data model semantics to be
> > used in Service Logic, e.g. getSubscriberInfo operation instead of executing
> > arbitrary SQL statements directly in SL.
> > - Performance.
>
> > Additional features:
> > - HA. Probably support provided by JBoss datasources is enough.
> > - Multiple queries on the same connection, transaction control.
> > there is a need to execute multiple queries at once (where a query might
> > depend on results from the previous one), getting connection anew each time
> > would be inefficient. Transactions are also committed automatically after
> > executing the request, while there is sometimes the necessity to combine
> > multiple queries into a single transaction.
>
> > Now the alternative approaches for this problem.
> > This satisfies main requirements:RAmay freely manage its own thread pool
> > specifics of the underlying data model. Moreover, as all interactions with
>
> > model-specific API
> > SL SBB <--- DMS API ---> DBRA<---> DATABASE
> > This is a simple, well known and tested approach. But what I don't like
> > copy-paste programming which is the weakest case of Reuse technology,
> > because it is effective only in the short term and causes an ever growing
> > maintenance overhead in the long term.
>
> > 2. Generic data model agnosticJDBCRA
> >JDBCRAimplementation) would be used. SuchRAuses a separate thread pool
> > anything about a specific data model. The function of presenting a
> > convenient API related to data model specifics would be delegated to a data
> > integration child SBB.
>
>
> > The value of this approach is in the fact that such generic DBRAwould be
> > gateway to a database. Reusing the same identical component (DBRA) without
> > maintenance effort, greater reliability, etc.
>
> > Alternative #2 looks superior from a purely theoretical point of view.
> > However, there is the problem of flexible transaction and connection
> > management mentioned above and some performance related considerations:
> > - if only a single query is allowed at once and a response to every single
> > query is routed as a new event, there is the obvious TPS (events) overhead
> > in scenarios where multiple queries are done, which is quite often the case
Eduardo Martins
asap... since 2.5.0.CR1 release will happen soon.
Issue (including patch) at
http://code.google.com/p/mobicents/issues/detail?id=2825
A small summary, there is a new method in the
JdbcActivity#execute(JdbcTask task) , which allows execution of impl
of a particular task interface.
The task interface has a single method execute(SleeTransactionManager
txManager), which the RA will invoke to execute the task. The RA
exposes the SLEE Tx Manager through the method param.
The execution of the task must return a JdbcTaskResult object impl (if
null nothing more is done), which provides the RA the event object and
event type id to fired.
-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco
2011/8/30 Carl-Magnus Björkell <nrgiz...@gmail.com>:
Carl-Magnus Björkell
I just checked the patch suggestion, and while this looks good and
flexible, I am wondering a bit about connection handling. If I'm
reading this correctly, this pattern would require the Sbb to do
connection handling just as it has before. This is overall a bad thing
I think. The responsibility for connection aquirement/releasing should
be in the RA imo. I'm saying this because we actually managed to
create a dead lock in the JDBC RA the other day when trying it out:
All connections are released in the event unreferenced method. Let's
say that we have a piece of code that creates and executes a query in
an arbitrary method, and then creates and executes another query in
the event handler of that query (exactly as in the RA documentation
example in fact), I will be requesting a new connection from the RA
before returning the old connection (still connected to the result
set). Then we have a deadlock if the connection pool is exhausted. All
threads request a new connection, and keeps blocking until a
connection is returned (which will never happen since they are all
tied up in the result set that is never freed).
The only reason I see for why the Sbb would need to get the connection
object either way is if wants to use the same prepared statement
multiple times, but the general purpose JdbcTask should solve that
need too. I.e. if you need to execute the same prepared statement many
times, just build a jdbc task that will do exactly that. This would
also have the added benefit of that we could move the data into the
jdbc task event, and hence close the result set already before the
event is fired into the SLEE. This would sort of make the JdbcTask the
"DAO" and the event the "DTO". Ideally, all the other methods in the
current JdbcActivity could re-made as "executeQuery(String
preparedStatement, Object... parameters)" so that connections would
never be needed in the Sbb at all, but that would require some kind of
flexible "DTO" class for a general purpose query I guess. (Or are
there other situations that I haven't considered that would need to
have access to the connections in the Sbb?)
This would of course change the task interface a bit: Maybe add a
JdbcRaContext class that would in turn contain the transaction manager
and any other RA resources that is needed to use connections without
the Sbb ever needing to bother about it.
Comments?
-Calle
--
Carl-Magnus Björkell
EmblaCom
> Ok, here is my concrete proposal, can you both please review it
> asap... since 2.5.0.CR1 release will happen soon.
>
> A small summary, there is a new method in the
> JdbcActivity#execute(JdbcTask task) , which allows execution of impl
> of a particular task interface.
>
> The task interface has a single method execute(SleeTransactionManager
> txManager), which the RA will invoke to execute the task. The RA
> exposes the SLEE Tx Manager through the method param.
>
> The execution of the task must return a JdbcTaskResult object impl (if
> null nothing more is done), which provides the RA the event object and
> event type id to fired.
>
> -- Eduardo
> ..............................................http://emmartins.blogspot.comhttp://redhat.com/solutions/telco
>
Carl-Magnus Björkell
I would propose is something along these lines:
* We would remove all the executeQuery type methods from the activity
interface.
* Also remove the getConnection() method from the provider.
* Change the JdbcTask so that it would be given a connection when it
is executed (it will not fetch it itself, it will always be provided
by the RA)
* Add code to the RA to automatically close the connection before the
JdbcTaskResult event is fired.
This way it wouldn't be as easy doing a very simple query, since it
would require implementation of the JdbcTask and a result event (DTO).
However it would have great benefits which includes:
* SLEE "purity". No I/O is handled in the Sbb code or event router
threads.
* Connection and thread safety. The RA can guarantee that a connection
is closed, and hence there is no possibility of deadlocks between the
JDBC RA and the event router threads.
* General purpose design that can be applied to any data model.
* Data model decoupling: Sbb code doesn't rely on SQL or the data
model, it only sees the result event. If the data model changes only
changes to the JdbcTask implementation is needed.
Of course, this would also break any current implementation using the
JDBC RA (since all interfaces would change completely), but this might
not be an issue as older versions of the RA can be used if needed.
I am willing to dedicate a few hours of my time to this if you feel
that this design seems to be a good idea. Toughts?
-Calle
>
> read more »
Vilius Panevėžys
sorry for the delay from our side. However, it turns out to be a good thing as
Carl has already outlined most of the concerns we have been thinking about as
well. :)
We would've suggested an even simpler approach: provide connection to
JdbcTask.execute as parameter and close it (return to pool) right after task
execution is complete (patch line 344). This way the connection would be
returned to pool as soon as possible as well as avoiding possible deadlock as
Carl has explained.
Overall, we think Eduardo's proposed implementation addresses the discussed
needs well, making the JDBC RA suitable to be used as the universal DB access in
Mobicents, which has been lacking for a long time.
One additional feature that would be interesting to have is monitoring. I'm not
currently familiar if JBoss Datasources have anything to that end, but what we
have in mind is that as the JDBC RA is responsible for managing connections to a
DB it would be great to check the actual DB accessibility periodically and raise
a SLEE Alarm in case such a check fails. This way administrators could take
action possibly even before actual queries start to fail filling up logs with
exceptions.
--
Vilius Panevėžys
Elitnet
Eduardo Martins
1) I'm not sure we should remove the getConnection methods from the RA
SBB Interface, this allows SBBs, which have no high performance needs,
to do sync JDBC interactions. In summary it allows a model where the
RA is used to simply expose the managed Java datasource, independent
of how this is actually done in the underlying Java EE AS. Surely this
allows bad SBBs from exhausting the Connection pool so perhaps the RA
should have a config property indicating if these methods are "on" or
"off", and in restricted environments, where the SLEE admin does not
truly controls SBBs, it is configured as "off" and these methods
throws a SecurityException if invoked.
2) About exposing a task context, that provides also means to get a
connection, which is automatically closed once the task execution
completes, I think that is a must if we have a restricted setup as
defined in 1). Now does it make any sense to allow more than one
connection during the task execution?
3) With respect to Java transactions, I first thought of not exposing
the tx manager, instead the task would signal the RA that execution
would be under a tx, and would have a way to signal that the tx should
rollback, similar to the way SBBs indicate that through the sbb
context. My concern was then how commit failure or rollback feedback
would be provided to the SBB, we could again mimic what happens in the
sbb and provide an additional failure event (besides the execution
exception one) indicating such info, but it was not clear to me how
that feedback can be of any good, mainly because it would be the RA
giving the feedback, not the task, so I ended up deciding for full tx
manager control by the task, that is, it may build any event if it
fails to commit or decides to rollback during the logic execution. The
RA simply ensures that any open tx is closed after the task execution
(with a friendly commit() invocation). Anything to comment about this?
4) About removing the other execute methods in the JdbcActivity due to
Connection pool exhaustion again, I'm fine with it, but I don't like
the fact an app needs to have the burden of developing custom events
or even have to implement complete JdbcTasks for simple operations.
Simplicity in the RA usage is a must, so maybe we could have a
"simple" child package, including an abstract class of task and an
pre-installed event type, the task execution would return instead a
plain data Object as result, which would then be included in the
event...
-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco
2011/9/2 Carl-Magnus Björkell <nrgiz...@gmail.com>:
Eduardo Martins
2011/9/2 Vilius Panevėžys <vil...@elitnet.lt>:
> Hi,
> sorry for the delay from our side. However, it turns out to be a good thing
> as Carl has already outlined most of the concerns we have been thinking
> about as well. :)
>
> We would've suggested an even simpler approach: provide connection to
> JdbcTask.execute as parameter and close it (return to pool) right after task
> execution is complete (patch line 344). This way the connection would be
> returned to pool as soon as possible as well as avoiding possible deadlock
> as Carl has explained.
This is not straightforward as it seems, my first idea was to do that,
but connections may need user and password, so would need to pollute
the task impl with method(s) for the RA to retrieve these params. I
think the alternative of allowing the task to get it from an task
context is "cleaner", but the RA may have to deal with the complexity
of a bad task trying to get multiple connections... Carl and anyone
else in the community (feel free to participate in the discussion!)
what would be your preference?
> Overall, we think Eduardo's proposed implementation addresses the discussed
> needs well, making the JDBC RA suitable to be used as the universal DB
> access in Mobicents, which has been lacking for a long time.
>
> One additional feature that would be interesting to have is monitoring. I'm
> not currently familiar if JBoss Datasources have anything to that end, but
> what we have in mind is that as the JDBC RA is responsible for managing
> connections to a DB it would be great to check the actual DB accessibility
> periodically and raise a SLEE Alarm in case such a check fails. This way
> administrators could take action possibly even before actual queries start
> to fail filling up logs with exceptions.
Sounds good to me, but for a later revision once we settle for the
final 1.0 RA Type and impl. Multiple datasource load balancing could
be interesting too...
Carl-Magnus Björkell
On Sep 2, 3:26 pm, Eduardo Martins <emmart...@gmail.com> wrote:
> Welcome back Vilius ;) See inline.
>
> 2011/9/2 Vilius Panevėžys <vil...@elitnet.lt>:
>
> > Hi,
> > sorry for the delay from our side. However, it turns out to be a good thing
> > as Carl has already outlined most of the concerns we have been thinking
> > about as well. :)
>
> > We would've suggested an even simpler approach: provide connection to
> > JdbcTask.execute as parameter and close it (return to pool) right after task
> > execution is complete (patch line 344). This way the connection would be
> > returned to pool as soon as possible as well as avoiding possible deadlock
> > as Carl has explained.
>
> This is not straightforward as it seems, my first idea was to do that,
> but connections may need user and password, so would need to pollute
> the task impl with method(s) for the RA to retrieve these params. I
> think the alternative of allowing the task to get it from an task
> context is "cleaner", but the RA may have to deal with the complexity
> of a bad task trying to get multiple connections... Carl and anyone
> else in the community (feel free to participate in the discussion!)
> what would be your preference?
>
really clear, I tend to ramble when I write and think at the same
time :) ).
That is, in its simplest form, the change I proposed was to modify the
JdbcTask execute method to:
public JdbcTaskResult execute(Connection connection,
SleeTransactionManager txManager);
The RA would be in complete control over the connection, and close it
once the execute method has returned. The connection would never be
visible to the Sbb.
As for username/password in the connection: I haven't ever had the
need to do this configuration in the connection, but rather use
username/password configuration in the datasource definition itself.
So for me this was a no-issue, but I realize that this might be
something that others need. Either way I would always go for the
option where the control of the connection life-cycle is in the RA and
nowhere else. Maybe a "JdbcConnectionCredentials" class that would be
included in a getter in JdbcTask would be the cleanest solution for
this if credentials are required. (If the getter returns a credential
object, the RA would use these to fetch the connection. If it returns
null, no special username/password would be used).
Carl-Magnus Björkell
On Sep 2, 3:13 pm, Eduardo Martins <emmart...@gmail.com> wrote:
> Hi Carl, tks for the feedback. I think we are not far from an agreement:
>
> 1) I'm not sure we should remove the getConnection methods from the RA
> SBB Interface, this allows SBBs, which have no high performance needs,
> to do sync JDBC interactions. In summary it allows a model where the
> RA is used to simply expose the managed Java datasource, independent
> of how this is actually done in the underlying Java EE AS. Surely this
> allows bad SBBs from exhausting the Connection pool so perhaps the RA
> should have a config property indicating if these methods are "on" or
> "off", and in restricted environments, where the SLEE admin does not
> truly controls SBBs, it is configured as "off" and these methods
> throws a SecurityException if invoked.
>
router threads waiting for I/O on principle, but it does have its
place for simple systems with low performance requirements. On
principle I would still like to see it gone however, code complexity
will not be significantly higher for doing asynchronous calls.
> 2) About exposing a task context, that provides also means to get a
> connection, which is automatically closed once the task execution
> completes, I think that is a must if we have a restricted setup as
> defined in 1). Now does it make any sense to allow more than one
> connection during the task execution?
connection, but means of retrieving a connection that has already been
assigned to the task. In its simplest form, there isn't a need for a
context, but just to add the Connection object to the
JdbcTask.execute() method. (see the other reply above). I cannot think
of a reason why a task would need two connections.
> 3) With respect to Java transactions, I first thought of not exposing
> the tx manager, instead the task would signal the RA that execution
> would be under a tx, and would have a way to signal that the tx should
> rollback, similar to the way SBBs indicate that through the sbb
> context. My concern was then how commit failure or rollback feedback
> would be provided to the SBB, we could again mimic what happens in the
> sbb and provide an additional failure event (besides the execution
> exception one) indicating such info, but it was not clear to me how
> that feedback can be of any good, mainly because it would be the RA
> giving the feedback, not the task, so I ended up deciding for full tx
> manager control by the task, that is, it may build any event if it
> fails to commit or decides to rollback during the logic execution. The
> RA simply ensures that any open tx is closed after the task execution
> (with a friendly commit() invocation). Anything to comment about this?
nicely.
> 4) About removing the other execute methods in the JdbcActivity due to
> Connection pool exhaustion again, I'm fine with it, but I don't like
> the fact an app needs to have the burden of developing custom events
> or even have to implement complete JdbcTasks for simple operations.
> Simplicity in the RA usage is a must, so maybe we could have a
> "simple" child package, including an abstract class of task and an
> pre-installed event type, the task execution would return instead a
> plain data Object as result, which would then be included in the
> event...
>
also be done if we go down this route.
-Calle
--
Carl-Magnus Björkell
EmblaCom
> ..............................................http://emmartins.blogspot.comhttp://redhat.com/solutions/telco
>
>
> >> > >> > Hello everyone,
> >> > >> > as we all know databases are crucial resources...
>
> read more »
Vilius Panevėžys
user/password control, however, I can imagine it once Eduardo has mentioned
that, for example, in case some privilege elevation is needed. Although, I think
such scenarios should be rare and even in such cases a workaround could be to
define multiple datasources with the different credentials.
Respecting Eduardo's concern with making the implementation as universal as
possible, I agree that if some additional parameters are needed in the JdbcTask
(credentials or anything else that did not cross my mind yet) the cleanest way
to hand them over is to use a single holder object (task context) instead of
getting each param using a separate RA's getter. Talking about the credentials
in particular, I don't see that as a really attractive feature, but more
opinions might be useful.
Moreover, giving a context holder object to the task does not conflict with
assigning a particular connection to a particular task. The connection might
event be part of the context.
And yes, I would definitely vote for adding the multiple datasource load
balancing and seamless fail-over to the wish list. :)
--
Vilius Panevėžys
Elitnet
Eduardo Martins
http://code.google.com/p/mobicents/issues/detail?id=2825
Note that docs won't be updated till we settle on the Java code.
-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco
2011/9/2 Vilius Panevėžys <vil...@elitnet.lt>:
Carl-Magnus Björkell
I had actually started doing this same thing on Friday, but luckily I
had other things on my plate as well, so I didn't get very far. :)
Nothing worth commenting on caught my eye in the patch. Overall I
think this will be a really good generic interface for the DB.
Asynchronous, extensible, and then transaction and connection safety
stored away in the RA. Very nice work indeed!
I have nothing further, your honor. :)
-Calle
--
Carl-Magnus Björkell
EmblaCom
> Here we go, new patches in the issue. Summary of changes there too:
>
> http://code.google.com/p/mobicents/issues/detail?id=2825
>
> Note that docs won't be updated till we settle on the Java code.
>
> -- Eduardo
Vilius Panevėžys
It seems to me the API got simpler and yet more powerful: a lot of flexibility
but even minimized possibilities to do something stupid. I think this will bring
JDBC RA from a useful sample to a reusable component.
Right now I don't have any immediate propositions (apart from additional
interesting features mentioned in this thread), we'll have to build some real
world use cases off this API to find new ways to make it better. :)
And with regard to documenting, I think special attention will be needed to
explain how easy it is to do simple use cases (using the task.simple package) to
not make it look like JDBC RA lost functionality and advanced use cases like
transaction control.
Thanks a lot to Eduardo for great responsiveness and great code and Carl for
sharing your thoughts.
--
Vilius Panevėžys
Elitnet
Eduardo Martins
the patch, this new RA will go in 2.5 release, which is great cause it
is a candidate release ;)
-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco
2011/9/5 Vilius Panevėžys <vil...@elitnet.lt>:
Eduardo Martins
-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco