Following on from my initial Blackboard SIS research I had a clearer idea of how to plumb it into my new Matrix Provisioning system which is based on ActiveMQ and Camel. The main problem I had was the lack of any status coming back from the SIS. You can send it what you like, even garbage and it replies with ‘OK’. Although the garbage ingestion is due to be fixed in SP9 or SP10 I think. The status won’t though. It will still return ‘OK’ even though the account wasn’t created. I had a chat with Behind the Blackboard and it’s fair to say that because it ingests feed files containing possibly thousands of users a single result isn’t suitable. It is in my case though as the users come in real time in JMS messages, one per message. So I decided to develop a small Building Block to wrap the SIS endpoint. The flow is shown in the diagram.

(more…)

In the first version of Matrix Provisioning the modules that handle the local systems such as Active Directory and Blackboard were responsible for dealing with messages they couldn’t process. For example if a message contained an invalid location code for an account then that account can’t be provisioned in Active Directory as the module doesn’t know where to create it in the tree. It’s a classic example of an error that’s not going to go away and it needs manual intervention to sort the bad location code. Either manually changing it in the message or deleting the message and issuing a new one with the correct location code. The module would persist the message to a database in this case and email someone to come and sort it but I’d rather keep the modules as simple and focussed as possible. More along the lines of the Single Responsibility Principle, although it’s quite a broad responsibility in that it creates/updates/deletes accounts in Active Directory based on messages coming from an ActiveMQ broker. What I’d rather do is allow the module to say to the broker ‘you’ve sent me a bum message, do something about it’ and forget about it. So I had a read of Enterprise Integration Patterns and decided to use the Invalid Message Channel. The flow is summarised in the diagram.

(more…)

I decided to implement SSL in MatrixClient to let messaging clients connect securely to an ActiveMQ broker and I got a bit lost in the various SSL errors that can happen so I thought I’d summarise the flow, which is shown in the diagram.

It all hangs on each end of the connection having its own keystore and truststore. The keystore is used for signing the request and the truststore is used for verifying the signed request. So for it all to work the client’s certificate must be in the broker’s truststore and the broker’s certificate must be in the client’s truststore. (more…)

Sometimes it’s easy to get carried away with annotations and when something doesn’t work you endlessly scratch your head. I’ve just extended MatrixClient to talk SSL to an ActiveMQ broker that wants client authentication and added the appropriate test:

public class MQClientTestSSL extends ClientTest ... {
  @Test
  public void test() {

but Maven wasn’t running the test. I could run it manually:

mvn test -Dtest=uk.ac.uhi.it.matrix.client.MQClientTestSSL

but mvn clean install didn’t run the test. According to the surefire documentation it’s meant to run tests with a pattern ‘Test*.java’ but it clearly wasn’t. The only way to get the test to run was to rename it:

public class MQClientSSLTest extends ClientTest ... {

and Maven then picked it up and ran it.

This was a seriously obscure bug it turned out. It was so obscure I turned to stackoverflow to ask about it. I’ve written a C# assembly that wraps the Apache NMS library to provide applications with messaging functionality and the NUnit tests for the DLL run fine but when I tried using the DLL from the main Windows Service that I’m working on the connection to the broker always failed. And to boot, the exception info was not helpful:

Error in the application

(more…)

So I started getting this error when connecting to an ActiveMQ broker as a consumer and producer from the same machine:

“the connection is already closed!”

which occurred when I tried to set the clientID on the producer, having already set up the consumer. Turned out I was using the same clientID for the consumer and the producer!

Time for a blog post methinks and good timing too as I’ve recently updated the Matrix provisioning system to support Invalid Message Channels in its routing engine. An invalid message is any message that can’t be processed for whatever reason including if the target system is down. This turns out to be quite convenient as the messages can be rerouted to the target topics when the system is back up.

(more…)

I’ve been working on a messaging system using Apache ActiveMQ embedded in Apache Camel, exposing JMS and Stomp topics that applications can use to provision themselves. As it’s basically a view of digital reality in how it relates to account creation, I decided to call it The Matrix. I’ve already plugged ActiveDirectory into it using GADfly and now Blackboard has a Head Plug. It’s a Building Block I developed that pulls from its own topic in The Matrix and the control page is Shibboleth enabled using Guanxi. Access is determined by the value of your urn:mace:dir:attribute-def:eduPersonEntitlement attribute. The control page lets you start and stop the topic consumer as well as troubleshoot and get diagnostic reports, once I’ve done that bit.

It’s nice to see the original concept coming together. Shibboleth, Messaging, Provisioning and a plethora of programming languages. It’s been a real journey to get this point, plugging two high profile systems into The Matrix.

I’ve ported the C++ STOMP code to C# with just a little problem, in that the STOMP support in ActiveMQ NMS doesn’t work. No to worry, the default protocol does. The first thing you need is ActiveMQ NMS (.NET Messaging). I used the 1.1.0 source release downloaded from here. You’ll also need nant to build it. Unzip nms-1.1.0 to NMS_SRC_HOME and make a quick change to nant-common.xml otherwise you’ll get this error:

Unknown function 'platform::is-windows()' (more...)

Worried about what clients are consuming messages on your broker? Implement a MessageAuthorizationPolicy. Add it to your camel-config:

<broker useJmx="true" persistent="false"
    xmlns="http://activemq.apache.org/schema/core">
  <messageAuthorizationPolicy>
    <bean class="org.funnyfarm.security.MessageGuard"
        xmlns="http://www.springframework.org/schema/beans"/>
  </messageAuthorizationPolicy>

  <transportConnectors>
    <transportConnector uri="tcp://localhost:61616" />
    <transportConnector name="stomp" uri="stomp://localhost:61613"/>
  </transportConnectors>
</broker> (more...)