SOCKET

SOCKET.net?

A recent article on the Microsoft site:

Calling an Arbitrary Web Service

Scott Golightly, Microsoft Regional Director
Keane, Inc.

April 2006

Posted at 02:46PM May 15, 2006 by Brian Peter Clark in General  |  Comments[14]

QMShibb - Software released

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.

Posted at 01:47PM May 14, 2006 by Andrew G. Booth in Questionmark Perception  | 

QMShibb - Installation, configuration and testing

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:

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.

Posted at 12:26PM May 13, 2006 by Andrew G. Booth in Questionmark Perception  | 

QMShibb - Installing Tomcat with IIS 6

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.

Posted at 01:58PM May 12, 2006 by Andrew G. Booth in Questionmark Perception  | 

11 May 2006

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.

Posted at 07:28PM May 11, 2006 by Brian Peter Clark in General  | 

QMShibb - Shibboleth enabling Questionmark Perception

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

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.

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
This servlet receives the Shibboleth attributes, carries out optional account/group creation and then redirects to a Perception assessment whose id is specified as a parameter in the request's query string. This servlet is accessed via a URL of the form: http://path.to.tomcat/QMShibb/getaccessassessment?assessment=1234567890
The user is presented with the assessment as if she had logged into the perception.dll

getaccessassessmentlist
This servlet receives the Shibboleth attributes, carries out optional account/group creation and then redirects to the user's list of available Perception assessments. This servlet is accessed via a URL of the form: http://path.to.tomcat/QMShibb/getaccessassessmentlist
The user is presented with the assessment list as if she had logged into the perception.dll

getaccessadministrator
This servlet receives the Shibboleth attributes of an existing Perception administrator, and redirects to the Perception Enterprise Manager without account or group creation. This servlet is accessed via a URL of the form: http://path.to.tomcat/QMShibb/getaccessadministrator
The user is presented with the Enterprise Manager as if she had logged into it directly.

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.

Posted at 12:10PM May 09, 2006 by Andrew G. Booth in Questionmark Perception  | 

EE, isn't the View luvvly...

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.

Posted at 07:36PM May 03, 2006 by Brian Peter Clark in View Factory & XSLT  | 

jUDDI Installation

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

<Context path="/juddi" docBase="juddi" debug="5" reloadable="true"
crossContext="true">
<Logger className="org.apache.catalina.logger.FileLogger"
prefix="localhost_juddiDB_log" suffix=".txt"
timestamp="true"/>
<!-- the Resource element will probably work better for
you on Tomcat 5+ if you simply use a Resource only tag
with xml attributes as opposed to the nested ResourceParams and
parameter elements -->
<Resource name="jdbc/juddiDB" auth="Container"
type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000"
username="juddi" password="******"
driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://localhost:3306/juddi?autoReconnect=true" />
</Context>

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

Posted at 03:54PM Apr 27, 2006 by Rob Garbutt in Misc technical  | 

Tomcat Installation

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.

Posted at 08:21AM Apr 27, 2006 by Rob Garbutt in Misc technical  | 

MySQL J Connector/J 3.1 Installation

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

or

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

Posted at 09:24PM Apr 24, 2006 by Rob Garbutt in Misc technical  |  Comments[1]

MySQL Installation

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

Posted at 09:14PM Apr 24, 2006 by Rob Garbutt in Misc technical  | 

Python Installation

To install the latest version of Python.

Download Python from:-

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

Posted at 05:43PM Apr 24, 2006 by Rob Garbutt in Misc technical  | 

Mod Python Installation

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

Posted at 05:40PM Apr 24, 2006 by Rob Garbutt in Misc technical  |  Comments[88]

Moinmoin Wiki Installation

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

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

Posted at 05:34PM Apr 24, 2006 by Rob Garbutt in Misc technical  | 

The SOCKET Admin Console

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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