Schemas they say ...

[HG]

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]

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

 

[HG]

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]

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

 

[hug]

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]

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" <[email protected]>
Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
References: <[email protected]>

<[email protected]>

 

[HG]

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]

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" <[email protected]>
References: <[email protected]>

<[email protected]>
<[email protected]>
<[email protected]>