About |  Download |  Design |  How To |  javadoc |  Legal 

j-bus, what's that?

j-bus is a light-weight, fully-functional, ESB (Enterprise Service Bus) implementation which provides the bare essentials for HTTP-based software system interoperability. Though limited in terms of protocol support (HTTP), it is relatively powerful in terms of operational control, `tweakability`, and queue management. It is also 100% open source. It is free for anyone to use - see the legal section for more info.

This said, I do not fancy the term 'Enterprise' in describing this software, but rather prefer the more simple 'Service Bus' or 'Bus' denomination. I find this to be more fair in view of the single-protocol support that j-bus offers (HTTP, for now). I lean more towards the more simple 'Bus' description, insofar that j-bus is simple software-based analogy of the bus networking topology.


Today, a range of sophisticated ESB products exist. However, when I started writting j-bus back in the summer of 2006, this wasn't the case. If my memory serves me well, they were either commercial and expensive or open-source and hell to operate. I do remember well, however, that none of them met all of my requirements. These were:

- It had to be 100% open-source,
- It had to be free (to use),
- It had to offer both volatile and persistent (database-backed) queueing options - (with optional XML file-based queueing),
- It had to offer the possibility to keep a small memory footprint,
- It had to be very well documented or easy to use/deploy,
- It had to offer the hot-deployment of services (rather than having to compile/build/deploy for each), and
- It had to 'runnable' just like any another java application.

Content payload format was irrelevant to me, though XML and/or text-based content transfer constituted a acceptable option.

The difficulty of finding a single product which met all these requirements led me to take on the undertaking of building an application which met all these requirements by myself. This was quite convenient for me as it, in terms of timing, coincided with period in which I was tinkering with my thesis for MSc in Software Engineering.

This software product presented here, which I decided to name 'j-bus' (which, in my mind, came to stand for java (application) bus), is the materialization of the said undertaking. It meets all of my requirements. If it happens to meet yours too, download it!


Well, as with any other issue, there are usually a number of potential ways to address a problem. At the highest level, I decided that I would settle for two types of users:

- Admin Users, and
- Clients.

I decided to term the first 'System User', insofar that this type of user would be responsible for managing the operational parameters of the bus (system). Likewise, I decided to term the later 'Service User', insofar that interactive scope of this type of user would limited to consuming services exposed by the bus as a system.

Next, I decided that the bus 'system' would be composed of two layers/sub-systems - the:

- Services (layer/sub-system), and
- Queueing (layer/sub-system).

The first would act as an interface to the bus for both System and Service Users. The interactive experiece for each of the user types would depend on their role. For System Users it would be the setup and management of the bus as an application/service. For Service Users it would be that of using the service(s) exposed by the bus to route their content as defined by the specifics of the service being used. In view of the simplistic approach to protocol support - namely HTTP-only, a decision was made to implemented services in terms of Servlet templates. Four behaviours were defined:

- Store,
- Store and Forward,
- Store and Retrieve, and
- Forward.

Each of these behaviours would carry out exactly what their verb description specifies - i.e.: a store operation would store data, a forward operation would forward data, etc. Each, in turn, may, or may not, have implied the storage - be it temporary or permanent, of data during its transit through the system. Wherever this was the case, the Services sub-system would also be responsible for interacting with the Queueing sub-system of the bus. The Queueing sub-system, in turn, would allow for two types of queueing behaviour:

- Volatile Queueing, and
- Persistent Queueing.

The first would cater to the needs of transient data, the second to needs which were less tolerant to data loss. The second, in turn, would cater to a small variety of persistence schemes - namely:

- Oracle-based Persistent Storage,
- MySQL-based Persistent Storage, and

- File-based Persistent Storage.

A sophisticated mechanism of queueing would cater to allow for some fault tolerance where any of these persited mechanisms were specified, but in practice found to have become unavailable (for one reason or another).

Et cetera

j-bus was created 'by-design'. It has a relatively simple interface for the 'admin(istrative)' setup of client services. These in turn are available at the resource you specify (e.g.: http://www.the-j-bus-system.com/services/xyz). Requests are communicated to the bus in terms of an HTTP POST. All operations which do not involve a 'forward' or 'retrieve', place data in a defined storage location - effectively acting as a simple data storage mechanism. 'Retrieve' and 'Forward' operations involve an HTTP POST. In the first case, the retrieving party, submitting an HTTP POST to a specified resource, will retrieve the data stored. In the second case, the system will dispatch an HTTP POST of the inbound data to a defined resource - again via an HTTP POST.

The greater part of the application is the queueing and data dispatching/management components of the application. These are all discussed in my thesis. This is freely available for consulation here. The core of the discussion is organized as a requirements specification, a design, and an implementation. The requirements specify what the application is expected to do; the design discusses how it proposes to so; and a fraction of the implementation is presented in support of the requirements and design considerations.

A decent amount of the UML, and non, diagrams, illustrated in the thesis/dissertation document are reproduced in the Design section, available here.

  Disclaimer, Privacy, and Other relevant info