On Oct 27, 2014, at 9:23 PM, David Schlenk <david.schl...@spanlink.com> wrote:
> Should I just forget about the JMS northbounder then, and call this > one something like eip-northbounder, camel-northbounder, something > like that? My personal opinion is that if you already have the work completed and would like to make the contribution, I would love to have the feature. I agree with Matt in that, *all* things messaging in OpenNMS would be better served if written in Camel. However, I can see that it is a learning curve and a complete change in the way of thinking about how to approach something like this. When I wrote the SyslogNorthbounder implementation, I was under the gun to get a feature into the product for a customer and we already had the Northbounder API from a previous project so I was able to implement it PDQ. The SyslogNorthbounder is functioning in an 8K node installation without issue since, so I’m pretty happy with it from that perspective. Caveat, Seth recently wrote a simple Event forwarder for yet another customer that does use Camel and forwards a small set of events from one OpenNMS to another via JMS using AMQ. While this code didn’t make it into the mainstream, yet, I would imagine that it would be a good example of what Matt is asking you to do. The reasons for these different methods is due to these being 2 different use cases. Seth’s requirement was a “simple distributed OpenNMS implementation” where the Northbounder is supposed to become a full Alarm Integration API. An Alarm API is much is actually much different than forwarding Events within a NMS environment. Alarm APIs have an integration centric use case vs. simple forwarding of item potent events within a framework. The Alarm APIs, which I would like to achieve in the NorthBounder Interface, typically do nothing until a request is made from an endpoint at runtime. At this point, the request should be persisted in configuration so that the API knows to continue where it left off if there is a system restart or failure. Typically, these APIs are defined in a manner to have the destination (endpoint) request all current Alarms and immediately subscribe for all subsequent new alarms and alarm state changes. Look forward to your thoughts on this, David. David Hustace ------------------------------------------------------------------------------ _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
