GSoC

GSoC Projects and who is doing what:

Qpid Demo - two projects (one for AMQP 0-9 and one for AMQP 0-10)

Candidates: Senaka Fernando, Buddika Laknath

Project Goal: Create a multi language Demo for Qpid, and use the demo as source to create the Qpid getting Started pages

Mentor: Carl/Rajith

Project Description:

The Qpid project likes to have an enterprise grade demo that reflects the messaging capabilities of the AMQP (www.amqp.org) protocol that uses brokers written in Java and C++ and the clients written in Java/JMS, c++, python, ruby, .NET

The Demo ca use any client server problem (like bank, stock, render farm, travel site etc) to illustrate the capabilities of the Qpid.

AMQP mgmt Bridge - JMX / WS-DM

Rahul Mehta

Project Goal: Create a bridge between AMQP-JMX and WS-DM

Mentor: Arnaud , Carl, Rajith

Project Description:

Project is to create a process will receive management Data through the AMQP mgmt protocol and translate those into JMX and expose it over WS-DM. This will allow the C++ broker to also be hooked into a JMX / WS-DM and allow for all the instrumentation data to be read, all the methods to be invoked, and the configuration to be updated through standard consoles.

Note that all the schema is dynamic, so the bridge needs to configure itself at runtime, so this service should derive it's behavior from the schema provided to it.

The schema is sent on first connection to the broker, from this the bridge can get be created though a mapping from mgmt schema to JMX objects and then the objects sent via updated can be exposed over WS-DM or straight to JMX console

AMQP mgmt side protocol can be found here: http://cwiki.apache.org/qpid/management-design-notes.html

To play with it, build the C++ broker
./bootstrap
./configure
make

on linux, the to run the cmd line mgmt set the PYTHONPATH and run it from mgnt-tool

You should pretty quickly see how the objects get dynamically build and how they are layed out, these can then quite simple be dynamically mapped to JMX.

Implementation language is Java

JMX Cli

Candidates: Lahiru Gunathilaka, Ruchira Wageesha

Project Goal: Provide the ability to access Java Broker mgmt info from cmd line.

Secondary Goal: Integrate with AMQP mgnt protocol ??

Mentor: Adian/Marnie/Martin

Project Description:

Design and implement a simple solution, runnable from the command line, for extracting useful JMX information from the Qpid Java Broker. Solution should be configurable at runtime to allow users to decide which bits of info they're interested in and when. Might be nice to see the information extracted in a report format

More info:

Currently, the Qpid Java broker provides several JMX methods to all users/applications to extract information about queues etc on the broker. We have used this information for two purposes: exposing management details in the existing Eclipse RCP Management Console UI and also to provide alerting in the broker log when certain configurable thresholds are reached e.g. maximum queue size etc.

However, some of our users have expressed an interest in being able to extract JMX information more simply i.e. without the constraints our existing confgurable alerting brings with it and also independently of the UI.

Thus, an application which could be called from the command line on Windows, Unix (Solaris) and Linux would be invaluable for our user projects.

Ideally this CLI would expose all the JMX calls in a simple wrapper and perhaps allow the user to dump the results to an XML file or a web page.

This is not intended to be too heavily prescriptive and is really intended as a starter for ten !

Qpid-java-broker-config

Candidates: Sachith Danushka.

Project Goal: Rationalize the configuration in the Java Broker to get it more consistent

Mentor: Adian/Marnie/Martin

Project Description:

Refactor Qpid Java Broker configuration into a more elegant xml schema, with xsd, covering all existing configuration options and allowing for extension. Additionally implement a module to validate broker configuration files, which could be run standalone i.e. before starting a broker, to check that they're well formed and validate against the xsd.

More info:

Currently the broker configuration for the Qpid Java Broker is a little untidy. There's the bulk of the core broker configuration, much of which the majority of our end users won't want to change much, in the default config.xml files that we ship. On top of that we have a set of properties for the virtualhosts (which includes the ability to define per host some queues which will always exist on broker startup etc) in a separate file.

At the moment, if you edit the config.xml file you're using and accidentally damage or remove an important section the broker will blow up in an unexpected fashion. Creating an xsd and validating the config.xml at startup (probably as a switch on/off-able option !) would help to avoid this possibility.

We could also provide more information about what the config file contains in a self-documenting way. I'd suggest we need to restructure the config set up too - the virtualhosts file is at the very least badly named, but probably not really fit for purpose.

qpid-android-demo

Project Goal:
Implement a simple demo on Android using the Qpid client to send messages to and from a broker, such as stock price information and trade orders

Contact person: Aidan Skinner <aidan AT apache DOT org>

Project Description:

Android is hot, Qpid is hot, porting the Qpid client to Android and getting it to pull some information and publish some would be hot.

DBus over Qpid

Project Goal:
Implement an AMQP transport for DBus using Qpid.

Contact Person: Aidan Skinner <aidan AT apache DOT org>

Project Description:
Running DBus over AMQP would allow some interesting use cases, such as home automation, automatic synchronisation and the like, turning it into a true network bus.

You would need to be familiar with C, C++, Python or Java, and would ideally have experience working with disparate Free Software communities.

Apache Derby Datastore

Project Goal:
Implement a datastore backed by Hibernate or Apache Derby

Contact Person: Aidan Skinner <aidan AT apache DOT org>

Project Description:

Create a persistent datastore for Qpid that uses JDBC to connect to a database and which uses Apache Derby as a default backend. Bonus points for implementing it using hibernate so it's easily portable across different databases.

You would need to be familiar with Java, JDBC, Hibernate and SQL.