How to read Web Method and parameters name from Web Service - c#

I am C#.NET developer. I am writing a application which can call web service dynamically. I got one web service that is written in Java. This web service returns only web method name in WSDL file but doesn't returns their input/output parameters details. They keep all details in another XSD link. That xsd link present in WSDL file. I want to know that how I can read that XSD file and how we can read Web Method name and their input and output parameters.
I am looking help on priority.
this is sample link: http://www.java-tutorial.ch/api-doc/ArticleService.html#src.N10068
Thanks in advance.
Rajeev

XSD files are valid XML which means you can parse it with classes from the System.Xml or System.Xml.Linq namespaces. I'm assuming when you say you're dynamically calling the web service that you can't rely on a static WSDL reference in Visual Studio

Assuming you are using Visual Studio and are looking to generate proxy classes to consume the web service you need to add a web reference to the WSDL. You can find instructions on how to do this at microsoft.
This process will generate the classes required to interact with the webservice, including all the methods and properties.
This isn't the only way to generate the proxy classes, but IMHO it's the easiest.
Here is a working example of what you can end up with:
I develop against an ERP system called Netsuite. They provide a WSDL at https://webservices.netsuite.com/wsdl/v2013_2_0/netsuite.wsdl.
Following the instructions in the link above I show the following:
I can now call the class like any other. In order to view the classes now available,
view the reference in the Object Browser. The image below shows all the classes, each one of course you can click into to see what properties are available.

Related

How to create wsdl from xsd

I want to create a wsdl by using 3 xsd-files. How do you that?
I tried this in the command prompt:
wsdl.exe /language:cs /parameters: c:\myService\Contract\HeaderData.xsd c:\myService\Contract\MyData.xsd c:\myService\Contract\Messages.xsd /out: MyWsdl.wsdl
What do I wrong?
I believe that there's a misunderstanding here. Most likely the wsdl.exe in your illustration refers to Microsoft's tool, which is described as:
The Web Services Description Language tool generates code for XML Web services and XML Web service clients from WSDL contract files, XSD schemas, and .discomap discovery documents.
From what you seem to imply by asking the output to be a WSDL file, I can safely assume that you really try to create a WSDL file starting from XSD files. Below I am trying to explain why you cannot do that that easy, and what options you have.
The diagram below shows you the model behind the WSDL 1.1 specification.
Your XSDs fit exactly, and only under types. It WSDL terms, types represent your type system used to describe the parts that make up messages, which are then used to describe input/output and faults of operations organized as ports (abstract interfaces) bound to application/transport protocols, and ultimately made (physically) accessible as services at one or more network endpoints.
To generate WSDL(s) out of XSD(s), you realized by now that you need to provide some more data to a tool that would automatically generate a WSDL for you. For example, what operations you want to describe in your WSDL? For each one of them, what's the input, most likely the output and maybe one or more faults? How would you group them (portType = interface)? What binding do you want to use: HTTP, SOAP? What version of SOAP? SOAP over: HTTP, MQ? SOAPAction? How many WSDL files: 1, or maybe 3?
Some tools may ask you a series of questions (data entry/wizards) along the above lines and then create the WSDL(s) for you. Others, use predefined patterns in the implementation of XSD schema constructs (for example, IFX has a certain way to define Request/Response elements) so based on those assumptions a specialized tool such as QTAssistant (I am associated with it) would ask you less questions, while still creating the WSDLs.
I remember one or two online tools that were able to allow the user to upload XSD files and then create WSDL after prompting you a couple of questions, but I can't seem to find them anymore... kind of like this one...
From my understanding, you don't go xsd->wsdl, but I could be wrong.
Generating a WSDL from an XSD file might help clear it up for you though.
You cannot auto-generate a WSDL from an XSD in this manner. In order to create the WSDL, you need to start with a new WSDL and import this XSD.
The XSD defines the types of data that are available for services. Some XSD is usually embedded in a WSDL, some are imported specifically.
An alternate way is to use the XSD in C# to generate a service, and then extract the concrete WSDL from that service, but this is not preferred as many teams prefer contract first web services.

How do I create a simple SOAP server using C# in Visual Studio 2010?

