Last modified 11 years ago Last modified on 06/04/2008 01:14:09 PM

Use of Java in Middleware: the Event Monitor


This is a proposal to confirm the use of Java in middleware components used at the data management control level. Specifically, we propose to use Java to implement the Event Monitor component. While we are currently using a Java component in our middleware in the reuse of an existing technology (ActiveMQ as an Event Broker), the Event Monitor represents the first time we will create new code in Java.


We have previously identified Java as development language for use in building user interfaces and in data management control components where there is an opportunity to leverage existing Java-based middleware.


The Event Monitor is a general middleware component that operates at the data management control level, particularly as part of the Pipeline Manager component. A Pipeline Manager is responsible for configuring, launching, monitoring, and cleaning up a Pipeline but is not a part of a Pipeline. As a result, execution of just a pipeline will not require the use of the of Java.

Steve Pietrowicz and Ray Plante are interested in using Java to implement the Event Monitor for the following reasons:

  • There is a possibility for leveraging existing Java libraries in the future. Java tends to lead in terms of maturity and features in libraries related to loosely-coupled communication, including messaging (JMS), remote procedure calls, XML, and web services. There is no particular Java library we are interested in using at this time.
  • Steve is an experienced Java programmer
  • This component provides the opportunity to raise issues of the use of Java in our system

The last reason in the strongest motivator for this proposal.

Given that we have a python interface to the event system (and we do not have a particular Java library in mind that we need to reuse today), the Event Monitor could be readily implemented in Python.

Discussion: 04 June 2008 CCG telecon

There was a general concern about Java-implemented components would creep into the application layer. In general,

  • we want to minimize the number of developers who have to add Java to their list of languages they need to program in
  • If we find ourselves needing to re-implement an existing framework class in Java, that would be a sign that the component is to close to the application layer and is therefore not a good choice.

There was general agreement that the Event Monitor did qualify as a component that operates at the DM control level and is sufficiently isolated from the application layer.

It was recommended that a crisper policy be crafted to state when Java be adopted to implement a new component. That policy should include:

  • the constraints on the components role and functionality
  • that there be a specific existing Java library or technology to be leveraged.

We noted that this proposal fails the 2nd test above.


  1. Because of the lack of a specific Java library to be leveraged, we recommend that Java not be used to implement the Event Monitor.
  2. Ray was given the action to propose a more specific proposal governing the use of Java