If I understand this article correctly, I think the real point they are making is that COBOL is supported in the .NET environment. Indirectly, this allows you to expose COBOL programs as web services - by virtue of the fact that a .NET program can use any other .NET component. Despite the regular hammering of .NET by the J2EE community - this is actually a pretty cool thing. However, this is not saying that your entire Web Services architecture is defined in COBOL (XML parser et al) as was implied in some other threads. You still use the .NET framework to handle the services infrastructure part - delegating to COBOL for the service implementation. Of course, this is a perfectly good way of integrating legacy environments into a WS model. Use the right tool for the job - C++, Java etc for the XML and services infrastructure; COBOL for legacy data access etc. However, there are already a number of alternatives for accessing COBOL programs from OO environments. For example, IBM have an entire connector framework for doing this. J2EE has its connector architecture as well. So...in principle it should be simple to wrap any COBOL code with a Java decorator, so it can be used in a Web Services. Not necessarily as clean as the .NET solution, and certainly a different philiosophy - but probably just as effective. I would invite any comments on this. Perhaps someone has a COBOL web service? regards, paul.
I am going to test your electrical conductivity with this tiny ad:
a bit of art, as a gift, the permaculture playing cards