From Bodington Wiki

Jump to: navigation, search

Back to TReCX



There are various kinds of technologies being included for review. Web Services will be required as the lingua franca between module deployments. There are standards related to calendaring, which is useful for outputting reporting data in formats that users are familiar with. Other kinds of tools such as JUnit and Ant are generic tools that are good practice to utilize in any Java project.

Statement from bid document

Wherever possible, we will use and/or investigate the following standards: HTTP; XML; J2EE; iCalendar (output), WS-Notification, WS-Eventing, WS-Addressing (tracking); IMS Abstract Framework, WS-RM, ebXML (messaging); BPEL (orchestration); Junit, HTTPUnit, XMLUnit (testing); UML1 (documentation); cruisecontrol, ANT (install and deploy) , IMS General Web Services, WS-I Basic Profile, WSDL, AXIS (& WSDD) (service description and deployment); Shibboleth (for authentication and authorisation of end user applications). We will also look at all available tools interoperability standards such as IMS TI and LAMS TI.

Web Services

WS-Eventing and WS-Notifications by Matthew

These are two specs for doing pretty much the same thing.

You have something that produces events, for example with a light switch, the events might be light switched on, light switched off. With these specs other systems like the coffee maker (consumers) can register with the producer to receive events when something happens. An example use might be that when the coffee machine starts up it registers with the light switch to receive "on" events. Then when the light switch it turned on it sends an "on" event to the coffee machine so it brews some coffee. The light switch and the coffee machine would have to agree on a message format but the specs define how the registration works and what the outline of the events looks like.

The producer looks after the list of consumers that want to be notified of events and when registration happens the consumer tells the producer where events should be sent to.

Neither of these specs specify anything about what is in the contents of the notifications.

They are similar to event listeners from the Java GUI world.

Both the specs came out around 2004:

ebXML and WS-RM by Selwyn

We have some recent experience of building reliable messaging framework services using SOAP, axis and ebxml.

We also tried to embed some message tracking within a distributed network so that we could provide a management interface which showed the journey a SOAP message followed and the processes it went through from agent to hub, hub to db, hub to other agent plus the varios acks.

At the beginning of 2005 we hoped to look at WSRM as an alternative to SUN's ebxml so that ioNode's could conform to both standards when it came to SOAP messaging.

In the summer we prototype ioAtom this is just our memorable name for a newer and simpler relaible messaging framework which we use for moving xml files reliable and securely from A to B etc we are planning to port this to a java / tomcat application.

We also hope to refactor ioNode to strip out just the ebxml based relaible messaging and the code name for this piece is ioNodeMX.

If our code or experience is of any use then it would be good to work with you.

Anyhow if you want standards look at ebxml and wsrm

RSS / Atom

It has been suggested that we use Atom as the messaging transport protocol.

WS-Callback by Alistair and Peter C

What about a WS-CallBack system where an app, say bodington, registers with another app, say mvnforum to be notified of certain event types. That way bod doesn't need to continually poll mvnforum, it will be notified instead.

So you'd need middleware to link them - something that can be written to and then broadcasts that event to all registered listeners.

IMS Tools Interoperability

IMS Global Learning Consortium, Inc. has released the IMS Tool Interoperability v1 Guidelines Public Draft at

The IMS Tools Interoperability (TI) approach addresses the growing demand for a reusable mechanism for integrating third-party tools with core LMS platforms. Tools can add specialist functionality to the LMS such as assessment or discipline-specific teaching aids. The approach recommended greatly simplifies this task whilst also offering a Web Services solution equally applicable to Java and .Net implementers. The reuse of a commonly understood approach across tools will eliminate the need for bilateral solutions, thus focusing investment on adding real value to the learner experience.

Public comments and questions are encouraged and should be posted to the public forum located at by December 31, 2005.


We spoke to Warwick Bailey at the kick off meeting about BPEL.

He says that Rob Sheratt at Hull has experience with BPEL. They have a repository projhect which is using this technology. They are looking at a vertical slice: User Interface - Spring - BPEL - User Interface.

He says look at Active Endpoints. They have an academic program and have a visual design tool which is great. There is also a virtual training calss.

There is also an open source BPEL server which may be of interest.


OK since you seem to have been funded why not take control of our design work, and make use of us in a continued design process, we were in the middle of factoring out an improved messaging element anyhow for what we have dubbed ioNodeMX.

