SOCKET

Sumer is acumen in..

2008-05-06T18:04:20+01:00

..and so is the next release of SOCKET. The Java commission has been completed and the amended Rose SOCKET factory now handles infinitely nested datatypes as well as attachments. Thanks to Atif Suleman who carried out the coding. The task was made significantly easier by using some classes from the Spring codebase. I suspect that this might have saved us a couple of weeks during the original project. Shoot the architect!

The new code is now in HEAD in our SourceForge CVS repository. After some prettying up of the XSLT and CSS style sheets I think that we will be ready to take SOCKET out of beta. (Just when the fashion turns to "permanent beta" we emerge from this state. Had to do it.)

Once the stylesheets are fit for looking at (the garish orange is a bit much, I'm told) I think we'll put up a couple of animated screen captures on what SOCKET can do now.

Even as the capabilities of IDEs such as NetBeans and Eclipse make the creation of Java clients for Web services the matter of literally a couple of button clicks, SOCKET has still got its nose in front with a paste-and-click generation of a Web app client for a Web service. As someone that is constantly sniffing around and testing Web services, SOCKET must have saved me hundreds of hours in the last year or so.

The SOCKET Roadmap

2007-08-12T12:46:13+01:00

Some new development work on SOCKET has just commenced to modify the Rose factory so that it will be able to deal with nested complex datatypes in the WSDL. It will also be able to handle file attachments. These additions will greatly increase the range of services that SOCKET will be able to process. The work is scheduled to be completed mid-September.

Completion of this work will signal the start of more development. Firstly, Java Management Extensions (JMX) instrumentation will be added to the SOCKET client in order to provide a monitoring and configuration interface. Service performance metrics will be available to a management application.

Also, users will be able to customise operation and parameter names in the stylesheets, again through a management application.

Having the JMX agent incorporated into the SOCKET client is an important addition in that it will eventually help integration into a SOLA and will also enable configuration of Shibboleth/Guanxi protection of the application.

The final item on the medium distance SOCKET roadmap is to replace the homegrown XSLT handling by the excellent Cocoon framework. This should lead a lot more functionality and flexibility in the view layer.

SOCKET Case Studies

2006-12-11T22:00:45+00:00

A new Case Studies page has been added to the SOCKET web site.

The first case study describes how it took no time at all for SOCKET and NetBeans to knock up a Protein Sequence Repository service that facilitates group work in a bioinformatics activity.

Job's a...

How to Build a Hinjun

2006-11-02T14:28:49+00:00

How to build a SOCKET engine, that is. The SOCKET engine depends on one or more consumer factories. Presently there is one sole factory, codenamed Rose, which itself has a dependency on an XSLT view factory. In order to build the SOCKET engine, therefore, three projects are involved.

Firstly, check out the three projects from sourceforge, http://sourceforge.net/projects/socket. The top directories of the three projects should lie in the same directory for minimal configuration duties. You will need ant to build the projects. If you are using an IDE, ant will normally be included. I am using ant 1.6.5.

1. Check out 'socket-engine' as a project named 'socket-engine'.
2. Check out 'rose-imp' in socket-consumer-factory as a project named 'rose'.
3. Check out 'socket-view' as a project named 'socket-view'.

4. Build socket view: right-click build.xml in an IDE and run the 'all' target.

5. In the rose directory, copy the sample.build.properties into the file build.properties. If the socket-view project is not on the same directory level as rose, then this file should be edited accordingly.
6. Build rose by right-clicking build.xml and choosing the 'all' target.

7. In the socket-engine directory, copy the sample.build.properties into the file build.properties. If the rose project is not on the same directory level as socket-engine, then this file should be edited accordingly.
8. Build socket-engine by right-clicking build.xml and choosing the 'all' target.

You have now built the hinjun socket-engine.war which you will find in the build/wars directory.

Drop the WAR into your friendly neighbourhood Tomcat (5.5.x) and point your SOCKET clients to http://www.myserver.ac.uk/socket-engine/engine/http

Lost Property

2006-09-03T14:46:05+01:00

You live and blinkin learn. I must have used properties files and ResourceBundles a thousand times. The trouble is - it was always in applets. You just fiddle around in JBuilder and eventually find somewhere to put it so that applet.properties ends up in the jar on the classpath.

For the first time I've just tried to use a ResourceBundle and properties file in a servlet. Well, could I get the darned program to pick up the properties file. I was sure that I was doing everything all right. There was a fully qualified path name to a location on the class path:

ResourceBundle rb = ResourceBundle.getBundle("path.to.my.properties.file");

I left out the .properties, like you're supposed to.

I put the thing everywhere, I put it in the hall, I hung it on the wall, but always the MissingResource Exception. All variations of naming conventions were tried.

As ever, you start thinking of corrupted jars at this point in the proceedings when you think that you've tried everything.

Then the tiniest of lights flickered in the noggin: servlets - classloaders - different classloaders - different datatypes...

Sure enough, a look at the Java specs revealed the presence of the following constructor method:

getBundle(String path, Locale locale, Classloader cl)

This sorted it all out:

getBundle("path.to.my.properties.file", Locale.getDefault(), getClass().getClassLoader())

I'm a chemist, ye know.

1 Registry Good, 2 Registries Better

2006-08-22T19:39:08+01:00

Even though the subject matter is registries, this blog is filed under general rather than UDDI. It looks further afield than UDDI and a step beyond SOCKET to what might come after. To the team, SOCKET has always been regarded as an exploratory first step in the progression to a full-blooded Service-Oriented Virtual Learning Environment (SOVLE).
I cast my mind back to The Godfather when Tom Hagen was replaced as the consigliere to Don Corleone. Tom Hagen was a great peace time consigliere, but no good for war time. UDDI is a fine peace time Web services registry, but will not do for the bloody struggle that is runtime. A dynamic SOVLE in which services and components are being constantly deployed, undeployed, configured, reconfigured and monitored is too much of a war zone for UDDI. There is too much fine-grained and dynamic grape-shot flying around to be serviced by SOAP messages shuttling back and forth to the gentle jUDDI. So who is the Michael Corleone of the registry world? Who can save the SOVLE from runtime confusion and defeat? Jimmy X is his name, MBeanServer is his game. The MBeanServer is a runtime Java registry for Managed Beans, or MBeans. Each MBean is associated with a managed resource. In the SOVLE this will be a Web application or a Web service. These MBeans can carry out the full range of management functions: deployment, installation, control and monitoring. The pairing of an MBean with a SOVLE resource creates the basis of a comprehensive plugin architecture. Every resource, including access control and group management, plugs into the MBeanServer registry through its associated MBean.
Although jUDDI has been retired, she still has important words of advice to give to Jimmy X. Which services are dependent on which others? What might a good bootup strategy be? Which services and components are fit to join Jimmy X?
On their own, Jimmy and jUDDI don't have the power to support a SOVLE.. together they can take on the world.

Saturn and Pluto

2006-08-14T17:47:42+01:00

Atif has just finished off two clients for the SOCKET engine, a command line tool, codenamed "Pluto", and a Web application, named "Saturn". A screenshot of Saturn is given below.

Credit: The Hubble Heritage Team (AURA/STScI/NASA).

One inputs the absolute URL of the WSDL document and, on submission of the form, a download link is returned for the service consumer war file.

A screen shot of Pluto in action is given below:

The sprint to the line is now on with the major remaining tasks, the most important being the handling of complex types. The grunt work has been done for this: essentially the job is to unravel a JavaBean to simple types where the existing SOCKET code can take over.

SOCKET Demo

2006-08-10T15:04:46+01:00

There is a socketized Bods demo at:

http://socket.leeds.ac.uk/bodington/site/

Interested parties are welcome to use the guest account:

username: guest
pw: guest1

The SOCKET links lead to the QMShibb sub-project and the main
sub-project. The QMShibb page has shibbed links to a
QuestionMark Perception test, a list of tests and the admin app (to
which 'guest' will not have access).

We have put up 2 SOCKET web services and a 'SOCKET web
application'. (The create SOCKET service tool will not be visible to a
guest user.)

