Using the .NET WebService tools

G

Gary Dunne

I have been provided with a set of wsdl files to create a number of web
services. Each wsdl file also has a corresponding XSD file.
I've been looking at the various .NET tools that can be used to generate
webservices (XSD.Exe, WSDL.Exe SoapSuds etc) but I'm still at a loss.

Can someone please confirm the following points:
XSD is used to create Serialized code that forms the webservice server
code.
WSDL is used to create the classes that can consume a webservice
SOAPSUDS can be used to create the classes that can consume a webservice
through Remoting

Thanks

Gary
 
D

Dino Chiesa [Microsoft]

the XSD.exe tool can be used to help map between .NET classes and XML files.
(This is called XML Serialization). The XSD.exe tool can read a W3C XML
Schema (XSD file) and produce a class definition that corresponds to that
schema. Instances of that class can then be serialized to instances of XML
documents that conform to the schema.

A WSDL file is a definition of a webservices interface. Think of a
webservice as a bit of logic that accepts a message, does something, and
then replies with another message. The WSDL file describes the messages
that the webservice accepts and returns (among other things). Typically
these messages are defined in (you guessed it) XML Schema. The WSDL file
can internally contain the schema for the incoming and outgoing messages,
or, the WSDL file can reference an external Schema (a separate XSD file)
that defines these things.

WSDL.exe is a tool that slurps in WSDL files and produces either:
- a client side proxy
- a server-side skeleton

The proxy is a class that your app could use to invoke the webservice
described by that WSDL file.
The skeleton is something you would use if you wanted to implement a
webservice that conformed to the given WSDL file. You are probably not
doing that.

----

SOAPSUDS.exe is for adding SOAP support to .NET Remoting - it sounds like
you don't want that here.

The scenarios I have seen are:
you get a WSDL file
run it through wsdl.exe to produce a proxy
build a client-side app that instantitates the proxy, then calls methods
on it.

Note when you use wsdl.exe on a WSDL file that references one or more
external XSD files, you usually have to include the WSDL file and all XSD
files on the command line, eg:

wsdl.exe TheInterface.wsdl Schema1.xsd Schema2.xsd


-Dino
 
G

Gary Dunne

Thanks for your help.

Here's a little more information.

In all I have a been provided with six sets of WSDL /XSD files. In some
cases I have to create a consumer and in others I have to create the web
service itself. The consumers are a mix of VB .Net and VB 6 applications.
Producing the consumers doesn't appear to be a problem (..there is a small
of issue around passing complex types through the SOAP toolkit in VB6 ...
but that's not my main concern at the moment)
I have used a combination of WSDL.Exe and XSD.EXE to produce the web service
classes however I am not sure how to prove that the resulting XML conforms
to the specified schema(s).
Also, in order to have the methods recognised as webmethods I have had to
remove the SOAP header inf that was generated by WSDL

