SOCKET

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  |