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/details.aspx?FamilyID=de0cc46b-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
--------------------

<t4m4RG2yEHA.3640@cpmsftngxa10.phx.gbl>
<uv3q4Z7yEHA.1392@TK2MSFTNGP14.phx.gbl>
<s416OSBzEHA.3984@cpmsftngxa10.phx.gbl>

cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.s
ul.t-online.de!t-online.de!frankfurt1.telia.de!newsfeed101.telia.com!nf02.dk
telia.net!news104.dk.telia.net!not-for-mail

microsoft.public.dotnet.framework.aspnet.webservices:26647

0