Schemas they say ...
 

Hi group.

They say:
Start with your schema definition of both messages and custom datatypes that
might be used in your messages.

I can follow that approach, I can see the logic, I can see why I have to
import schema(s) into WSDL document.'

This seems like the way to go, for the best interop webservice design.
You get a "domain model" of schema types

But, can anyone tell me if Microsoft have fixed (or will fix and if so when)
the "bug" with import of schemas:

If I generate proxy classes for two web services (WSDL docs), which happens
to share the same schema type (say Customer), I get two "non-compatible"
classes (Customer) for the same schema type.

Anyone, please..

What about this Dan Rogers guy...He seems to be knowing a lot about web
services (judged from his latest posts) :-)

Regards

Henrik

RE: Schemas they say ...
 

Hi Henrik,

The sharing of types between proxies is a feature that is on the list for
Visual Studio 2005.

In the mean time, you can overcome this on an as-needed basis by making the
two proxies share the same implementation of the classes that are
implementing your types. If you look at the two generated proxies, you'll
find that the issue is that the two proxies are in different .NET
namespaces - and thus the two types are, to the runtime type system, not
the same thing. To get around this, an easy fix is to take the code that
you wish to see in common and put it into a separate .NET namespace and
compile it into a new assembly. Then add a reference to this new assembly
to your project, and make the generated proxy code reference the new types.
You can do this by adding a Using or Imports statement at the top of the
proxy file and commenting out the types you have moved into the new
namespace.

Once you have done this, the type sharing will be working. If you
regenerate your proxies (refresh reference), the changes will be lost, so
you may also want to take the hidden proxy code and save it as a normal
code file. Proxies aren't special, or even very complex, so there is
little to lose by taking control over them in this way.

Regards,

Dan Rogers
Microsoft Corporation
--------------------
>From: "HG" <hg@nospam.websolver.dk>
>Subject: Schemas they say ...
>Date: Fri, 12 Nov 2004 11:50:21 +0100
>Lines: 29
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>NNTP-Posting-Host: 194.239.230.253
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP09
.phx.gbl
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservic es:26496
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>
>Hi group.
>
>They say:
>Start with your schema definition of both messages and custom datatypes
that
>might be used in your messages.
>
>I can follow that approach, I can see the logic, I can see why I have to
>import schema(s) into WSDL document.'
>
>This seems like the way to go, for the best interop webservice design.
>You get a "domain model" of schema types
>
>But, can anyone tell me if Microsoft have fixed (or will fix and if so
when)
>the "bug" with import of schemas:
>
>If I generate proxy classes for two web services (WSDL docs), which happens
>to share the same schema type (say Customer), I get two "non-compatible"
>classes (Customer) for the same schema type.
>
>Anyone, please..
>
>What about this Dan Rogers guy...He seems to be knowing a lot about web
>services (judged from his latest posts) :-)
>
>Regards
>
>Henrik
>
>
>

Re: Schemas they say ...
 

Hi Dan

Thanx for the reply. Very useful indeed, and nice to see that it is a
feature of VS 2005.

But what about the approach?

To me it seems "right" to have a "domain model" described in terms of XML
Schemas and generate proxies and (data)objects for those Schemas.

So you have schemas defining the messages (web service methods) and
you have schemas defining the "domain model", eg. what can be affected by
your messages.

The "message" schemas reference the "domain model" schemas through imports.

Last you have the WSDL which references the "message" schemas and NOT the
"domain model" schemas as they are already there through the "message"
schemas.

Is this considered "best practice"...Is there any best practice at all...?

Regards

Henrik



"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
news:t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl...
> Hi Henrik,
>
> The sharing of types between proxies is a feature that is on the list for
> Visual Studio 2005.
>
> In the mean time, you can overcome this on an as-needed basis by making
the
> two proxies share the same implementation of the classes that are
> implementing your types. If you look at the two generated proxies, you'll
> find that the issue is that the two proxies are in different .NET
> namespaces - and thus the two types are, to the runtime type system, not
> the same thing. To get around this, an easy fix is to take the code that
> you wish to see in common and put it into a separate .NET namespace and
> compile it into a new assembly. Then add a reference to this new assembly
> to your project, and make the generated proxy code reference the new
types.
> You can do this by adding a Using or Imports statement at the top of the
> proxy file and commenting out the types you have moved into the new
> namespace.
>
> Once you have done this, the type sharing will be working. If you
> regenerate your proxies (refresh reference), the changes will be lost, so
> you may also want to take the hidden proxy code and save it as a normal
> code file. Proxies aren't special, or even very complex, so there is
> little to lose by taking control over them in this way.
>
> Regards,
>
> Dan Rogers
> Microsoft Corporation
> --------------------
> >From: "HG" <hg@nospam.websolver.dk>
> >Subject: Schemas they say ...
> >Date: Fri, 12 Nov 2004 11:50:21 +0100
> >Lines: 29
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
> >NNTP-Posting-Host: 194.239.230.253
> >Path:
>
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP09
> phx.gbl
> >Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.aspnet.webservic es:26496
> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
> >
> >Hi group.
> >
> >They say:
> >Start with your schema definition of both messages and custom datatypes
> that
> >might be used in your messages.
> >
> >I can follow that approach, I can see the logic, I can see why I have to
> >import schema(s) into WSDL document.'
> >
> >This seems like the way to go, for the best interop webservice design.
> >You get a "domain model" of schema types
> >
> >But, can anyone tell me if Microsoft have fixed (or will fix and if so
> when)
> >the "bug" with import of schemas:
> >
> >If I generate proxy classes for two web services (WSDL docs), which
happens
> >to share the same schema type (say Customer), I get two "non-compatible"
> >classes (Customer) for the same schema type.
> >
> >Anyone, please..
> >
> >What about this Dan Rogers guy...He seems to be knowing a lot about web
> >services (judged from his latest posts) :-)
> >
> >Regards
> >
> >Henrik
> >
> >
> >
>

Re: Schemas they say ...
 

Hi Henrik,

That model you describe makes sense. The thing to watch out for are
version issues. In this approach it is easy to have someone sneak a schema
change into the lower level model and have unexpected consequences above
it. Consider a compiled service that expects a particular set of
information in one of the messages it processes. At some point X after the
service is deployed, a well meaning editor changes the domain model schema
and just puts it back in place.

Any compiled code that was based on the original state of that schema is
now compromised, and possibly broken.

