Schemas they say ...

Discussion in 'ASP .Net Web Services' started by HG, Nov 12, 2004.

  1. HG

    HG Guest

    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
     
    HG, Nov 12, 2004
    #1
    1. Advertising

  2. HG

    Dan Rogers Guest

    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" <>
    >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: <>
    >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >NNTP-Posting-Host: 194.239.230.253
    >Path:

    cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
    .phx.gbl
    >Xref: cpmsftngxa10.phx.gbl

    microsoft.public.dotnet.framework.aspnet.webservices:26496
    >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >
    >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
    >
    >
    >
     
    Dan Rogers, Nov 15, 2004
    #2
    1. Advertising

  3. HG

    HG Guest

    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" <> skrev i en meddelelse
    news:...
    > 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" <>
    > >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: <>
    > >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >NNTP-Posting-Host: 194.239.230.253
    > >Path:

    >

    cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
    > phx.gbl
    > >Xref: cpmsftngxa10.phx.gbl

    > microsoft.public.dotnet.framework.aspnet.webservices:26496
    > >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >
    > >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
    > >
    > >
    > >

    >
     
    HG, Nov 16, 2004
    #3
  4. HG

    Dan Rogers Guest

    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" <>
    >References: <>

    <>
    >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: <>
    >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >NNTP-Posting-Host: 194.239.230.253
    >Path:

    cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14
    ..phx.gbl
    >Xref: cpmsftngxa10.phx.gbl

    microsoft.public.dotnet.framework.aspnet.webservices:26594
    >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >
    >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" <> skrev i en meddelelse
    >news:...
    >> 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" <>
    >> >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: <>
    >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >> >NNTP-Posting-Host: 194.239.230.253
    >> >Path:

    >>

    >cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP0

    9
    >> phx.gbl
    >> >Xref: cpmsftngxa10.phx.gbl

    >> microsoft.public.dotnet.framework.aspnet.webservices:26496
    >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >> >
    >> >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
    >> >
    >> >
    >> >

    >>

    >
    >
    >
     
    Dan Rogers, Nov 16, 2004
    #4
  5. HG

    hug Guest

    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" <> wrote in message
    news:...
    > 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" <>
    > >References: <>

    > <>
    > >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: <>
    > >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >NNTP-Posting-Host: 194.239.230.253
    > >Path:

    >

    cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14
    > phx.gbl
    > >Xref: cpmsftngxa10.phx.gbl

    > microsoft.public.dotnet.framework.aspnet.webservices:26594
    > >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >
    > >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" <> skrev i en meddelelse
    > >news:...
    > >> 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" <>
    > >> >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: <>
    > >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >> >NNTP-Posting-Host: 194.239.230.253
    > >> >Path:
    > >>

    >
    >cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP0
    > 9
    > >> phx.gbl
    > >> >Xref: cpmsftngxa10.phx.gbl
    > >> microsoft.public.dotnet.framework.aspnet.webservices:26496
    > >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >> >
    > >> >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
    > >> >
    > >> >
    > >> >
    > >>

    > >
    > >
    > >

    >
     
    hug, Nov 17, 2004
    #5
  6. HG

    Dan Rogers Guest

    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
    --------------------
    >From: "hug" <>
    >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >References: <>

    <>
    <>
    <>
    >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$>
    >NNTP-Posting-Host: 212.10.120.159
    >X-Trace: 1100653517 news.stofanet.dk 22685 212.10.120.159
    >X-Complaints-To: Telia Stofa Abuse <>
    >Path:

    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
    >Xref: cpmsftngxa10.phx.gbl

    microsoft.public.dotnet.framework.aspnet.webservices:26647
    >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >
    >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" <> wrote in message
    >news:...
    >> 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" <>
    >> >References: <>

    >> <>
    >> >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: <>
    >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >> >NNTP-Posting-Host: 194.239.230.253
    >> >Path:

    >>

    >cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP1

    4
    >> phx.gbl
    >> >Xref: cpmsftngxa10.phx.gbl

    >> microsoft.public.dotnet.framework.aspnet.webservices:26594
    >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >> >
    >> >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" <> skrev i en meddelelse
    >> >news:...
    >> >> 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" <>
    >> >> >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: <>
    >> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >> >> >NNTP-Posting-Host: 194.239.230.253
    >> >> >Path:
    >> >>

    >>
    >>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP

    0
    >> 9
    >> >> phx.gbl
    >> >> >Xref: cpmsftngxa10.phx.gbl
    >> >> microsoft.public.dotnet.framework.aspnet.webservices:26496
    >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >> >> >
    >> >> >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
    >> >> >
    >> >> >
    >> >> >
    >> >>
    >> >
    >> >
    >> >

    >>

    >
    >
    >
     
    Dan Rogers, Nov 17, 2004
    #6
  7. HG

    HG Guest

    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" <> skrev i en meddelelse
    news:...
    > 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
    > --------------------
    > >From: "hug" <>
    > >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >References: <>

    > <>
    > <>
    > <>
    > >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$>
    > >NNTP-Posting-Host: 212.10.120.159
    > >X-Trace: 1100653517 news.stofanet.dk 22685 212.10.120.159
    > >X-Complaints-To: Telia Stofa Abuse <>
    > >Path:

    >

    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
    > >Xref: cpmsftngxa10.phx.gbl

    > microsoft.public.dotnet.framework.aspnet.webservices:26647
    > >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >
    > >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" <> wrote in message
    > >news:...
    > >> 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" <>
    > >> >References: <>
    > >> <>
    > >> >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: <>
    > >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >> >NNTP-Posting-Host: 194.239.230.253
    > >> >Path:
    > >>

    >
    >cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP1
    > 4
    > >> phx.gbl
    > >> >Xref: cpmsftngxa10.phx.gbl
    > >> microsoft.public.dotnet.framework.aspnet.webservices:26594
    > >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >> >
    > >> >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" <> skrev i en meddelelse
    > >> >news:...
    > >> >> 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" <>
    > >> >> >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: <>
    > >> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >> >> >NNTP-Posting-Host: 194.239.230.253
    > >> >> >Path:
    > >> >>
    > >>

    >
    >>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP

    > 0
    > >> 9
    > >> >> phx.gbl
    > >> >> >Xref: cpmsftngxa10.phx.gbl
    > >> >> microsoft.public.dotnet.framework.aspnet.webservices:26496
    > >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >> >> >
    > >> >> >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
    > >> >> >
    > >> >> >
    > >> >> >
    > >> >>
    > >> >
    > >> >
    > >> >
    > >>

    > >
    > >
    > >

    >
     
    HG, Nov 17, 2004
    #7
  8. HG

    Dan Rogers Guest

    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" <>
    >References: <>

    <>
    <>
    <>
    <419aa3cc$0$22685$>
    <>
    >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$>
    >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >NNTP-Posting-Host: 194.239.230.253
    >Path:

    cpmsftngxa10.phx.gbl!TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP0
    8.phx.gbl!TK2MSFTNGP11.phx.gbl
    >Xref: cpmsftngxa10.phx.gbl

    microsoft.public.dotnet.framework.aspnet.webservices:26657
    >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >
    >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" <> skrev i en meddelelse
    >news:...
    >> 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-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" <>
    >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >> >References: <>

    >> <>
    >> <>
    >> <>
    >> >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$>
    >> >NNTP-Posting-Host: 212.10.120.159
    >> >X-Trace: 1100653517 news.stofanet.dk 22685 212.10.120.159
    >> >X-Complaints-To: Telia Stofa Abuse <>
    >> >Path:

    >>

    >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.d

    k
    >> telia.net!news104.dk.telia.net!not-for-mail
    >> >Xref: cpmsftngxa10.phx.gbl

    >> microsoft.public.dotnet.framework.aspnet.webservices:26647
    >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >> >
    >> >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" <> wrote in message
    >> >news:...
    >> >> 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" <>
    >> >> >References: <>
    >> >> <>
    >> >> >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: <>
    >> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >> >> >NNTP-Posting-Host: 194.239.230.253
    >> >> >Path:
    >> >>

    >>
    >>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP

    1
    >> 4
    >> >> phx.gbl
    >> >> >Xref: cpmsftngxa10.phx.gbl
    >> >> microsoft.public.dotnet.framework.aspnet.webservices:26594
    >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >> >> >
    >> >> >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" <> skrev i en meddelelse
    >> >> >news:...
    >> >> >> 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" <>
    >> >> >> >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: <>
    >> >> >> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >> >> >> >NNTP-Posting-Host: 194.239.230.253
    >> >> >> >Path:
    >> >> >>
    >> >>

    >>
    >>>cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNG

    P
    >> 0
    >> >> 9
    >> >> >> phx.gbl
    >> >> >> >Xref: cpmsftngxa10.phx.gbl
    >> >> >> microsoft.public.dotnet.framework.aspnet.webservices:26496
    >> >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >> >> >> >
    >> >> >> >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
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >>
    >> >> >
    >> >> >
    >> >> >
    >> >>
    >> >
    >> >
    >> >

    >>

    >
    >
    >
     
    Dan Rogers, Nov 18, 2004
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George Hester
    Replies:
    3
    Views:
    3,495
    Carl Prothman [MVP]
    Aug 11, 2003
  2. U S Contractors Offering Service A Non-profit

    " Hind sight is that of 20/20 they say ? "

    U S Contractors Offering Service A Non-profit, Nov 7, 2006, in forum: C Programming
    Replies:
    0
    Views:
    319
    U S Contractors Offering Service A Non-profit
    Nov 7, 2006
  3. U S Contractors Offering Service A Non-profit

    " They say why buy the cOw when the milk is fOr frEE "

    U S Contractors Offering Service A Non-profit, Nov 30, 2006, in forum: C Programming
    Replies:
    0
    Views:
    627
    U S Contractors Offering Service A Non-profit
    Nov 30, 2006
  4. David A. Black
    Replies:
    2
    Views:
    227
    Tim Hunter
    Aug 19, 2004
  5. Steve Litt

    They say I write Ruby like Perl

    Steve Litt, Dec 8, 2005, in forum: Ruby
    Replies:
    44
    Views:
    447
    Jim McFarland
    Dec 12, 2005
Loading...

Share This Page