Example - WSDL.Exe produces the following excerpt
<System.Web.Services.Protocols.SoapHeaderAttribute("channelHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapHeaderAttribute("coHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapHeaderAttribute("userHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapDocumentMethodAttribute("NewCTFApplic
ationResponse1",
Use:=System.Web.Services.Description.SoapBindingUse.Literal,
ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Bare)> _
Public Function
NewCTFApplicationResponse1(<System.Xml.Serialization.XmlElementAttribute([Na
mespace]:="http://capita.co.uk/clps/1.0.07/")> ByVal
NewCTFApplicationResponseInput1 As NewCTFApplicationResponseInput1) As
<System.Xml.Serialization.XmlElementAttribute("NewCTFApplicationResponseOutp
ut1", [Namespace]:="http://capita.co.uk/clps/1.0.07/")>
NewCTFApplicationResponseOutput1
Dim results() As Object = Me.Invoke("NewCTFApplicationResponse1",
New Object() {NewCTFApplicationResponseInput1})
Return CType(results(0), NewCTFApplicationResponseOutput1)
End Function

In order to get the method recognised as a web method (and to return a
result) I changed the above to : -

<System.Web.Services.WebService(Namespace:="http://capita.co.uk/clps/NewCTFA
pplicationResponse1")> _
Public Class NewCTFApplicationResponse1
Inherits System.Web.Services.WebService

Public coHeader As coHeaderType

Public userHeader As userHeaderType

Public channelHeader As channelHeaderType

<WebMethod()> _
Public Function
NewCTFApplicationResponse1(<System.Xml.Serialization.XmlElementAttribute([Na
mespace]:="http://capita.co.uk/clps/1.0.07/")> ByVal oResponseInput As
NewCTFApplicationResponseInput1) As
<System.Xml.Serialization.XmlElementAttribute("NewCTFApplicationResponseOutp
ut1", [Namespace]:="http://capita.co.uk/clps/1.0.07/")>
NewCTFApplicationResponseOutput1
Dim oReturn As New NewCTFApplicationResponseOutput1
oReturn.result = "Hello"
Return oReturn
End Function

Thereby removing the SOAP header

Again, thank you for your help.

Gary Dunne
 
D

Dino Chiesa [Microsoft]

Hmmm.,
First,
in your example you show what WSDL.exe has produced.
This appears to be an excerpt from a client-side proxy class.

With the modifications you described, you are trying to convert that
client-side proxy class into a server-side webservice. Is that right?

If you want to generate a service from a WSDL file, why are you not using
the /server switch on the wsdl.exe command ?
wsdl.exe <file> - generates a client-side proxy
wsdl.exe /server <file> - generates a server-side skeleton (Actually an
abstract class)

You will still need to modify the code that is generated using the /server
switch. But it consists of modifications to make the class concrete, not
abstract. In other words, remove the abstract qualifier on the class, and
provide concrete implementations for each of the methods.

I do not recommend using the abstract class as generated from the tool. The
reason is that all of the attributes (which may be many) on the class and
its methods do not apply to subclasses. So you would have to cut-n-paste
all that code, which is error prone. Why do it? Just modify the abstract
class directly.

Does this help?

-D

Gary Dunne said:
Thanks for your help.

Here's a little more information.

In all I have a been provided with six sets of WSDL /XSD files. In some
cases I have to create a consumer and in others I have to create the web
service itself. The consumers are a mix of VB .Net and VB 6 applications.
Producing the consumers doesn't appear to be a problem (..there is a small
of issue around passing complex types through the SOAP toolkit in VB6 ...
but that's not my main concern at the moment)
I have used a combination of WSDL.Exe and XSD.EXE to produce the web service
classes however I am not sure how to prove that the resulting XML conforms
to the specified schema(s).
Also, in order to have the methods recognised as webmethods I have had to
remove the SOAP header inf that was generated by WSDL

Example - WSDL.Exe produces the following excerpt
<System.Web.Services.Protocols.SoapHeaderAttribute("channelHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapHeaderAttribute("coHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapHeaderAttribute("userHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapDocumentMethodAttribute("NewCTFApplic
ationResponse1",
Use:=System.Web.Services.Description.SoapBindingUse.Literal,
ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Bare)> _
Public Function
NewCTFApplicationResponse1(<System.Xml.Serialization.XmlElementAttribute([Na
mespace]:="http://capita.co.uk/clps/1.0.07/")> ByVal
NewCTFApplicationResponseInput1 As NewCTFApplicationResponseInput1) As
<System.Xml.Serialization.XmlElementAttribute("NewCTFApplicationResponseOutp
ut1", [Namespace]:="http://capita.co.uk/clps/1.0.07/")>
NewCTFApplicationResponseOutput1
Dim results() As Object = Me.Invoke("NewCTFApplicationResponse1",
New Object() {NewCTFApplicationResponseInput1})
Return CType(results(0), NewCTFApplicationResponseOutput1)
End Function

In order to get the method recognised as a web method (and to return a
result) I changed the above to : -

<System.Web.Services.WebService(Namespace:="http://capita.co.uk/clps/NewCTFA
pplicationResponse1")> _
Public Class NewCTFApplicationResponse1
Inherits System.Web.Services.WebService

Public coHeader As coHeaderType

Public userHeader As userHeaderType

Public channelHeader As channelHeaderType

<WebMethod()> _
Public Function
NewCTFApplicationResponse1(<System.Xml.Serialization.XmlElementAttribute([Na
mespace]:="http://capita.co.uk/clps/1.0.07/")> ByVal oResponseInput As
NewCTFApplicationResponseInput1) As
<System.Xml.Serialization.XmlElementAttribute("NewCTFApplicationResponseOutp
ut1", [Namespace]:="http://capita.co.uk/clps/1.0.07/")>
NewCTFApplicationResponseOutput1
Dim oReturn As New NewCTFApplicationResponseOutput1
oReturn.result = "Hello"
Return oReturn
End Function

Thereby removing the SOAP header

Again, thank you for your help.

Gary Dunne



Dino Chiesa said:
the XSD.exe tool can be used to help map between .NET classes and XML files.
(This is called XML Serialization). The XSD.exe tool can read a W3C XML
Schema (XSD file) and produce a class definition that corresponds to that
schema. Instances of that class can then be serialized to instances of XML
documents that conform to the schema.

A WSDL file is a definition of a webservices interface. Think of a
webservice as a bit of logic that accepts a message, does something, and
then replies with another message. The WSDL file describes the messages
that the webservice accepts and returns (among other things). Typically
these messages are defined in (you guessed it) XML Schema. The WSDL file
can internally contain the schema for the incoming and outgoing messages,
or, the WSDL file can reference an external Schema (a separate XSD file)
that defines these things.

WSDL.exe is a tool that slurps in WSDL files and produces either:
- a client side proxy
- a server-side skeleton

The proxy is a class that your app could use to invoke the webservice
described by that WSDL file.
The skeleton is something you would use if you wanted to implement a
webservice that conformed to the given WSDL file. You are probably not
doing that.

----

SOAPSUDS.exe is for adding SOAP support to .NET Remoting - it sounds like
you don't want that here.

The scenarios I have seen are:
you get a WSDL file
run it through wsdl.exe to produce a proxy
build a client-side app that instantitates the proxy, then calls methods
on it.

Note when you use wsdl.exe on a WSDL file that references one or more
external XSD files, you usually have to include the WSDL file and all XSD
files on the command line, eg:

wsdl.exe TheInterface.wsdl Schema1.xsd Schema2.xsd


-Dino
 
G

Gary Dunne

I hadn't spotted the Server switch. .... after some tweaking it works
perfectly now.

Thanks for your help .......... saved me a lot of stress and effort :)

Gary Dunne



Dino Chiesa said:
Hmmm.,
First,
in your example you show what WSDL.exe has produced.
This appears to be an excerpt from a client-side proxy class.

With the modifications you described, you are trying to convert that
client-side proxy class into a server-side webservice. Is that right?

If you want to generate a service from a WSDL file, why are you not using
the /server switch on the wsdl.exe command ?
wsdl.exe <file> - generates a client-side proxy
wsdl.exe /server <file> - generates a server-side skeleton (Actually an
abstract class)

You will still need to modify the code that is generated using the /server
switch. But it consists of modifications to make the class concrete, not
abstract. In other words, remove the abstract qualifier on the class, and
provide concrete implementations for each of the methods.

I do not recommend using the abstract class as generated from the tool. The
reason is that all of the attributes (which may be many) on the class and
its methods do not apply to subclasses. So you would have to cut-n-paste
all that code, which is error prone. Why do it? Just modify the abstract
class directly.

Does this help?

-D

Gary Dunne said:
Thanks for your help.

Here's a little more information.

In all I have a been provided with six sets of WSDL /XSD files. In some
cases I have to create a consumer and in others I have to create the web
service itself. The consumers are a mix of VB .Net and VB 6 applications.
Producing the consumers doesn't appear to be a problem (..there is a small
of issue around passing complex types through the SOAP toolkit in VB6 ....
but that's not my main concern at the moment)
I have used a combination of WSDL.Exe and XSD.EXE to produce the web service
classes however I am not sure how to prove that the resulting XML conforms
to the specified schema(s).
Also, in order to have the methods recognised as webmethods I have had to
remove the SOAP header inf that was generated by WSDL

Example - WSDL.Exe produces the following excerpt
<System.Web.Services.Protocols.SoapHeaderAttribute("channelHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapHeaderAttribute("coHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapHeaderAttribute("userHeader",
Direction:=System.Web.Services.Protocols.SoapHeaderDirection.InOut), _
System.Web.Services.Protocols.SoapDocumentMethodAttribute("NewCTFApplic
ationResponse1",
Use:=System.Web.Services.Description.SoapBindingUse.Literal,
ParameterStyle:=System.Web.Services.Protocols.SoapParameterStyle.Bare)> _
Public Function
NewCTFApplicationResponse1(<System.Xml.Serialization.XmlElementAttribute([Na
mespace]:="http://capita.co.uk/clps/1.0.07/")> ByVal
NewCTFApplicationResponseInput1 As NewCTFApplicationResponseInput1) As
<System.Xml.Serialization.XmlElementAttribute("NewCTFApplicationResponseOutp
ut1", [Namespace]:="http://capita.co.uk/clps/1.0.07/")>
NewCTFApplicationResponseOutput1
Dim results() As Object = Me.Invoke("NewCTFApplicationResponse1",
New Object() {NewCTFApplicationResponseInput1})
Return CType(results(0), NewCTFApplicationResponseOutput1)
End Function

In order to get the method recognised as a web method (and to return a
result) I changed the above to : -
<System.Web.Services.WebService(Namespace:="http://capita.co.uk/clps/NewCTFA
pplicationResponse1")> _
Public Class NewCTFApplicationResponse1
Inherits System.Web.Services.WebService

Public coHeader As coHeaderType

Public userHeader As userHeaderType

Public channelHeader As channelHeaderType

<WebMethod()> _
Public Function
NewCTFApplicationResponse1(<System.Xml.Serialization.XmlElementAttribute([Na
mespace]:="http://capita.co.uk/clps/1.0.07/")> ByVal oResponseInput As
NewCTFApplicationResponseInput1) As
<System.Xml.Serialization.XmlElementAttribute("NewCTFApplicationResponseOutp
ut1", [Namespace]:="http://capita.co.uk/clps/1.0.07/")>
NewCTFApplicationResponseOutput1
Dim oReturn As New NewCTFApplicationResponseOutput1
oReturn.result = "Hello"
Return oReturn
End Function

Thereby removing the SOAP header

Again, thank you for your help.

Gary Dunne



Dino Chiesa said:
the XSD.exe tool can be used to help map between .NET classes and XML files.
(This is called XML Serialization). The XSD.exe tool can read a W3C XML
Schema (XSD file) and produce a class definition that corresponds to that
schema. Instances of that class can then be serialized to instances
of
XML
documents that conform to the schema.

A WSDL file is a definition of a webservices interface. Think of a
webservice as a bit of logic that accepts a message, does something, and
then replies with another message. The WSDL file describes the messages
that the webservice accepts and returns (among other things). Typically
these messages are defined in (you guessed it) XML Schema. The WSDL file
can internally contain the schema for the incoming and outgoing messages,
or, the WSDL file can reference an external Schema (a separate XSD file)
that defines these things.

WSDL.exe is a tool that slurps in WSDL files and produces either:
- a client side proxy
- a server-side skeleton

The proxy is a class that your app could use to invoke the webservice
described by that WSDL file.
The skeleton is something you would use if you wanted to implement a
webservice that conformed to the given WSDL file. You are probably not
doing that.

----

SOAPSUDS.exe is for adding SOAP support to .NET Remoting - it sounds like
you don't want that here.

The scenarios I have seen are:
you get a WSDL file
run it through wsdl.exe to produce a proxy
build a client-side app that instantitates the proxy, then calls methods
on it.

Note when you use wsdl.exe on a WSDL file that references one or more
external XSD files, you usually have to include the WSDL file and all XSD
files on the command line, eg:

wsdl.exe TheInterface.wsdl Schema1.xsd Schema2.xsd


-Dino


I have been provided with a set of wsdl files to create a number of web
services. Each wsdl file also has a corresponding XSD file.
I've been looking at the various .NET tools that can be used to generate
webservices (XSD.Exe, WSDL.Exe SoapSuds etc) but I'm still at a loss.

Can someone please confirm the following points:
XSD is used to create Serialized code that forms the webservice server
code.
WSDL is used to create the classes that can consume a webservice
SOAPSUDS can be used to create the classes that can consume a
webservice
through Remoting

Thanks

Gary
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,177
Latest member
OrderGlucea
Top