Without a careful control over how changes are introduced to schema, even a
pure XML view of the world is broken because of the distributed nature of
callers and service providers. In most cases where software is involved,
you can't change the contract on the wire without negative impact on the
running systems. So the danger I caution you about is to "lock down" your
schemas and broadly communicate that the approach to separate schemas in
this way was done to achieve benefits (whatever they may be) that do not
include the ability to edit them independently due to the versioning and
application stability issues that changes introduce.

Does this make sense?

Thanks

Dan Rogers
Microsoft Corporation
--------------------
>From: "HG" <hg@nospam.websolver.dk>
>References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
<t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
>Subject: Re: Schemas they say ...
>Date: Tue, 16 Nov 2004 09:30:01 +0100
>Lines: 116
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Message-ID: <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
>Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>NNTP-Posting-Host: 194.239.230.253
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP14
..phx.gbl
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservic es:26594
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>
>Hi Dan
>
>Thanx for the reply. Very useful indeed, and nice to see that it is a
>feature of VS 2005.
>
>But what about the approach?
>
>To me it seems "right" to have a "domain model" described in terms of XML
>Schemas and generate proxies and (data)objects for those Schemas.
>
>So you have schemas defining the messages (web service methods) and
>you have schemas defining the "domain model", eg. what can be affected by
>your messages.
>
>The "message" schemas reference the "domain model" schemas through imports.
>
>Last you have the WSDL which references the "message" schemas and NOT the
>"domain model" schemas as they are already there through the "message"
>schemas.
>
>Is this considered "best practice"...Is there any best practice at all...?
>
>Regards
>
>Henrik
>
>
>
>"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
>news:t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl...
>> Hi Henrik,
>>
>> The sharing of types between proxies is a feature that is on the list for
>> Visual Studio 2005.
>>
>> In the mean time, you can overcome this on an as-needed basis by making
>the
>> two proxies share the same implementation of the classes that are
>> implementing your types. If you look at the two generated proxies,
you'll
>> find that the issue is that the two proxies are in different .NET
>> namespaces - and thus the two types are, to the runtime type system, not
>> the same thing. To get around this, an easy fix is to take the code that
>> you wish to see in common and put it into a separate .NET namespace and
>> compile it into a new assembly. Then add a reference to this new
assembly
>> to your project, and make the generated proxy code reference the new
>types.
>> You can do this by adding a Using or Imports statement at the top of
the
>> proxy file and commenting out the types you have moved into the new
>> namespace.
>>
>> Once you have done this, the type sharing will be working. If you
>> regenerate your proxies (refresh reference), the changes will be lost, so
>> you may also want to take the hidden proxy code and save it as a normal
>> code file. Proxies aren't special, or even very complex, so there is
>> little to lose by taking control over them in this way.
>>
>> Regards,
>>
>> Dan Rogers
>> Microsoft Corporation
>> --------------------
>> >From: "HG" <hg@nospam.websolver.dk>
>> >Subject: Schemas they say ...
>> >Date: Fri, 12 Nov 2004 11:50:21 +0100
>> >Lines: 29
>> >X-Priority: 3
>> >X-MSMail-Priority: Normal
>> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>> >Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>> >NNTP-Posting-Host: 194.239.230.253
>> >Path:
>>
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSF TNGP08.phx.gbl!TK2MSFTNGP0
9
>> phx.gbl
>> >Xref: cpmsftngxa10.phx.gbl
>> microsoft.public.dotnet.framework.aspnet.webservic es:26496
>> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>> >
>> >Hi group.
>> >
>> >They say:
>> >Start with your schema definition of both messages and custom datatypes
>> that
>> >might be used in your messages.
>> >
>> >I can follow that approach, I can see the logic, I can see why I have to
>> >import schema(s) into WSDL document.'
>> >
>> >This seems like the way to go, for the best interop webservice design.
>> >You get a "domain model" of schema types
>> >
>> >But, can anyone tell me if Microsoft have fixed (or will fix and if so
>> when)
>> >the "bug" with import of schemas:
>> >
>> >If I generate proxy classes for two web services (WSDL docs), which
>happens
>> >to share the same schema type (say Customer), I get two "non-compatible"
>> >classes (Customer) for the same schema type.
>> >
>> >Anyone, please..
>> >
>> >What about this Dan Rogers guy...He seems to be knowing a lot about web
>> >services (judged from his latest posts) :-)
>> >
>> >Regards
>> >
>> >Henrik
>> >
>> >
>> >
>>
>
>
>

Re: Schemas they say ...
 

Hi Dan

Sure it makes sense.

The same thing applies for the WSDLs themselves. With this approach the
files "where things can go wrong if you edit them" has been doubled because
you make dependencies among the files (eg. schema-to-schema and
wsdl-to-schema).

Do you have any other approach to versioning, than the "usual" one..Applying
version information as part of the namespace/URI?

Regards and thanx for you very useful answers

Henrik

