Discover web services in my application

robertb_NZ

Well-known member
Joined
May 11, 2010
Messages
146
Location
Auckland, New Zealand
Programming Experience
10+
I want to develop a feature in my VB.NET application that allows the user to discover and use web services, with a dialog that will behave rather like the "Add Service Reference" in Visual Studio. Thus a user can give a URI where services are available, and the dialog responds with a list of the services there. The user selects one of the services, and my program can get the WSDL information to construct COBOL and PL/I access code. The services can be assumed to follow SOAP and WSDL standards.

Are there classes available that will help me with this? What should I read?

Thank you,
Robert Barnes
 
You cannot add a service reference at runtime for a service of a type your application does not know of.

I must not have been clear enough. My application will discover web services (when given a URI) and create COBOL and PL/I objects (record layouts, access code). These are then compiled into programs that will actually access the web service. So it is functioning like Visual Studio, although working with COBOL rather than .NET, and so what I want to do must be possible.

I have previously created WCF web services and VB.NET programs that use these services, so I know how to do this.
 
If all you need is the WSDL for the service, and if that service is hosted through WcfServiceHost.exe, and has metadata exchange enabled, just add ?wsdl at the end of your service URI. That should return the WSDL for the service.
 
I've succeeded in using these classes to read the XML from my WCF web service, but I'm having difficulty interpreting what I'm getting back. The only example that I've found is
DiscoveryClientProtocol Class (System.Web.Services.Discovery)
which is fine as far as it goes but I'm still struggling to find out where I get the services from and how I invoke them. Are there any more examples available?
 
Hence my original comment. What Visual Studio does and you don't see, is that when you add a reference to a web service some proxy interfaces to access that service are generated in the background and linked to your app. You can see the code generated by using svcutil.exe that comes with .NET to generate those proxy classes. You need to do the same with your COBOL program. Without that, your application has no idea how to communicate with the service. You need to read the metadata off the service (if available) and generate those proxy classes, then compile them into your program so that you can instanciate the service from it. Keep in mind I have not done COBOL in 25 years or so, so I have no idea what the tools and IDE are like today.

Maybe it would help if you would post clear examples of the data you are getting back and of the code where you are getting stuck.
 
We chatted a bit more in private about the specifics.

I just wanted to say, personally I think the mainframe days are largely over (at least in terms of what used to be called mainframes). There are still thousands of them running, and there will probably still be in 20 years, but the point is those people running them probably won't have to develop anything new on them for years, because the systems they are using are so mature. This is the main reason there are still many out there, people with old IBM mainframes want to replace hardware without ever touching the software platform, and they are probably right for the most part. However I don't think anybody today will open up a new company and decide to buy a mainframe, it's just counterproductive. Instead you can buy an awesome server rack with 10000x more power at a fraction of the price. And then you can install Linux on it, for FREE.

The only reason people are still using mainframes is because of prior financial investment and love for the platform, the end. Even converting DB2 or sequential data stores is fairly easy today, even for systems that have 20 years of accumulated data to be converted. If a company really wanted to upgrade, they wouldn't want a new mainframe programming language to learn, they would want a proper server, a SQL-like database, and new interfaces to use the data. A migration like this would probably have to be planned for a year or so though, and cost lots of money, so people stick with what they are stuck with that works.
 
See The Mainframe Isn't Dead, and Neither Is the PC - CIO.com

Herman, while in general I agree with you there is still a worthwhile niche that will remain for some time, just as there was a niche for programming Apple computers in the days when Windows was dominant and Apple might have gone out of business had it not been baled out by Microsoft. It would make no sense at all for you with your extremely high Microsoft skills to consider such technology, but for me with adequate-to-good Microsoft skills and also historically excellent mainframe skills it's a different story.

Regards, Robert.
 
Back
Top