codeBeamer has a long history of providing extension- and customization points, most importantly a web service based Remote API and a Listener API. Reactions from the developer community have always been very positive, but a question we regular hear from them is: "Look, I want to listen to codeBeamer events. I know this is perfectly possible in the same JVM where CB runs, but now I need to do this in an external application. How can I receive notifications in external applications?"
Well, until now, this was not possible: events were not published outside CB’s own JVM.
To satisfy this popular request, recently we developed a Java Message Service (JMS) publisher component. After you have configured and activated the JMS publisher, CodeBeamer will send a standard JMS message to a configurable topic each time an internal event is fired. External applications can subscribe to these topics, and then they will get notified about every interesting event. Please note that this pub-sub model and messaging in general are standard and proven techniques in Enterprise Application Integration. Just Google it for more information.
Internal events that are published as JSM messages include:
- wiki pages: created, updated or read
- issues: submitted, edited or commented
- documents: uploaded, edited or opened
- forum posts: submitted or edited
Comparison between the Listener API and the new messaging based approach:
| Messaging | Using the Listener API | |
|---|---|---|
| Coupling | Louse. | Tight. |
| JVM | CB and the listener can run in separete JVMs. | CB and the listener must run in the same JVM. |
| Development Ease | Make sure your Message Provider is up and running. Configure CB to be able to publish to it. Configure your app to subscribe it. Afterwards, you don’t have to touch CB anymore, you can focus on your app. | Implement the interfaces, deploy the implementation classes to the classpath, and restart CB or configure auto-reload to pick up your changes every time. |
| Deployment | Any time. This is completely transparent for CB. | CB (and its JVM) must be restarted. Alternatively, classes can be auto-reloaded, but this is discouraged for production systems. |
| Stability & Scalability | External apps run in their own JVM. They can perform expensive operations, consume any resources, or crash, and CB is not affected. | Expensive operations or a large number of listeners can slow CB down. Internal listeners are inherently synchronous. |
We believe this can open up a myriad of great opportunities for integration. You can start developing desktop apps, realtime apps, and start to solve any kind of event driven integration problems now.