"Dan Rogers" <danro@microsoft.com> wrote in message
news:s416OSBzEHA.3984@cpmsftngxa10.phx.gbl...
> Hi Henrik,
>
> That model you describe makes sense. The thing to watch out for are
> version issues. In this approach it is easy to have someone sneak a
schema
> change into the lower level model and have unexpected consequences above
> it. Consider a compiled service that expects a particular set of
> information in one of the messages it processes. At some point X after
the
> service is deployed, a well meaning editor changes the domain model schema
> and just puts it back in place.
>
> Any compiled code that was based on the original state of that schema is
> now compromised, and possibly broken.
>
> Without a careful control over how changes are introduced to schema, even
a
> pure XML view of the world is broken because of the distributed nature of
> callers and service providers. In most cases where software is involved,
> you can't change the contract on the wire without negative impact on the
> running systems. So the danger I caution you about is to "lock down" your
> schemas and broadly communicate that the approach to separate schemas in
> this way was done to achieve benefits (whatever they may be) that do not
> include the ability to edit them independently due to the versioning and
> application stability issues that changes introduce.
>
> Does this make sense?
>
> Thanks
>
> Dan Rogers
> Microsoft Corporation
> --------------------
> >From: "HG" <hg@nospam.websolver.dk>
> >References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
> <t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
> >Subject: Re: Schemas they say ...
> >Date: Tue, 16 Nov 2004 09:30:01 +0100
> >Lines: 116
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >Message-ID: <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
> >NNTP-Posting-Host: 194.239.230.253
> >Path:
>
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP14
> phx.gbl
> >Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.aspnet.webservic es:26594
> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
> >
> >Hi Dan
> >
> >Thanx for the reply. Very useful indeed, and nice to see that it is a
> >feature of VS 2005.
> >
> >But what about the approach?
> >
> >To me it seems "right" to have a "domain model" described in terms of XML
> >Schemas and generate proxies and (data)objects for those Schemas.
> >
> >So you have schemas defining the messages (web service methods) and
> >you have schemas defining the "domain model", eg. what can be affected by
> >your messages.
> >
> >The "message" schemas reference the "domain model" schemas through
imports.
> >
> >Last you have the WSDL which references the "message" schemas and NOT the
> >"domain model" schemas as they are already there through the "message"
> >schemas.
> >
> >Is this considered "best practice"...Is there any best practice at
all...?
> >
> >Regards
> >
> >Henrik
> >
> >
> >
> >"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
> >news:t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl...
> >> Hi Henrik,
> >>
> >> The sharing of types between proxies is a feature that is on the list
for
> >> Visual Studio 2005.
> >>
> >> In the mean time, you can overcome this on an as-needed basis by making
> >the
> >> two proxies share the same implementation of the classes that are
> >> implementing your types. If you look at the two generated proxies,
> you'll
> >> find that the issue is that the two proxies are in different .NET
> >> namespaces - and thus the two types are, to the runtime type system,
not
> >> the same thing. To get around this, an easy fix is to take the code
that
> >> you wish to see in common and put it into a separate .NET namespace and
> >> compile it into a new assembly. Then add a reference to this new
> assembly
> >> to your project, and make the generated proxy code reference the new
> >types.
> >> You can do this by adding a Using or Imports statement at the top of
> the
> >> proxy file and commenting out the types you have moved into the new
> >> namespace.
> >>
> >> Once you have done this, the type sharing will be working. If you
> >> regenerate your proxies (refresh reference), the changes will be lost,
so
> >> you may also want to take the hidden proxy code and save it as a normal
> >> code file. Proxies aren't special, or even very complex, so there is
> >> little to lose by taking control over them in this way.
> >>
> >> Regards,
> >>
> >> Dan Rogers
> >> Microsoft Corporation
> >> --------------------
> >> >From: "HG" <hg@nospam.websolver.dk>
> >> >Subject: Schemas they say ...
> >> >Date: Fri, 12 Nov 2004 11:50:21 +0100
> >> >Lines: 29
> >> >X-Priority: 3
> >> >X-MSMail-Priority: Normal
> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >> >Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
> >> >NNTP-Posting-Host: 194.239.230.253
> >> >Path:
> >>
>
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSF TNGP08.phx.gbl!TK2MSFTNGP0
> 9
> >> phx.gbl
> >> >Xref: cpmsftngxa10.phx.gbl
> >> microsoft.public.dotnet.framework.aspnet.webservic es:26496
> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
> >> >
> >> >Hi group.
> >> >
> >> >They say:
> >> >Start with your schema definition of both messages and custom
datatypes
> >> that
> >> >might be used in your messages.
> >> >
> >> >I can follow that approach, I can see the logic, I can see why I have
to
> >> >import schema(s) into WSDL document.'
> >> >
> >> >This seems like the way to go, for the best interop webservice design.
> >> >You get a "domain model" of schema types
> >> >
> >> >But, can anyone tell me if Microsoft have fixed (or will fix and if so
> >> when)
> >> >the "bug" with import of schemas:
> >> >
> >> >If I generate proxy classes for two web services (WSDL docs), which
> >happens
> >> >to share the same schema type (say Customer), I get two
"non-compatible"
> >> >classes (Customer) for the same schema type.
> >> >
> >> >Anyone, please..
> >> >
> >> >What about this Dan Rogers guy...He seems to be knowing a lot about
web
> >> >services (judged from his latest posts) :-)
> >> >
> >> >Regards
> >> >
> >> >Henrik
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>

Re: Schemas they say ...
 

Hi Henrik,

Yes, there is a lot you can do to prepare a time insensitive stable
interface, and to prepare your schemas for a forward compatible versioning
strategy.

With web services, however, there are versioning related issues that go
beyond schema. The really hard one is whether you want to have an
application code base that is version-agile. Think of version agility as
the ability for a V1 compiled calling application to be reconnected to a V2
service implementation. The service needs to be constructed so that it is
both interface compatible with the V1 callers, but also logic compatible.
Similarly, you may want to accommodate V2 compiled calling applications
that connect to a V1 service implementation. You won't want the V1 service
in this case to choke - so V1 has to be V2 interface compatible from the
get-go, and still be able to operate (perhaps with reduced functionality).

The trick to gaining this agililty is to provide for two kinds of
versioning mechanisms in your schema design. I describe one of them in an
article I published last year on MSDN
(http://www.microsoft.com/downloads/d...c46b-4dea-4786
-9eb0-8733e41bf5a8&DisplayLang=en)

In this download you'll find some samples that work around this simple
schema construct:
<xs:complexType name="extensibleType" abstract="true" block="#all" >
<xs:annotation>
<xs:documentation>
Type that creates the usage pattern convention being prescribed.
Derive (by extension) from this type to create an extensible type.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="extensions" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="extension" minOccurs="0" maxOccurs="unbounded" >
<xs:complexType>
<xs:sequence>
<xs:element name="docExtension" minOccurs="1" maxOccurs="1"
type="xs:anyType" />
</xs:sequence>
<xs:attribute name="extensionId" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>

Along with an implementation. Your interfaces (version agile inputs and
outputs) derive from this type, and you put version specific payload
requirements in extensions - which are just other complexTypes that are
well known to your application. Your base method calls are always the V1
base, and for a V2 application, you can either add in to the
request/response payload at the Extension point, or you can put a marker in
your schema for your version specific definitions and follow that marker
with an XS:Any.

These two approaches in combination let you create a version stable,
version agile interface that lets the same base methods and payloads
suffice where they cross over between your application versions. Each time
you introduce a new method - say in a new version of your product or
service, you create a new baseline for that message. The "any" treatment
lets you add in things that are ignored by the older versions of your
application (you keep the schema namespace constant), and the extension
pattern lets you make version agile, round-trip-able request/responses that
let you return data that an app doesn't know about but still have that app
return that when it is approprate for it to round trip some server data
after making changes to known payloads.

It's a bit deep for a single message... but this is the crux of tackling
this issue in your distributed, XML based interfaces going forward. Over
time it is likely you'll see these patterns formalized - right now they are
just workable approaches that can be implemented now.

I hope this helps, and if this was too much detail, I appologize,

