|
|
You're in the
dotnet web services
group:Best place to use AND how to validate a Version
dotnet web services:
Hi Mike,
For the Xml Types we defined in Xml schemas for webservice's data type or WSDL's message element type, they're all identified and scoped by xml namespace. So generally, for the xml data types and message element types, we will scope them under the sample namespace(or same root namespace....) for example: we can define the root namespace of our webservice as: http://myservice/ and the xml schema can use a sub namespace like: http://myservice/datatypes wsdl message types can use http://myservice/contract as namespace. There is no version info for xml types, just use XML namespace to identify their scope. Also, at runtime, the webservice engine , e.g the ASP.NET webservice handler will parse the xml content and mapping the xml data to types through namespace. So when you need to define new version of the datatypes, you can just define a new schema or other xml data with new namespace.... Thanks, Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- Thread-Topic: Best place to use AND how to validate a Version thread-index: AcXaWtvmrp2mLjaLShOjAyVQmdWyMg== X-WBNR-Posting-Host: 165.176.240.10 From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <MikeLogan@community.nospam> Subject: Best place to use AND how to validate a Version Date: Wed, 26 Oct 2005 11:27:02 -0700 Lines: 21 Message-ID: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Utf-8" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Newsgroups: microsoft.public.dotnet.framework.webservices NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices:8365 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices I am using the "contract first" design methodology. Contract First is design the WSDL first then design the server and client. However I must design my XSD/XML Schema before anything. I am developing my schema now. I have a version on my schema. However once I start the server side code, how is the server now that the right "complexType" is being passed? What happens if this complexType my web service consumes needs to be different. Should every "complexType" in my message have "schemaVersion" element that is non-null, and check that everytime the Web Service is generated. OR I also design my messages in the XML Schema. Should I check the version in the SOAP Header? Thanks for your input. --
I am using the "contract first" design methodology. Contract First is design
the WSDL first then design the server and client. However I must design my XSD/XML Schema before anything. I am developing my schema now. I have a version on my schema. However once I start the server side code, how is the server now that the right "complexType" is being passed? What happens if this complexType my web service consumes needs to be different. Should every "complexType" in my message have "schemaVersion" element that is non-null, and check that everytime the Web Service is generated. OR I also design my messages in the XML Schema. Should I check the version in the SOAP Header? Thanks for your input. --
Hi Mike,
Of course, we can defining datatypes and messages in the same schema. Actually there is no definite rules on this. If you need to adopt some best practice, you may try searching some existing webservice contracts/types schema on the net and get some ideas from them. Thanks, Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- Thread-Topic: Best place to use AND how to validate a Version thread-index: AcXa5HfN7e4LdWiCSDyZuPNob21Ngg== X-WBNR-Posting-Host: 165.176.240.10 From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <MikeLogan@community.nospam> References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> <5421m1dc2gfmfps5370e16bsgr7o72dfm8@4ax.com> Subject: Re: Best place to use AND how to validate a Version Date: Thu, 27 Oct 2005 03:52:04 -0700 Lines: 128 Message-ID: <BD772E91-E908-41CF-A223-108C888D1B61@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Utf-8" Content-Transfer-Encoding: 8bit X-Newsreader: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Newsgroups: microsoft.public.dotnet.framework.webservices NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices:8381 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices Just a followup: I like the idea of using versions in the namespace. However, Steven, in your example, the datatypes schema was seperate from the message schema. If you are on say: "http://mywebservice/datatypes/2005/10/27", and "http://mywebservice/contract/2005/10/27" then change to "http://mywebservice/datatypes/2005/12/5". If this happens I should also have to change my contract/message schema, correct? Is there a place that documents "Best Practices" for this? I was initially defining datatypes and messages in the same schema. I would assume that is alright for a small system? Thanks for the help. -- Mike Logan [quoted text, click to view] "Marvin Smit" wrote:
> Hi Guys, > > This is such a nice topic i couldn't resist putting my 2ct. in ;-) > > The versioning scheme suggested by Henrik is a very common one. You > essentially have the following options; > > - Modify your namespace-uri for different versions (*the example > below) > This is a very strict way of versioning. The problem is that for each > new version your clients will have to "update reference & recompile". > > - include version attribute in your schema > This is how it was intended, but i no of NONE XML-XSD parser that will > actually read/use the version attribute and be able to have multiple > versions of the same schema. > > Please be aware that when you are developing a WebService with .Net > (same goes for Axis AFAIK) that; > > - XSD Validation on the incomming message is NOT THERE by default. > - The deserialization happens with "Defaults" (i.e. an element that is > not found will be filled with ; 0 for numbers, "" for strings, etc) > - The .Net types representing the XSD complextypes are not 100% XSD > equivilant. (You loose the facets in the .Net type, like > 'maxInclusive', maxLength, etc) > > Hope this helps, > > Marvin Smit. > > > On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <hg@websolver.dk> > wrote: > > >Hi Steven and Mike > > > >Sorry for inteferring your thread but.. > > > >I don't know if it is considered "bad practice", but one could also > >embed versioninfo in the XML namespace as: > > > >http://myservice/datatypes/customer/10 > >for version 1.0 of the customer datatype > > > >and http://myservice/datatypes/customer/11 > >for the version 1.1 of the customer datatype > > > >Similar approach could be taken with the contracts. > > > >Anyway. Are there any drawbacks with this approach? > >One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 > >Webservice, will it? > > > >Isn't it right that Indigo deal with this, as there can be many > >"contracts" assigned to a single service? > > > >Looking forward to hear your insights. > > > >Regards > > > >Henrik > > > >Steven Cheng[MSFT] wrote: > >> Hi Mike, > >> > >> For the Xml Types we defined in Xml schemas for webservice's data type or > >> WSDL's message element type, they're all identified and scoped by xml > >> namespace. So generally, for the xml data types and message element types, > >> we will scope them under the sample namespace(or same root namespace....) > >> for example: > >> > >> we can define the root namespace of our webservice as: > >> > >> http://myservice/ > >> > >> and the xml schema can use a sub namespace like: > >> > >> http://myservice/datatypes > >> > >> wsdl message types can use > >> > >> http://myservice/contract > >> > >> as namespace. There is no version info for xml types, just use XML > >> namespace to identify their scope. Also, at runtime, the webservice engine > >> , e.g the ASP.NET webservice handler will parse the xml content and mapping > >> the xml data to types through namespace. So when you need to define new > >> version of the datatypes, you can just define a new schema or other xml > >> data with new namespace.... > >> > >> Thanks, > >> > >> Steven Cheng > >> Microsoft Online Support > >> > >> Get Secure! www.microsoft.com/security > >> (This posting is provided "AS IS", with no warranties, and confers no > >> rights.) > >> > >> > >>
Just a followup:
I like the idea of using versions in the namespace. However, Steven, in your example, the datatypes schema was seperate from the message schema. If you are on say: "http://mywebservice/datatypes/2005/10/27", and "http://mywebservice/contract/2005/10/27" then change to "http://mywebservice/datatypes/2005/12/5". If this happens I should also have to change my contract/message schema, correct? Is there a place that documents "Best Practices" for this? I was initially defining datatypes and messages in the same schema. I would assume that is alright for a small system? Thanks for the help. -- Mike Logan [quoted text, click to view] "Marvin Smit" wrote:
> Hi Guys, > > This is such a nice topic i couldn't resist putting my 2ct. in ;-) > > The versioning scheme suggested by Henrik is a very common one. You > essentially have the following options; > > - Modify your namespace-uri for different versions (*the example > below) > This is a very strict way of versioning. The problem is that for each > new version your clients will have to "update reference & recompile". > > - include version attribute in your schema > This is how it was intended, but i no of NONE XML-XSD parser that will > actually read/use the version attribute and be able to have multiple > versions of the same schema. > > Please be aware that when you are developing a WebService with .Net > (same goes for Axis AFAIK) that; > > - XSD Validation on the incomming message is NOT THERE by default. > - The deserialization happens with "Defaults" (i.e. an element that is > not found will be filled with ; 0 for numbers, "" for strings, etc) > - The .Net types representing the XSD complextypes are not 100% XSD > equivilant. (You loose the facets in the .Net type, like > 'maxInclusive', maxLength, etc) > > Hope this helps, > > Marvin Smit. > > > On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <hg@websolver.dk> > wrote: > > >Hi Steven and Mike > > > >Sorry for inteferring your thread but.. > > > >I don't know if it is considered "bad practice", but one could also > >embed versioninfo in the XML namespace as: > > > >http://myservice/datatypes/customer/10 > >for version 1.0 of the customer datatype > > > >and http://myservice/datatypes/customer/11 > >for the version 1.1 of the customer datatype > > > >Similar approach could be taken with the contracts. > > > >Anyway. Are there any drawbacks with this approach? > >One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 > >Webservice, will it? > > > >Isn't it right that Indigo deal with this, as there can be many > >"contracts" assigned to a single service? > > > >Looking forward to hear your insights. > > > >Regards > > > >Henrik > > > >Steven Cheng[MSFT] wrote: > >> Hi Mike, > >> > >> For the Xml Types we defined in Xml schemas for webservice's data type or > >> WSDL's message element type, they're all identified and scoped by xml > >> namespace. So generally, for the xml data types and message element types, > >> we will scope them under the sample namespace(or same root namespace....) > >> for example: > >> > >> we can define the root namespace of our webservice as: > >> > >> http://myservice/ > >> > >> and the xml schema can use a sub namespace like: > >> > >> http://myservice/datatypes > >> > >> wsdl message types can use > >> > >> http://myservice/contract > >> > >> as namespace. There is no version info for xml types, just use XML > >> namespace to identify their scope. Also, at runtime, the webservice engine > >> , e.g the ASP.NET webservice handler will parse the xml content and mapping > >> the xml data to types through namespace. So when you need to define new > >> version of the datatypes, you can just define a new schema or other xml > >> data with new namespace.... > >> > >> Thanks, > >> > >> Steven Cheng > >> Microsoft Online Support > >> > >> Get Secure! www.microsoft.com/security > >> (This posting is provided "AS IS", with no warranties, and confers no > >> rights.) > >> > >> > >>
Welcome Henrick and thanks for your inputs.
I think the things you mentioned is just I've also involved in my reply. for XML data types, they're defined by xml schema(xsd.. ). And unlike the programming source code/ or assemblies which can have version info. The Xml data types use namespace to identify a certain collection of data, so namespace is a buildin feature for providing version info. In fact, we can find many realworld example like the SOAP 1.1 and SOAP 1.2's schema SOAP 1.1 http://schemas.xmlsoap.org/soap/envelope/ SOAP 1.2 http://www.w3.org/2001/12/soap-envelope Thanks, Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- Date: Thu, 27 Oct 2005 08:03:46 +0200 From: =?ISO-8859-1?Q?Henrik_G=F8ttig?= <hg@websolver.dk> User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: Best place to use AND how to validate a Version References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> In-Reply-To: <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices NNTP-Posting-Host: 194.239.230.244 Lines: 1 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices:8371 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices Hi Steven and Mike Sorry for inteferring your thread but.. I don't know if it is considered "bad practice", but one could also embed versioninfo in the XML namespace as: http://myservice/datatypes/customer/10 for version 1.0 of the customer datatype and http://myservice/datatypes/customer/11 for the version 1.1 of the customer datatype Similar approach could be taken with the contracts. Anyway. Are there any drawbacks with this approach? One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 Webservice, will it? Isn't it right that Indigo deal with this, as there can be many "contracts" assigned to a single service? Looking forward to hear your insights. Regards Henrik [quoted text, click to view] Steven Cheng[MSFT] wrote:
> Hi Mike, > > For the Xml Types we defined in Xml schemas for webservice's data type or > WSDL's message element type, they're all identified and scoped by xml > namespace. So generally, for the xml data types and message element types, > we will scope them under the sample namespace(or same root namespace....) > for example: > > we can define the root namespace of our webservice as: > > http://myservice/ > > and the xml schema can use a sub namespace like: > > http://myservice/datatypes > > wsdl message types can use > > http://myservice/contract > > as namespace. There is no version info for xml types, just use XML > namespace to identify their scope. Also, at runtime, the webservice engine > , e.g the ASP.NET webservice handler will parse the xml content and mapping > the xml data to types through namespace. So when you need to define new > version of the datatypes, you can just define a new schema or other xml > data with new namespace.... > > Thanks, > > Steven Cheng > Microsoft Online Support > > Get Secure! www.microsoft.com/security > (This posting is provided "AS IS", with no warranties, and confers no > rights.) > >
Hi Steven and Mike
Sorry for inteferring your thread but.. I don't know if it is considered "bad practice", but one could also embed versioninfo in the XML namespace as: http://myservice/datatypes/customer/10 for version 1.0 of the customer datatype and http://myservice/datatypes/customer/11 for the version 1.1 of the customer datatype Similar approach could be taken with the contracts. Anyway. Are there any drawbacks with this approach? One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 Webservice, will it? Isn't it right that Indigo deal with this, as there can be many "contracts" assigned to a single service? Looking forward to hear your insights. Regards Henrik [quoted text, click to view] Steven Cheng[MSFT] wrote:
> Hi Mike, > > For the Xml Types we defined in Xml schemas for webservice's data type or > WSDL's message element type, they're all identified and scoped by xml > namespace. So generally, for the xml data types and message element types, > we will scope them under the sample namespace(or same root namespace....) > for example: > > we can define the root namespace of our webservice as: > > http://myservice/ > > and the xml schema can use a sub namespace like: > > http://myservice/datatypes > > wsdl message types can use > > http://myservice/contract > > as namespace. There is no version info for xml types, just use XML > namespace to identify their scope. Also, at runtime, the webservice engine > , e.g the ASP.NET webservice handler will parse the xml content and mapping > the xml data to types through namespace. So when you need to define new > version of the datatypes, you can just define a new schema or other xml > data with new namespace.... > > Thanks, > > Steven Cheng > Microsoft Online Support > > Get Secure! www.microsoft.com/security > (This posting is provided "AS IS", with no warranties, and confers no > rights.) > >
Hi Marvin,
Thanks for your good inputs. I agree with the things you mentioned. Also as for the below: =========== - The .Net types representing the XSD complextypes are not 100% XSD equivilant. (You loose the facets in the .Net type, like 'maxInclusive', maxLength, etc) ============ Yes, .NET type(with xml serliazation attribute) can not 100% express what XSD can do. However, we can accomplish some of those rules in XSD through programming language's code logic. e.g. the 'maxInclusive', maxLength, etc) can be done through code validtion in the property's get/set accessor.... and that's also why we use .NET type mapping. Thanks, Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- From: Marvin Smit <marvin.smit@gmail.com> Newsgroups: microsoft.public.dotnet.framework.webservices Subject: Re: Best place to use AND how to validate a Version Date: Thu, 27 Oct 2005 10:06:00 +0200 Message-ID: <5421m1dc2gfmfps5370e16bsgr7o72dfm8@4ax.com> References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> X-Newsreader: Forte Free Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@chello.nl Organization: chello.nl Lines: 102 NNTP-Posting-Host: 62.194.138.116 (62.194.138.116) NNTP-Posting-Date: Thu, 27 Oct 2005 10:03:21 +0200 X-Trace: d55ff436089c99b672fd116176 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!newsfe ed01.sul.t-online.de!t-online.de!newsfeed01.chello.at!amsnews01.chello.com!a msnews14.chello.com!news.chello.nl.POSTED!not-for-mail Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices:8377 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices Hi Guys, This is such a nice topic i couldn't resist putting my 2ct. in ;-) The versioning scheme suggested by Henrik is a very common one. You essentially have the following options; - Modify your namespace-uri for different versions (*the example below) This is a very strict way of versioning. The problem is that for each new version your clients will have to "update reference & recompile". - include version attribute in your schema This is how it was intended, but i no of NONE XML-XSD parser that will actually read/use the version attribute and be able to have multiple versions of the same schema. Please be aware that when you are developing a WebService with .Net (same goes for Axis AFAIK) that; - XSD Validation on the incomming message is NOT THERE by default. - The deserialization happens with "Defaults" (i.e. an element that is not found will be filled with ; 0 for numbers, "" for strings, etc) - The .Net types representing the XSD complextypes are not 100% XSD equivilant. (You loose the facets in the .Net type, like 'maxInclusive', maxLength, etc) Hope this helps, Marvin Smit. On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <hg@websolver.dk> [quoted text, click to view] wrote:
>Hi Steven and Mike > >Sorry for inteferring your thread but.. > >I don't know if it is considered "bad practice", but one could also >embed versioninfo in the XML namespace as: > >http://myservice/datatypes/customer/10 >for version 1.0 of the customer datatype > >and http://myservice/datatypes/customer/11 >for the version 1.1 of the customer datatype > >Similar approach could be taken with the contracts. > >Anyway. Are there any drawbacks with this approach? >One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 >Webservice, will it? > >Isn't it right that Indigo deal with this, as there can be many >"contracts" assigned to a single service? > >Looking forward to hear your insights. > >Regards > >Henrik > >Steven Cheng[MSFT] wrote: >> Hi Mike, >> >> For the Xml Types we defined in Xml schemas for webservice's data type or >> WSDL's message element type, they're all identified and scoped by xml >> namespace. So generally, for the xml data types and message element types, >> we will scope them under the sample namespace(or same root namespace....) >> for example: >> >> we can define the root namespace of our webservice as: >> >> http://myservice/ >> >> and the xml schema can use a sub namespace like: >> >> http://myservice/datatypes >> >> wsdl message types can use >> >> http://myservice/contract >> >> as namespace. There is no version info for xml types, just use XML >> namespace to identify their scope. Also, at runtime, the webservice engine >> , e.g the ASP.NET webservice handler will parse the xml content and mapping >> the xml data to types through namespace. So when you need to define new >> version of the datatypes, you can just define a new schema or other xml >> data with new namespace.... >> >> Thanks, >> >> Steven Cheng >> Microsoft Online Support >> >> Get Secure! www.microsoft.com/security >> (This posting is provided "AS IS", with no warranties, and confers no >> rights.) >> >>
Hi Guys,
This is such a nice topic i couldn't resist putting my 2ct. in ;-) The versioning scheme suggested by Henrik is a very common one. You essentially have the following options; - Modify your namespace-uri for different versions (*the example below) This is a very strict way of versioning. The problem is that for each new version your clients will have to "update reference & recompile". - include version attribute in your schema This is how it was intended, but i no of NONE XML-XSD parser that will actually read/use the version attribute and be able to have multiple versions of the same schema. Please be aware that when you are developing a WebService with .Net (same goes for Axis AFAIK) that; - XSD Validation on the incomming message is NOT THERE by default. - The deserialization happens with "Defaults" (i.e. an element that is not found will be filled with ; 0 for numbers, "" for strings, etc) - The .Net types representing the XSD complextypes are not 100% XSD equivilant. (You loose the facets in the .Net type, like 'maxInclusive', maxLength, etc) Hope this helps, Marvin Smit. On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <hg@websolver.dk> [quoted text, click to view] wrote:
>Hi Steven and Mike > >Sorry for inteferring your thread but.. > >I don't know if it is considered "bad practice", but one could also >embed versioninfo in the XML namespace as: > >http://myservice/datatypes/customer/10 >for version 1.0 of the customer datatype > >and http://myservice/datatypes/customer/11 >for the version 1.1 of the customer datatype > >Similar approach could be taken with the contracts. > >Anyway. Are there any drawbacks with this approach? >One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 >Webservice, will it? > >Isn't it right that Indigo deal with this, as there can be many >"contracts" assigned to a single service? > >Looking forward to hear your insights. > >Regards > >Henrik > >Steven Cheng[MSFT] wrote: >> Hi Mike, >> >> For the Xml Types we defined in Xml schemas for webservice's data type or >> WSDL's message element type, they're all identified and scoped by xml >> namespace. So generally, for the xml data types and message element types, >> we will scope them under the sample namespace(or same root namespace....) >> for example: >> >> we can define the root namespace of our webservice as: >> >> http://myservice/ >> >> and the xml schema can use a sub namespace like: >> >> http://myservice/datatypes >> >> wsdl message types can use >> >> http://myservice/contract >> >> as namespace. There is no version info for xml types, just use XML >> namespace to identify their scope. Also, at runtime, the webservice engine >> , e.g the ASP.NET webservice handler will parse the xml content and mapping >> the xml data to types through namespace. So when you need to define new >> version of the datatypes, you can just define a new schema or other xml >> data with new namespace.... >> >> Thanks, >> >> Steven Cheng >> Microsoft Online Support >> >> Get Secure! www.microsoft.com/security >> (This posting is provided "AS IS", with no warranties, and confers no >> rights.) >> >>
Hi Marvin (and Steven and Mike and ???)
Thanx for joining in and it is indeed a nice topic :-) Do you know if the question I asked about Indigo applies? Will Indigo deal with versioning in the way, that you can several contracts (message and datatypes) applied to the very same service? So one could say, that this service supports version 1 and version 2 of the contract. I think this is one of the most under-documented "problems" of using the web services stack. ANYONE dealing with web services in production WILL face this issue at some point in time. I have seen others apply "the new service approach", where a change of contract (in an exsting message and/or datatype) results in creating a new branch of the same service just a another endpoint. Regards Henrik [quoted text, click to view] Marvin Smit wrote:
> Hi Guys, > > This is such a nice topic i couldn't resist putting my 2ct. in ;-) > > The versioning scheme suggested by Henrik is a very common one. You > essentially have the following options; > > - Modify your namespace-uri for different versions (*the example > below) > This is a very strict way of versioning. The problem is that for each > new version your clients will have to "update reference & recompile". > > - include version attribute in your schema > This is how it was intended, but i no of NONE XML-XSD parser that will > actually read/use the version attribute and be able to have multiple > versions of the same schema. > > Please be aware that when you are developing a WebService with .Net > (same goes for Axis AFAIK) that; > > - XSD Validation on the incomming message is NOT THERE by default. > - The deserialization happens with "Defaults" (i.e. an element that is > not found will be filled with ; 0 for numbers, "" for strings, etc) > - The .Net types representing the XSD complextypes are not 100% XSD > equivilant. (You loose the facets in the .Net type, like > 'maxInclusive', maxLength, etc) > > Hope this helps, > > Marvin Smit.
Hi Mike,
Any further questions on this issue? If there're anything else we can help, pleas feel free to post here. Thanks , Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- X-Tomcat-ID: 38917779 References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> <5421m1dc2gfmfps5370e16bsgr7o72dfm8@4ax.com> <BD772E91-E908-41CF-A223-108C888D1B61@microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_0001_4E822A8D" Content-Transfer-Encoding: 7bit From: stcheng@online.microsoft.com (Steven Cheng[MSFT]) Organization: Microsoft Date: Fri, 28 Oct 2005 02:15:50 GMT Subject: Re: Best place to use AND how to validate a Version X-Tomcat-NG: microsoft.public.dotnet.framework.webservices Message-ID: <z5$KMW22FHA.1172@TK2MSFTNGXA01.phx.gbl> Newsgroups: microsoft.public.dotnet.framework.webservices Lines: 325 Path: TK2MSFTNGXA01.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices:8396 NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182 Hi Mike, Of course, we can defining datatypes and messages in the same schema. Actually there is no definite rules on this. If you need to adopt some best practice, you may try searching some existing webservice contracts/types schema on the net and get some ideas from them. Thanks, Steven Cheng Microsoft Online Support Get Secure! www.microsoft.com/security (This posting is provided "AS IS", with no warranties, and confers no rights.) -------------------- Thread-Topic: Best place to use AND how to validate a Version thread-index: AcXa5HfN7e4LdWiCSDyZuPNob21Ngg== X-WBNR-Posting-Host: 165.176.240.10 From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <MikeLogan@community.nospam> References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> <5421m1dc2gfmfps5370e16bsgr7o72dfm8@4ax.com> Subject: Re: Best place to use AND how to validate a Version Date: Thu, 27 Oct 2005 03:52:04 -0700 Lines: 128 Message-ID: <BD772E91-E908-41CF-A223-108C888D1B61@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Utf-8" Content-Transfer-Encoding: 8bit X-Newsreader: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Newsgroups: microsoft.public.dotnet.framework.webservices NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250 Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.dotnet.framework.webservices:8381 X-Tomcat-NG: microsoft.public.dotnet.framework.webservices Just a followup: I like the idea of using versions in the namespace. However, Steven, in your example, the datatypes schema was seperate from the message schema. If you are on say: "http://mywebservice/datatypes/2005/10/27", and "http://mywebservice/contract/2005/10/27" then change to "http://mywebservice/datatypes/2005/12/5". If this happens I should also have to change my contract/message schema, correct? Is there a place that documents "Best Practices" for this? I was initially defining datatypes and messages in the same schema. I would assume that is alright for a small system? Thanks for the help. -- Mike Logan [quoted text, click to view] "Marvin Smit" wrote:
> Hi Guys, > > This is such a nice topic i couldn't resist putting my 2ct. in ;-) > > The versioning scheme suggested by Henrik is a very common one. You > essentially have the following options; > > - Modify your namespace-uri for different versions (*the example > below) > This is a very strict way of versioning. The problem is that for each > new version your clients will have to "update reference & recompile". > > - include version attribute in your schema > This is how it was intended, but i no of NONE XML-XSD parser that will > actually read/use the version attribute and be able to have multiple > versions of the same schema. > > Please be aware that when you are developing a WebService with .Net > (same goes for Axis AFAIK) that; > > - XSD Validation on the incomming message is NOT THERE by default. > - The deserialization happens with "Defaults" (i.e. an element that is > not found will be filled with ; 0 for numbers, "" for strings, etc) > - The .Net types representing the XSD complextypes are not 100% XSD > equivilant. (You loose the facets in the .Net type, like > 'maxInclusive', maxLength, etc) > > Hope this helps, > > Marvin Smit. > > > On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <hg@websolver.dk> > wrote: > > >Hi Steven and Mike > > > >Sorry for inteferring your thread but.. > > > >I don't know if it is considered "bad practice", but one could also > >embed versioninfo in the XML namespace as: > > > >http://myservice/datatypes/customer/10 > >for version 1.0 of the customer datatype > > > >and http://myservice/datatypes/customer/11 > >for the version 1.1 of the customer datatype > > > >Similar approach could be taken with the contracts. > > > >Anyway. Are there any drawbacks with this approach? > >One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 > >Webservice, will it? > > > >Isn't it right that Indigo deal with this, as there can be many > >"contracts" assigned to a single service? > > > >Looking forward to hear your insights. > > > >Regards > > > >Henrik > > > >Steven Cheng[MSFT] wrote: > >> Hi Mike, > >> > >> For the Xml Types we defined in Xml schemas for webservice's data type or > >> WSDL's message element type, they're all identified and scoped by xml > >> namespace. So generally, for the xml data types and message element types, > >> we will scope them under the sample namespace(or same root namespace....) > >> for example: > >> > >> we can define the root namespace of our webservice as: > >> > >> http://myservice/ > >> > >> and the xml schema can use a sub namespace like: > >> > >> http://myservice/datatypes > >> > >> wsdl message types can use > >> > >> http://myservice/contract > >> > >> as namespace. There is no version info for xml types, just use XML > >> namespace to identify their scope. Also, at runtime, the webservice engine > >> , e.g the ASP.NET webservice handler will parse the xml content and mapping > >> the xml data to types through namespace. So when you need to define new > >> version of the datatypes, you can just define a new schema or other xml > >> data with new namespace.... > >> > >> Thanks, > >> > >> Steven Cheng > >> Microsoft Online Support > >>
A major issue I've been facing - It is often written that in document
literal style - one has a lot of flexibility and one can do two things specifically - 1=2E Validate the SOAP body against a schema 2=2E Use an XSLT stylesheet to modify the SOAP body. It seems from a previous post - schema validation is not automatically done. How does one do it? At what point can the stylesheet be applied - since the XML gets converted to objects before I can do anything with it.. Thanks! [quoted text, click to view] Steven Cheng[MSFT] wrote:
> Hi Mike, > > Any further questions on this issue? If there're anything else we can hel= p, > pleas feel free to post here. > Thanks , > > Steven Cheng > Microsoft Online Support > > Get Secure! www.microsoft.com/security > (This posting is provided "AS IS", with no warranties, and confers no > rights.) > -------------------- > X-Tomcat-ID: 38917779 > References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> > <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> > <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> > <5421m1dc2gfmfps5370e16bsgr7o72dfm8@4ax.com> > <BD772E91-E908-41CF-A223-108C888D1B61@microsoft.com> > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary=3D"----=3D_NextPart_0001_4E= 822A8D" > Content-Transfer-Encoding: 7bit > From: stcheng@online.microsoft.com (Steven Cheng[MSFT]) > Organization: Microsoft > Date: Fri, 28 Oct 2005 02:15:50 GMT > Subject: Re: Best place to use AND how to validate a Version > X-Tomcat-NG: microsoft.public.dotnet.framework.webservices > Message-ID: <z5$KMW22FHA.1172@TK2MSFTNGXA01.phx.gbl> > Newsgroups: microsoft.public.dotnet.framework.webservices > Lines: 325 > Path: TK2MSFTNGXA01.phx.gbl > Xref: TK2MSFTNGXA01.phx.gbl > microsoft.public.dotnet.framework.webservices:8396 > NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182 > > Hi Mike, > > Of course, we can defining datatypes and messages in the same schema. > Actually there is no definite rules on this. If you need to adopt some be= st > practice, you may try searching some existing webservice contracts/types > schema on the net and get some ideas from them. > > Thanks, > > Steven Cheng > Microsoft Online Support > > Get Secure! www.microsoft.com/security > (This posting is provided "AS IS", with no warranties, and confers no > rights.) > > > > > > -------------------- > Thread-Topic: Best place to use AND how to validate a Version > thread-index: AcXa5HfN7e4LdWiCSDyZuPNob21Ngg=3D=3D > X-WBNR-Posting-Host: 165.176.240.10 > From: "=3D?Utf-8?B?TWlrZSBMb2dhbg=3D=3D?=3D" <MikeLogan@community.nospam> > References: <00AB6074-D71E-4525-BE00-4D113F631907@microsoft.com> > <HYIKmlp2FHA.2904@TK2MSFTNGXA01.phx.gbl> > <u9aM0xr2FHA.3876@TK2MSFTNGP09.phx.gbl> > <5421m1dc2gfmfps5370e16bsgr7o72dfm8@4ax.com> > Subject: Re: Best place to use AND how to validate a Version > Date: Thu, 27 Oct 2005 03:52:04 -0700 > Lines: 128 > Message-ID: <BD772E91-E908-41CF-A223-108C888D1B61@microsoft.com> > MIME-Version: 1.0 > Content-Type: text/plain; > charset=3D"Utf-8" > Content-Transfer-Encoding: 8bit > X-Newsreader: Microsoft CDO for Windows 2000 > Content-Class: urn:content-classes:message > Importance: normal > Priority: normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 > Newsgroups: microsoft.public.dotnet.framework.webservices > NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250 > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl > Xref: TK2MSFTNGXA01.phx.gbl > microsoft.public.dotnet.framework.webservices:8381 > X-Tomcat-NG: microsoft.public.dotnet.framework.webservices > > Just a followup: > > I like the idea of using versions in the namespace. However, Steven, in > your example, the datatypes schema was seperate from the message schema. > If > you are on say: > > "http://mywebservice/datatypes/2005/10/27", and > "http://mywebservice/contract/2005/10/27" > > then change to > > "http://mywebservice/datatypes/2005/12/5". If this happens I should also > have to change my contract/message schema, correct? > > Is there a place that documents "Best Practices" for this? I was initial= ly > defining datatypes and messages in the same schema. I would assume that = is > alright for a small system? > > Thanks for the help. > -- > Mike Logan > > > "Marvin Smit" wrote: > > > Hi Guys, > > > > This is such a nice topic i couldn't resist putting my 2ct. in ;-) > > > > The versioning scheme suggested by Henrik is a very common one. You > > essentially have the following options; > > > > - Modify your namespace-uri for different versions (*the example > > below) > > This is a very strict way of versioning. The problem is that for each > > new version your clients will have to "update reference & recompile". > > > > - include version attribute in your schema > > This is how it was intended, but i no of NONE XML-XSD parser that will > > actually read/use the version attribute and be able to have multiple > > versions of the same schema. > > > > Please be aware that when you are developing a WebService with .Net > > (same goes for Axis AFAIK) that; > > > > - XSD Validation on the incomming message is NOT THERE by default. > > - The deserialization happens with "Defaults" (i.e. an element that is > > not found will be filled with ; 0 for numbers, "" for strings, etc) > > - The .Net types representing the XSD complextypes are not 100% XSD > > equivilant. (You loose the facets in the .Net type, like > > 'maxInclusive', maxLength, etc) > > > > Hope this helps, > > > > Marvin Smit. > > > > > > On Thu, 27 Oct 2005 08:03:46 +0200, Henrik G=F8ttig <hg@websolver.dk> > > wrote: > > > > >Hi Steven and Mike > > > > > >Sorry for inteferring your thread but.. > > > > > >I don't know if it is considered "bad practice", but one could also > > >embed versioninfo in the XML namespace as: > > > > > >http://myservice/datatypes/customer/10 > > >for version 1.0 of the customer datatype > > > > > >and http://myservice/datatypes/customer/11 > > >for the version 1.1 of the customer datatype > > > > > >Similar approach could be taken with the contracts. > > > > > >Anyway. Are there any drawbacks with this approach? > > >One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1 > > >Webservice, will it? > > > > > >Isn't it right that Indigo deal with this, as there can be many > > >"contracts" assigned to a single service? > > > > > >Looking forward to hear your insights. > > > > > >Regards > > > > > >Henrik > > > > > >Steven Cheng[MSFT] wrote: > > >> Hi Mike, > > >> > > >> For the Xml Types we defined in Xml schemas for webservice's data ty= pe > or > > >> WSDL's message element type, they're all identified and scoped by xml > > >> namespace. So generally, for the xml data types and message element > types, > > >> we will scope them under the sample namespace(or same root > namespace....)
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |