SOCKET

The SOCKET Admin Console

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).

Posted at 02:45PM Apr 12, 2006 by Brian Peter Clark in Bodington  |