Good question. Certainly, XSD and the CTS (the .NET type system)
are both things that you can use to define "types", and there's
quite a lot of work that goes into marshalling data between those two different worlds.
To get at the difference between schema and type, it's easiest to look at where we
came from back in the olden days of COM.
In COM, two components communicated by sharing interface definition.
COM interfaces defined a strict binary layout in memory. COM interfaces were uniquely
identified by IID's and commonly defined in shared metadata via type libraries. The
end result of this was that I could walk up to you and say "Here is an IFoo,
its IID is XXX and it's defined in this .tlb file" and you would know *exactly*
what the vtable layout of that interface would look like in memory.
Because they were based around this idea of a binary specification
of vtable layout, COM interfaces could only define methods. That is, they presented
a set of behaviors to a consumer. Some of those behaviors might be to manipulate an
object's local state via methods like GetXXXValue and SetXXXValue, but they were still
behaviors nonetheless. Thus, when I walk up to you with a COM interface, I'm essentially
telling you "here's the set of things that I can do".
This lead to all sorts of problems. It was very difficult to
ensure semantic consistency across interface implementations because there was no
way to contractually specify what an interface method was actually supposed to do
-- COM interfaces told you how to call methods, but they didn't tell you what effect
calling those methods will have. Another problem with COM interfaces was that they
were immutable once published. If you wanted to add a member to a published interface,
you had to create a whole new interface. That's why we get things like IDispatch2Ex
-- COM interfaces just didn't grow very nicely.
Web services attempt to solve these problems by communicating
in terms of schemas and contract. A schema is a description of the legitimate contents
of a message. It communicates only state, and says nothing about behavior. For example,
a person schema allows to mechanically verify assertions like "I am expecting
a Person, and that Person will at least have FirstName and a LastName." There
is nothing in the schema that says what that person can *do*, because it really can't
do anything -- it's just a blob of structured stuff. Furthermore, if these schemas
are designed to take advantage of XML's intrinsic support for open content, people
can evolve these schemas transparently without breaking old systems.
Contracts are the way that web services describe their behaviors.
Contracts are used to define the legal patterns of messages that two services may
exchange. For example, a contract for a purchase ordering system might be a mechanically
verifiable expression of the idea that "if you send me a Purchase Order message(defined
by the PurchaseOrder schema) and I can successfully process it, I'll send you back
a Purchase Order Filled message (defined in the PurchaseOrderFilled schema). By contractually
specifying the legal sets of inputs and outputs to a system, web services help ensure
consistent semantics across services (which is something that COM could never do).
In summary, a type is a closed encapsulation of state+behavior.
A schema is a potentially open description of state, while a contract is a description
of the messaging patterns that define service behaviors.
Previous Topic