Dan Rogers
Microsoft Corporation
--------------------
>From: "hug" <hug@rollon.com>
>Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
<t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
<uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
<s416OSBzEHA.3984@cpmsftngxa10.phx.gbl>
>Subject: Re: Schemas they say ...
>Date: Wed, 17 Nov 2004 02:05:15 +0100
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Lines: 207
>Message-ID: <419aa3cc$0$22685$ba624c82@nntp04.dk.telia.net>
>NNTP-Posting-Host: 212.10.120.159
>X-Trace: 1100653517 news.stofanet.dk 22685 212.10.120.159
>X-Complaints-To: Telia Stofa Abuse <abuse@stofa.dk>
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!newsfeed00.s
ul.t-online.de!t-online.de!frankfurt1.telia.de!newsfeed101.telia.co m!nf02.dk
telia.net!news104.dk.telia.net!not-for-mail
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservic es:26647
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>
>Hi Dan
>
>Sure it makes sense.
>
>The same thing applies for the WSDLs themselves. With this approach the
>files "where things can go wrong if you edit them" has been doubled because
>you make dependencies among the files (eg. schema-to-schema and
>wsdl-to-schema).
>
>Do you have any other approach to versioning, than the "usual"
one..Applying
>version information as part of the namespace/URI?
>
>Regards and thanx for you very useful answers
>
>Henrik
>
>"Dan Rogers" <danro@microsoft.com> wrote in message
>news:s416OSBzEHA.3984@cpmsftngxa10.phx.gbl...
>> Hi Henrik,
>>
>> That model you describe makes sense. The thing to watch out for are
>> version issues. In this approach it is easy to have someone sneak a
>schema
>> change into the lower level model and have unexpected consequences above
>> it. Consider a compiled service that expects a particular set of
>> information in one of the messages it processes. At some point X after
>the
>> service is deployed, a well meaning editor changes the domain model
schema
>> and just puts it back in place.
>>
>> Any compiled code that was based on the original state of that schema is
>> now compromised, and possibly broken.
>>
>> Without a careful control over how changes are introduced to schema, even
>a
>> pure XML view of the world is broken because of the distributed nature of
>> callers and service providers. In most cases where software is involved,
>> you can't change the contract on the wire without negative impact on the
>> running systems. So the danger I caution you about is to "lock down"
your
>> schemas and broadly communicate that the approach to separate schemas in
>> this way was done to achieve benefits (whatever they may be) that do not
>> include the ability to edit them independently due to the versioning and
>> application stability issues that changes introduce.
>>
>> Does this make sense?
>>
>> Thanks
>>
>> Dan Rogers
>> Microsoft Corporation
>> --------------------
>> >From: "HG" <hg@nospam.websolver.dk>
>> >References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>> <t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
>> >Subject: Re: Schemas they say ...
>> >Date: Tue, 16 Nov 2004 09:30:01 +0100
>> >Lines: 116
>> >X-Priority: 3
>> >X-MSMail-Priority: Normal
>> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>> >Message-ID: <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
>> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>> >NNTP-Posting-Host: 194.239.230.253
>> >Path:
>>
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSF TNGP08.phx.gbl!TK2MSFTNGP1
4
>> phx.gbl
>> >Xref: cpmsftngxa10.phx.gbl
>> microsoft.public.dotnet.framework.aspnet.webservic es:26594
>> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>> >
>> >Hi Dan
>> >
>> >Thanx for the reply. Very useful indeed, and nice to see that it is a
>> >feature of VS 2005.
>> >
>> >But what about the approach?
>> >
>> >To me it seems "right" to have a "domain model" described in terms of
XML
>> >Schemas and generate proxies and (data)objects for those Schemas.
>> >
>> >So you have schemas defining the messages (web service methods) and
>> >you have schemas defining the "domain model", eg. what can be affected
by
>> >your messages.
>> >
>> >The "message" schemas reference the "domain model" schemas through
>imports.
>> >
>> >Last you have the WSDL which references the "message" schemas and NOT
the
>> >"domain model" schemas as they are already there through the "message"
>> >schemas.
>> >
>> >Is this considered "best practice"...Is there any best practice at
>all...?
>> >
>> >Regards
>> >
>> >Henrik
>> >
>> >
>> >
>> >"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
>> >news:t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl...
>> >> Hi Henrik,
>> >>
>> >> The sharing of types between proxies is a feature that is on the list
>for
>> >> Visual Studio 2005.
>> >>
>> >> In the mean time, you can overcome this on an as-needed basis by
making
>> >the
>> >> two proxies share the same implementation of the classes that are
>> >> implementing your types. If you look at the two generated proxies,
>> you'll
>> >> find that the issue is that the two proxies are in different .NET
>> >> namespaces - and thus the two types are, to the runtime type system,
>not
>> >> the same thing. To get around this, an easy fix is to take the code
>that
>> >> you wish to see in common and put it into a separate .NET namespace
and
>> >> compile it into a new assembly. Then add a reference to this new
>> assembly
>> >> to your project, and make the generated proxy code reference the new
>> >types.
>> >> You can do this by adding a Using or Imports statement at the top of
>> the
>> >> proxy file and commenting out the types you have moved into the new
>> >> namespace.
>> >>
>> >> Once you have done this, the type sharing will be working. If you
>> >> regenerate your proxies (refresh reference), the changes will be lost,
>so
>> >> you may also want to take the hidden proxy code and save it as a
normal
>> >> code file. Proxies aren't special, or even very complex, so there is
>> >> little to lose by taking control over them in this way.
>> >>
>> >> Regards,
>> >>
>> >> Dan Rogers
>> >> Microsoft Corporation
>> >> --------------------
>> >> >From: "HG" <hg@nospam.websolver.dk>
>> >> >Subject: Schemas they say ...
>> >> >Date: Fri, 12 Nov 2004 11:50:21 +0100
>> >> >Lines: 29
>> >> >X-Priority: 3
>> >> >X-MSMail-Priority: Normal
>> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>> >> >Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>> >> >NNTP-Posting-Host: 194.239.230.253
>> >> >Path:
>> >>
>>
>>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MS FTNGP08.phx.gbl!TK2MSFTNGP
0
>> 9
>> >> phx.gbl
>> >> >Xref: cpmsftngxa10.phx.gbl
>> >> microsoft.public.dotnet.framework.aspnet.webservic es:26496
>> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>> >> >
>> >> >Hi group.
>> >> >
>> >> >They say:
>> >> >Start with your schema definition of both messages and custom
>datatypes
>> >> that
>> >> >might be used in your messages.
>> >> >
>> >> >I can follow that approach, I can see the logic, I can see why I have
>to
>> >> >import schema(s) into WSDL document.'
>> >> >
>> >> >This seems like the way to go, for the best interop webservice
design.
>> >> >You get a "domain model" of schema types
>> >> >
>> >> >But, can anyone tell me if Microsoft have fixed (or will fix and if
so
>> >> when)
>> >> >the "bug" with import of schemas:
>> >> >
>> >> >If I generate proxy classes for two web services (WSDL docs), which
>> >happens
>> >> >to share the same schema type (say Customer), I get two
>"non-compatible"
>> >> >classes (Customer) for the same schema type.
>> >> >
>> >> >Anyone, please..
>> >> >
>> >> >What about this Dan Rogers guy...He seems to be knowing a lot about
>web
>> >> >services (judged from his latest posts) :-)
>> >> >
>> >> >Regards
>> >> >
>> >> >Henrik
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>>
>
>
>