The web service producers are on an external server, while the
consumer apps are in socket.leeds.ac.uk along with the bodington
instance.

Chemical Elements

This is one of our test services. The stylesheets are development
versions - we are making no claims that these are fit for teaching
purposes.

Jabber

We have plugged in a Jabber applet which is served out from a remote server in a jsp. (The Jabber server uses an
embedded Hypersonic. Wouldn't want any conflict with
QuickBods.)

I simply chose what looked like the simplest Jabber applet around:
e4Applet 1.1.1

You can sign on with Jabber account:

username: guest01
password: socket01

You can join the following room:

socket@conference.webforwireless.co.uk

No pw required.

SSRun

Although we will sign off with the ability to handle complex data
types, the present socket engine handles simple datatypes only -
strings, ints, floats, doubles, booleans, dates. (Client-side js
validation comes as standard.) However, we have set up the
JISC/Icodeon ASSIS/SSRun web service and passed the wsdl
through the engine. The test data has not been loaded into the
Web service and there are complex data types so the service is
not functional, but this gives a basic impression of what the final
turnkey product will do. As with Chemical Elements, there has
been absolutely no tinkering with the Java, only some stylesheet
tweaks (I added a fetching orange/yellow gradient fill to SSRun, for
example). Two extremely valuable operations are working, though: ping and
createRunId, proving that the service is live.

We will be putting up a SOCKET development release soon, with
perhaps a couple more over the next few weeks leading up to 1.0:
simple types; arrays; complex types included.

For further information: email me, sign into Jabber Bods and I'll be
clayton ( or Brian: b.p.clark at leeds dot ac dot uk )

Location, Location, Location and JAXP

2006-07-30T06:31:40+01:00

Still on the XSLT theme. The XSLT transformed output contains urls for the hyperlinks, images and stylesheets. To get relative urls to work the same in different browsers after responses are made up on the fly, dispatched and filtered is impossible. Set Content Base header doesn't work.
JAXP comes to the rescue here by allowing us to inject an absolute url into the transform object:

tf = TransformerFactory.newInstance();
xform = tf.newTransformer(new StreamSource(ctx.getResourceAsStream(xslt)));
xform.setParameter("absolute_url", absoluteUrl);

The XSL transformation picks up this value as a parameter:

<xsl:param name="absolute_url" select="'http://default'"/>

The absolute url can be picked up on the fly with something like:

StringBuffer absoluteUrl = new StringBuffer("http://");
String serverName = request.getServerName();
absoluteUrl.append(serverName);
int serverPort = request.getServerPort();
if (serverPort > 0 && serverPort != 80)
{
absoluteUrl.append(":" + serverPort);
}
String contextName = request.getContextPath();
absoluteUrl.append(contextName + "/");

Job's a...

XSLT, Servlet Filter and a Squeak on Browser Reload

2006-07-30T06:12:59+01:00

