Archives / 2003 / October
  • PDC2003::Building Peer To Peer Applications

    Indigo: Building Peer to Peer Applications

    Todd R. Manion tells us all about how Indigo will help us design our P2P applications.

    P2P Landscape

    • Collaboration
      • Project workspaces solving a goal
      • Sharing your files with other people
    • Content Distribution
      • Concert, company meeting, class
      • Distribution of product updates
    • Real-Time Communications
      • Instant messaging voice, video
      • Real-time game play/collaboration
    • Distributed Processing
      • Dissection and distribution of task
    • Improved Internet Technologies


    Why something new?

    • Limited Supply of Public Addresses
    • NATs prevent sharing from the edge
    • Limited Name Resolution system
      • Does not handle dynamic addresses
      • Does not work in ad-hoc environments
      • Does not lend itself to consumer use
    • Inefficient Multipoint Communication
    • Everyone rewrites the infrastructure


    Infrastructure Design Goals

    • Secure, robust in face of failure/attack
    • Scalable, from ad-hoc to the Internet
    • Server-less, no central point of failure
    • Self-tuning, adapts to constant change
    • Self-repairing, automatically fixes itself


    P2P Technologies

    • Peer Name Resolution Protocol (PNRP)
      • Scalable, secure, serverless name resolution
    • "Indigo" PeerChannel
      • Efficient distribution of information between nodes
      • Auto-tuning, self-repairing communication layer
    • Peer Groups
      • Create and manage persistent securable groups
    • Peer Store (built using WinFS)
      • Distributed data management
      • Synchronized, replicated meta-data store


    Name Registration/Resolution

    • Members of System.Net.PeerToPeer
    • Major Classes
      • PeerName
      • PeerIdentity
      • PnrpEndPoint
      • PnrpEndPointRegistration
      • PnrpEndPointResolver
      • Cloud/CloudWatcher
    • Available in Longhorn PDC Preview


    Indigo PeerChannel

    • MajorClasses
      • PeerChannel
      • PeerManager
      • Node
      • Message
      • Port
    • Available in future Longhorn release (boo!)


    PeerStore And PeerGroup

    • Major Classes
      • PeerIdentity
      • PeerGroup
      • Member
      • PeerStore
      • Record
      • GroupInfo


  • PDC2003::What's New In System.Xml for Whidbey?

    What's New In System.Xml for Whidbey?

    Mark Fussell let's us in on what's we can expect in System.Xml in Whidbey.

    Note: So far this session is quite empty which is very surprising to me. I would have thought more people really care about this subject. IMVHO, they should. Everything you'll be developing for Longhorn involves XML in some way.

    Performance Improvements

    • Schema validation 20% faster (beta 1)
    • XmlTextReader 100% faster (tech preview)
    • XmlTextWriter 100% faster (Beta 1)
    • XSLT 400% faster (Beta 1)
      • XsltProcessor generates MSIL


    Usability Improvements (Beta 1)

    • CLR type accesors on XmlReader, XmlWriter and XPathNavigator: Double unitPrice = reader.ValueAsDouble
    • XmlFactory
      • Single class for creating XmlReaders and XmlWriters


    XmlFactory f = new XmlFactory();


    f.ReaderSettings.XsdValidate = true;

    XmlReader reader = f.CreateReader("myData.xml");

    XPathDocument A Better XML DOM

    "XmlDocument is dead."


    • XPathDocument replaces the XmlDocument as the primary XML store.
    • Feature Set
      • 20%-40% more performant for XSLT and Xquery
      • Editing capabilities through the XPathEditor (derives from XPathDocument) using an XmlWriter (the mythical XmlNodeWriter we've all been searching for).
      • XML schema validation
      • Strongly typed store. Integers stored as int internally (per schema) (Beta 1)
      • Change tracking at node level
      • UI databinding support to WinForms and ASP.NET controls (Beta 1)


    Note: XPathDocument2 in PDC bits will be XPathDocument once again by Beta 1. "We were at an unfortunate design stage at the point where the PDC bits were created."


    "The Deathstar of XML specs… will destroy everything in it's path."



    "The Deathstar of XML specs… will destroy everything in it's path."


    What is XQuery?

    • XQuery is to XML as SQL is to a relational database
    • Use to query XML documents and XML data source
    • Industry wide adoption


    Includes XPath and more…

    • Has a friendly syntax
    • Strongly-typed using XSD types
    • Construction
    • Has the ability to do joins across documents
    • Comprehensive set of functions and operations


    The Essentials

    • As simple as XPath…
      • Get all the customers - /customers
    • Yet much more powerful
      • Get all the customers and for each customer list their orders joining across two documents



    • Migration of XQLXML 3.0 into ADO.NET
      • Built to work with SQL server
    • XML programming model for queries and update
    • XQuery is the query language
    • XML Views
      • Mapping technology to expose logical XML views of SQL server relational tables
      • XML Views provide the schema contract to shape the data



    • The application evolves with XML schema
      • Vertical industry schemas e.g. XBRL, RIXML, FinXML
      • A source and sink for XML
        • Content management systems, B2B scenarios
        • Queries and updates against XML Views
      • Streaming XML into relational tables
        • e.g. catalog information, RSS feeds

    Middle-Tier XML Views

    • Declarative syntax for mapping between XML and relational data
    • Support for common database design patterns
      • Stored proc support
      • Extensibility mechanism with SQL queries
    • XQuery over XML views
    • Identical mapping technology used by ADO.NET ObjectSpaces for objects (interesting!)

    XML Schema



    MSD - Mapping Schema Definition (XmlView)



    RSD - Relational Schema Definition (Database)

     Update for Disconnected Scenarios

    • Update is essential for data access
    • XmlAdapter
      • Equivalent to the DataAdapter with an XML data model
      • Can fill an XPathDocument from SQL Server via an XQuery and an XML View
      • Can update the changes made to an XPathDocument back to SQL Server
      • Automatically generates the SQL update statements based upon the XML View
    • XmlBulkLoad
      • Streaming update for XML into SQL server using an XmlReader with an XML View


    Mental Note: Almost all demos for this session have been based around an RSS document.


    Improvements in VS.NET for XML

    • Expand and contract elements (hides all child nodes)
    • Editor highlights XML structure validation
      • You forget an end tag
      • Use number at the beginning of an attribute name
      • No such namespace declared
      • Invalid entity name
    • Auto-schema generation based on instance document structure.
    • Better Intellisense support for instance documents which are using a schema
    • Built-in DTD -> XML Schema generator
    • XSLT editor supports full schema validation now, thus enabling full intellisense while editing stylesheets
    • Realtime execution of XSLTs on instance documents within the enviroment!@$&!@*!@$ (WOW!)
    • XSLT debugging (YAY!)
    • XSLTs compiled into MSIL at project build time!


  • PDC2003::Connected Application Technology Roadmap

    Indigo: Connected Application Technology Roadmap

    Indigo: Connected Application Technology Roadmap

    Note: I just had to move to a totally diff. conf. room. Turns out the rooms changed. They only told us like 2 minutes before the start of the next session. That sucked. Now I'm like 10 minutes behind in the session. :(

    Indigo and Existing Technology
    Binary Interoperability


    • It Just Works - no changes required
      • ASP.NET Web Services
        The latest version of WSE
    • Update to Longhorn
      • COM+


    COM+ Migration Fundamentals

    • Existing binaries just work; No recompiliation
    • Focus on bridging service environments;
    • COM+ application can be accessed from Indigo clients
    • Indigo Web services can be access from COM clients (moniker, just use CoGetObject)


    COM+ Binary Migration Details



    • Use a TLB
    • Be installed in COM+
    • Declare all co-classes and all interfaces on each co-class in the tlb
    • Declare explicit interface types as parameters



    • Explicit use of COSERVERINFO
      • Let config decide where the service lives
    • Using interface pointers in custom UCPs
      • Marshal-by-value approach works better
    • Calling COSetProxyBlanket after first use of proxy


    Will not be supported

    • Proxy/stub marshalling



    Ended Coverage Early: Ok, I left this session early and moved to another WinFS one. It's all about migration and is just not interesting to me.


  • WinFS: Schemas and Extensibility

    My first session of the day. I'm looking forward to seeing what decisions were made as far as the base schema Longhorn will ship with as well as just how extensible it really is. You can check out my session notes by clicking here. We're running about 15 minutes late today because the keynote (which I didn't attend) is running long.


  • PDC2003::WinFS Schemas and Extensibility

    WinFS: Schemas and Extensibility

    J. Patrick Thomas: The man behind WinFS schemas.

    Note: They have a giant, ~12'x2' poster at the back of the room with over 30(?) schema classes built into Longhorn at present.


    WinFS Item Store

    • Complete Data SubSystem
      • Object, Relational and XML
    • Schema Framework
      • Extensible "everyday info" schemas
      • ISV-built schemas
    • Data store and model


    User Benefits

    • Find my stuff
      • "The big presentation I got from Toby I was working on last week" (sample nature language search)
    • One view of data
      • IM Today, Hotmail Toby, Corporate Toby, ...
    • Exposing Relationships
      • Doc authors, Meeting attendees, Meeting Locations, Location occupants


    Developer Benefits

    • Populated, well-defined data definitions (types)
    • Store and API are automatically generated
    • Applications can create and share data
    • The storage subsystem is Extensible
      • It's much easier to build a smart connected application
      • Applications can create and share types


    What is a Schema? (analogous to a CLR namespace)

    • Collection of type declarations
      • Items, properties, relationships between items, item extensions 

        (special kinds of types)

    • What you get
      • Structures in the store
      • APIs


    Define schema using custom XML vocabulary, pass through schema compiler, compiler generates CLR type definitions, store created for data types. Can add in business logic. All takes advantage of partial classes.


    WinFS is still changing in terms of schema and the bits we have will change, hopefully not too much, but he already showed us the differences.


    Base Schema (aka WinFS Schema) is System.Storage in CLR

    Heart of it all is Item. Very simple, trying to keep it that way. The only really important property is the ItemId.



    +Created : DateTime [0:1]
    +DisplayName: String(4000) [0:1]

    +IsFileBacked: Boolean [0:1]

    +ItemId: Guid [1:1]
    +Modified: DateTime [0:1]


    Relationship : Item

    +IsHidden : Boolean [1:1]

    +Mode: Int32 [1:1] (reference, holding, embedding)

    +Name: String(4000) [0:1]
    +RelationshipId: Guid [1:1]
    +SourceItemId: Guid [1:1]

    +TargetItemId: Guid [0:1]


    NestedType (just types, indistinguisable from a CLR type)



    +ExtensionId : Guid [1:1]

    +ItemId: Guid [1:1]


    WinFS Folder : Item

    +IsArchive: Boolean [1:1]

    +IsCompressed: Boolean [1:1]

    +IsSystem:Boolean [1:1]

    +IsTemporary [1:1]


    FolderMember : Item


    GenericFile : Item


    Can't extend Nested Type or relationship… just Item


    Note: Holding/Embedding relationships require objects to live in same physical store.


    Core Schema

    Defines concept of Component and Attachments. Location, as a notion of a geographical location. Contact: has roles, locations. Events: have event content. Message: voicemail, email, etc. Document: previous version, attachment, document component, document contacts. Devices: printer, computer, fridge, etc. (Moving pretty fast now.)


    Built in NestedTypes

    • Uri
    • Keyword
    • RichText
    • Presence
    • More (slide moved by way too quick)



    Ways to Extend the Store

    • Use someone else's schema
      • Creating new Item instances
      • Create your own part of the namespace
      • Modifying Items
      • Use of keywords
    • Extend a schema
      • Item extensions
      • NestedType extensions
      • Subtypes
    • Roll your own
      • Design your own Item types


    Extension & NestedType

    • Subtyping Extension
      • One Extension of a given type
    • Extending NestedTypes
      • Collisions


    Item Subtypes

    • Implications of single inheritance
    • Abstract
    • Internal, Public and Friend Schemas


    Note: You can seal types. Some of the types shipping with Longhorn will be sealed.


    "Extensions are a way of tagging information."




  • Day 4

    So here we are again. Each day more exciting than the next. I've actually altered my schedule for today based on the previous days' experiences. I was planning on attending more Avalon sessions when I originally set up the schedule, but after seeing it I realized no longer needed to make those sessions a priority. Everything I need to know about Avalon I can learn from the online reference. I already understand the major facets of the technology having spent the past five or so years working with DHTML, CSS and even dabbling in SVG. The people who really need to attend those sessions are the people who were in denial about needing to learn (X)HTML and clung tightly to their HWNDs.

    So, with that out of the way, what have I decided to fill those session slots with? Well right now I'm sitting here preparing for my second taste of WinFS. I was simply blown away when I saw it yesterday. Not because it was revolutionary, because if you've done any O/R mapping work then you're familiar with it, but because they actually did it. It's there. It's native in Windows. It's not just a layer on top of a SQLServer database.


  • End of Day 3

    Ok, today was awesome

    Indigo is... exactly what I need^H^H^H^H^H^H anyone who's programming service oriented system needs. I can't even put it into words how happy I was as the serialization session progressed. By the end of the session a great weight was lifted off my shoulders. Oh man, when Doug explained that the serialization architecture is now one model and that that model is the XML Information set... well... let's just say that I'm still smiling.

    WinFS is everything I expected. It model is very similar to O/R mapping layers today. I've designed two versions of an O/R mapping layer and the latest version, which is .NET, bares a striking resemblence to WinFS. The reason I'm so happy about that is because now I can go back to my development team next Monday and spend about ten minutes explaining the analogies between the two and they'll basically know how to program WinFS. Awesome.

    Now, back to reality. The “good” Indigo stuff really isn't coming until Longhorn. Although there are some improvements coming in the Whidbey bits. WinFS? Well there's no doubt we're waiting 'til Longhorn for that. So the negative perspective that some people are taking is: “I love to see this stuff, but it's useless because I can't use it for the next three years.“ To some extent, I feel the same way, but then I realize something: We, the developers, have a real opportunity here. We're seeing the APIs in their toddler stages. We still have a real opportunity to shape the outcome of this stuff. If we start playing with the bits and come up with constructive criticism (whining isn't gonna help) I know Microsoft will listen. It's either that or forget what we've seen this week and wait until 2006 and potentially be stuck with ugly, difficult, unintuitive designs.

    Speak now or forever hold your peace.


  • PDC2003::Using XSD, CLR Types and Serialization in Web Services

    Indigo: Using XSD, CLR Types and Serialization in Web Services

    Doug Purdy dishes out the goods on Indigo.

    Serialization Overview

    • The transformation of a graph of objects to a stream and back again
      • System.Xml.Serialization
      • System.Runtime.Serialization
    • The transformation of a CLR type into another type system (XSD) and back again
      • System.XmlSeriliazation
    • Framework-wide feature
      • Web Serices, Remoting, Yukon, etc.
      • End-user feature


    What's new for Whidbey

    • XmlSerializer
      • New imperative modes
      • Schema import extensibility
      • Serializer pre-generation (sgen.exe today, future implementations will use Reflection.Emit)
      • Generics support
      • SqlTypes (switch on XSD.exe, support for optional primitives)
    • BinaryFormatter
      • Version tolerant serialization
      • Performance improvements
      • Generics support


    [OptionallySerializable] (name may change) can be applied to new fields when a class is versioned up to allow the BinaryFormatter to deserialize the new version of your class from an old serialized version.



    • Serialization Engine
    • Extensibility
    • Xml Processing
    • Representation


    Idea is to make anything that is [Serializable]/ISerializable will work with the new XmlFormatter.

    "XmlFormatter about XML, not text! Should really call it the InfosetFormatter." All about the abstract data model of the Infoset. You could have a binary representation or any custom representation of the Infoset you like, but the Infoset is what the serialization architecture is now based on.


    New model requires you to be explicit about everything. [DataContract] on class, [DataMember] on members (including non-public fields).


    XmlFormatter has two modes:

    • Tightly coupled - means you care about CLR type you serialized (actually embeds .NET assembly qualified name as attribue of class element)
    • Loosely coupled - means you care about the service oriented contract of the data (allows you to serialize into any CLR type that has a compatible contract)


    Mode set in constructor of XmlFormmater (SerializationMode enum).


    DataMember has VersionAdded property, of type int, that can be used to indicate which version of the schema the property was added. Allows loading of old serialized data into newer versions of a CLR type that maps to that DataContract.


    Method marked with [OnDeserialization] with signature "MyClass(StreamingContext)" so you can do custom deserialization. CALLED BEFORE CONSTRUCTOR!?!? Method marked with [OnSerialization], same signature, so you can do custom serialization.


    XSD Support

    • Every serializable type is interoperable
      • Export valid XSD for any CLR construct (including Generics and IDictionary)
      • Mapping is not extensible (POR for v1)
    • Every XSD schema is supported
      • XmlFormatter
        • Provides a canonical mapping for CLR <-> XSD mapping
        • No mapping extensibility (POR for v1)
      • Xml programming models
        • Supports all schema constructs
        • XmlSerializer, XPathNavigator


    Xml Serialization != Xml Programming

    New tool, dc.exe (note: dc == data contract), runs over CLR types and generates a valid XSD schema.


    Versioning handled in schema using a ref'd group called "unknownData" as opposed to an open content model. Group contains . Allows endless extensibility by repeating that patter in subclasses! WOW. Hell of a solution!

    Three levels of support for deserialization on the service end. [ServiceMethods] can use XmlFormatter (you care about CLR types), mark with [XmlMethod] indicates you care more about the [DataContract] scenario than the CLR types, or if you really really want to touch the XML, you can take a Message parameter and Indigo will just hand you the message without any processing and you can read the XML off however you like using it's XmlReader properties.


  • PDC2003::Using WinFS In Your Applications (Part 1)

    WinFS: Using WinFS In Your Applications (Part 1)

    John Ludeman unleashes WinFS on the eager to learn crowd.

    Developer Benefits

    • Power in transparency
    • Objects - a powerful and simple way to work with data
    • Consistent model of diverse data types
    • Rich indexing and query services
    • Simple access to user data
    • Many apps will benefit with no changes


    Rich searching allows us to "organize by query rather than location".


    Types and Subtypes

    • WinFS types are similar to types and subtypes in CLR
      • Template with properties, methods
      • Single inheritance
    • Example: Contact
      • Item is base type
      • Person, Group, Oranization are derived types
      • Person type has GivenName, Surname props; GetGroups method
    • Windows Schemas define a set of types
    • Types surcase in the API model as classes


    Main assemblies: System.Storage[.Schema], wincorlib


    Classes/helper methods auto-generated from schema types file.


    Base class for all types is System.Storage.Item.


    Item, NestedType and Extension

    • Base Schema defines
      • Item
      • NestedType
      • Extension types
    • Example: Person type
      • Derives from Iem type
      • Properties - Name, Address, BirthDate
        • BirthDate is a scalar type
        • Name and Address are structures that derive from NestedType
    • Extension type
      • Allows customization without deriving new subtype
      • Facitlitates sharing



    Entry to most of the WinFS programs that will be written.


    • Root for all WinFS API operations
      • Defines store and scope
      • Transaction boundaries
      • "Working" object cache
    • Should always close ItemContext (use C# using pattern)
    • Can open remote stores like UNC shares
    • FindResults will be directly bindable to Avalon and WinForm controls


    Finding Items In WinFS

    • OPath
      • Simple query language in the object domain (uh… smell like ObjectSpaces yet? That's 'cause WinFS is designed by the same team)
      • Uses paradigm familiar to OO programmers
    • Supports
      • Simple equalities
      • Wild cards
      • 'IN', 'LIKE'
      • Joins
      • Etc.


    He mentioned something about supporting generics, but he blazed past it so quickly, I'm not sure exactly what aspect of the API he was referring to. I'll check after the session.


    Someone asked if you'll be able to have SQL access to the backing store. The answer is "yes, but limited".


    Supports transactions at the ItemContext level. (i.e. change 30 objects within an ItemContext and then have an exception and roll all object changes up to that point back).



    • Items are associated to each other through Relationships
      • Defined at schema design time
      • Relatiohnships have a source and target
      • Correspond to classes
      • New relationships can be created or derived
    • Example: AuthorRelationship
      • Source: Document type
      • Target: Contact type
    • Three types
      • Holding
      • Embedding (not in PDC)
      • Reference


    Holding and Embedding have lifetime relationships. If parent deleted, held/embedded item gets deleted. An item can only be the target of one embedding relationship. Holding allows multiple relationships. Last holding item to let go, deletes held item. Reference is just a link, has no lifetime semantics.


    Can't have graphs with holding relationships; like symbolic links.


    Dangling references CAN EXIST. You should test for null, but it's useful in certain scenarios to know that your reference was deleted.


    Using Relationships


    • Establishing Relationships
      • Directly
      • API Shortcuts
        • Group.MemberRelationships.Add()
    • In Queries
      • Groups
        • Target(MemberOfGroups).DisplayName = …"
        • Source(MemberOf


    Embedding relationships NOT IMPLEMENTED IN PDC BUILD. "Will absolutely be there in beta1."


    Items and File Streams

    • WinFS Items use Stream property
      • Just like CLR streams
      • Use System.IO to read/write
    • File-backed items
      • Transparent Win32 interop
      • Use for legacy file formats


    What to Expect Post PDC

    • Schema updates
    • API surface updates
    • "Categories" to be replaced
    • "Links" converted to "Relationships“
    • Improved performance


  • PDC2003::Building Services (Part 2) - Secure, Reliable, Transacted Services

    Indigo: Building Services (Part 2) - Secure, Reliable, Transacted Services

    Don Box preaching about transactions.

    Early Mental Note: Federation support being built into OS and Indigo will take advantage of it.


    The Role of Transactions

    • Intra-service correctness
    • Availability versus latency
    • Compensation and trust
    • Declarative and ubiquitous


    The default transaction setting is to NOT propagate transactions across systems. Latency screws availability because locks can be (are) held too long.


    Trust factor. What if the transaction goes to someone you trust, but they need to forward that on to someone you don't trust?


    Atomic transactions are something we only use in an autonomous scenario. Propagation of atomic transaction is not where MS sees the industry going.

    So what do we do? First step: make transactions ubiquitous. In Indigo, more and more of what you see is transacted. Not just databases anymore. Box: "We're making transactions simple enough for VB programmers." (ouch, heheh). Making sure transaction performance is as fast as it can be. Box: "Blisteringly fast." Example, you can have a transacted ArrayList/Hashtable and it's feasible thing.


    How does Indigo accomplish this?  System.Transactions assembly. Managed code for doing transactional programming.

    • Bottom of stack is a manual transaction layer (ITransaction, ITransactionManager, IEnlistment). Ideas taken from OLE-TX.
    • Next layer in stack is Implicit Transactions (Transaction.Current, TransactionScope) and Resource Manager Utilities (Log, Isolation).
    • Final layer is Declarative Transactions ([Transaction]).


    Only bottom stack and Implicit Transactions are available in Whidbey. Rest of stack is in Indigo. COM+ service applications will not integrate today with this model in Whidbey, but will in Indigo. This is because today's COM+ service implementation is reliant on MSDTC.


    Transactions Demo

    • Transaction.Create([overloaded]) - static method which loads transaction manager, calls ITransactionManager.Create method and returns an object reference to an Itransaction.
    • ITransaction::Rollback exists, but ITransaction::Commit no longer exists, because it is an enlistment point! Only top of stack should have control of commitment. So, Transaction.Create() actually returns an ICommitableTransaction which does have a Commit method.
    • Transaction.Current - property that gets/sets current transaction for the call context. Flows with your code inside an AppDomain (including across asyc calls), but never leaves the AppDomain. You put a Clone of ICommitableTransaction into this property. Clone actually returns an ITransaction with no ICommitableTransaction so other people can't cast and take control.
    • Implicit approach like so:

      using(TransactionScope s = new TransactionScope(TransactionScopeOptions.Required)
          … everything in here within scope of the transaction ...
      // TransactionScope disposed here, looks at state of
      // transaction's consistent bit and, if consistent, allows it to commit,
      // otherwise it is forced to abort


    Indigo And Transactions
    Transacted Methods

    • Transaction scopes can be automated through attribute
      • Tx.Current established by Service Model
      • Outcome determined based on normal/abnormal termination


    • Origin of transaction orthogonal to scope


    Transacted I/O

    • Indigo channel can support transaction protection on message delivery (Indigo only, not Whidbey)
    • Transacted send defers transmission until successful TX outcome

    Transacted receive returns message to queue upon failed TX

    • Established during channel creation
      • Per-method attribute sets default


    Transacted Services (Indigo only, not Whidbey)

    • Common logging facility makes compensation efficient and tractable
      • Unified log between TM, RM, and application
      • Based on ARIES log protocol
    • Isolation support via service specific optimistic concurrency or via TX-aware locks


    Transaction Propagation

    • Indigo supports propagation of arbitrary execution context
      • DCOM causality
      • .NET Remoting LCID
      • ILogicalThreadAffinitive
    •  Transactions are but another piece of context that can flow


     The Role of Reliable Messaging

    • The impact of intermediaries
    • The impact of contracts
    • Immediate versus deferred transfer - you don't always have a direct TCP connection, Indigo architecture never assumes it



    Reliable Messaging in Indigo

    • Indigo provides reliable message sequences
      • Uni- or bi-directional
      • Sender/receiver lifetimes may overlap or not
      • Message store is configurable
        • Volatile vs. durable
        • Transacted resource manager
      • Parameterized delivery assurances


    Sample contract code:

    public interface IBobAndJane

        void f();
        void g();
        void h();


    Can say f, g and h must be called and what order they should be called in, that once h is called nothing else can be called, etc. (Note: He's moving quickly now, not really showing us everything, just talking about it.)


    The Role of Security

    • Services have a variety of security needs
    • Messages need to be protected or both integrity and confidentiality
    • Services and clients need authentication
    • Services often wish to grant authorization selectively based on client credentials
    • All of this needs to work across organization and platform boundaries


    Turn-Key Indigo Security

    • Development (code attributes)
      • Annotate services with code attributes
      • Define authentication, confidentiality, integrity and access control requirements
    • Deployment (configuration)
      • Define and select security profile settings
    • Administration (security data)
      • Specify authorization mappings (user to role)
      • Specify username-password credentials
      • Specify presentation credentials


    SecurityAttribute - applied at class level, controls authentication of the service

    AuthorizationAttribute - controls which role is required in order to dispatch messages to the service.


  • PDC2003::Building Services (Part 1) - The Fundamentals

    Indigo: Building Services (Part 1) - The Fundamentals

    Don Box starts lays some Indigo on us.

    For starters, this room is wayyyy too small for all the attendees in here. There's people sitting all over the floors. Bad planning on MS' part. Did they think Indigo wouldn't draw a crowd? Nevermind the fact that it's a Don Box session. I hope Part 2 isn't this bad. I'm sitting on the floor, can't see the screens, not a happy camper. :(


    The "Connector" is effectively how we get a "SOAP Dial-tone" in Indigo. The first thing you "see" when you start working with Indigo. Based on four simple concepts:

    • Messages - SOAP envelope
    • Services - piece of external code we send messages to and receive responses from
    • Ports - a named location in network space
    • Channels - allow message I/O through a port


    Indigo makes some very deep commitments to SOAP. Body is only for target of message; headers, more transparent, can be for intermediaries. Every message in Indigo makes "hard" commitments to SOAP. If you understand a SOAP message today, you understand an Indigo Message. That said, the wire format is not necessarily SOAP. There are pluggable formatters you can use to serialize a message however you see fit.


    Message object bases on XmlReader/XmlWriter architecture. Doesn't mean it necessary gets written as XML (i.e. write your own custom XmlWriter that writes to binary), but that's the way the API is structured.








    +SetProperty(string, object)

    +GetProperty(string) : object


    A Port is a location in network space

    • Acts as factory for Channels
    • Resides in single AppDomain
    • Has one or more affiliated transport channels
    • Provides a base URI for all addresses


    Messages flow through a Port.


    Channels stack in a port; can be multiple in a row.












    • IInputChannel - receiver
    • IOutputChannel - sender


    IDuplexChannel subtypes both IInputChannel and IOutputChannel.


    IRequestChannel - client side of request/response

    IReplyChannel - service side of request/response


    IService the equivalent of IUnknown in Indigo. Has one method: GetServiceReference. Used to identify URI and WS-Addressing information that helps located the service. ServiceReference identical to EndpointReference in WS-Addressing.


    Ok, I left about ten minutes early. That session was just not good. I mean, the content was great, but it was overpacked, overheated, technical breakdowns (whole right side of the room lost power so the projectors went off), etc. Hopefully Part 2 will be better. :\


  • Day 3

    Well, it got off to a bumpy start as the bus from my hotel to the conference hall was off schedule. So a few of us there got to the Eric Rudder Keynote a little late. The keynote was all about the new features in Whidbey, so I really didn't miss anything since I've been on the testing program and have had the chance to play with it for some time now.

    Today my schedule is all about Indigo. I can't wait to see what Don and his team have come up with. It is the future of web services on the .NET platform and is probably the number one reason I came to this PDC other than the “cool factor” of Longhorn.


  • Advances in GDI? Doubt It.

    This question is for the guys there at the PDC.

    I would like to know if something has changed with GDI+ maybe GDI 2 ?


    You mean besides Avalon? I haven't heard about any advances in the GDI APIs. Everything is moving towards Avalon and vector graphics. It was explicitly pointed out that there are two graphics stacks in Longhorn. GDI for legacy apps and Avalon for Longhorn+ apps. As I understand it, so far, is the support for GDI is now essentially a thunking layer to Avalon. Legacy windows apps seem to run just fine (they showed Visicalc), but they look like complete strangers in the rich Avalon world.


  • End of Day 2

    One word sums up the PDC experience so far: “Wow”. Considering the fact that this is really only Day 2 (technically Day 1 if you don't count the pre-con), it's just gonna get more amazing from here on in.

    I don't think I suffered too much from information overload since everything I attended today was pretty high level stuff, with the exception of some of the Avalon code demos. I also kinda knew about the basics of the technologies coming in Longhorn, but seeing them all actually work and, more importantly, work together, was the really cool part.

    The Avalon stuff really amazes me. They've done an amazing job, although some of the implementation details that I noticed still have me scratching my head wondering “why did they do it that way?” or “why don't they take advantage of such and such a standard there?”. However I guess I'll have to play around with the bits (which, incidentally, I'm installing right now) and get a firmer grasp on it before I start to critique.

    Today's Indigo session was really just an intro as to the “Whys” of Indigo, rather than the “Hows”. Tomorrow I expect Don to get us all knee deep in some seriously cool code demos. Indigo is where I will be spending most of my time over the next few years, so I hope it's as good as it looks so far. I have faith in Don and his team though, they really seem to have a firm grasp on what needs to happen in service oriented systems.

    I believe I also have my only WinFS session tomorrow. I'm actually looking forward to it more than I originally was now that I've seen some of what can be done with it in this morning's keynote demos.


  • The Webloggers' BoF

    So I'm sitting here at The Webloggers' BoF. The room is overflowing with passion about which XML formats should be used (XMLRPC or Atom?), which Web Services APIs should be used (metaBlogger or Echo?) and what kinds of advances need to happen in clients/aggregators to make the data more useable for the average end user (how to avoid information overload).

    Check out how full this room is. After a full day of .NET conference sessions, these people are dedicated enough to be here discussing these topics. Great stuff.


  • PDC2003::Services and the Future of Distributed Applications

    Indigo: Services and the Future of Distributed Applications

    Don Box kicks off the Indigo session.

    Trivia: Began in 2000


    Don's opening speech is all about understanding that Microsoft's commitment to moving to managed, object oriented code is real. Believe it.

    Distributed object technology is dead. It never worked correctly. DCOM, Corba both failed at bringing the dream of object location transparency to the masses in a real world, scalable, useable way.


    The key to make web services work is to acknowledge and respect the boundaries of others. Don did an excellent demo where he had an audience member come up on stage and he  did various things to violate his personal boundaries: touching him, talking in his face, asking his salary, etc. Then he said, "We're pretty tightly coupled here, but how long do you think this would last? Ten years?". The answer from the volunteer was "I doubt the next ten seconds." Point proven.


    Service Oriented Architecture


    Q: What is a service?

    A: A program you communicate using messages. No more, no less.

    Q: What is a client?

    A: A program that sends messages to a service.



    • Services are autonomous. Independent deployment, versioning and security.
    • Share Schema, not Class. Integration bases on message formats and exchange patterns, not classes and objects.
    • Policy-based compatibility. Service compatibility based on policy assertions using stable global names.


    .NET Remoting is awesome, infinitely extensible, but not the future. It will be supported for a long time, but the future, as Microsoft sees it, is more along the lines of what ASMX provides today.


    Indigo is .NET technology that makes it simpler to design and implement web services. Don: "That's all it is." Does not assume other systems are not Indigo... assumes only standards.


    Indigo will ship in the box with Longhorn, but does not require Longhorn. Runs on 2k3, XP and Longhorn.


    Designed to allow you to host Indigo in any execution environment (ASP.NET, services, Avalon applications).


    To tell Indigo to expose your class as a service, you decorate it with the [System.ServiceModel.Service] attribute. To expose your methods, you must decorate them with the [System.ServiceModel.ServiceMethod]. CLR accessibility is ignored (i.e. just making them public doesn't cut it).


    Classes must be marked up with [System.Runtime.Serialization.DataContract]. Says "this data type has a schema and I'm going to control the way this schema looks." The individual class members must then be marked up with [System.Runtime.Serialization.DataMember] in order to be included.



    Indigo brings the best of ASMX, .NET remoting and Enterprise Services into one model and aims to make it go as fast as they possibly can.


     Indigo will be Microsoft's primary implementation of WS-* specifications.


    Indigo aims to make sure your investments in today's technologies go forward into tomorrow.


  • My Laptop

    I've been receiving several compliments and inquiries about my laptop. So I figured I'd blog about it real quick. It's a Toshiba P25-S607. It's a gigantic 17” behemoth with 16x9 aspect ratio screen. I believe the S609 model has taken its place now with a 3Ghz chip (vs 2.8Ghz in this guy). I recommend it highly. I've only ever bought Toshiba laptops and I've never had any issues with them.

    Don's starting the Indigo talk, I'll put up my notes soon, but already my battery is at 40%. :(


  • PDC2003::Building Applications With Controls And Dialogs

    Avalon: Building Applications With Controls And Dialogs

    Rob Relyea dishes out all the goodness about leveraging/compositing Avalon controls.

    Better Faster Easier

    • XAML Declaritive Programming
    • Library of Panels provides great layout functionality
    • Great Visuals - Opacity, Gradients, Shapes, Anmiations and Transforms
    • Styling capabilities
    • Data drive


    Using flow documents provides complete support for scaling and resizing.


    Windows client print driver creates XAML!?


    Presentation elements of Avalon live in System.Windows namespace (.Documents, .Anmiation, etc)


    Five element families:

    • Control - MSAvalon.Windows.Controls, MSAvalon.Windows.Controls.Primitives
    • Panel -
    • Decorator -
    • Shape - MsAvalon.Windows.Shapes
    • Content Element - MSAvalon.Windows.Documents


    MSAvalon will be renamed System.


    Lower level presentation engine is accessible if needed, but average developer will not need to worry about it.


    Working with XAML and Code-Behind is presented as ASPX and code-behind is today for ASP.NET projects.


    Proprietary <style> tag with totally diff. rules than CSS. Defined in resources. Supports analogous selector concepts (element, class, id). Element says Style="{foo}" where "foo" is a named style.


    Build process takes XAML file and makes a source file out of it, then compiles it to a .baml (binary-xaml).


    Panels are a container control and contain child elements controlling their layout. Analogous to HTML div element.

    • DockPanel - provides common docking layout
    • GridPanel - provides common table layout
    • TextPanel - analogous to HTML table element
    • FlowPanel - takes series of child controls and handles flow control like HTML where things wrap or expand as control is sized
    • FixedPanel - lays out fixed size elements


    Special attribute naming syntax uses "." to signify properties to parent control. For example: <DockPanel><ListBox DockPanel.Dock="Left"/></DockPanel>.


    Shapes are elements for Vector Graphics. Here's where SVG experience would help you. ;)


    Decorators: Have one child and affect rendering of that child. Examples today:

    • Borders
    • Transforms


    Style.VisualTree element changes rendering of existing elements (tweak or replace). Style.VisualTriggers allow you to look at properties of the visual control and change appearance based on that. Analogous to dynamic CSS properties in IE5+.


    Code can be embedded in the middle of XAML (instead of using code-behind).


  • Avalon: Introducing the Next Generation of Windows Presentation Services

    You can find my full coverage of the first general Avalon session here. I'm getting ready to head into a more specific one now. Learning to better manage my power to make the battery last longer in the sessions. Charging up now for next one. Network has been spotty today. It's not that you can't connect to the wireless network, it's that it just doesn't give you an address. :(


  • PDC2003::Introducing the Next Generation of Windows Presentation Services

    “Avalon” : Introducing the Next Generation of Windows Presentation Services


    The Avalon Approach

    • Unified approach to UI, Documents and Media
    • Integrated, vector-based composition engine
    • Declarative programming
    • Integration a major consideration in the new design


    Different layout modes provided

    • Adaptive layout - basic scaling, sizing
    • Flow layout - flow control
    • Auto-Flow layout - flow + paging/text-sizing for you


    Developer Experience

    "Best of Web, Best of Windows" - bringing together the advantages from both worlds


    Declarative programming

    XAML = Extensible Application Markup

    • 1to1 correspondence with object model
    • Key role in enabling interoperation between UI authoring tools and developer tools


    Fundamental XAML concepts

    • Markup can contain code
    • Markup can be compiled for execution
    • Markup and procedural code are peers in terms of execution speed


    New Development Process Dynamics

    • Markup and code integration enables designers to take a direct role in the application and content development process
    • Expressiveness of XAML enables designers to create compelling experiences with high visual quality and refinement
    • Separation of markup and code enables designers to focus on the experience while developers focus on the logic.


    Consistency with Flexibility

    • Consistent Programming Model
      • Code and markup are both first class citizens
      • Consistent model between UI, document and media
      • Presented through managed interfaces
    • Greater access to the underlying presentation services
      • Ability to customize system components
      • Easily build new components from system base classes



    Key Service/Concepts

    Building blocks for applications

    • Controls
      • Enabling re-use and new levels of customization
      • Control extensibility and composition
      • Panels for layout of controls
      • Properties and styles
      • Accessibility patterns for new controls
      • Composition of controls is what it's all about now
    • Media
      • Enabling future experiences with a higher level of quality
      • Revolutionizing the Media pipeline
      • Future proofing - resolution independence, double floating point precision, deeper color pipeline
      • Desktop Composition enables enhanced experiences, as well as a provides High DPI support for non-Avalon application
      • Direct3D based hardware acceleration through out the stack
    • Databinding
      • Moving data out of the grid - enabling data to play a greater and more interactive role in application and content
      • Make data interactive
        • Generate UI elements from data
        • Visualize data by generating graphical elements
      • Integration point with WinFS, Indigo, XML data
      • Two-way transforms on data
    • Document Platform
      • Enhanced readability, supported by common platform services
      • Formats supporting the different markets and consumption of documents
        • Fixed, flow, adaptive flow
      • Document specific controls
      • Container to aggregate multiple renditions, metadata packaging and right management
    • Desktop Experience
      • Integration of applications with the desktop experience
      • Presenting your data and provding a launch point for your applications
      • Re-using the Explorer Storage User Experience in your applications
      • Presenting the peripheral information on the desktop
      • Navigation and standalone applications with common deployment and discoverability models
      • Directo support of AERO models and guidelines



    Rich design-time support. Demo showed moving, rotation and sizing of elements on a XAML form. Enabled by placing controls in a XAML "DesignSurface" element and setting attributes that say "this element can be edited" (think contentEditable in MSHTML).


  • PDC2003::Keynote

    Bill Gates and Jim Allchin Keynote Address

    Gates kicks off the PDC.


    Big push for a more secure platform

    • Outlook Express overhauled
    • Static code analysis techniques employed on all code now compiled
    • Auto-Updating Overhaul
    • XP SP2 taking advantage of new hardware and techniques
    • Error reports that were uploaded are being used to find out where the most problems occur (special tools (data mining) created to process all the data and make it useful
    • Understanding what drivers aren't providing a good level of quality, video drivers specifically mentioned (*cough* ATI *cough*)


    Hardware innovation is key to each new platform being successful

    • Gates: hardware "moving full speed ahead"
    • 64-bit a big move, supported fully
    • Next-gen processors will build in NGSCB (next generation secure computing base) will be used for encryption
    • Computer must turn on quickly and network must always be there
    • Today's constraint is software! Software needs to manage itself and reduce it's complexity


    Digital Decade

    • Listening to music, organizing photos, videos, will be dramatically driven by software
    • The increase in productivity will be stronger in this decade than it was in the last, though there may not be as much hype
    • Expect to see form factors advance: wrist size, pocket size, hand held, desktop… expect all to change
    • Too much complexity today, need to solve security and need to provide unification
    • Connected Systems - Wiring up systems through software so they're transparent
      • Network types
        • Personal networks
        • Business networks
        • Social networks
        • Value Chain networks
        • Scientific networks
      • Breakthroughs
        • Advanced Web Services
        • Workflow and Process
        • Distributed Management
        • Ad-hoc Connections
      • P2P very important
    • Information Driven
      • Need to improve OS level so applications can share common features
      • No standard schemas. Had the clipboards, but haven't advanced since then.
      • Need
        • Rich search and views
        • Unified storage
        • Self-organization
        • Information agent
      • Ability to intermix mail, news, notes into hierarchy defined by user
      • If not done in OS, every application has to do it itself and then user has to spend time learning differences
    • Experiences
      • Breakthroughs
        • Speech recognition and synthesis
        • Real time communications and phone integration
        • Scalable reading experience
        • Visual manage 1000s of files, pictures, contacts, songs
    • Gates: "Going to come together in Longhorn"
    • Gates: "Biggest release since Windows '95"
    • Developer Platform Advances
      • Presentation - Avalon - organized around compositing, built around XML
      • Data - WinFS - unified storage
      • Communication - Indigo - queuing software, transaction software, new messaging approach
    • Guided tour of Longhorn
      • Ctrl+Alt+Delete (wouldn't be windows without it!)
      • Alpha-transparency abundant
        • Windows animate in and out
        • Sidebar on the right top most, but alpha-transparent
        • All because of Avalon
          • Pixel Shaders!
      • Ran Visicalc to prove compatibility
      • Sidebar all about presenting information services
        • Time
        • Buddy list
        • RSS feed
        • Anything
        • Add/Remove whatever you want
      • My Documents advanced
        • 1100 items shown
        • Not sitting in one physical folder
        • Dynamic view generated by system
        • Typed into search criteria and the filter was applied on the fly, blazingly fast
        • Can filter on built in columns
        • Stack view shows all the items according to selected column
          • Dynamic
          • Based on metadata of WinFS
        • Completely extensible schema
        • Ink file names in the shell view!
        • Can drag-drop files to associate metadata of virtual stack folders (NOT PHYSICAL FOLDERS)
        • Can stack by multiple columns
      • People and Groups
        • Manages all address book like functionality in one place
          • IM
          • Addressing
          • Faxing
          • Communication History kept
        • Common File Dialog/Control Provided in Avalon
      • Broadcast presence demonstrated
        • LIVE VIEW OF REMOTE DESKTOP IN A WINDOW (like real-time tv-broadcast!)
        • All because of Avalon
      • Ground up 100% Longhorn Targeted App
        • Demo'd as a smart client from a web-site
        • Demonstrated schema extensions
        • Demonstrated relationships
        • Showed a lot of blending/fading and seamless integration of a video clip
      • "When you think about Indigo, think about Web Services"
    • Three waves of software
      • Today
        • WinXP
        • Win Server 2k3
        • Office 2k3
        • Live Communications Server 2k3
        • Visual Studio .NET
      • Tommorow
        • Yukon
        • Visual Studio .NET (whidbey)
      • Near(?) Future
        • Longhorn
    • Ride the Next Wave
      • Fundamentals
      • Web services
      • Managed Code
      • Smart clients
      • Community involvement


    Next generation Windows API called WinFX



    • Deployment and services
      • "Click Once"
      • No reboots
      • Software Up Services
      • Comprehension migration
    • Reliability
      • System and app tracing
    • Performance
      • Super paging


    • Creating a secure system
      • Start securely
        • Driver signing
        • System DLL protection
        • Code integrity
        • Hardware-assisted secure boot
      • Stay Secure
        • Software Update Service (SUS)
        • Windows Update
        • Security Configuration Wizard
        • Trust Center
      • Build Securely
        • Visual Studio
        • Secure Execution Environment (SEE)
      • Communicate Securely
        • Smart Card, Identity System, Biometrics
        • Secure networking, WS-Security
        • Internet Connection Firewall
        • Creoss-organization trust
      • Run securely
        • SEE
        • Behavior Blocking/NX
        • LUA/PA
        • Consistent UI


    Presentation Challenges

    • Unified presentation model
    • Blend UI types (windows, web, media)
    • Unified programming model (Avalon)
    • Integrated, vector-based compositing engine
    • Native support for advanced input
    • Support for declarative programming (XAML (zaamul))
      • Markup for Windows
      • Code and Content are separate (CODE-BEHIND!)
      • Easy for tools to consume and generate
      • xmlns=""
    • Demo'd by Chris Anderson and Box
      • Plenty of jokes about Don using Emacs
      • Namespaces MSAvalon.Windows[.Controls]
      • Base class Window
      • Up against the "metal", no more "wrappers"
      • C# compiler now ships with the platform
      • Unified build system, MSBuild, ships with the platform
        • XML based (very similar to nAnt)
        • Generated by VS.NET Whidbey!
      • XAML uses partial classes to combine the .xaml file with the code-behind
      • Avalon now supports unit heights natively (pt, inches, etc.)
      • Uses exact same patterns as ASP.NET to resolve form fields/event handler methods from XAML to Code-Behind
      • Syntax of XAML reminds me of SVG (DonXML is in heaven right now)

    Storage (WinFS)

    • Data is trapped inside application silos, each with its own schema and store
    • Relationships are buried; software doesn’t surface the obvious links
    • Shell views are tied to folder heirarchy
    • So what can we do?
      • Schematize the data
      • Logical views
      • Programmatic relationships
      • Synchronization service
      • Information agents
    • Demo'd again by Don and Jim
      • Starts off with Don making Allchin his code-monkey, Jim's going to be doing all the coding in vi
      • ContactPickerDialog a core Avalon dialog 
      • Note to self: If you had any doubt as to whether Allchin has his hands in this stuff, he is banging out code like he writes it everyday.
      • System.Storage[.Core] namespaces are where the WinFS bits lives


    Ok... my battery dies right about here, so I had to resort to drastic measures: pen and paper. *sigh*




    • Challenges
      • Web services are a great start, but..
      • Advance Web Services
        • Secure, reliable, transacted
        • Heterogeneous interop
      • Powerful messaging capabilities
      • Programming model extends existing



    • Too many ways to manage contacts today
    • No single RTC API
    • Current RTC APIs are monolithic and provide no common set of UI controls
    • OS now provides
      • Single source for contacts
      • Modular platform UI controls
    • Demo again by Chris and Don
      • Demo app was a weblog editor (see post on Don's blog!)
      • System.MessageBus is the root namespace for Indigo
      • Port class is "where all life begins"
        • ISendChannel interface
        • Message class


    The keynote has ended and I'm jacked into a socket. I now have the bits in my hand and will be installing them shortly. My first session up is another Avalon session... stay tuned.


  • The Keynote

    Well, the keynote has begun. You can find my coverage here (not much yet, since it's mostly business). Here's a couple pics too:

    Update 10:24AM (PT):
    Just letting everyone know that updates have been spotty because the wireless has been spotty in the conf. hall. I just updated with tons of information, check it out.

    Update 12:05PM (PT):
    The keynote has ended. I've made my final update to the notes and will be adding some pics and maybe video shortly.


  • Day 2

    Thanks to Drew and Kevin for the awesome job they are doing on the PDC Blogs. They were up until 2 a.m. looking for great stuff to post. I hope they can keep up later today when the flood gates (or is that Gates) get turned on. Heck, I hope I can keep up.

    [The Scobleizer Weblog]

    I'll be doing my best to provide the same level of coverage all week for all the sessions I attend. What it all comes down to is power. I have all the network I need, but I can only get through two hours on this battery before I need to start parkin' my butt next to a socket. I just wish they'd figure out how to harness the power of the human body already. Sheesh, what's the hold up? :P 

    Ok, so it's about 7:10PT at the moment and I'm doing my best to prepare my brain for all the information it's going to need to process today. Hopefully I'll be able to retain at least 60% of it. I'm going to try to get a good seat in keynote hall (Hall A) so that I can snap off some pics and maybe even sneak out a little video of Bill and Jim. Refresh your aggregators often starting 8:30PT. I think I'll stick with the same format as I used yesterday where I have a blog entry per session where I'll link to an article which I will continuously update with information. I prefer using OneNote to take the notes and once I build up enough of a buffer I just copy paste into the .Text post editor and update the post. The process seemed to work quite well.

    Tip o' the mornin': Attendees, if you're having problems accessing commnet or pdcvibe, make sure you remove any WINS servers you have set up.


  • End of Day 1 (for me at least)

    Ok, well we're definitely off to a good start. Don, Tim and Martin definitely put on a good show in their pre-conference. You'll find my coverage of it here. While it wasn't exactly earth shattering, it wasn't meant to be. If you've never written a web-service before then you got an amazing introduction. If you have, then you got a great refresher course and maybe even learned some tricks you didn't know about. What's good though is that they basically ramped us all the way up to where we need to be for the Indigo sessions to begin. I'm pretty psyched about that.

    After the second session I finally got to meet a couple people who I've interacted with at one time or another in blogspace: Kirk Allen Evan, Don XML (it actually says it on his nametag) and Scott Watermasysk (of .Text fame). I hope to meet plenty more as the PDC progresses.

    Alas, I'm suffering from jet lag. My body just doesn't tolerate changes in its sleeping schedule at all. Even though we gained an hour and everything I'm still messed up. Oh well, I'll hit the sheets extra early tonight and hopefully feel better tomorrow. Keep your eyes peeled for plenty more blogging on tomorrow's sessions! ;)


  • PDC 2003::Pre-Conference::The XML and WebServices Perspective

    The XML and WebServices Perspective

    “Gudge” on the floor doing the speaking, Don Box (top left) chiming in with his bits of wisdom, Tim Ewald (top right, behind computer) doing the dirty work of writing sample code.

    Part 1: XML Core Technologies

    Q: What is XML?

    • Just a way of representing information.
    • A tree representation of data.
    • The XML Information Set.


    Emphasis on XML declaration and it's effect on parsing the contents of the file.


    How is the decl. read if the encoding is not yet known? BOM rules (first 4-5 bytes) defined in Appendix F of the Infoset specification.


    XmlReader/XmlWriter APIs being abstract allow backend store to be anything:


    XPathNavigator makes sense most applications.


    Don mentions a new XmlReader coming along with Whidbey. *cough* binary *cough*


    Most XML APIs require you to explicitly request attributes (i.e. not included in standard reading  cursor methods). Also pointed out is that, unlike the forward only mode of the cursor model, you can freely move back and forth through attributes for the given element node.



    XmlReader supports XML Infoset and extra features include:

    • Distinguishes between empty elements and elements with explicit close tags.
    • QuoteChar property (so you can tell if single or double quotes were used).


    Be aware of the fact that the XmlReader does support text nodes properly where empty space is included in the instance document. Test against multiple instance documents. You can tell the XmlText reader to be more strict about what it parses using the WhiteSpaceHandling property/enum. Default is All. Property can be changed on the fly.



    Martin points out that there's no XmlNodeWriter impementation in the framework and Don chimed in with "currently". If I'm not mistaken, there is a third party implementation available.



    Good for constructing documents, horrible for navigation.



    Allows you to describe the traversal of the tree in a language independent matter. Each path made up of location steps. Location steps made up of: axis, node test, predicates. Short hand syntax provided to cut down on keystrokes. XPath works with namespace specification. Must be explicit with prefixes if nodes are not in default (empty) namespace. Prefixes don't matter, they're just hash keys to the URI used to reduce keystrokes/document clutter.



    Read-only. Dynamic Cursor. Query a document for it's nodes in an efficient manner. XPathExpression instances can be used to compile commonly used expressions. XPathDocument should be used over basic XmlDocument if you're doing a lot of XPath queries (provides improved performance). Using Xpath, while potentially more verbose, much less brittle than hard coding against XmlDocument. Also, XPath has great support for handling whitespace situations mentioned earlier in XmlReader topic.



    Build on top of previously discussed XML technologies. Can be declarative or imperatively.


    XML Schema

    Don: "The most complicated layer in the XML stack." Martin chipped in "shipping today", I assume they're referring to XQuery.

    Used to describe XML trees. Allows types to be assigned to text content (XML Schema Part 2: Data Types) ints, strings, dates, etc. Rules really have nothing to do with XML, could technically use same rules to write any other text parser. Dates are aggravating aspect.


    XML Schema Part 1 consists of three warring factions. SGML group, basis for XML, got no respect in the 80s. When XML came around and they got their recognition, but were quickly shot down by OO group and database group.


    elementFormDefault attribute is perhaps the most confusing attribute on a schema document. "qualified" is most commonly used, but not the default! Attribute is provided to allow people to make the choice between being explicit or not, but ends up causing confusion.


    blockDefault="#all" just makes the schema do what you expect it to do. Don: "You'd be amazed at what your schema would do if you didn't use the attribute."


    How can we use schema?

    • Validation (most common)
    • Infer types for programming languages (C#, VB, etc.), XSLT 2.0, XQuery


    Many schemas start by developers reverse engineering a sample instance document. Tim suggests always using global element declarations and then ref'ing them. This is to avoid ambiguity between local element names within a schema because "that's the way people think".



    Layers on top of XmlReader, but XmlTextReader the only XmlReader it can layer on top of "today" (hinting that this is finally fixed in Whidbey). XmlResolver implementation is used to resolve URIs, however the base implementation can't resolve opaque URIs. Therefore you must add them to the schema cache (Schemas property) manually. Exceptions thrown for schema compilation or validation errors unless a callbacks are registered and prevent the exception from being raised.


    Part 2: SOAP, Drill Down on ASMX

    Q: What are web services?

    A: A set of protocols that allow us to build our services and make them available to others who wish to access them. Layered on the XML stack. Can't exist without XML and XML schema. SOAP and WSDL being the primary specifications.



    Signaled the move from object-based integration to service-based integration.


    Microsoft provides "21/2" stacks in .NET v1 for working with SOAP:

    • Remoting using SoapFormatter - If there was one piece of the .NET platform that could be recalled, it would be the SoapFormatter: "an architectual dead end". Don says "'re living a lie.." if your using the SoapFormatter.
    • ASMX - Focuses the developer on the code that is "mine" and the code that is the callers. Service-oriented programming. Explicit boundaries. Autonomy. Messaging. Share schema and not classes.


    SOAP gives us a simple, yet understandable model for evolution of a format. Enables the systems involved to evolve independently of each other. Came after trying to get DCOM to be the protocol over the internet. SOAP took a step back and said: "this HTTP thing isn't going to go away, so why not take advantage of it?" That said, SOAP was not designed specifically for HTTP, it was designed with the concept of having a framing transport to exchange the messages (SMTP, MSMQ are two other existing examples) lying underneath it.


    Intermediaries are a major factor in the SOAP processing model. Tim gave examples of how Microsoft is figuring out it's web service deployment strategy and gives examples of how the network group wants the ability to control and know more about SOAP requests, not just at the network hardware (switch/firewall) layer.


    Don states that SOAP 1.2 is the last SOAP specification "we'll ever need". Reasons:

    • You never get a chance to do three versions
    • SOAP 1.1 is embedded in systems already - getting people to version up is just impossible. Don gives TCP IPv4 to IPv6 example as an example.
    • "If it is not, it is all a lie." - because the sole purpose was to be a completely extensible protocol


    Next version of platform speaks 1.2 natively. Almost spoke 1.2 in Win2k3, but spec wasn't finalized in time.


    SOAP is based around the concept of an envelope. Don calls an envelope "Data+". It's just data. It is NOT a serialized object graph. If you want to treat it as one in your application, that is a "subjective decision that has no bearing on the architecture".


    The best way to think about the SOAP body is that you are expected to know what is coming. The best way to think about the header is that you are not expected to know what is coming. The default processing model for the header is that you can just ignore what you don't understand. SOAP requires that all headers must be read and if any mandatory headers (mustUnderstand="true") are present, they must be processed. Most SOAP stacks buffer the headers and then, stream the body. The headers are targeted at the destination of the message unless there is an explicit target defined with the "actor" (in 1.1) or "role" (in 1.2) attribute. Explicit roles via URIs can be specified of the "next" role can be specified using the well known URI "". Soap 1.2 adds a "relay" attribute which says that "if you don't process this header, please make sure to pass it on to the next intermediary".



    An extension to XML Schema. Used primarily at design-time. Can be used at runtime for discovery and other purposes, but once communication begins, WSDL is out of the picture. Mostly used today to generate language specific bindings.


    Most important content is an XML schema. Can be by reference (linked) or by value (inline).


    Messages define request/response messages and declare what instance document is expected. WSDL 2.0 aims to remove too many levels of indirection, which means the message element as we know it goes away.


    PortTypes are "the focal point of WSDL". Specifies input and output stages.


    Bindings look identical to PortTypes and basically are. Changing a portType means you need to change a binding. Define transport specific details.


    Q: How are web services implemented in .NET?

    A: Classes/methods peppered with attributes from the System.Web.Services[.Protocols[.Description]] and System.Xml.Serialization namespaces.


    Can design from either the .NET first perspective or the WSDL first. WSDL first gives you greater control over what is really important: your public interface. .NET first gives you the ability to avoid learning the finer aspects of WSDL (a bad thing IMHO).


    Right now Tim is going over the various attributes and what affect they actually have on your WSDL file. I won't bother covering it here since it's nothing you can't learn in the SDK.


    Part 3: Mind-Numbing, Blistering, Crazy, Hard, Fascinating "Stuff"

    Tim points out the fact that by the time the typical web method gets access to the data of a request, the "XMLness" of it is gone. The various layers in the SOAP stack between the low level request and your code receiving it have turned it into native .NET data.


    Q: So, how do we maintain that control?

    A: By making your WebMethod take an XmlElement as a parameter decorated with the XmlAnyElementAttribute. Note that this also means that you now have to take over the XML processing for the SOAP body's child element.


    Use XmlConvert whenever you need to parse strings. It is implemented according to the rules in XML Schema Specification Part 2.


    The mandatory header problem: not processing headers with mustUnderstand. Can cause any SOAP service to fail by sending it a header it doesn't understand. ASMX stack takes unknown headers, those not mapped into the ASMX class' fields using SoapHeaderAttribute, and puts them into SoapUnknownHeader instances. Use Tim's SoapExtension to test for unhandled headers on every message received.


    Don's having trouble with an example where he wants to transform an incoming XmlElement using XslTransform and then hand it back as an XmlElement. Little does he know that he just needs to use the overload of XslTransform::Transform that takes an XmlWriter layered over a MemoryStream and then load it back into an XmlDocument instance by resetting the position of the MemoryStream, layering an XmlTextReader over it, then passing that to XmlDocument::Load. I wish I could tell him, but he's sitting far away and Tim has moved on in the slides. :)


    Web Service Enhancements - WSE

    Allows Microsoft to do short cycle product releases without affecting the core of the framework, yet get something out there for the developers to keep up with the spec. Intended for early adopters and not supported as long as the typical MS product support.


    Protocols supported are not widely implemented by other vendors yet. So expect your clients to have trouble matching support on their end unless they're .NET as well.


    We're currently going over the various input/output filters in the WSE. All code samples, not much to write about.


    Ok, we pretty much blazed through some serious stuff (WS-Addressing, WS-Security) at the end. It was pretty much spec coverage with explanations of how WSE implements them. Make sure to download the 2.0 tech-preview if you want to play with this stuff.


  • Deleting Posts Not Working

    Not sure if this is a bug in .Text or not but just tried deleting a post and it gave an error, anyone else tried this?

    [Andrew Stopford's Weblog]
    No, you're not alone. I just tried to delete a post and it gave me an error as well. Unfortunately Scott is here at the PDC and probably won't be able to have a chance to look at this until later tonight.


  • Pre-Conference: .NET - The XML and WebServices Perspective

    So I just pulled up in the front row of the .NET - The XML and WebServices Perspective pre-conference session. Don and Tim are setting up as I type. I'll update this entry periodically with notes that I'll be taking in OneNote.

    Update 9:34AM (PT):

    Well, Murphy already has his way with us. We lost power briefly while they were setting up. Not to worry though, everything is back up and running at this point. The “room” is  already pretty full and there's still plenty of time for people to get here before it starts.

    Update 11:08AM (PT):

    Ok, instead of continuously updating this post and making it huge, I've started an article over here.

    Update 1:45 (PT):
    Just to let everyone know, I've started updating with coverage of the second part of the pre-conference session.


  • And So It Begins...

    Well, the masses are pouring in and it's only Pre-Conference day. Here's a shot of the registration process (from a distance):

    And here's a shot of the “Community Lounge” where they provide ethernet connections, power and wireless access points:


  • My PDC Calendar

    In case anyone's interested. Here's what my PDC Calendar is looking like so far. Of course I might change things on the fly depending on how I'm feeling about certain subjects, but probably not too drastically. You'll notice it consists mostly of Indigo sessions with sprinklings of Avalon and Longhorn.


  • PDC Bound

    Welp, I depart Newark airport tommorrow at 3PM to head for LA. I'm really excited that I'm going to be there to experience the first major step in the revolution of Windows programming since Win32.

    I'm really looking forward to finally being able to talk about Whidbey in public. The few things Scott has leaked about ASP.NET are but a taste of what you can expect to see once you get Whidbey up and running. I'm also looking forward to finally getting my hands on Longhorn, Avalon and Indigo. So little is actually known at this point about them, but all will be revealed starting Sunday. Being able to actually sit down and experience the technologies first hand is the best way to learn and understand them. So 

    Saturday night is going to be like xmas eve for PDC attendees. I don't know if I'll even be able to fall asleep. ;)


  • Going to the PDC

    Yeah, I've been real quiet for a while now. Partly because I needed a break from spending so much time with technology and partly because I haven't felt that I really have any new insight to offer into .NET since it's been out in the wild for quite some time now and all the tips and tricks are pretty much out there.

    Well, here comes the PDC. We've got a lot of new technology upon us and I expect that I'll get back into the crazy mode of dissecting it all and relaying my thoughts and opinions about it to everyone through this weblog.

    Hope to see some of you there!