Re: Schemas they say ...
 

Hi Dan

It way eactly this detail I needed. Very interesting point of views.

Maybe, in the future, it will be a part of the UDDI registry job to handle
versioning in some standard way?

Thanx for your input.

Best regards

Henrik

"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
news:QV8CjpEzEHA.3028@cpmsftngxa10.phx.gbl...
> Hi Henrik,
>
> Yes, there is a lot you can do to prepare a time insensitive stable
> interface, and to prepare your schemas for a forward compatible versioning
> strategy.
>
> With web services, however, there are versioning related issues that go
> beyond schema. The really hard one is whether you want to have an
> application code base that is version-agile. Think of version agility as
> the ability for a V1 compiled calling application to be reconnected to a
V2
> service implementation. The service needs to be constructed so that it is
> both interface compatible with the V1 callers, but also logic compatible.
> Similarly, you may want to accommodate V2 compiled calling applications
> that connect to a V1 service implementation. You won't want the V1
service
> in this case to choke - so V1 has to be V2 interface compatible from the
> get-go, and still be able to operate (perhaps with reduced functionality).
>
> The trick to gaining this agililty is to provide for two kinds of
> versioning mechanisms in your schema design. I describe one of them in an
> article I published last year on MSDN
>
(http://www.microsoft.com/downloads/d...c46b-4dea-4786
> -9eb0-8733e41bf5a8&DisplayLang=en)
>
> In this download you'll find some samples that work around this simple
> schema construct:
> <xs:complexType name="extensibleType" abstract="true" block="#all" >
> <xs:annotation>
> <xs:documentation>
> Type that creates the usage pattern convention being prescribed.
> Derive (by extension) from this type to create an extensible type.
> </xs:documentation>
> </xs:annotation>
> <xs:sequence>
> <xs:element name="extensions" minOccurs="0" maxOccurs="1">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="extension" minOccurs="0" maxOccurs="unbounded" >
> <xs:complexType>
> <xs:sequence>
> <xs:element name="docExtension" minOccurs="1" maxOccurs="1"
> type="xs:anyType" />
> </xs:sequence>
> <xs:attribute name="extensionId" type="xs:string" use="required"/>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
>
> Along with an implementation. Your interfaces (version agile inputs and
> outputs) derive from this type, and you put version specific payload
> requirements in extensions - which are just other complexTypes that are
> well known to your application. Your base method calls are always the V1
> base, and for a V2 application, you can either add in to the
> request/response payload at the Extension point, or you can put a marker
in
> your schema for your version specific definitions and follow that marker
> with an XS:Any.
>
> These two approaches in combination let you create a version stable,
> version agile interface that lets the same base methods and payloads
> suffice where they cross over between your application versions. Each
time
> you introduce a new method - say in a new version of your product or
> service, you create a new baseline for that message. The "any" treatment
> lets you add in things that are ignored by the older versions of your
> application (you keep the schema namespace constant), and the extension
> pattern lets you make version agile, round-trip-able request/responses
that
> let you return data that an app doesn't know about but still have that app
> return that when it is approprate for it to round trip some server data
> after making changes to known payloads.
>
> It's a bit deep for a single message... but this is the crux of tackling
> this issue in your distributed, XML based interfaces going forward. Over
> time it is likely you'll see these patterns formalized - right now they
are
> just workable approaches that can be implemented now.
>
> I hope this helps, and if this was too much detail, I appologize,
>
> Dan Rogers
> Microsoft Corporation
> --------------------
> >From: "hug" <hug@rollon.com>
> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
> >References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
> <t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
> <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
> <s416OSBzEHA.3984@cpmsftngxa10.phx.gbl>
> >Subject: Re: Schemas they say ...
> >Date: Wed, 17 Nov 2004 02:05:15 +0100
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >Lines: 207
> >Message-ID: <419aa3cc$0$22685$ba624c82@nntp04.dk.telia.net>
> >NNTP-Posting-Host: 212.10.120.159
> >X-Trace: 1100653517 news.stofanet.dk 22685 212.10.120.159
> >X-Complaints-To: Telia Stofa Abuse <abuse@stofa.dk>
> >Path:
>
cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFT NGP08.phx.gbl!newsfeed00.s
>
ul.t-online.de!t-online.de!frankfurt1.telia.de!newsfeed101.telia.co m!nf02.dk
> telia.net!news104.dk.telia.net!not-for-mail
> >Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.aspnet.webservic es:26647
> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
> >
> >Hi Dan
> >
> >Sure it makes sense.
> >
> >The same thing applies for the WSDLs themselves. With this approach the
> >files "where things can go wrong if you edit them" has been doubled
because
> >you make dependencies among the files (eg. schema-to-schema and
> >wsdl-to-schema).
> >
> >Do you have any other approach to versioning, than the "usual"
> one..Applying
> >version information as part of the namespace/URI?
> >
> >Regards and thanx for you very useful answers
> >
> >Henrik
> >
> >"Dan Rogers" <danro@microsoft.com> wrote in message
> >news:s416OSBzEHA.3984@cpmsftngxa10.phx.gbl...
> >> Hi Henrik,
> >>
> >> That model you describe makes sense. The thing to watch out for are
> >> version issues. In this approach it is easy to have someone sneak a
> >schema
> >> change into the lower level model and have unexpected consequences
above
> >> it. Consider a compiled service that expects a particular set of
> >> information in one of the messages it processes. At some point X after
> >the
> >> service is deployed, a well meaning editor changes the domain model
> schema
> >> and just puts it back in place.
> >>
> >> Any compiled code that was based on the original state of that schema
is
> >> now compromised, and possibly broken.
> >>
> >> Without a careful control over how changes are introduced to schema,
even
> >a
> >> pure XML view of the world is broken because of the distributed nature
of
> >> callers and service providers. In most cases where software is
involved,
> >> you can't change the contract on the wire without negative impact on
the
> >> running systems. So the danger I caution you about is to "lock down"
> your
> >> schemas and broadly communicate that the approach to separate schemas
in
> >> this way was done to achieve benefits (whatever they may be) that do
not
> >> include the ability to edit them independently due to the versioning
and
> >> application stability issues that changes introduce.
> >>
> >> Does this make sense?
> >>
> >> Thanks
> >>
> >> Dan Rogers
> >> Microsoft Corporation
> >> --------------------
> >> >From: "HG" <hg@nospam.websolver.dk>
> >> >References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
> >> <t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
> >> >Subject: Re: Schemas they say ...
> >> >Date: Tue, 16 Nov 2004 09:30:01 +0100
> >> >Lines: 116
> >> >X-Priority: 3
> >> >X-MSMail-Priority: Normal
> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >> >Message-ID: <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
> >> >NNTP-Posting-Host: 194.239.230.253
> >> >Path:
> >>
>
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSF TNGP08.phx.gbl!TK2MSFTNGP1
> 4
> >> phx.gbl
> >> >Xref: cpmsftngxa10.phx.gbl
> >> microsoft.public.dotnet.framework.aspnet.webservic es:26594
> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
> >> >
> >> >Hi Dan
> >> >
> >> >Thanx for the reply. Very useful indeed, and nice to see that it is a
> >> >feature of VS 2005.
> >> >
> >> >But what about the approach?
> >> >
> >> >To me it seems "right" to have a "domain model" described in terms of
> XML
> >> >Schemas and generate proxies and (data)objects for those Schemas.
> >> >
> >> >So you have schemas defining the messages (web service methods) and
> >> >you have schemas defining the "domain model", eg. what can be affected
> by
> >> >your messages.
> >> >
> >> >The "message" schemas reference the "domain model" schemas through
> >imports.
> >> >
> >> >Last you have the WSDL which references the "message" schemas and NOT
> the
> >> >"domain model" schemas as they are already there through the "message"
> >> >schemas.
> >> >
> >> >Is this considered "best practice"...Is there any best practice at
> >all...?
> >> >
> >> >Regards
> >> >
> >> >Henrik
> >> >
> >> >
> >> >
> >> >"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
> >> >news:t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl...
> >> >> Hi Henrik,
> >> >>
> >> >> The sharing of types between proxies is a feature that is on the
list
> >for
> >> >> Visual Studio 2005.
> >> >>
> >> >> In the mean time, you can overcome this on an as-needed basis by
> making
> >> >the
> >> >> two proxies share the same implementation of the classes that are
> >> >> implementing your types. If you look at the two generated proxies,
> >> you'll
> >> >> find that the issue is that the two proxies are in different .NET
> >> >> namespaces - and thus the two types are, to the runtime type system,
> >not
> >> >> the same thing. To get around this, an easy fix is to take the code
> >that
> >> >> you wish to see in common and put it into a separate .NET namespace
> and
> >> >> compile it into a new assembly. Then add a reference to this new
> >> assembly
> >> >> to your project, and make the generated proxy code reference the new
> >> >types.
> >> >> You can do this by adding a Using or Imports statement at the top
of
> >> the
> >> >> proxy file and commenting out the types you have moved into the new
> >> >> namespace.
> >> >>
> >> >> Once you have done this, the type sharing will be working. If you
> >> >> regenerate your proxies (refresh reference), the changes will be
lost,
> >so
> >> >> you may also want to take the hidden proxy code and save it as a
> normal
> >> >> code file. Proxies aren't special, or even very complex, so there
is
> >> >> little to lose by taking control over them in this way.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Dan Rogers
> >> >> Microsoft Corporation
> >> >> --------------------
> >> >> >From: "HG" <hg@nospam.websolver.dk>
> >> >> >Subject: Schemas they say ...
> >> >> >Date: Fri, 12 Nov 2004 11:50:21 +0100
> >> >> >Lines: 29
> >> >> >X-Priority: 3
> >> >> >X-MSMail-Priority: Normal
> >> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
> >> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> >> >> >Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
> >> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
> >> >> >NNTP-Posting-Host: 194.239.230.253
> >> >> >Path:
> >> >>
> >>
>
>>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MS FTNGP08.phx.gbl!TK2MSFTNGP
> 0
> >> 9
> >> >> phx.gbl
> >> >> >Xref: cpmsftngxa10.phx.gbl
> >> >> microsoft.public.dotnet.framework.aspnet.webservic es:26496
> >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
> >> >> >
> >> >> >Hi group.
> >> >> >
> >> >> >They say:
> >> >> >Start with your schema definition of both messages and custom
> >datatypes
> >> >> that
> >> >> >might be used in your messages.
> >> >> >
> >> >> >I can follow that approach, I can see the logic, I can see why I
have
> >to
> >> >> >import schema(s) into WSDL document.'
> >> >> >
> >> >> >This seems like the way to go, for the best interop webservice
> design.
> >> >> >You get a "domain model" of schema types
> >> >> >
> >> >> >But, can anyone tell me if Microsoft have fixed (or will fix and if
> so
> >> >> when)
> >> >> >the "bug" with import of schemas:
> >> >> >
> >> >> >If I generate proxy classes for two web services (WSDL docs), which
> >> >happens
> >> >> >to share the same schema type (say Customer), I get two
> >"non-compatible"
> >> >> >classes (Customer) for the same schema type.
> >> >> >
> >> >> >Anyone, please..
> >> >> >
> >> >> >What about this Dan Rogers guy...He seems to be knowing a lot about
> >web
> >> >> >services (judged from his latest posts) :-)
> >> >> >
> >> >> >Regards
> >> >> >
> >> >> >Henrik
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>

