Comments on XMLSERVICE Performance

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.

At Your 'XMLSERVICE'

We've had some exciting feedback so far on our latest EXTRA article about using the new XMLSERVICE open-source toolset to turn "ordinary" RPG programs into Web services to easily make your RPG repertoire of business logic more widely available.

We heard from one reader who saw potential in using XMLSERVICE in his company's application. He sent the idea up the chain to one of the internal technical consultants in his company who was apparently sufficiently impressed to send it up to a director, who in turn sent it on to a leading technical architect with a recommendation to pursue a proof of concept (PoC) project. The PoC project will, fortunately, include the person who originally suggested the idea! See what reading our articles can do for your career visibility!

A more general lesson may be derived from this--if you learn about some new technology or technique that sounds like it could be of use in your company's application suite, take a shot at sending it up the management chain. Even if the tool or technique in question proves not to be the best solution, the fact that you took the initiative to identify the potential and to suggest its use can have a very positive impact on your visibility. Indeed it can have a significant impact on the visibility of the IBM i in the organization. All too often when discussing "threatened" systems we find that management rarely knows what the system is capable of and that is part of the reason for the threat.

Another person--a fellow author in the IBM i community, Dan Darnell--emailed us to say he has implemented the XMLSERVICE toolset for calling Web services from EGL. He plans to publish an article about his results shortly. The interesting impact this has for some of his clients is that many of them may be able to use the new free community edition of EGL in combination with XMLSERVICE to implement their applications without the need to purchase the rather pricey RBD tool. (We apologize about that to our friends at Rational!)

We also installed XMLSERVICE recently at a client who is now actively involved in a PoC project of its own to see if it solves a need the client has had for a while to use RPG programs as Web services.

If you have taken a look at using XMLSERVICE, or for that matter any of the other techniques or technologies we've written about recently, let us know. We would love to share your experiences with others.