It is time again for another Soaplet release. This release focuses on support for WSDL (minus arrays and overly complex types - coming in version 0.4). The WSDLSoaplet creates a SOAP message on the fly from the WSDL url. Then all you need to do is set the parameters in that xml document via XPath. So for the Google web service you would do something like this:

setParameter( "//start", "0" );
setParameter( "//maxResults", "10" );
setParameter( "//filter", "true" );
setParameter( "//safeSearch", "false" );
setParameter( "//ie", "latin1" );
setParameter( "//oe", "latin1" );
setParameter( "//key", "your google key" );
setParameter( "//q", "your google query" );

Check out the docs for more information.

Also supported in this release is velocity template autogeneration. For those who aren't familiar with Soaplets, you can create velocity templates which are a soap request - a soap request where you fill in the blanks with velocity code. Once again, I refer you to the Soaplet website for more information.

Bon Apetite!

Well, after spending hours messing around with Axis, due to either my ignorance or Axis's bugs, I've decided to finally create a server side soap implementation. Soaplet was a first step in this direction - separating the java model on the client side from the SOAP message. However, the client end of things is easy - the service contracts have already been created. Just use the WSDL to generate the framework to submit the soap messages - whether this be java code or you are sending an xml document (note: the soaplet framework doesn't do this yet).

On the server side of things - you must create the wsdl document. No one wants to create wsdl by hand or the corresponding XSD. So it is autogenerated - from your code most often. I don't want to create my web service in java though. Why?

• Web services are xml documents not objects (despite what the acronym SOAP stands for). Often can not capture the richness of the service you want to create. Then we get all kinds of metadata into the mix.
• If you change the object model of your service, you end up changing the service model. This can be avoided by create a new set of objects that are almost like your service model but designed for sending over the wire. Ugh.
• Axis is not the best software IMO.
• Current soap software is not simple - all we're doing is sending data over the wire. What's so complicated about that? (don't answer that!)
• For a new fun project to add to my list that teaches me the ins and outs of SOAP :-). (This is the "all-my-above-points-may-be-wrong-but-you-can't-criticize-this-one" comment)

What do I propose then? A four step web service creation process facilitated by some not-yet created software:

1. Create a model
2. From model create WSDL, XSD, and SOAP template
3. Fill in the blanks in the soap template
4. Register requests handlers.

The big question comes at #1. What are the options?

• I could use an existing object model in my app. Then customize WSDL, XSD and SOAP. Sounds like a pain though.
• I could create the web service model by creating some new java interfaces that are similar to what I want my service to look like - they wouldn't be part of my app - just used for web service creation.
• Use UML modeler to create the model.
• Create the WSDL and XSD by hand.

I don't feel like any of these are great solutions, but I lean toward the second one. However - there doesn't need to be a single solution. From this model WSDL, XSD, and soap templates can easily be created. Then it is just a matter of filling in the blanks between the brackets.

Requests handlers could probably done using XPath quite easily. Just query out the elements that you want and bind them to your model. Maybe typed XPath could do this really easily if literal (as opposed to soap encoded) services are used.

Thoughts? Comments? Suggestions? Criticisms?