Web Services: The State of the Art in Tooling

[MCWebsite.Staff]

** This thread discusses the article: Web Services: The State of the Art in Tooling **
** This thread discusses the Content article: Web Services: The State of the Art in Tooling **
0

[J.Wells]

Web Services: The State of the Art in Tooling

** This thread discusses the article: Web Services: The State of the Art in Tooling **
Joe, Thank you for the great article! I have an upcoming project that may require me to write (configure? create? build?) some web services (both consumer and producer?) on the 400. This may be what forces me to finally use WDSC. However, it intimidates me that you struggled using WDSC......makes me wonder how I will fare! All that being said, it makes me wonder if I should purchase a tool like this - http://www.rpg-xml.com/ . I have downloaded the free trial and will begin testing shortly. Do you (or anyone else) have any experience with this, or similar products? Thanks, Joe p.s. In your article, you said "I'll introduce the consumer side of the equation: writing applications that consume existing Web services (creating your own Web services to be consumed by others is another topic for another day)." Have you written the second article yet?

[J.Pluta]

Web Services: The State of the Art in Tooling

** This thread discusses the article: Web Services: The State of the Art in Tooling **
Thanks, Joe! I've been away from the Web Services world for a little while now. I'm pretty comfortable in my original position that Web Services aren't quite soup yet; how many years did EDI take to get standardized? And after all is said and done, the biggest business use for Web Services will be as an EDI replacement. Like a lot of things in our industry, the hype far surpassed the reality with this particular technology. In the pure technology world, Web Services is a solution looking for problem. The overhead of SOAP makes it pretty useless for sending small amounts of data (for example, in response to user actions); that's going to be Ajax or some other lean communications protocol. And at the macro-level of messaging, until there is an agreed upon standard for XML messages, the only use is going to be in platform-specific proprietary messaging. That looks like what you might be doing. Since that's a pretty high-level area, performance is less an issue than time-to-market, and so you might consider using a Java-based solution (or even something in .NET). I can't say much about the product you mention; I don't know what it does nor how it works. I do suggest that if you have the time you take a good look at the JAXB support; it seems to me to be the simplest and most straightforward method of creating XML documents that I've seen to date. And who knows? Maybe it's time to write a followup article, eh? Joe

[Guest.Visitor]

Web Services: The State of the Art in Tooling

** This thread discusses the article: Web Services: The State of the Art in Tooling **
Hi Joe, If you are somewhat comfortable with Java then the easiest way would be to wrap RPG programs that need to be exposed as web services into Java classes and then make services out of them using open source apps (such as Tomcat / Axis) running on iSeries or anywhere else. I was considering this route for one of the integration projects and played with the example in the article below on our development box: http://www-128.ibm.com/developerwork...400/index.html It worked fine. Unfortunately the project got shelved due to budgeting constrains so I cannot say anything about performance hit for this type of calls. HTH Dmitriy