Sometimes you need to know when to cut bait.

Back in 2005, I began a project called Crucible. Crucible was my reaction to the constant tech news blurbs about blog sites getting hacked. As I was administering a bulletin board site and was looking to expand the site by using the newer web technologies out there, I was very concerned with site security. After examining the XmlRPC spec that was published at the time, I decided to write my own web service protocol and application framework. This project was called Crucible.

Whereas XmlRPC (ca. 2005) did not have named service parameters, all Crucible services were going to have named and constrained parameters. Not only did I want to avoid a scenario where invalid parameters could unhinge the server, but I also wanted to filter out ridiculous requests and/or DoS attacks based on valid parameters, such as having my dice roller roll six million dice six million times.

The method I employed involved passing XML data between the client (browser) and the server. Additionally, service specification files written in XML would be used as the basis for a service contract between the client and the server. A specification compiler would generate the contractual code in Ruby, Javascript and Java. This contractual code would handle data validation and verification on both client and server, including constraints handling for individual parameters.

While I made some good initial progress, life pressures caused me to put this project on the back burner.

Now that Brick Mill Games is becoming a reality and its digital delivery offerings require a web services backbone, I dusted off this old project to see if it was still valid. The verdict: not so much. I was not the only one looking to improve web service security and people who had day jobs devoted to this and other issues over the past 13 years have moved things along quite nicely. While I still think that using a service specification file to serve as a single point of definition across client and server code, across multiple languages, is still a good idea, the time it would take to convert this project to more modern methodologies and to finish this project would require time that I just don’t have. At the end of the day, users don’t care *how* it works, just that it does work and does so securely.

While I won’t delete the project, I can certainly revisit this after the initial services get off the ground.