"Gary Dunne" <KeepYourSpam.Gdunne@zarion.com.deletethis> wrote in message
news:%23pIMoZ$cEHA.3096@tk2msftngp13.phx.gbl...
> 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
>
>

"Dino Chiesa [Microsoft]" <dinoch@online.microsoft.com> wrote in message
news:uqnwS1BdEHA.2664@TK2MSFTNGP09.phx.gbl...
>
> 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
>
>
> "Gary Dunne" <KeepYourSpam.Gdunne@zarion.com.deletethis> wrote in message
> news:%23pIMoZ$cEHA.3096@tk2msftngp13.phx.gbl...
> > 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
> >
> >
>
>

"Gary Dunne" <KeepYourSpam.Gdunne@zarion.com.deletethis> wrote in message
news:u%232h%23eJdEHA.2908@TK2MSFTNGP10.phx.gbl...
> 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 [Microsoft]" <dinoch@online.microsoft.com> wrote in message
> news:uqnwS1BdEHA.2664@TK2MSFTNGP09.phx.gbl...
> >
> > 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
> >
> >
> > "Gary Dunne" <KeepYourSpam.Gdunne@zarion.com.deletethis> wrote in
message
> > news:%23pIMoZ$cEHA.3096@tk2msftngp13.phx.gbl...
> > > I have been provided with a set of wsdl files to create a number of

"Dino Chiesa [Microsoft]" <dinoch@online.microsoft.com> wrote in message
news:e1cppbNdEHA.4048@TK2MSFTNGP12.phx.gbl...
> 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" <KeepYourSpam.Gdunne@zarion.com.deletethis> wrote in message
> news:u%232h%23eJdEHA.2908@TK2MSFTNGP10.phx.gbl...
> > 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 [Microsoft]" <dinoch@online.microsoft.com> wrote in message
> > news:uqnwS1BdEHA.2664@TK2MSFTNGP09.phx.gbl...
> > >
> > > 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