Re: Schemas they say ...
 

Hi Henrik,

The UDDI registry allows you to descibe interfaces and then include version
compatibility information. Each interface would be represented by a
tModel. Each version would be represented by a different tModel.

Then when you register an individual endpoint, you would include the tModel
that represents the interface, and each of the supported version tModel
identifiers. This would set a convention that says "I support this verison
and this version of this interface.". Similarly, you could represent each
individual extension by a tModel and then create a policy expression
registration (by using a tModle that means "policy") and thus expose
information about policy by making the policy tModel key a part of the end
point signature. The detail URL on the policy node in the end point
signature would point to the WS-Policy that describes which extensions are
accepted or required.

So, yes, this was the intent when we designed the UDDI approach to concept
registration.
Hope that helps

Dan Rogers
Technical Chair, Specification Author, Architect UDDI V1, V2
Microsoft Corporation
--------------------
>From: "HG" <hg@nospam.websolver.dk>
>References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
<t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
<uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
<s416OSBzEHA.3984@cpmsftngxa10.phx.gbl>
<419aa3cc$0$22685$ba624c82@nntp04.dk.telia.net>
<QV8CjpEzEHA.3028@cpmsftngxa10.phx.gbl>
>Subject: Re: Schemas they say ...
>Date: Wed, 17 Nov 2004 09:09:59 +0100
>Lines: 372
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>Message-ID: <Ow$sWzHzEHA.3336@TK2MSFTNGP11.phx.gbl>
>Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>NNTP-Posting-Host: 194.239.230.253
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA02.phx.gbl!TK2MSFT NGXA01.phx.gbl!TK2MSFTNGP0
8.phx.gbl!TK2MSFTNGP11.phx.gbl
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservic es:26657
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>
>Hi Dan
>
>It way eactly this detail I needed. Very interesting point of views.
>
>Maybe, in the future, it will be a part of the UDDI registry job to handle
>versioning in some standard way?
>
>Thanx for your input.
>
>Best regards
>
>Henrik
>
>"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
>news:QV8CjpEzEHA.3028@cpmsftngxa10.phx.gbl...
>> Hi Henrik,
>>
>> Yes, there is a lot you can do to prepare a time insensitive stable
>> interface, and to prepare your schemas for a forward compatible
versioning
>> strategy.
>>
>> With web services, however, there are versioning related issues that go
>> beyond schema. The really hard one is whether you want to have an
>> application code base that is version-agile. Think of version agility as
>> the ability for a V1 compiled calling application to be reconnected to a
>V2
>> service implementation. The service needs to be constructed so that it
is
>> both interface compatible with the V1 callers, but also logic compatible.
>> Similarly, you may want to accommodate V2 compiled calling applications
>> that connect to a V1 service implementation. You won't want the V1
>service
>> in this case to choke - so V1 has to be V2 interface compatible from the
>> get-go, and still be able to operate (perhaps with reduced
functionality).
>>
>> The trick to gaining this agililty is to provide for two kinds of
>> versioning mechanisms in your schema design. I describe one of them in
an
>> article I published last year on MSDN
>>
>(http://www.microsoft.com/downloads/d...cc46b-4dea-478
6
>> -9eb0-8733e41bf5a8&DisplayLang=en)
>>
>> In this download you'll find some samples that work around this simple
>> schema construct:
>> <xs:complexType name="extensibleType" abstract="true" block="#all" >
>> <xs:annotation>
>> <xs:documentation>
>> Type that creates the usage pattern convention being prescribed.
>> Derive (by extension) from this type to create an extensible type.
>> </xs:documentation>
>> </xs:annotation>
>> <xs:sequence>
>> <xs:element name="extensions" minOccurs="0" maxOccurs="1">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="extension" minOccurs="0" maxOccurs="unbounded" >
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="docExtension" minOccurs="1" maxOccurs="1"
>> type="xs:anyType" />
>> </xs:sequence>
>> <xs:attribute name="extensionId" type="xs:string" use="required"/>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>>
>> Along with an implementation. Your interfaces (version agile inputs and
>> outputs) derive from this type, and you put version specific payload
>> requirements in extensions - which are just other complexTypes that are
>> well known to your application. Your base method calls are always the V1
>> base, and for a V2 application, you can either add in to the
>> request/response payload at the Extension point, or you can put a marker
>in
>> your schema for your version specific definitions and follow that marker
>> with an XS:Any.
>>
>> These two approaches in combination let you create a version stable,
>> version agile interface that lets the same base methods and payloads
>> suffice where they cross over between your application versions. Each
>time
>> you introduce a new method - say in a new version of your product or
>> service, you create a new baseline for that message. The "any" treatment
>> lets you add in things that are ignored by the older versions of your
>> application (you keep the schema namespace constant), and the extension
>> pattern lets you make version agile, round-trip-able request/responses
>that
>> let you return data that an app doesn't know about but still have that
app
>> return that when it is approprate for it to round trip some server data
>> after making changes to known payloads.
>>
>> It's a bit deep for a single message... but this is the crux of tackling
>> this issue in your distributed, XML based interfaces going forward. Over
>> time it is likely you'll see these patterns formalized - right now they
>are
>> just workable approaches that can be implemented now.
>>
>> I hope this helps, and if this was too much detail, I appologize,
>>
>> Dan Rogers
>> Microsoft Corporation
>> --------------------
>> >From: "hug" <hug@rollon.com>
>> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>> >References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>> <t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
>> <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
>> <s416OSBzEHA.3984@cpmsftngxa10.phx.gbl>
>> >Subject: Re: Schemas they say ...
>> >Date: Wed, 17 Nov 2004 02:05:15 +0100
>> >X-Priority: 3
>> >X-MSMail-Priority: Normal
>> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>> >Lines: 207
>> >Message-ID: <419aa3cc$0$22685$ba624c82@nntp04.dk.telia.net>
>> >NNTP-Posting-Host: 212.10.120.159
>> >X-Trace: 1100653517 news.stofanet.dk 22685 212.10.120.159
>> >X-Complaints-To: Telia Stofa Abuse <abuse@stofa.dk>
>> >Path:
>>
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSF TNGP08.phx.gbl!newsfeed00.
s
>>
>ul.t-online.de!t-online.de!frankfurt1.telia.de!newsfeed101.telia.co m!nf02.d
k
>> telia.net!news104.dk.telia.net!not-for-mail
>> >Xref: cpmsftngxa10.phx.gbl
>> microsoft.public.dotnet.framework.aspnet.webservic es:26647
>> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>> >
>> >Hi Dan
>> >
>> >Sure it makes sense.
>> >
>> >The same thing applies for the WSDLs themselves. With this approach the
>> >files "where things can go wrong if you edit them" has been doubled
>because
>> >you make dependencies among the files (eg. schema-to-schema and
>> >wsdl-to-schema).
>> >
>> >Do you have any other approach to versioning, than the "usual"
>> one..Applying
>> >version information as part of the namespace/URI?
>> >
>> >Regards and thanx for you very useful answers
>> >
>> >Henrik
>> >
>> >"Dan Rogers" <danro@microsoft.com> wrote in message
>> >news:s416OSBzEHA.3984@cpmsftngxa10.phx.gbl...
>> >> Hi Henrik,
>> >>
>> >> That model you describe makes sense. The thing to watch out for are
>> >> version issues. In this approach it is easy to have someone sneak a
>> >schema
>> >> change into the lower level model and have unexpected consequences
>above
>> >> it. Consider a compiled service that expects a particular set of
>> >> information in one of the messages it processes. At some point X
after
>> >the
>> >> service is deployed, a well meaning editor changes the domain model
>> schema
>> >> and just puts it back in place.
>> >>
>> >> Any compiled code that was based on the original state of that schema
>is
>> >> now compromised, and possibly broken.
>> >>
>> >> Without a careful control over how changes are introduced to schema,
>even
>> >a
>> >> pure XML view of the world is broken because of the distributed nature
>of
>> >> callers and service providers. In most cases where software is
>involved,
>> >> you can't change the contract on the wire without negative impact on
>the
>> >> running systems. So the danger I caution you about is to "lock down"
>> your
>> >> schemas and broadly communicate that the approach to separate schemas
>in
>> >> this way was done to achieve benefits (whatever they may be) that do
>not
>> >> include the ability to edit them independently due to the versioning
>and
>> >> application stability issues that changes introduce.
>> >>
>> >> Does this make sense?
>> >>
>> >> Thanks
>> >>
>> >> Dan Rogers
>> >> Microsoft Corporation
>> >> --------------------
>> >> >From: "HG" <hg@nospam.websolver.dk>
>> >> >References: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>> >> <t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
>> >> >Subject: Re: Schemas they say ...
>> >> >Date: Tue, 16 Nov 2004 09:30:01 +0100
>> >> >Lines: 116
>> >> >X-Priority: 3
>> >> >X-MSMail-Priority: Normal
>> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>> >> >Message-ID: <uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
>> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>> >> >NNTP-Posting-Host: 194.239.230.253
>> >> >Path:
>> >>
>>
>>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MS FTNGP08.phx.gbl!TK2MSFTNGP
1
>> 4
>> >> phx.gbl
>> >> >Xref: cpmsftngxa10.phx.gbl
>> >> microsoft.public.dotnet.framework.aspnet.webservic es:26594
>> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>> >> >
>> >> >Hi Dan
>> >> >
>> >> >Thanx for the reply. Very useful indeed, and nice to see that it is a
>> >> >feature of VS 2005.
>> >> >
>> >> >But what about the approach?
>> >> >
>> >> >To me it seems "right" to have a "domain model" described in terms of
>> XML
>> >> >Schemas and generate proxies and (data)objects for those Schemas.
>> >> >
>> >> >So you have schemas defining the messages (web service methods) and
>> >> >you have schemas defining the "domain model", eg. what can be
affected
>> by
>> >> >your messages.
>> >> >
>> >> >The "message" schemas reference the "domain model" schemas through
>> >imports.
>> >> >
>> >> >Last you have the WSDL which references the "message" schemas and NOT
>> the
>> >> >"domain model" schemas as they are already there through the
"message"
>> >> >schemas.
>> >> >
>> >> >Is this considered "best practice"...Is there any best practice at
>> >all...?
>> >> >
>> >> >Regards
>> >> >
>> >> >Henrik
>> >> >
>> >> >
>> >> >
>> >> >"Dan Rogers" <danro@microsoft.com> skrev i en meddelelse
>> >> >news:t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl...
>> >> >> Hi Henrik,
>> >> >>
>> >> >> The sharing of types between proxies is a feature that is on the
>list
>> >for
>> >> >> Visual Studio 2005.
>> >> >>
>> >> >> In the mean time, you can overcome this on an as-needed basis by
>> making
>> >> >the
>> >> >> two proxies share the same implementation of the classes that are
>> >> >> implementing your types. If you look at the two generated proxies,
>> >> you'll
>> >> >> find that the issue is that the two proxies are in different .NET
>> >> >> namespaces - and thus the two types are, to the runtime type
system,
>> >not
>> >> >> the same thing. To get around this, an easy fix is to take the
code
>> >that
>> >> >> you wish to see in common and put it into a separate .NET namespace
>> and
>> >> >> compile it into a new assembly. Then add a reference to this new
>> >> assembly
>> >> >> to your project, and make the generated proxy code reference the
new
>> >> >types.
>> >> >> You can do this by adding a Using or Imports statement at the top
>of
>> >> the
>> >> >> proxy file and commenting out the types you have moved into the new
>> >> >> namespace.
>> >> >>
>> >> >> Once you have done this, the type sharing will be working. If you
>> >> >> regenerate your proxies (refresh reference), the changes will be
>lost,
>> >so
>> >> >> you may also want to take the hidden proxy code and save it as a
>> normal
>> >> >> code file. Proxies aren't special, or even very complex, so there
>is
>> >> >> little to lose by taking control over them in this way.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> Dan Rogers
>> >> >> Microsoft Corporation
>> >> >> --------------------
>> >> >> >From: "HG" <hg@nospam.websolver.dk>
>> >> >> >Subject: Schemas they say ...
>> >> >> >Date: Fri, 12 Nov 2004 11:50:21 +0100
>> >> >> >Lines: 29
>> >> >> >X-Priority: 3
>> >> >> >X-MSMail-Priority: Normal
>> >> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
>> >> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
>> >> >> >Message-ID: <u6hxpVKyEHA.4028@TK2MSFTNGP09.phx.gbl>
>> >> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservic es
>> >> >> >NNTP-Posting-Host: 194.239.230.253
>> >> >> >Path:
>> >> >>
>> >>
>>
>>>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2M SFTNGP08.phx.gbl!TK2MSFTNG
P
>> 0
>> >> 9
>> >> >> phx.gbl
>> >> >> >Xref: cpmsftngxa10.phx.gbl
>> >> >> microsoft.public.dotnet.framework.aspnet.webservic es:26496
>> >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservic es
>> >> >> >
>> >> >> >Hi group.
>> >> >> >
>> >> >> >They say:
>> >> >> >Start with your schema definition of both messages and custom
>> >datatypes
>> >> >> that
>> >> >> >might be used in your messages.
>> >> >> >
>> >> >> >I can follow that approach, I can see the logic, I can see why I
>have
>> >to
>> >> >> >import schema(s) into WSDL document.'
>> >> >> >
>> >> >> >This seems like the way to go, for the best interop webservice
>> design.
>> >> >> >You get a "domain model" of schema types
>> >> >> >
>> >> >> >But, can anyone tell me if Microsoft have fixed (or will fix and
if
>> so
>> >> >> when)
>> >> >> >the "bug" with import of schemas:
>> >> >> >
>> >> >> >If I generate proxy classes for two web services (WSDL docs),
which
>> >> >happens
>> >> >> >to share the same schema type (say Customer), I get two
>> >"non-compatible"
>> >> >> >classes (Customer) for the same schema type.
>> >> >> >
>> >> >> >Anyone, please..
>> >> >> >
>> >> >> >What about this Dan Rogers guy...He seems to be knowing a lot
about
>> >web
>> >> >> >services (judged from his latest posts) :-)
>> >> >> >
>> >> >> >Regards
>> >> >> >
>> >> >> >Henrik
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>>
>
>
>