Kafka - XSL SOAP Toolkit 

News:

Kafka Endpoint Passes UserLand SOAP Validator! - February 27, 2001

I first decided to write the XslConnector object for the Microsoft SOAP Toolkit without thinking enough about what I was going to do with it.  I thought it was a cool idea, and I knew I could use it for testing, but it wasn't until after it was written that I realized that I didn't have any XSL documents that could transform a SOAP request message into a response.  Motivated by the need to make XslConnector not be a complete waste of my time, I bought Micheal Kay's XSLT Programmer's Reference and started to learn XSL.  Five days and little sleep later, I had what looked like the first cut of an XSLT framework for writing SOAP endpoints.  I decided to call it Kafka since a piece of software without a catchy name isn't as much fun, and I just can't think of any more SOAP puns.  

For the record, I want to give credit for this idea to Don Box, who proved that you could build an XSL endpoint about a year ago.  It's taken me this long to free up some time to pursue his idea.

This is an example of using the framework to build an endpoint in XSL.  It's a small framework, but I think that the hooks can be put in place to keep growing it, and the concept seems sound.  As I said above, I started working with this stuff a little over a week ago, so if what follows makes no sense or violates some basic tenet of XSL, just send me an email to let me know, and I'll go back to writing COM code. :)

<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
   <!-- add.xsl : Kafka SOAP Endpoint Example -->

   <!-- Import soap.xsl to use the framework -->
   <xsl:import href="..\kafka\soap.xsl"/>
   <xsl:output method="xml" encoding="utf-8" omit-xml-declaration="yes"/>

   <!-- Define the global variables for the framework -->
   <xsl:variable name="Method">Add</xsl:variable>
   <xsl:variable name="MethodNS">http://www.topxml.com/</xsl:variable>

   <!-- Add : Add two numbers and return the sum -->
   <!-- Function Add( A as Double, B as Double ) as Double -->
   <xsl:template name="ProcessPayload">
      <xsl:param name="Payload"/>
      <xsl:for-each select="$Payload">
         <!-- These lines show you how to look up parameters -->
         <xsl:variable name="A" select="child::*[local-name() = 'A']"/>
         <xsl:variable name="B" select="child::*[local-name() = 'B']"/>

         <!-- The WriteParameter template writes out a parameter, and includes -->
         <!-- the xsi:type attribute needed for Apache. -->
         <xsl:call-template name="WriteParameter">
            <xsl:with-param name="p" select="'Result'"/>
            <xsl:with-param name="v" select="$A + $B"/>
            <xsl:with-param name="t" select="'double'"/>
         </xsl:call-template>
      </xsl:for-each>
   </xsl:template>
   
</xsl:stylesheet>

Here are some of the important points.  The guts of the SOAP processing are in soap.xsl right now, which gets included into the endpoint XSL file like the one above.  soap.xsl has all the templates for verifying the Envelope, version, finding the Body, looking for the indicated payload, etc.  I still need to add Header munging to it, but that shouldn't be too bad.  The soap.xsl file also contains templates for throwing standard faults and writing response parameters.  The endpoint XSL file just has to do two things: define global variable to help the framework know what methods you are expecting (this part is optional), and write a ProcessPayload method that will get called when the methods you indicate are found in the message.  The framework is responsible for making sure that the specification guidelines are met, you are responsible for coding the response parameters.

The best thing about the framework is that you can deploy endpoints using ASP, JSP, or just execute them locally using XslConnector or XslTransport.  The ASP file needed just takes the request and transforms it using MSXML.  It's boilerplate and can be used for any endpoint, just change the name of the XSL file.  I've tested the server with the Microsoft SOAP Toolkit, PocketSOAP, and Apache, and it looks good against all of those clients.  My tests are being done against the endpoints I have built on the server (TimeServer, Add, and my favorite, ID); they all use this framework and illustrate how you can build a couple of different types of endpoints using it.

The worst thing about the framework is that in this first attempt, there is no easy way to implement multiple methods at the same endpoint.  I'm trying to think about a clean way to handle that for the future.  For now, you just use something like <xsl:choose> to figure out the name of the payload and map it accordingly.

This is by no means an endpoint toolkit comparable to Microsoft, Apache, 4S4C, SOAP::Lite, etc.  This is just yet another way to do an endpoint, with its own advantages and disadvantages.  Because of the ability to execute the endpoints locally or remotely, I am convinced it is a useful tool to have in your SOAP programmer's toolbox.  I have some good ideas about how to build this up, but I would appreciate any suggestions.  If you want updates or to talk to me about improvements and things, theTopXMLfolks started a Yahoo group for me at http://groups.yahoo.com/group/soapworkshop, so you can sign up there and talk about SOAP and these tools.

Check out the Kafka XSL files:

soap.xsl

utils.xsl

Download the sample application files here:

Add

TimeServer

ID

Valid

Could someone please:

• Help a Java-impaired individual like myself test with Apache?

• Same as above, with Perl and SOAP::Lite?

For the future:

• Document this whole thing better

• Build more sample applications (XML documents, etc.)

• Build Header support into the framework

• Test with more clients (especially SOAP:Lite and Apache)

• Support for chaining endpoints/transformations

• XML-RPC Support

• WSDL and Smart Page Generation Support

• Suggestions?