Sunday, 24 October 2010

Have fun with ARINC 661, XUL, Javascript, beanshell, and Java

Remember this post two years ago? Well you can also add Groovy to the list...

The Client-Server ARINC 661 framework project has been Open Sourced for 2 months now. You can get the binaries, and the sources here: http://j661.sourceforge.net/. Just a quick reminder: In the ARINC 661 standard, the Client (called User Application in the standard), handles the logic, and the Server performs the graphic rendering.

The communication protocol in ARINC 661 is specific and a bit complex (no SOAP, no REST, no CORBA, not RMI, but purely specific binary messages on top of the lower-level bus-level layer protocol). So to ease development of Java clients, the j661 project propose a generic API to handle this in the Client side.

The basic Client just allows users to send messages to the Server, but there is more than that. It is possible to script the Client behavior, and even to add a user interface for Client options (for example a Slider - called Scale in XUL, to change a value).

There are three parts which are necessary to script the Client:

  • The graphics part is rendered by one or several XUL script files

  • The controller is performed by Javascript (by using Rhino

  • The logic is performed by beanshell or Groovy



One cool side-effect of using XUL is that users are able to debug their scripts using Firefox.

How is it working? When clicking a button, or performing any user action on the XUL script, the associated XUL widget fire the appropriate JavaScript command (nothing special here). What begins to change a little is the fact that JavaScript is allowed to execute Beanshell or Groovy code, which in return can communicate with the Server using the ARINC 661 protocol.

Let's use an example (check the Scripting tutorial for the j661 project if you want more informations):


<button id="identifier" label="Hide Triangle" disabled="false"
oncommand="triangleHidden()" />


If the user click on the button, it will fire the triangleHidden() method on JavaScript. In this case, this method is directly written inside the XUL script (it could also have been defined in a external JavaScript file):

function triangleHidden() {
changeTriangleVisibility();
}

As there is no changeTriangleVisibility() method in JavaScript, it will look for a method with this name in Beanshell (in our case). The Beanshell script has been referenced in our XUL script in this way:

<script type="text/bsh" src="testScript2.bsh" />


And the Beanshell script contains the following code:

tatefullAPI api;
XULScriptContext ctx;
int LAYER_ID = 56;
int TRIANGLE_ID = 100;
boolean visible = true;
init(StatefullAPI theApi, XULScriptContext theCtx) {
api = theApi;
this.ctx = theCtx;
}
run() {
}
changeTriangleVisibility() {
visible = !visible;
api.setWidgetParameter(LAYER_ID, TRIANGLE_ID, ARINC661.A661_VISIBLE,
visible);
api.sendLayerMessage(LAYER_ID);
}


All of ARINC 661 messages can be handled like this.

1 comment:

MechAero said...

Thanks for this info,

I understand that scripting the client like this can use the GUI, but it does not have to, correct? I mean, it could just be a script with no interface, initially starting a process scripted in Groovy that would, say, communicate with a simulator to read and send data? Would there be any advantage to scripting it this way over simply using API mentioned in the post in a custom codebase?

Thanks,

Samuel.