Spider has done a significant amount of Web service extensions to our Scoreboard software throughout the past several years. Connect is a tool that uses these Web services to easily integrate data from existing sources into Scoreboard. I've personally found Web service technologies to be quite fascinatingly rewarding to work with.
What's so different about Web service coding, however, as opposed to typical web application programming, is the way that you can make sure your code is working as expected.
When building a typical web application, you can write your code, deploy it, and view it through your web browser. When building any sort of SOA functionality though, all communication is done through code…not quite as "visual" (unless you're also writing a bunch of extra logging code), and arguably a bit more difficult to debug.
I wanted a quick way to test out the Web services that Scoreboard was providing…similar to the way that you might use a SQL console to test out your queries before you throw them into your application.
Of course there are plenty of development tools out there that will explore a WSDL, tell you which endpoints are available, and help you to build clients and POJO's to use those services…but I wanted something simpler.
I already knew exactly what my endpoints were, and what the SOAP messages should look like, it was just a matter of ensuring that they were working as expected. I wanted to send a simple SOAP message, and see what the response looked like before I started writing client code that would consume those services.
Perhaps I just didn't look hard enough, but I couldn't find any tools out there that were a simple "form" that I could throw a SOAP header, body, and URL into, and send them off for a response.
Thus, I built my own. It's a pretty simple Java Swing application that runs completely independent of both Scoreboard and Connect. I'm looking forward to it relieving many headaches related to analyzing JDOM elements through my Eclipse debugger!