SOCKET

Sumer is acumen in..

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

Posted at 06:04PM May 06, 2008 by Brian Peter Clark in General  | 

The SOCKET Roadmap

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.

Posted at 12:46PM Aug 12, 2007 by Brian Peter Clark in General  | 

SOCKET Case Studies

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

Posted at 10:00PM Dec 11, 2006 by Brian Peter Clark in General  | 

How to Build a Hinjun

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

Posted at 02:28PM Nov 02, 2006 by Brian Peter Clark in Consumer Factory  | 

Lost Property

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.

Posted at 02:46PM Sep 03, 2006 by Brian Peter Clark in Java  | 

1 Registry Good, 2 Registries Better

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.

Posted at 07:39PM Aug 22, 2006 by Brian Peter Clark in General  | 

Saturn and Pluto

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.

Posted at 05:47PM Aug 14, 2006 by Brian Peter Clark in General  | 

SOCKET Demo

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 )

Posted at 03:04PM Aug 10, 2006 by Brian Peter Clark in General  | 

Location, Location, Location and JAXP

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

Posted at 06:31AM Jul 30, 2006 by Brian Peter Clark in View Factory & XSLT  | 

XSLT, Servlet Filter and a Squeak on Browser Reload

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.

Posted at 06:12AM Jul 30, 2006 by Brian Peter Clark in View Factory & XSLT  | 

Punch in jUDDI

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)
{
}
}
}

Posted at 06:16AM Jul 09, 2006 by Brian Peter Clark in UDDI & jUDDI  | 

The Industrial Estate Design Pattern

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.

Posted at 03:00PM Jun 18, 2006 by Brian Peter Clark in View Factory & XSLT  | 

Writing new tools for Bodington

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:

Add the sql script to the String[] array tables_sql_in_order in org.bodington.installation.Installer.java. The first entry should be the name of the tool's table and the second should be the full path to the SQL script.

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

Posted at 11:57AM Jun 04, 2006 by Andrew G. Booth in Bodington  |  Comments[1]

The Bodington VLE does SOCKET

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.

Posted at 09:10AM Jun 03, 2006 by Andrew G. Booth in Bodington  | 

Running in the Derby

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.

Posted at 05:06PM May 19, 2006 by Brian Peter Clark in Misc technical  |