PDC - Conclusion
Sponsored By
Oh, yes, PDC was the shiznit. We learned about the Pillars of Longhorn:
- Lornhorn - It's ALPHA, but it's real. Feel free to peruse the SDK. There's 3 years of work into in, and 3 more to go
- Avalon - An even bigger leap forward for the Windows Graphics Subsystem than the introduction of DirectX. XAML will play a big role not only in WinForms, but look for a XAML to ASP.NET renderer as well. Here's a link to my Avalon article at .NET Developer Journal. I'll post a much more in depth article with code samples soon, but here's what Charles Petzold says. Some folks were expecting SVG to play a larger role and Werner explains why it's not the end of the world. The library of congress-sized namespaces in .NET Framework 1.0 and 1.1 got nothing on the namespaces coming up.
- Aero - The look and feel catches up to Mac OS X, and introduces some interesting twists, such as Common Dialogs for People.
- Indigo - To protect your current investment, stick with ASMX and you won't go wrong. Don Box says Objects are baked. They're done, you use them, be happy. Use objects interally in your apps, but start getting your head around the differences between explicitly working with a remote object and sending a messsage. Messaging doesn't equal RPC. Boundaries between applications are explicit. Share schema, not type. Benjamin Mitchell has some great notes from Omri's talk.
Interesting note, Gudge says DIME is dead, but Soap with Attachments and SOAP/MTOM live on, so don't be sad. - Generics - Generics aren't exactly templates, just as delegates aren't exactly function pointers. But, close enough. Be aware of the differences between syntaxes on C# and VB.NET.
- Serialization - Think about Contracts and Message Passing. Repeat: Share schema, not type.
- ADO.NET 2.0 - is a lot more “database independant“ and a DBProviderFactory pattern makes it even more clear.
- WinFS - NTFS still has many good years under it (although a better defragmenter couldn't hurt)
but WinFS adds a new world of Metadata to Documents and Settings. WinFS's System.Storage will let us query metadata on our content with SQL, OLEDB, COM, or managed APIs. It is truly the base of the pyramid.
- Speech - Ya, speech. We saw parts of this at PDC, but expect speech recognition to play a bigger role when we have 4 and 6 Ghz systems. :)
- Migration - It may be early to plan for deploying Longhorn, but it's not too early to be aware of certain migration strategies.
What's in store for PDC 2004/5? - Don't fool yourself, the next PDC will also be “The Longhorn PDC,“ except you'll see your feedback folded into much improved Beta bits. Remember, this was a preview, there's still great things being done with .NET 1.0, 1.1 and soon Whidbey (.NET 2.0).
Monday, back to reality, and I'm back to coding some great .NET Framework 1.1 libraries to support some of the world's largest banks (and interop'ing with some VB6 libraries! Oy, the glamour!) :)
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
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.
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.
Comments are closed.
"Share schema, not type."???