SOCKET

Writing new tools for Bodington

2006-06-04T11:57:25+01:00

I've written a couple of tools for Bodington - the Peer Marker and the SOCKET Link. I thought it might be useful to document how this is done because as far as I'm aware it is not documented anywhere else. The easiest way to write a new tool is to download the latest Bodington code from Sourceforge and copy/edit the code for an existing tool. Each tool has the following components:

A unique tool ID number.

A tool class that extends org.bodington.server.resources.Resource. This class contains get/set methods for the tool's properties and also methods that allow the tool object to be retrieved from the database using various keys.

A session interface that extends org.bodington.server.BuildingSession. This interface specifies methods that represent a user's session with a specific tool.

A session class that implements the session interface.

A facility class that extends org.bodington.servlet.facilities.Facility. This class implements the user interface using the tool's templates. All input/output code is confined to this class.

An SQL script that is used to create the table and fields needed to store persistent information about the tool.

A set of resources that contain the localised strings for the code and templates

A set of HTML and/or XHTML templates containing tags which will be replaced by interactive content generated by the methods in the facility class. The SQL script is written in the dialect of Microsoft SQL Server. It will be automatically translated into the dialect of other supported database manager products if necessary. In addition to creating the tool's table, it must register the tool's ID, table name and tool class by recording them in the Bodington CLASSES table. It must also record in the Bodington FIELDS table, the name of each field in the tool class that is to be recorded in the database, together with the names of its get/set methods and the types that the methods expect/return. Be VERY careful about specifying the primary key. This is one of the fields in the FIELDS table. Get it wrong and you will produce a bug that is almost impossible to debug. (I speak from bitter experience.) Having written the classes, interface, SQL script, resources and templates, you then need to integrate them into Bodington. This is done as follows:

tables_sql_in_order

Add the tool ID to the list at the beginning of Resource.java

Add the tool ID to the list in the method Resource.mapHttpFacilityNoToResourceType()

Add the tool ID to the list in the method Resource.getResourceTypeName()

Add the tool's nickname to the comma-separated list in bodington-defaults.properties. The nickname should be the same as the name of the directory containing the tool's templates.

Add an entry to bodington-defaults.properties of the form: bodington.facility.<tool nickname> = <tool facility class>

Add an entry to org.bodington.server.resources.ResourceTypeNames.properties

Create create_tool.html and confirmcreate_tool.html templates in the style_default/default directory

Add a section to the creationmenu.html in the appropriate template directories so that the option to create your tool appears in the list of tools. Now recompile Bodington and test your tool. (It is probably best to generate a quickstart war for this testing process.)

The Bodington VLE does SOCKET

2006-06-03T09:10:19+01:00

There is now a Bodington tool for putting links to SOCKET services onto Bodington resource pages. Basically, it's a modified quick link that takes its title, description and URL from the SocketService selected from the list of services provided by the SocketJuddiToolkit. In due course this will be contributed to the Bodington CVS on Sourceforge.

The SOCKET Admin Console

2006-04-12T14:45:18+01:00

As the time approaches for the first deft incisions to be made into the corpus of the Bodington codebase some consideration has had to be given to the administration interface that will control the SOCKET processes. The mockup below is our first draft. Explaining the various features in the interface is also an excellent way of describing the essence of the SOCKET project.

[The right-hand frame (RHF) will be a tabbed pane interface, and I think we'll use JSF for this.]

The left-hand frame (LHF) displays what is called the SOCKET service status table. It displays the status of the SOCKET services in tabular format.

The Add Service button initiates the first stage in the SOCKET service lifecycle. This opens a file chooser that is used to select a WSDL file. On selection, the WSDL file is saved in the SOCKET file system and a new entry is added to the SOCKET jUDDI service registry. A new row appears in the status table. (Mark II will use JAXR to be able to go to other registries for WSDL information, but caw canny the noo.)

The rows in the status table are live: clicking a row focuses all the options in the RHF onto the selected service.

The right-hand column in the status table is colour coded. The initial colour is white, indicating that the service WSDL has been imported into the SOCKET system but has not been processed. The WSDL file can now be inspected using the first tab on the RHF. Initially this will simply be a scrolling text area, but there is lots of scope for JSF here.

A yellow colour in the status table might indicate that the WSDL has been socketized and a war file created consisting of the service client, the Guanxi security guard and any view layer appurtenances.

Green might be the next stage where the service has been made available to the Bodington vle.

A red colour might indicate that rare bird, a SOCKET fault.

The service consumer factory menu - the SOCKET engine room - is controlled from the SOCKET Functions menu. There'll be a "Socketize" button, fault info, and other output options.

The service summary will present a list of the WSDL operations and messages.

The Invoke menu will allow pre-testing of socketized functions.

Finally, the jUDDI menu. Most of the interactions with the jUDDI registry will take place in the background, but it will be handy to have naked access to the jUDDI console.

Bodington will communicate with the SOCKET registry to discover the list of available services.

The status of the services will be governed by a simple custom UDDI tModel.

This is, to repeat, simply a first draft, but I shouldn't imagine the final effort being too far away (it'll be a lot purtier, for sure).