You might also consider ioAtom which is way beyond the design phase and due for iminent release anyhow.

Of course there are fundamental questions which some UCA would unearth as to why you are doing messaging anyhow.

Summary of the pros of working with Phosphorix / ioNode stuff

  • direct support from the developers / architects
  • developers willing to share experience and explain the various messaging mechanisms ioNodes can use on the ioNetwork - when and why we use different models
  • extend the bodington developer community with some Phosphorix developers
  • iminent release of two new simple to extend reliable messaging products which are independent of the ioNetwork
  • not reinventing the wheel
  • stop competing with us - is this what JISC funded open source community is coming to?

Summary of the cons [in your context] of working with Phosphorix / ioNode stuff

  • the ioNode your thinking of is really a multi instituional network solution which relies on their being more than one node and other elements of an ioNetwork such as lifelong learner record database - for that reason we are well into a ruthless refactoring of the code
  • to get the old solution working quickly you have to build an ioNode server
  • relies on tomcat and axis - old code
  • documentation of the old code needs improvement
  • the old code is likely to be ditched

Actually we have looked at numerous other reliable messaging solutions, in the context of the kind of VPN ioNetwork provides, SMTP is untouchable imho.

In an ioNetwork VPN we have tried and proven reliable messaging logic for

  • SOAP
  • SOAPwa
  • SCP
  • SMTP

One of the challenges we have set ourselves is reliable messaging issues outside of 'the ioNetwork' i.e. without a dedicated secure network and to deal with some of the cons... people can stick messaging components on their own servers / work stations...

We had decided to redevelop the SOAP and SCP with the following criteria

  • easy to extend with business processes / messaging rules sequencing
  • easy to secure with ssl
  • easy to install with the minimum of installation procedure

and thus far we have

  • ioAtom [reliable, traceable SCP messaging service] in alpha testing going through release steps
  • ioNodeMX in design phase [reliable, traceable SOAP messaging]

We are considering, researching and investigating many other open source messaging frameworks for ioNodeMX including the ones mentioned below and many others...

Is there any point you doing this work aswell or should we hand over our design to you? Or better still and I think Adam's point we can colaborate.

Application Servers

ActiveMQ and JORAM

Brian: JORAM, or ActiveMQ, both seem to me like first-rate candidates. The specs on both are v impressive - ActiveMQ drops into Axis, for example, to provide reliable messaging, can be configured using Spring.

Service Mix

Brian: I wonder if you have considered ServiceMix for TReCX? It would sit nicely in Bods and also as a lightweight component out in the field. It would help do a lot of the plumbing for you (WS-Notification, BPEL, SAAJ, for example).

It's a JBI container which is essentially a protocol adapter and is stuffed with lots of message transformation capabilities.

I think it might fit in well with the SOCKET project, too: SOCKET, PLUG and ADAPTER, in fact. From a SOCKET point of view I can see it being useful initially for handling the recalcitrant document literal messages using SAAJ.

Now, there's just one little thing - they bill themselves as an ESB, but remember that's just a way of doing things. It's a JBI container. JBI is going to get huge in the WS space and it might serve as a good point of contact between many of the ELF projects

Aspect-oriented programming

The use of aspect-oriented programming is being considered for use in this project specifically for the purposes of adding tracking behaviour to e-Learning tools which currently do not have it. The situation is that each time someone does something like, for example, successfully submit a post to a message board you may wish to interface with the tracking API so that this event enters the tracking system. Thus an obvious possibility is that you end up with the codebase (which you probably did not originally author) being peppered with little changes in lots of different places. AOP calls this tangle and scatter. What's possible with AOP is that you can define when you want some code to run (called advice) through the use of what are called joinpoints and pointcuts. In principle with AOP you can take the codebase for an application (unmodified) and through the use of aspects can create code that will be weaved into the original application in order to add behaviour that it didn't previously have. An IDE environment such as AJDT shows you clearly via the use of markers in the code, where pieces of advice will run and enables you to click through to the advice to see what it will do. (Advice is just standard code).

There are 2 closely related projects hosted at Eclipse. AspectJ is an implementation of aspect-oriented programming for the Java language and consists of the core libraries plus tools such as a GUI browser. The AJDT project is solely concerned with taking AspectJ and implementing it as a plugin for the Eclipse IDE.

Back to TReCX