Hard to believe that another year has gone by already; maybe it's just us, but time seems to go faster as we get older. We started this blog back in 2007 and the number of people reading it has grown steadily since then--so thanks for that. It really is depressing when you publish something only to find that nobody actually reads it. The number of comments we get confirms that people are indeed reading the blog. Speaking of comments ...
Chris made a couple of performance-related comments on our post on the new XMLSERVICE tools. We absolutely agree that performance must be a consideration when deploying Web services or, indeed, any application, to production. But we still feel that it's missing our point a bit. Many of the situations we have encountered recently do not call for "10,000s of hits a day." They involve maybe 200 or 300 hits in a day. Even with high transaction rates it can still be faster than currently implemented options. For example, one client currently has a multi-tiered solution in place involving proprietary commercial software and may be able to replace this with XMLSERVICE. Initial tests indicate that it's substantially faster than the client's current approach.
Could it be even better with a custom approach? Of course. But the current hodgepodge came about because the IT staff didn't have time to build the "right" solution. They were on a very tight deadline and used the tooling they were familiar with. They're still resource short, and performance of the current approach is becoming a problem. XMLSERVICE may give them temporary relief and provide another easier way to meet such future needs quickly. This, sadly, is the reality most IBM i shops live with on a daily basis. Like Chris, we'd prefer to take the time to "do it right," but many times that just isn't the way things work.
Chris also noted that "XML seems to have quite a overhead." This is, of course, pretty much inevitable given the text-based nature of XML and the need to parse it to obtain the data. But this is true of all XML usage, and XML is pervasive in the Web service world. The vast majority of Web services used by our clients are XML based, most being SOAP services. As a result, XML skills and tooling are widely available within the company. XML is also supported by most programming languages, including RPG. Given that XMLSERVICE is intended to provide an easy interface to IBM i from any platform, XML, regardless of the performance issues, seems a natural choice.
We would like to see XMLSERVICE sprout a JSON interface. JSON is being increasingly used, particularly when the service is supplying data to a browser application. Because XMLSERVICE is open-source anyone can do it. Perhaps we'll even find time to work on it ourselves in the future.
We hope this doesn't seem like we're picking on Chris. We appreciate the comments and we certainly agree that performance is a consideration in implementing Web services (or any other technology). On the other hand, given that the biggest challenge facing many IBM i shops today is maintaining their relevance, XMLSERVICE's convenience and speed of initial implementation offers hope to RPGers lost in maze of options.