The SOCKET view layer uses XSLT in a servlet filter to transform XML content to HTML for the browser.
Everything worked fine - until, that is, one clicked the refresh button on the browser when the thing squeaked about a premature end to the file that was being transformed.
The problem went away with Cache-Control = no-store, Pragma = no-store, and Expires = a long time ago set on the response headers. (Firefox doesn't work with 'no-cache' instead of 'no-store', IE is indifferent.) Not quite, though. When the university proxy server was switched on through the browser LAN settings, again the refresh failed.
I've only just stumbled upon an explanation of what's going on in Eric Burke's book, Java & XSLT, out of O'Reilly. Even the expert said that it was a difficult one to track down.
The error arises from the fact that in certain circumstances Tomcat re-uses the same HttpServletResponse object. One of these circumstances is the browser reload. Burke states that the servlet specs are not definitive on this point so that implementation dependent behaviour will be observed. We haven't tested on anything other than Tomcat 5 and 5.5, while Burke referred to version 4.
And so, the problem is finally laid to rest. It put up a good fight. The solution is to test for a zero or null output byte array from the ByteArrayPrintWriter, and, if positive, send back the original unwrapped response with

chain.doFilter(request, response);
return;

instead of the

chain.doFilter(request, wrappedResponse);

which results in the squeak. Job's a good 'un.

Punch in jUDDI

2006-07-09T06:16:06+01:00

This is a brief description of how to set up UDDI4J to communicate with a UDDI registry.

In version 2, UDDI4J brought in a pluggable transport layer that can be set to Apache Soap, Apache Axis or an HP implementation of Soap.

For Axis, the following line of code should be used:

System.setProperty("org.uddi4j.TransportClassName","org.uddi4j.transport.ApacheAxisTransport");

Each transport option introduces its own set of dependencies. For Axis, the following resources should be on the classpath.

uddi4j.jar
axis.jar
jaxrpc.jar
saaj.jar
jax-runtime.jar
jax-rpi.jar
commons-logging-1.0.4.jar
commons-discovery-0.2.jar
commons-httpclient-3.0-rc2.jar
the five javamail jars
activation.jar (JAF 1.1)

These are the import statements I have used in my main class:

import org.uddi4j.client.*;
import org.uddi4j.datatype.*;
import org.uddi4j.response.*;
import org.uddi4j.util.*;
import org.uddi4j.transport.*;
import org.uddi4j.*;
import org.uddi4j.datatype.business.*;
import org.uddi4j.datatype.tmodel.*;
import org.apache.axis.transport.*;
import javax.xml.rpc.*;
import javax.xml.soap.*;
import org.apache.commons.logging.*;
import javax.mail.internet.*;
import javax.activation.*;
import java.net.*;

Here's a couple of basic Java classes to start playing around with:

/**
*
* Main class for fiddling around with jUDDI.
*
* @author Clayton Moore
* @version 0.7.0
*/
public class UddiManager {

UDDIProxy uddiProxy;
SocketBusinessManager socketBusinessManager;

public UddiManager() {

//Sets SOAP transport system to Axis (alternatives are Apache Soap
//and HPSoap.
System.setProperty("org.uddi4j.TransportClassName","org.uddi4j.transport.ApacheAxisTransport");

//Create a new UDDIProxy object on which all the UDDI methods can
//be called.
uddiProxy = new UDDIProxy();

//Class to carry out some basic businessEntity functions
socketBusinessManager = new SocketBusinessManager(uddiProxy);

//Set publish and inquiry URLs: publish should be https, which
//would require the use of JSSE.

//Change localdomain to the domain name and path to the UDDI
//implementation.
uddiProxy.setPublishURL("http://localdomain/juddi/publish");
uddiProxy.setInquiryURL("http://localdomain/juddi/inquiry");
}

public static void main(String[] args) {

UddiManager uddiManager = new UddiManager();

try
{
AuthToken token = null;
//All publish operations on a jUDDI must be accompanied by
//an authorisation token, a sort of mini-session object.
token = uddiManager.uddiProxy.get_authToken("juddi", "juddi");

System.out.println("Token received: " + token.getAuthInfoString());

//Tokens will time out, but best create a new one for each task
//or set of related tasks and invalidate the token afterwards.
//This obviously means that no-one else can use it.

//uddiManager.uddiProxy.discard_authToken(token.getAuthInfoString());
//System.out.println("Token invalidated: " + token.getAuthInfoString());

uddiManager.socketBusinessManager.addBusiness("SOCKET-Leeds", token);

System.out.println("New business created.");

}
catch (TransportException ex)
{
System.out.println("We have a transport exception.");
}
catch (UDDIException ex)
{
System.out.println("We have a UDDI exception.");
System.out.println(ex.toString());
}

}
}

Some of the code in the next class is taken from
http://www-128.ibm.com/developerworks/webservices/library/ws-uddi4j.html?dwzone=webservices

Doug Tidwell: UDDI4J Matchmaking for Web Services, Jan 2001.

import java.util.ArrayList;
import org.uddi4j.client.UDDIProxy;
import java.util.Vector;
import org.uddi4j.transport.*;
import org.uddi4j.*;
import org.uddi4j.datatype.business.BusinessEntity;
import org.uddi4j.response.AuthToken;
import org.uddi4j.response.BusinessDetail;
import org.uddi4j.response.BusinessList;
import org.uddi4j.response.BusinessInfo;
import org.uddi4j.response.DispositionReport;

/**
* Class for carrying out basic business entity functions.
*
* @author Clayton Moore
* @version 0.7.0
*/
public class SocketBusinessManager
{
private UDDIProxy uddiProxy;

public SocketBusinessManager()
{
}

public SocketBusinessManager(UDDIProxy uddiProxy)
{
this.uddiProxy = uddiProxy;
}

public void addBusiness(String businessName, AuthToken token)
{
Vector entities = new Vector();

BusinessEntity be = new BusinessEntity();

Vector businessNames = new Vector();

Name name = new Name(businessName);

businessNames.add(name);

be.setNameVector(businessNames);

entities.addElement(be);

try
{

BusinessDetail bd = uddiProxy.save_business(token.getAuthInfoString(),
entities);

Vector businessEntities = bd.getBusinessEntityVector();

BusinessEntity returnedBusinessEntity = (BusinessEntity)(businessEntities.elementAt(0));

System.out.println("Returned businessKey:" + returnedBusinessEntity.getBusinessKey());

}
catch (TransportException ex)
{
}
catch (UDDIException ex)
{
}
}
}

The Industrial Estate Design Pattern

2006-06-18T15:00:32+01:00

Atif, SOCKET lead developer, always shakes his head in a disapproving manner whenever I refer to the SOCKET view application (code: Sun, Rob & I; XSLT: Rob) as the "View Factory". "It's not a factory. It's a servlet filter that calls an XSLT transformation". Atif is, indeed, correct. As it stands, the View won't fit in with the elegance of the design of the rest of the project. Atif has seen to it that the core functionality of SOCKET is highly modular and pluggable. Even the plugs have plugs. So the View must become a true View Factory. (Sink me, a hacker such as meself straying into Gang of Four territory feels most odd.) Not that this is an unreasonable development: the Abstract Factory Pattern is often applied in affairs of the View. Swing abounds with factories.

There is a 2-dimensional structure at the heart of the implementation of the Abstract Factory Pattern. For example, one dimension could be the platform, such as Windows, Motif or MacOS, and the other could be a range of view widgets. A program might be charged with producing widgets so that the program can easily be configured for each particular platform.

In SOCKET, one dimension can be looked on as View Technology and the other as User Agent. The pluggable consumer software module that is in place at the moment happens to feed out an xml file, an abstract Graphical User Interface Descriptor (GUID), to be posh. The natural view technology is therefore an XSLT transformation. However, another implementation of the consumer module (OK, the consumer factory) might send out a bean, in which case a more natural view technology might be a JSP page or a pojo beanhandler.

So what is required is a Factory architecture that will facilitate the production of the View for a range of technologies and a range of User Agents - browsers, PDAs, WAP and so on. And so, we start with an interface. (By the way, I refuse to put Impl on the end of everything that derives from an interface. It's damned ugly - for a start, Impl is too close to pimple.)

public interface ISocketViewFactory
{
//For PC browsers.
public abstract XhtmlView createXhtmlView();
//For range of mobile devices.
public abstract XhtmlBasicView createXhtmlBasicView();
//For WAP browsers.
public abstract WmlView createWmlView();
}

I might even add a special one for my pride and joy, my Nokia 770 .

We can then have an XSLT factory, say.

public class XsltSocketViewFactory implements ISocketViewFactory
{
public XhtmlView createXhtmlView()
{
return new XsltXhtmlView();
}

public XhtmlBasicView createXhtmlBasicView()
{
return new XsltXhtmlBasicView();
}

public WmlView createWmlView()
{
return new XsltWmlView();
}
}

Each returned view object will have a transform method to carry out the actual data transformation.

Now the good bit - the SocketViewFactoryFactory - a factory to create the factory. Depending on an input parameter, a different implementation of the view factory can be returned.

public class SocketViewFactoryFactory
{
private static SocketViewFactoryFactory soleInstance = new SocketViewFactoryFactory();

//XSLT-based view factory.
public final static int XSLT = 1;
//View factory processes Java bean containing view data.
public final static int BEANHANDLER = 2;

/**
* Private constructor brings about singleton status.
*/
private SocketViewFactoryFactory()
{
}

/**
* Returns the one and only instance of the SocketViewFactoryFactory.
*
* @return soleInstance
*/
public static SocketViewFactoryFactory getInstance()
{
return soleInstance;
}

/**
* Returns a SocketViewFactory whose type is determined by the
* technology integer.
*
* technology = 1 => XSLT factory
* technology = 2 => BeanHandler factory
*
* @param int technology
* @return ISocketViewFactory
*/
public ISocketViewFactory createSocketViewFactory(int technology)
{
switch (technology)
{
case XSLT:
return new XsltSocketViewFactory();
case BEANHANDLER:
return new BeanHandlerSocketViewFactory();
default:
return new XsltSocketViewFactory();
}
}
}

Is that OK, Atif? I need what now? A message queue???

Some factory classes are completely populated by factory methods. A good name for this might be the Industrial Estate Design Pattern. Might not internationalize well.

ps The Pojo BeanHandlers is actually the name of a Tennessee mountain jug band.

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.

Running in the Derby

2006-05-19T17:06:09+01:00

The Derby database, of course. Going on general reports, recommendations from a colleague, and mutterings from my Auntie Fanny, the decision has been made to use Apache Derby as the back end for the jUDDI registry. The most obvious advantage is ease of deployment and portability. The whole of SOCKET can be wrapped up in a WAR with the derby.jar file nicely stowed away inside.

Derby is ridiculously straightforward to crank up, especially with the aid of the book, Apache Derby - Off to the Races - Includes Details of IBM Cloudscape, by Paul C. Zikopoulos, Dan Scott and George Baklarz out of IBM Press, Pearson (2006). This book is a real pleasure to fondle. Beautiful crisp, black, blue and white IBM theme with a blurred hossie on the front. A sturdy hardback, well laid out and good quality paper.

I provide below some jottings on how to start experimenting with the database under Java on Windows XP.

Get the latest stable release from http://db.apache.org/derby/derby_downloads.html. This is presently 10.1.2.1. The lib download is fine: db-derby-10.1.2.1-lib.zip.

Unzipping this download reveals a few derby jars plus some internationalization jars. For the moment, the two important ones here are derby.jar and derbytools.jar. derby.jar contains the database files while derbytools.jar has inside it 'ij', the Apache Derby JDBC scripting tool, using which you can execute SQL scripts against Derby databases.

Add these two files to your Java classpath by first opening the My Computer window, right-clicking and selecting Properties to summon the System Properties window. Select the Advanced tab and then the Environment Variables button. Make a new user variable called CLASSPATH. My value for this was

D:/derby/db-derby-10.1.2.1-lib/lib/derbytools.jar;D:/derby/db-derby-10.1.2.1-lib/lib/derby.jar

If there are already entries in the CLASSPATH variable, just tack these two soldiers on the end with semi-colon separators.

Now you can use the ij tool to create a database as shown below.

There is now a directory D:/JUDDI containing the Derby files for the JUDDI database. You can add a path to the directory when you create it.

Add dataEncryption=true;bootPassword=myBootPassword to encrypt the newly created database. In this case the bootPassword property of the connection object must be set to myBootPassword to gain access.

Now you can write a little Java program to access the database:

package derbytest;

import java.sql.*;
import javax.sql.*;
import java.io.*;
import java.math.*;
import java.text.*;
import java.util.*;

public class DerbyCranker {

public DerbyCranker() {
}

public static void main(String[] args) {
DerbyCranker derbyCranker1 = new DerbyCranker();
String DerbyDriver = "org.apache.derby.jdbc.EmbeddedDriver";

try {
Class.forName(DerbyDriver).newInstance();
System.out.println("Driver located and loaded.");
}
catch (Exception NoDriver) {
System.out.println("No driver: " + DerbyDriver);
System.exit(1);
}

String url = "jdbc:derby:D:/JUDDI";
Properties properties = new Properties();
properties.put("retrieveMessagesFromServerOnGetMessage", "true");
try {
Connection conn = DriverManager.getConnection(url, properties);
.
.
.
conn.close();
}
catch (SQLException se) {
String SQLState = se.getSQLState();
String SQLMessage = se.getMessage();
System.out.println("Error: " + SQLState);
System.out.println(SQLMessage);
}
}
}

Hours of fun.

SOCKET.net?

2006-05-15T14:46:42+01:00

A recent article on the Microsoft site:

Calling an Arbitrary Web Service

Scott Golightly, Microsoft Regional Director
Keane, Inc.

April 2006

QMShibb - Software released

2006-05-14T13:47:35+01:00

The QMShibb software is now released on the Socket Sourceforge site. It is released as a .war file for deployment in Apache Tomcat. See the other items in this blog for details of how to install, configure, test and deploy QMShibb. Alternatively, full details are contained in the docs directory of the webapp obtained when the war file is deployed.

QMShibb - Installation, configuration and testing

2006-05-13T12:26:39+01:00

QMShibb is a web application that can be installed and tested in Apache Tomcat. Here's how to do it. I assume that the Questionmark Web Integrated Services environment (QMWISE) is installed on the IIS server running Perception and that Tomcat has been installed.

Setting up Perception and QMWISe for QMShibb

Go to the directory that contains the configuration file for Perception, probably Perception\server, and open the file Perception.ini (or Perceptionv4.ini). Look for these entries in the Enterprise Manager section:

Enable exlogin=0

Allow external EM entry =0

Simple EM checksum =0

Edit these to:

Enable exlogin=1

Allow external EM entry =1

Simple EM checksum =1

There may be a section in this file that refers to QMWISe. If so, look for the following entries in that section:

SecurityRequire=0

TrustRequire=0

Edit these to:

SecurityRequire=1

TrustRequire=0

Now go to the directory that contains QMWISE, probably Perception\server\qmwise, and open the file Web.config in a text editor. Look for the entries:

<add key="SecurityRequire" value="0" />
<add key="TrustRequire" value="0" />

Edit these to:

<add key="SecurityRequire" value="1" />
<add key="TrustRequire" value="0" />

Save the file and use the Enterprise Manager to reset the Perception dlls.

Installing and configuring QMShibb

Download the file QMShibb.war from the SOCKET Sourceforge site.

Put this file in the webapps directory of Tomcat (e.g. c:\Program Files\Tomcat 5.5\webapps). It will be automatically expanded with all of the directory structures and files needed.

Go to the QMShibb WEB-INF directory (e.g. c:\Program Files\Tomcat 5.5\webapps\QMShibb\WEB-INF) and open the file web.xml in a text editor. This file contains the configuration settings for QMShibb. Here is a description of the settings:

<context-param> <param-name> security </param-name> <param-value> 1 </param-value> </context-param>	This parameter controls whether or not the QMWISe security header is sent in the SOAP request. You should set this to 1 if the header is to be sent or 0 if not. The recommended setting is 1. This is a required parameter.
<context-param> <param-name> ClientID </param-name> <param-value> Manager </param-value> </context-param>	This parameter contains the username of a Perception administrator who has at least sufficient privilege to manage the server dlls and configure the server. This parameter is ignored if the security parameter is set to 0.
<context-param> <param-name> checksum </param-name> <param-value> xxxxxx </param-value> </context-param>	This parameter contains the security checksum. It is an MD5 digest of the concatenation of the username and encrypted password of the administrator whose username is present in the ClientID parameter. See below for a description of how the checksum is obtained. This parameter is ignored if the security parameter is set to 0.
<context-param> <param-name> QMWISe-url </param-name> <param-value> http://.../QMWISe/QMWISe.asmx </param-value> </context-param>	This parameter contains the URL of the QMWISe web service. This is a required parameter. The value can be obtained by running IIS Manager and then looking for the actual path of the virtual directory qmwise.
<context-param> <param-name> test-mode </param-name> <param-value> 1 </param-value> </context-param>	This parameter allows you to put QMShibb into test mode. This allows you to test QMShibb without having to put it behind a Shibboleth Service Provider. When this parameter is set to 1, QMShibb will generate Shibboleth attributes using the information in the following parameters. This parameter should be set to 0 for a production deployment. This is a required parameter.
<context-param> <param-name> test-user </param-name> <param-value> ADent </param-value> </context-param>	The username of the fictional user in the Shibboleth attribute to be used in test mode. This parameter is ignored if the test-mode parameter is set to zero.
<context-param> <param-name> test-firstname </param-name> <param-value> Arthur </param-value> </context-param>	The first name of the fictional user in the Shibboleth attribute to be used in test mode. This parameter is ignored if the test-mode parameter is set to zero.
<context-param> <param-name> test-lastname </param-name> <param-value> Dent </param-value> </context-param>	The last name of the fictional user in the Shibboleth attribute to be used in test mode. This parameter is ignored if the test-mode parameter is set to zero.
<context-param> <param-name> test-groups </param-name> <param-value> test_group1;test_group2 </param-value> </context-param>	The names of the fictional groups in the Shibboleth attribute used in test mode. This parameter is ignored if the test-mode parameter is set to zero.
<context-param> <param-name> create-account </param-name> <param-value> 1 </param-value> </context-param>	When this parameter is set to 1, QMShibb will create a new Perception participant account for the user whose username is present in the Shibboleth header defined below. If the parameter is set to 0, no automatic account creation will occur. This is a required parameter.
<context-param> <param-name> join-existing-groups </param-name> <param-value> 1 </param-value> </context-param>	When this parameter is set to 1, QMShibb will add the user whose username is present in the Shibboleth header defined below to any existing Perception group whose name matches one of the group names present in the Shibboleth header defined below. This parameter is ignored if the create-account parameter is set to 0.
<context-param> <param-name> create-groups </param-name> <param-value> 0 </param-value> </context-param>	When this parameter is set to 1, QMShibb will create a Perception group if its name matches one of the group names present in the Shibboleth header defined below and the group does not already exist. It will then add the user whose username is present in the Shibboleth header defined below to the newly-created or existing group. This parameter is ignored if the create-account parameter is set to 0 or the join-existing-group parameter is set to 1.
<context-param> <param-name> username-attribute </param-name> <param-value> HTTP_..._eduPersonPrincipalName </param-value> </context-param>	The name of the Shibboleth attribute carrying the site-qualified username of the user. This is a required parameter. QMShibb will report an error if this Shibboleth header is not present in the HTTP request.
<context-param> <param-name> fullname-attribute </param-name> <param-value> HTTP_..._eduPersonNickname </param-value> </context-param>	The name of the Shibboleth attribute carrying the full name of the user. This parameter is ignored if the firstname-attribute and lastname-attribute Shibboleth headers described below are both present in the HTTP request. If no Shibboleth header containing name information is present in the HTTP request, QMShibb will give the user the default name Anonymous User.
<context-param> <param-name> firstname-attribute </param-name> <param-value> HTTP_givenName </param-value> </context-param>	The name of the Shibboleth attribute carrying the first name of the user. This parameter is not required if the full name of the user is delivered in the Shibboleth attribute defined in the fullname-attribute above. If no Shibboleth header containing name information is present in the HTTP request, QMShibb will give the user the default name Anonymous User.
<context-param> <param-name> lastname-attribute </param-name> <param-value> HTTP_sn </param-value> </context-param>	The name of the Shibboleth attribute carrying the last name of the user. This parameter is not required if the full name of the user is delivered in the Shibboleth attribute defined in the fullname-attribute above. If no Shibboleth header containing name information is present in the HTTP request, QMShibb will give the user the default name Anonymous User.
<context-param> <param-name> groups-separator </param-name> <param-value> ; </param-value> </context-param>	The names of the groups to which the user belongs are delivered as a list in a single Shibboleth attribute. This parameter is used to define the list separator (e.g. a comma, colon or semicolon).
<context-param> <param-name> groups-attribute </param-name> <param-value> HTTP_urn:bodington:member </param-value> </context-param>	The name of the Shibboleth attribute carrying the list of groups to which the user belongs. This list will be used to create equivalent groups in Perception if the appropriate parameters are set above.

You need to provide the username of a Perception administrator who has at least sufficient privilege to manage the server dlls and configure the server. Edit the ClientID parameter to that username. You also need to edit the checksum parameter. QMWISe comes with a test harness program that is designed to generate the checksum from the administrator's username and password. At the time of writing, the checksums generated by this program are incorrect. You can contact Questionmark for help with generating checksums. In the US you can email support@questionmark.com and in the UK you should contact helpdesk@questionmark.co.uk. If you have access to the installation of Microsoft SQL Server that hosts the Perception database, you can generate your own checksum as follows:

Open the SQL Server management application and connect to the server. Select the Perception database and open the Tables item. Select the table whose name ends in User (e.g. dbo.G_User). Right-click on this item and select Open Table. You should be able to locate the username of your chosen administrator in the User Name column. Next to it is the Password column. This contains 16-digit numbers that are the encrypted form of the password. Note the number corresponding to your chosen administrator. Close the SQL Server Management application. Open a web browser and go to http://pajhome.org.uk/crypt/md5/. In the input box type the username of the administrator followed immediately by the encrypted password. If you administrator's username is Admin and the encrypted password is 1234567887654321, then you should type Admin1234567887654321. The input is case-sensitive so make sure that the Caps Lock key on your keyboard is not on and make sure that there is no space between the username and the encrypted password. Now click on the MD5 button. The result is the checksum that you should enter in the checksum parameter in your web.xml file.

Go back to your web.xml file and make sure that the QMWISe-url parameter is correct for your setup. Set the test-mode parameter to 1 and save the web.xml file. Then restart Tomcat.

Testing QMShibb

Open a browser.

If your Tomcat is a standalone installation, go to the URL:

http://path_to_Tomcat:8080/QMShibb/getaccessassessmentlist

If you have installed Tomcat into IIS, go to the URL:

http://path_to_IIS/QMShibb/getaccessassessmentlist

There will be a slight delay while the servlet is instantiated, but then you should be directed to the Perception list of assessments for Arthur Dent. This will probably be empty.

Open the Questionmark Enterprise Manager and look at the lists of Participants and Groups. Arthur Dent should now be one of your Participants and he should be the only member of a group called external_shibboleth_users. You can delete the Participant and the Group if you want to. Close the Enterprise Manager and go back to the directory containing the QMShibb web.xml file. Change the test-mode parameter to 0. Decide on a policy regarding automatic account and group creation and set the parameters appropriately. Save the web.xml file and restart Tomcat.

Shibboleth and QMShibb

Having established that QMShibb is working correctly, you must protect the servlets in the QMShibb directory. The easiest way to do this is to put the QMShibb servlets behind a Guanxi Service Provider Guard. This approach has the advantage that it will work irrespective of the location of Tomcat - on the Perception server, a VLE server or a third server. Alternatively, if you have installed Tomcat into the IIS server running Perception, you can install the Internet2 Service Provider and configure it to protect the QMShibb directory. Whichever method you choose, you will have to make sure that before you try using QMShibb, your Service Provider has exchanged the appropriate metadata and certificates with the Shibboleth Identity Provider(s) that you are going to use.

QMShibb - Installing Tomcat with IIS 6

2006-05-12T13:58:19+01:00

Although QMShibb will work on any server running a servlet container, it is convenient to install it into IIS on the same server as that running QuestionMark Perception. Unfortunately, IIS is not a servlet container, so you must install Java and Tomcat, and then optionally install the Jakarta Tomcat Connector. Here's how to do it. I'm assuming that you are running Windows Server 2003 and IIS 6.0.

Install Java

Download the Java JDK 1.5 from http://java.sun.com/j2se/1.5.0/download.jsp

Choose a custom installation so that you can specify the installation location. I chose to install in c:\Program Files\Java

When the Java JDK has installed, you need to set a couple of environment variables to ensure that Tomcat will work correctly. Click on the Windows Start button at the bottom left of your screen. Select Control Panel. In the Control panel, select System. This will bring up the System Properties dialog. Click on the Advanced tab and then on the Environment Variables button. Create a variable called JAVA_HOME and give it the value of the directory where you installed Java - in my case this is c:\Program Files\Java. Create another environment variable called CATALINA_HOME and give it the value c:\Program Files\Tomcat 5.5 then close the environment variables dialog. Back in Control Panel, select the Java item. This will launch the Java Control Panel. Select the Update tab. Make sure that the Check for Updates Automatically box is unchecked. Close the Java Control Panel and the Windows Control Panel.

Install Apache Tomcat

Download the Windows Excutable from http://tomcat.apache.org/download-55.cgi. At the time of writing the current version is 5.5.17.

Run the installer and select a Full Installation.

At the Choose Install Location dialog, enter c:\Program Files\Tomcat 5.5

At the Configuration Options, leave the port as 8080 (assuming you have nothing else running on that port) and change the password to a strong one that you can remember.

At the Java Virtual Machine dialog, enter the path to your Java setup - in my case c:\Program Files\Java

At the final dialog, click on the Finish button. Tomcat is now installed as service that will start automatically.

Install the Jakarta Tomcat Connector

It is not essential to install the Connector as Tomcat and IIS will coexist happily, each serving pages on their respective ports, 8080 and 80. However, it is convenient to arrange for IIS to receive all requests and to pass those for servlets to Tomcat while dealing with all other requests itself. In this case, all requests can address IIS and the users can ignore the issue of ports.

The Apache Tomcat website has a complicated protocol for installing the connector, involving dangerous operations such as editing the registry. Mercifully, this is not necessary as there is a program you can download that handles most of the installation process. Download isapi_redirect.msi from http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.15/. Run the installer and install the redirector to c:\Program Files\Tomcat 5.5.

Open IIS manager and check that there is a virtual directory called jakarta in the default web site. The virtual directory should point to c:\Program Files\Tomcat 5.5\bin and it should contain the files isapi_redirect.dll and isapi_redirect.properties as well as some others. Check that there is a Web Service Extension called jakarta whose status is Allowed.

Right-click on Default Web Site in the left pane. Select Properties. In the Default Web Site Properties dialog, click on the ISAPI Filters tab. There should be a filter called jakarta, but this step of the installation often fails. If it's not there, click on the Add... button. Give the filter the name jakarta, set the executable as c:\Program Files\Tomcat 5.5\bin\isapi_redirect.dll and then click on OK.

Go to the directory c:\Program Files\Tomcat 5.5\conf and open the file server.xml in a text editor. Locate the line:

<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

Make sure that this entry is not commented out. Save the file.

Open the file workers.properties in a text editor and edit its contents to the following:


worker.list=wlb,jkstatus



worker.ajp13w.type=ajp13

worker.ajp13w.host=localhost

worker.ajp13w.port=8009



worker.wlb.type=lb

worker.wlb.balance_workers=ajp13w



worker.jkstatus.type=status

Save the file.

Open the file uriworkers.properties in a text editor and edit its contents to the following:


/admin/*=wlb

/manager/*=wlb

/jsp-examples/*=wlb

/servlets-examples/*=wlb

/QMShibb/*=wlb



/jkmanager=jkstatus

Save the file.

Now restart Tomcat and IIS. All requests for URLs containing the directories admin, manager, jsp-examples, servlets-examples and QMShibb will now be passed from IIS to Tomcat.

To reiterate: these instructions show how to install Tomcat into the IIS server running Perception, but QMShibb can be installed into Tomcat running on any server - the server running Perception, the server running a Java-based VLE such as Bodington, or an entirely separate server.

11 May 2006

2006-05-11T19:28:05+01:00

The French and British sides of the Channel Tunnel met on 22 May 1991.

The SOCKET service consumer software and the viewfactory filter met on 11 May 2006.

A data transformation was observed and a small breakthrough ceremony took place.

QMShibb - Shibboleth enabling Questionmark Perception

2006-05-09T12:10:00+01:00

If you are interested in Shibboleth, then you are probably aware of the complex shuttling between the Service Provider (SP) and the Identity Provider (IdP) ultimately leading to a set of attributes emerging from the Service Provider and being presented to the Shibboleth-protected resource. (If this is all new to you, read the excellent introduction in the Educause Quarterly.)

Let's assume that the user has tried to access a Shibboleth-protected resource. She has been intercepted by the SP and sent off to the WAYF which in turn sends her on to the IdP. She authenticates to the the IdP which then sends an authentication assertion to the SP. The SP responds by requesting the user's attributes from the IdP. But what happens when they arrive? Many diagrams of the Shibboleth authentication process simply end at this point with 'access to resource granted'. This may be the case if all that is necessary for access is for certain Shibboleth attributes to be present in the HTTP request. In this case the protected resource doesn't use the values of the attributes. It is enough to know for example that there is an attribute present that indicates that the user is a member of an organization that has paid a subscription for access to the resource.

Shibboleth and e-Learning

Shibboleth as originally developed has a very strong emphasis on protecting the user's privacy and not releasing more information than absolutely necessary. For example, as long as the user or her organization has paid a subscription, there is no need to release her identity to a publisher's website. However, this does not work in the world of e-learning where the protected resource might be a bulletin board or an online assessment system such as Questionmark Perception. Students need to be assessed. How can you assess a student if you don't know who she is? If you are accessing systems such as Questionmark Perception, then the minimum user attributes necessary will be some sort of system-specific identifier (e.g. a username), probably the student's real name and possibly an indication of the groups to which she belongs.

Shibboleth and Questionmark Perception

This means that you can't just put Perception behind a Shibboleth SP and expect it to work. You need another software component, a Resource Manager, that can extract the information from the Shibboleth attributes and pass it on to Perception in a form that it can use. Perception has web service called Questionmark Web Integration Services environment (QMWISe). This allows password-free access to much of Perception's functionality, including account and group creation, presentation of assessments and other administrative functions. As part of the SOCKET JISC eLF project, we have developed a resource manager that will allow Shibboleth attributes to be passed to QMWISe. The resource manager is called QMShibb.

QMShibb

Questionmark Perception is a Windows web application running within Microsoft Internet Information Server (IIS). We are primarily interested in interfacing Perception to our VLE, which uses the Bodington software written in Java. Bodington has the advantage that it has both Shibboleth IdP and Shibboleth SP functionality built-in. QMShibb is a set of Java servlets which run in a servlet container that implements the Java Servlet Specification version 2.3 or above. It can be deployed on the same server as the VLE, the same server as Perception or on a third server. There is no restriction on the domains in which the servers reside, but they should not use HTTP proxies.

The preferred servlet container for QMShibb is Apache Tomcat. This can be installed as a standalone application, or it can be installed within Apache or IIS. In the latter case, it can be installed within the same installation of IIS as that running Perception.

When QMShibb is installed behind a Shibboleth SP, it expects to find the following attributes in the HTTP request headers:

An attribute containing the user's principalName. This will usually take the form of a site-qualified username e.g. username@mysite.myuni.ac.uk This attribute is required and QMShibb will report an error if it is not present.

A single attribute containing the user's real name or a pair of attributes containing the first and last names. If there is no name attribute, the user will be given the default name 'Anonymous User'

An optional attribute containing a list of the names of groups to which the user belongs. The list separator character can be set in QMShibb's configuration file.

The names of the HTTP headers containing these attributes can be set in the configuration file. The configuration file also contains entries for setting the SOAP security header required by QMWISe. Other entries allow optional automatic participant account creation, automatic addition of the participant to existing groups within Perception, or the automatic creation of groups (with the same names as those in the Shibboleth attribute) and the addition of the participant to them.

Currently, three servlets are provided with QMShibb. These are:

getaccessassessment

getaccessassessmentlist

getaccessadministrator

Here's an image of a Perception assessment accessed via Shibboleth (the Guanxi implementation)+QMShibb+QMWISe from the Bodington VLE.

Following a conversation with John Kleeman, the Questionmark chairman, we modified the behaviour of the getaccessassessment and getaccessassessmentlist servlets. Both of these now ensure that the participant is added to the group 'external_shibboleth_users'. In addition, the getaccessassessment servlet checks to see if a schedule exists that links the user to the assessment. If not, then it creates a schedule that allows the user a single attempt at the assessment. For any further use of the assessment by that user a new schedule must be created.

EE, isn't the View luvvly...

2006-05-03T19:36:25+01:00

In the past five years or so there seems to have been a moderate and growing interest in the subject of abstract descriptions of the user interface (UI) to software applications (Wikipedia lists about 20 different flavours). Starting from an abstract user interface description (UID), transformations can be applied to create concrete UIs suitable for a range of different client devices and display technologies.
XML is the universally favoured tool for the UID language (UIDL) and transformations can be carried out by direct programmatic manipulation of the markup or using XSLT transformations.
One important part of the SOCKET project is the View Factory (VF), a servlet filter that renders a view from an XML feed produced by the service consumer software.
I've just about convinced meself that the technology that will ultimately constitute the main part the SOCKET VF will be XForms. The browser interface is form-based: data that will populate the soap message are posted to a server before being sent orff using Axis. However, the time is not right - for a small project team and a short project I suspect that it is an API too far to give it proper attention. Also, getting to grips with the various XForm engines would be a task. We are all doing well with WSDL, SOAP, JAX-RPC, Axis, UDDI, XSLT/XPath, and Aggie has just tamed Windows Server 2003, IIS 6, SQL Server 2005 and Questionmark Perception. It is simpler at present to create a poor man's XForms (an extremely poor man - more than a poor man - a man deeply in debt - a lost soul - OK, to tell the truth, nothing like XForms). A couple of drafts of the VF schema had been completed before I tracked down the schema from the WSGUI project originally instigated at Stanford University as part of the FX-Agents research project (Michael Kassoff, Daishi Kato, Waqar Mohsin) and revised by Josef Spillner (January 2006 - see http://web.inf.tu-dresden.de/~js177634/webservices/wsgui.html). This is the closest thing I've seen to my original impression of how the design should go. The SOCKET VF schema is more agricultural, the initial aim being to keep the XSLT processing relatively straightforward. However, the SOCKET version is strongly typed, which allows a greater degree of client-side validation. With Web services you have two bites at client-side validation: first bite on the browser; and second bite using the consumer software (OK, it's really server-side validation). I suppose it's validation of the individual input parameters on the browser and schema-based message validation by the consumer software should a schema be available.

jUDDI Installation

2006-04-27T15:54:23+01:00

jUUDI Installation

The installation of jUDDI is fairly straight forward, however, there are some quirks...as with all things.

The quirks lie with installing jUUDI on Tomcat 5.5.x as opposed to 5.0.x and below. I'll shall come to this in a bit.

Firstly, download the jUDDI package into your home directory from:-

http://ws.apache.org/juddi/releases.html

Get the latest and greatest.

tar zxvf juddi.tar.gz

Then copy the .war file that resides within the jUDDI directory into your webapps directory

cp juddi/juddi.war /path/to/tomcat/webapps

MySQL - Database creation and population

You need to run 2 x .sql scripts that come with the jUDDI package. These are:-

/path/to/juddipackage/sql/mysql/create_database.sql
/path/to/juddipackage/sql/mysql/insert_publishers.sql

You can run these by doing the following:-

# mysql -u root -p < /path/to/juddipackage/sql/mysql/create_database.sql
password:

# mysql -u root -p juddi < /path/to/juddipackage/sql/mysql/insert_publishers.sql
password:

You now need to populate the database with a user. Do this by logging into the MySQL console and running the following sql.

# mysql -u root -p
password:

mysql> use juddi;
INSERT INTO PUBLISHER (PUBLISHER_ID,PUBLISHER_NAME,IS_ADMIN,IS_ENABLED)
VALUES ('jdoe','John Doe','false','true');

Final tweaks

Finally, create a file called juddi.xml in /path/to/tomcat/server/Catalina/localhost and enter the following:-

***this is code required for tomcat 5.5.x and is not stated in the official jUDDI docs. It is different for 5.0.x and below***

Amend as necessary to match your MySQL details, e.g. change the username and password.

To enable log4j, you need to create a file at juddi/WEB-INF/classes/log4j.properties. In that file enter:-

#
# set the log file to ${HOME}/juddi.log and not the ${PWD}/juddi.log
#
log4j.appender.LOGFILE.File=/opt/tomcat/logs/juddi.log

and amend the file juddi.properties at:-

/juddi/WEB-INF/judi.properties to suit e.g:-

# The UDDI Operator Name
juddi.operatorName =socket1.leeds.ac.uk

Then simply restart tomcat and browse to:-

http://localhost/juddi

click on 'validate' and see the output for any errors.

Tomcat Installation

2006-04-27T08:21:45+01:00

Tomcat Installation

Prerequisites: Java 1.5

Firstly download the latest and greatest Tomcat binary distribution from:-

http://tomcat.apache.org/download-55.cgi

The latest version at the time of this writing, is 5.5.16

Tomcat 5.5.x strictly requires Java 1.5, so this needs to be installed prior to installation.

so the commands:-

mv jakarta-tomcat-5.5.10.tar.gz /usr/local/jakarta-tomcat-5.5.10.tar.gz
cd /usr/local
tar zxvf jakarta-tomcat-5.5.x.tar.gz

Owing to the long name of the directory, you may want to rename this to simply tomcat, so:-

mv /usr/local/jakarta-tomcat-5.5.10 /usr/local/tomcat

To start tomcat:-

/usr/local/tomcat/bin/startup.sh

Then browse to:-

http://myIPaddress:8080, and you should see the famous cat!

To stop tomcat:-

/usr/local/tomcat/bin/shutdown.sh

Many instances of tomcat can run on the same server, simply change the http, https and shutdown port numbers in /usr/local/tomcat/conf/server.xml so that they don't clash.

MySQL J Connector/J 3.1 Installation

2006-04-24T21:24:43+01:00

MySQL Connector/J 3.1 installation

Download the connector from:-

http://dev.mysql.com/downloads/connector/j/3.1.html
http://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-3.1.12.tar.gz/from/http://www.mirrorservice.org/sites/ftp.mysql.com/

tar zxvf mysql-connector-3.1.tar.gz
cd mysql-connector-3.1

Then copy the .jar file into either:-

cp mysql-connector-3.1.jar /path/to/jdk/jre/lib/ext

cp mysql-connector-3.1.jar /path/to/tomcat/common/lib

MySQL Installation

2006-04-24T21:14:26+01:00

MySQL Installation

To install MySQL version 4.0, 4.1 or 5.0 do the following...

as root:-

download stable mysql 4.0 binary release from:- http://www.mysql.com/downloads/download.php

tar zxvf mysqlbinary.tar.gz
mv mysqlbinary /usr/local/mysql (rename the untarred file 'mysql' and move it into /usr/local)

bash#groupadd mysql
bash# useradd -g mysql mysql
bash# passwd mysql
password: mysqlpassword (give the mysql unix account password)
bash# cd /usr/local/mysql
bash# scripts/mysql_install_db
bash# chown -R mysql:mysql /usr/local/mysql/data
bash# bin/mysqld_safe --user=mysql &

to start the mysql daemon:
/usr/local/mysql/bin/mysqld_safe --user=mysql &

to add root password:
/usr/local/mysql /bin/mysqladmin -u root password 'new-password'

ln -s /usr/local/mysql/bin/mysql /usr/sbin/mysql or add to PATH to aid easy admin of MySQL

Python Installation

2006-04-24T17:43:48+01:00

To install the latest version of Python.

Download Python from:-

http://www.python.org/

tar zxvf python.tgz

cd /path/to/python

./configure --prefix=/path/to/desiredlocation --enable-shared
make
make install.

Flags to observe here are:-

--prefix=/path/to/desiredlocation
--enable-shared – this is required so that mod python can be loaded dynamically into Apache.

Mod Python Installation

2006-04-24T17:40:04+01:00

This blog highlights the procedure to install mod python and config httpd.conf so that moinmoin runs using the mod_python module.

The official docs for this step are at:-

http://moinmoin.wikiwikiweb.de/HelpOnInstalling/ApacheWithModPython
http://www.modpython.org/live/current/doc-html/installation.html

Firstly download mod_python from:-

http://httpd.apache.org/modules/python-download.cgi

untar it, then ./configure and make it. There are a few flags worth taking note of in the docs, namely :-

• ./configure --with-apxs=/usr/local/apache/bin/apxs
• ./configure --with-python=/usr/local/bin/python2.3
• ./configure --with-flex=/usr/local/bin/flex

Then just make and make install.

Now it’s just a case of amending the httpd.conf apache file to accommodate mod python.

You need to add the line:-

LoadModule python_module modules/mod_python.so

Which tells apache to load the mod python module

Moinmoin Wiki Installation

2006-04-24T17:34:31+01:00

Prerequisite -> The latest version of Python to be installed. Docs for which can be found here:-

http://www.agbooth.com/SOCKETBlog/www.socketelf.org_8080/roller/page/socket?entry=mod_python_installation

OK, firstly, pull the latest version of moinmoin down from:-

http://sourceforge.net/project/showfiles.php?group_id=8482

then:-

tar zxvf moinmoin-1.5.x.tgz
cd moinmoin-1.5.x

It would help to pull up the official docs at this point at:-

http://moinmoin.wikiwikiweb.de/HelpOnInstalling

The first stage of the install is called BasicInstallation.

Assuming your Python location is in your PATH, simply type:-

python -v setup.py --quiet install --record=install.log

This will install the relevant files into the home directory e.g. ~moinmoin

Then to test:-

> python
Python 2.3.4 (#1, May 29 2004, 17:05:23)
[GCC 3.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import MoinMoin
>>>

easy as pie! Moinmoin is now installed…unless you see errors in the above.

The next step is to create an instance of a wiki.

Like it says in the docs, choose a location to put your wiki’s, e.g:-

~moinmoin/share/moin

and create a directory named after your wiki e.g.:-

~moinmoin/share/moin/socket

Then copy the following dir’s into that dir:-

data
underlay
wikiconfig.py
and the contents of ‘htdocs’

This was the flaw in the docs. As far as I could see as there was no mention of this step and thus the wiki fails to load correctly.

There are a couple of tweaks required to wikiconfig.py, namely change the location of the ‘data’ and ‘underlay’ dirs from relevant to absolute.

Change permissions as follows:-

chmod –R 777 data
chmod –R 777 underlay

The next step is to configure Mod Python which you can find at:-

http://www.agbooth.com/SOCKETBlog/www.socketelf.org_8080/roller/page/socket?entry=mod_python_installation

Then add the following to your directive in httpd.conf:-

<Location /mywiki>
SetHandler python-program
# Add the path of your wiki directory
PythonPath "['/var/www/moin/mywiki'] + sys.path"
PythonHandler MoinMoin.request::RequestModPy.run
</Location>

obviously amend to suit your environment.

That’s basically it, a quick restart of apache, check of the error logs, and we’re ready to roll!!!

Simply go to your browser and browse to:-

http://youripaddress:yourport/yourwiki

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

The Bad Easy

2006-04-12T10:16:38+01:00

On first meeting Web services and WSDLs, the concepts of rpc-style and document-style services are confusing. The problem stems from the fact that there are two completely different considerations that are described using the same terminology, the implementation of the Web service itself and the structure of the soap content in the WSDL document.

The important facet is the programming model that the consumer and producer use to process their soap messages, not the style of the WSDL. This is where the real distinction between rpc-style and document-style services lies. Since the fundamental aim of SOCKET is to create consumer software for Web services from a WSDL it is essential that we know all the variations that services can throw at us so that we can proceed as far as possible in the process of setting up the consumer side of the service. For very simple services, SOCKET will be able to provide a one-step turnkey process for creating a client. For more complex rpc services and document-style services, SOCKET will probably provide a handler interface wrapped around the XML message which can then be implemented for a complete construction of the functionality of the service.

If we are using the Axis (JAX-RPC) programs Java2WSDL and WSDL2Java, or their equivalents in our language of choice, then we're probably doing rpc. And, bad news, rpc is bad. It's bad for interoperability. If Java shall speak only unto Java, and C# shall speak only to C# and Python shall speak only to Python, then we'd be OK, but then what'd be the point of Web services? It's when Java tries to talk to RosieLea, or when Python wrestles with Anaconda, that the rpc difficulties emerge, essentially through the minefield of mismatched datatypes, and also in the so-called XML-OO impedance mismatch.

So what is the document style? In a document-style Web service, you simply send the soap message to the producer and say, Look, we've talked about this, and we bashed out our schema, take the message and do what you want with it. The producer does this and sends a soap document back. There you are, consumer, we talked about this and we bashed out our schema, take the reply and do what you want with it. Using this style, I suspect that SAAJ 1.2 soap elements, which implement DOM, feeding into an XSLT/XPath engine will be the most important protocol, rather than using some tool-generated language-specific API. This will become clearer in the near future. So how is this better than rpc? Well, hopefully the problem spots have been identified and can be catered for. One field might be a date. The producers can say - look, this field is a date, but - hey - we might feed it in as a null value (nillable = true in the schema) - so watch out for this. In the rpc service, the null date might feed straight into an api that hasn't got null date types - it might go in as a zero...with hilarious consequences (I take this particular example from a Ted Neward interview on The Server Side).

So rpc is bad, and document is good. Document is also good from a related angle - message-oriented middleware and the Humptyhump Humpty Bus. I might say more about this at a later date - I usually do.

The bad news is that for simple services rpc is easier - all tool based, and taken directly from the WSDL operations and messages. With a bit of luck, for simple rpc-style services you are saved the problems that necessarily exist if an XML document has to be developed to implement complex service functionality. Having said this, even simple rpc-style services will have semantic problems, albeit of a different kind, in the absence of good annotations or documentation. Please input gas pressure. Surely - in Pascals, bars, torrs, atmospheres, psi...? Missions to Mars have perished on such semantic asteroids, and so will many a badly-drawn Web service.

So, there are rpc-style and document-style Web services. Either style can be employed using rpc-style or document-style WSDL documents. The WSDL styles are normally referred to as rpc-literal and doc(ument)-literal. So, if we can have an RPC-style Web Service (RWS) and a Document-style Web Service (DWS), there are 4 immediate possibilities: rpc-literal and doc-literal RWS; and rpc-literal and doc-literal DWS (I suppose we ought to give document-wrapped literal a namecheck, too, which makes it easier for tools to handle RWS with doc-style WSDLs).

SOCKET has started orff with the bad easy stuff, a natural place to start: rpc-literal RWS.

8080 restored

2006-04-11T12:53:02+01:00

mea culpa stop silly ass stop permalink problem fixed stop utf-8 not configured properly stop arriving istanbul wed stop

Broken Links - RSS Feed Exporter Omits Port Number

2006-04-08T16:29:50+01:00

212 characters for message stop cetis elrond links to individual blog items broken stop rss exporter omits port 8080 in permalinks stop access to blog via web site stop those puzzling at style ? the first 212 characters are visible in the aggregator stopp

WSDL2Java

2006-04-06T16:26:49+01:00

Some brief notes from Atif on using the WSDL2Java program.

You'll find the Axis WSDL-to-Java tool in "org.apache.axis.wsdl.WSDL2Java". The basic invocation form looks like this:

$> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java (WSDL-file-URL)

For example lets say we have a web service running at the following address:
http://localhost:8080/samples/services/Version
THEN we would invoke Axis WSDL-to-Java tool like THIS:
$> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java http://localhost:8080/samples/services/Version?wsdl

This will create java classes in the current directory.

LETS say we want the ouput of Axis WSDL-to-Java tool to go into certain directory THEN you need to use the -o option.
e.g. $> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java http://localhost:8080/samples/services/Version?wsdl -oC:\test

By default WSDL-to-Java tool will put the ouput classess into packages WHICH mirror the targetNamespace in the web service WSDL.
To change this default YOU need to use the following option: -p
e.g. $> java -cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java http://localhost:8080/samples/services/Version?wsdl -pws.version

Installing Axis client

2006-04-06T16:24:21+01:00

Some brief notes from Atif on installing Axis client.

The following software was used when installing Axis client.
* Java SE 1.5
* Axis 1.3

1. unzip axis-bin-1_3.tar to directory C:\DevTool\axis-1_3

2. Set variable AXIS_HOME to C:\DevTool\axis-1_3

3. Add an XML parser, acquire the JAXP 1.1 XML compliant parser (i.e. xalan) to $AXIS_HOME\lib

4. set variable AXIS_LIB to %AXIS_HOME%\lib

5. set variable AXISCLASSPATH to:

%AXIS_LIB%\axis.jar;%AXIS_LIB%\commons-discovery-0.2.jar;
%AXIS_LIB%\commons-logging-1.0.4.jar;%AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\saaj.jar;
%AXIS_LIB%\log4j-1.2.8.jar;%AXIS_LIB%\xalan.jar;%AXIS_LIB%\wsdl4j-1.5.1.jar;
%AXIS_LIB%\axis-schema.jar

To use Axis client code on the command line, you can select AXISCLASSPATH when invoking Java by entering

java -cp %AXISCLASSPATH% ...

java -cp "$AXISCLASSPATH" ...

depending on the platform. You may omit the quotes if your CLASSPATH doesn't have spaces in it.

Operations - double trouble

2006-04-06T16:09:39+01:00

Building Web Services with Java, Making sense of XML, SOAP, WSDL, and UDDI, (2nd Edition, 2005)by Steve Graham et many als, Sams Publishing.

This is a terrific book - well written with plenty of xml examples.

One little highlighted note in the WSDL chapter goes like this:

Note: When you're designing WSDL portTypes, you should be careful with the names of the portType's operations: They should all be different.

Perhaps they should, but need they be? Atif and I had recently been discussing this matter from the Java to WSDL point of view. The key to the affair is method overloading - two methods with the same name but differentiated by having different signatures. Since portType operations are the equivalent of method names, this would suggest that to accommodate method overloading one might suspect that operations names would not be required to be unique. Out came the WSDL 1.1 specs. Indeed, no stipulations are made about uniqueness of operation names in a WSDL document. Just to make sure, we ran a little test. A Java class with 2 methods with the same name - getTest() - but with different signatures were submitted to the Axis Java2WSDL utility. The relevant part of the resultant WSDL is given below.

<wsdl:portType name="Test">

<wsdl:operation name="getTest" parameterOrder="value">

<wsdl:input message="impl:getTestRequest"name="getTestRequest"/>

<wsdl:output message="impl:getTestResponse"name="getTestResponse" />

</wsdl:operation>

<wsdl:operation name="getTest" parameterOrder="value">

<wsdl:input message="impl:getTestRequest1" name="getTestRequest1" />

<wsdl:output message="impl:getTestResponse1" name="getTestResponse1" />

</wsdl:operation>

</wsdl:portType>

Sure enough, two operations with the same name. The message names, on the other hand, must be unique (as per the specs). These represent the method signatures. You wouldn't want two operations with the same names and the same messages. Again, clever little Axis has differentiated the messages eg getTestRequest and getTestRequest1.

As Atif would say: Job's a good'un.

SOCKET

2006-04-06T14:55:46+01:00

This is the technical blog for SOCKET, a JISC ELF toolkit project.

The aim of the project is to assemble a toolkit that, given a WSDL file, will automatically generate consumer software for a Web service together with an interface that makes it available as a resource in a virtual learning environment.

Project Web site: http://www.agbooth.com/SOCKETBlog/www.socketelf.org_8080/eldg/socket/home.jsp

Project dates: 1 February 2006 - 31 July 2006.

Members of the project team belong to the e-Learning Development Group in the Faculty of Biological Sciences at the University of Leeds.

Professor Andrew G. Booth, Project Director

Dr Brian P. Clark, Project Manager

Atif Suleman, Principal Developer

Rob J. Garbutt, Developer

We are pleased to have the following consultants for the project.

Alistair Young (Guanxi Consultant) from the UHI Millennium Institute at Sabhal Mòr Ostaig, Isle of Skye. Alistair wrote the alternative implementation of the Shibboleth profile used in the Guanxi Identity Provider and Service Provider.

John Kleeman (Questionmark Consultant) is the Chairman of Questionmark Computing Limited, the vendors of Questionmark Perception.