I was trying to follow the instructions here but they seem to quickly be getting very specific to Sharepoint, as they go along further. I just want a general tutorial for creating a non-sharepoint SOAP starter projects, and Google is not my friend, at the moment.
It seems that some of the above steps are applicable.
So far I have:
A solution 'WebSite1' created with File -> New Website.
A 'ClassLibrary1' project in C#, with System.Web.Services added to References.
a key02.snk (strongname key file) file node in the classlibrary1.
No code implementing any SOAP server methods yet.
No idea how to add code to the above, and then build and run, and have a soap hello-world type method.
I'd like to implement a simple HelloWorld method that takes at least one parameter. The resulting service could be queried for its WSDL with a url like this:
http[s]://localhost/myfirstsoapserver/helloWorldMethod1.asmx?WSDL
If my guess above is right, the above Url would be usable by any tool that can import WSDL.
My goal is rapid prototyping and mocking up of various other SOAP interfaces that I need to deal with, and I'm hoping that C#+visualStudio2010+IIS is a reasonably easy way to do that.
First create a new project as a web application:
Then add a new item of type web service:
Have you considered using WCF?: http://msdn.microsoft.com/en-us/library/bb386386.aspx

how to generate wsdl with SvcUtil?

Is it possible to generate wsdl with use of SvcUtil or any other tool. I know I can view wsdl in browser while running the service but I need to have one wsdl file that doesn't have xsd:import directive but rather specifies all the information in this file.
If it's a one off you could manually construct the single WSDL file. But that's no fun. :)
Another way is to create an endpoint behavior. See Improving WCF Interoperability: Flattening your WSDL for the full details.

C# WSDL proxy methods

I need to consume a SOAP web service from a C# .Net 4.0 client. I've added the WSDL as a Service Reference in VS 2008 and can now see the XML types as classes so I can construct the SOAP message.
The WSDL Port is defined as an Interface and the two operations defined in the WSDL (UploadMessage and ValidateMessage) are visible methods.
How do you actually use these methods? I thought the Port would be available as a class so you could directly call the methods and that VS would have created the relevant code for sending the SOAP message, but it looks like you have to write code to go in these methods. Is that correct?
I have googled this but can't find a simple example using .Net 4.0 ;-(
When you add your service using Add Service Reference, you should have a new namespace (which you defined in the Add Service Reference dialog box - bottom left corner).
Inside that namespace, there ought to be a class called something like (yourservicename)Client.
If you can't find it, open up the Service References node in your Visual Studio Solution Explorer, and find the Show All Files button in the Solution Explorer's little toolbar - click on it to see all files.
Under your Service Reference, several nodes deep, you should find a file called Reference.cs which contains the code classes generated from your WSDL.
In that Reference.cs, you should find your client class. This is a regular class, which you can instantiate in your code and call methods on. This will call the web service methods on that remote server you want to connect to.
Typically a Service Reference will create a class called [ServiceName]Client that implements the interface you mentioned.
New it up, then call the operations.
Of far greater importance than getting the client and calling it will be your configuration, which will be dependent on the service. This article will help.

How to call a webservice in the same website?

I have to call a webservice published in the same website the caller aspx is.
When I try to "Add a Web Reference" the editor does not show the webservice methods from the generated namespace.
Do I have to use the "Add Web Reference" or is there another way because the webservice is in the same website?
Visual Studio 2005, C#
Thanks,
Eduardo
I used the way that Andy Rose wrote in comments:
Instantiate the webservice class and call the methods directly because it is accessible inside the project (no need to add web reference).
There are ways to trick it... You can deploy the app with the web service, then add reference to the deployed location.
Another idea is to just start it using ctrl-f5 so as to not start the debugger as well, then add a reference to your localhost:/.asmx
This will get all of the configuration information created in your web.config which, of course, you can modify later as necessary.
The Webreference itself is just a proxy implementation so that VS can pretend it knows how your webservice will react to calls to it (so you can compile), you can actually code without them (though it is much harder :)).
You have a few of options, that I can think of, if you want to do this:
Create your webservice as a separate project, but deploy it to the same location. You will get mixed binaries in the bin directory, but otherwise it should work fine. In this way you can deploy each separately as needed.
Consider pulling them apart into two separate applications. This might not be available for whatever reason.
Create a stub webservice in your main project, which only has the function definitions (return type and parameters) and deploy that, then generate your webservice against that. You can then begin your development against the prototype and fill it in as necessary
Do the two-step shuffle as Chris suggested. First create a approximate representation of your webservice, deploy it. Second create your proxy against it, create your web app, deploy it and test. Repeat as necessary.
Once your proxy is created you can change the URL it points to in the proxy bindings.

Categories

Resources