Clemens Vasters on Longhorn

Exploring Next Generation Web Services with Indigo

October 2003 - Posts

  • Installing the PDC build

    Filed under:

    I’ve got the PDC build running on my box. Jim Allchin was right; it isn’t exactly screamingly fast – at least in Virtual PC. Here are a few notes:

    ·         Needless to say, but: Have a dedicated box for Longhorn or use Virtual PC. I’ll likely get a new box when I am back at home. Sounds like a machine brutally optimized for 3D gaming is a good bet – along with 2GB of memory.

    ·         If you can’t at least assign 256MB of memory to the VPC machine, forget it. If you can allocate more, go for it. Shut down all apps and services on the host you can and give Longhorn room to breathe.

    ·         The VPC2004 from the PDC disks will remove any previous Virtual PC builds from Connectix. The version from the PDC disks will expire February 28th, 2004. Which means that I just went from a licensed copy to a demo copy. I don’t like that, at all.

    ·         You will need to log on to the server to acquire your product key. The userid and password is in the disk booklet.

    ·         Take your time. Installing into Virtual PC takes a very long time. Expect that your box will take about 2-3 hours and I wouldn’t do too much on it during that time. Expect the box to lock up, requiring a hard reset. It did that several times for me.

    ·         I’ve mounted one of the ISO images from Disk 2 into VPC, which seemed to be the most convenient option.

    ·         On my Dell Inspiron 8100, Longhorn comes up in 4-bit color mode and that’s the only mode available. You will have to install the VPC additions into Longhorn to get a graphics driver that works, reboot and then switch to that one.

    ·         Just right after install, with nothing done, the VPC disk size stands at 3GB. I think you should have some 6-10GB available if you want to do anything with it but looking.

  • PDC: Don's solo session on Monday

    Filed under:

    The typical PDC attendee is very special. PDC is not like TechEd where you get very practical information on today’s shipping products. PDC is about futures and it requires a lot of imagination of how applications could look and could work on the new platform. It’s about building excitement for the things to come. PDC attendees are the folks who will make the first wave of applications happen. They are excited about technology and they love to code.

    Don Box’ talk yesterday afternoon (WSV201) was very much about now. I heard a few people complain that he didn’t show enough new code. I don’t think he should have. I found his talk very important and Don delivered his message very well. Don’s talk was very much about architecture. No matter how much you want to see code, it’s not the 1990’s anymore. Simply hacking up an app won’t let you play in a connected application ecosystem that’s powered by Web services. WinFX will enable better applications by simplifying coding complex applications in a big way and making developers more productive. You’ll code less. Code isn’t all that matters. Architecture matters. Negotiation and contracts matter. Design matters.

    There were four key takeaways from his talk: Boundaries between applications are explicit. Indigo’s programming model is different from previous distributed programming models such as COM and Remoting, because it doesn’t make objects implicitly remote. You need to declare things as being remote. The fact that you’re theoretically able to write a local application and can then write a configuration script that distributes this application across multiple machines using Remoting was a naïve approach. Likewise, writing a COM application that’s built as a local application and reconfiguring it to run as a distributed application using a different registry setup is a naïve approach. With Indigo, you will need to start writing applications explicitly as being remote. If you love objects, you will find a few things very restricting in this world, and at first sight. There are no automatically marshaled callbacks, interfaces and objects. There are messages, not object references going across the wire. The endpoints of communication, called services, aren’t fragments of the same application based on the same types and classes. Services are autonomous units which adhere to compatible data contracts and policy, not dependent units that use identical implementations. We share schema, not type.

    Don recommended, as I’ve done earlier here on the blog, one of the most important Indigo talks for anyone who’s building software on today’s platform (that means: everyone at PDC): WSV203, “Indigo”: Connected Application Technology Roadmap; Wednesday, 11:30am, 409AB.  Go.

  • PDC: Rebooting the blog after the keynote: Indigo in a nutshell

    Filed under:

    Here’s my quick, two sentence definition of Indigo in order to give you an idea about the scope of this thing:

    Indigo is the successor technology and the consolidation of DCOM, COM+, Enterprise Services, Remoting, ASP.NET Web Services (ASMX), WSE, and the Microsoft Message Queue. It provides services for building distributed systems all the way from simplistic cross-appdomain message passing and ORPC to cross-platform, cross-organization, vastly distributed, service-oriented architectures providing reliable, secure, transactional, scalable and fast, online or offline, synchronous and asynchronous XML messaging.

  • PDC: Best keynote ... ever.

    Filed under:

    The PDC keynote, featuring Bill Gates, Jim Allchin, Don Box, Chris Anderson and, on video, John Scully, Marc Andreesen, Bill Clinton, Warren Buffet, Sean Combs (P. Diddy) and lot of other folks ... was easiest the best, most substantial, longest and fun keynote I've ever seen. And I've seen very many.

    Longhorn, the Aero shell, the Avalon programming model, WinFS and Indigo rock already and they are going to get better and better as time progresses.

    Hey, Linux Penguins, here's the new thing to clone. Good luck.

  • Steve Swartz and Doug Purdy set to blog about work.

    My good friend Steve Swartz is giving blogging a second try and this time for real. Given that the stuff he's been working on is/was in the stealthier areas of the Indigo effort (not the public WS-* specs), it was pretty difficult for him to blog about work, but now with PDC things are changing.

    In an effort to get newtelligence's PDC T-Shirt, Doug Purdy switched from Radio to dasBlog as well.

    These two blogs will be very interesting places to watch if you are interested in the Indigo programming model.

    Doug Purdy is the Program Manager for the new serialization framework (which consolidates XmlSerializer, BinaryFormatter and SoapFormatter), Steve Swartz drives the Indigo programming model that all of us will use.

  • PDC Countdown: Use ASMX and Enterprise Services Now For Tomorrow

    Filed under:

    Brad More is asking whether and why he should use Enterprise Services.

    Brad, if you go to the PDC, you can get the definitive, strategic answer on that question in this talk:

    “Indigo”: Connected Application Technology Roadmap
    Track: Web/Services   Code: WSV203
    Room: Room 409AB   Time Slot: Wed, October 29 11:30 AM-12:45 PM
    Speakers: Angela Mills, Joe Long

    Joe Long is Product Unit Manager for Enterprise Services at Microsoft, a product unit that is part of the larger Indigo group. The Indigo team owns Remoting, ASP.NET Web Services, Enterprise Services, all of COM/COM+ and everything that has to do with Serialization.

    And if you want to hear the same song sung by the technologyspeakmaster, go and hear Don:

    “Indigo": Services and the Future of Distributed Applications
    Track: Web/Services   Code: WSV201
    Room: Room 150/151/152/153   Time Slot: Mon, October 27 4:45 PM-6:00 PM
    Speaker: Don Box

    If you want to read the core message right now, just scroll down here. I've been working directly with the Indigo folks on the messaging for my talks at TechEd in Dallas earlier this year as part of the effort of setting the stage for Indigo's debut at the PDC.

    I'd also suggest that you don't implement your own ES clone using custom channel sinks, context sinks, or formatters and ignore the entire context model of .NET Remoting if you want to play in Indigo-Land without having to rewrite a large deal of your apps. The lack of security support of Remoting is not a missing feature; Enterprise Services is layered on top of Remoting and provides security. The very limited scalability of Remoting on any transport but cross-appdomain is not a real limitation; if you want to scale use Enterprise Services. Check out this page from my old blog for a few intimate details on transport in Enterprise Services.

    ASMX is the default, ES ist the fall-back strategy if you need the features or the performance and Remoting the the cheap, local ORPC model. 

    If you rely on ASMX and ES today, you'll have a pretty smooth upgrade path. Take that expectation with you and go to Joe's session.

    [PS: What I am saying there about ES marshaling not using COM/Interop is true except for two cases that I found later: Queued Components and calls with isomorphic call signatures where the binary representation of COM and the CLR is identical - like with a function that passes and returns only ints. The reason why COM/Interop is used in those cases is very simple: it's a lot faster.] 

  • Blogging on newtelligence, Longhornblogs and Blogger at the same time. Blogging Enters The Age Of Push.

    Filed under:

    Yesterday and today I have added another new feature to dasBlog called "Crossposting". This feature, which will be available in the v1.4 build that I still plan to publish before the Microsoft PDC next week, is simplifying having multiple blogs on several sites by allowing a entries to be posted to a master weblog running dasBlog and having the engine crosspost across multiple weblogs using the Blogger API or the (more powerful) MetaWeblog API. If the entry is updates locally, the crossposts are updated and if the entry is deleted, the crossposts get wiped, too.

    My concrete problem was that I wanted to contribute to, but didn't want to maintain a separate blog. Now I can post a local post here, check a checkbox and it'll appear in both places. To still get the referrals, I am "bugging" the crossposted articles with a transparent GIF that phones home into the referrer stats of the main blog.

    I'll post a "how to" along with the release, which I hope will happen by Friday. Until then, you can check that it works by looking at the three synchronized weblogs.

  • PDC Countdown: While you wait for the Indigo show to start....

    Filed under:

    While you wait for the Indigo show to start, here is some stuff to look at and consider (again).

    The links at the bottom of this post point to five slide decks that I have been using for presentations throughout this year. All of them are, indeed, very relevant to the Indigo story you will be hearing at PDC 03.

    This spring, I’ve been on the road together with my good friend Steve Swartz, who is one of the Architects and Program Managers at Microsoft’s Indigo Team. On this tour, we have presented lots of ideas around scalable applications in seven cities all over Europe. And of course, we knew at the time that Indigo was coming … ;)

    The “DistSys” ZIP files below contain the four decks we have been using on that tour. “Layers” is about layering, tiers and services (pay attention to “dialogs”), “Processes” is about implementation aspects such as process models, state and sessions, “Transactions” is about taking thinking about transactions beyond the database and “Scaling” highlights several essential ideas around scalability.

    My DEV357 talk at TechEd Dallas, which is in part an aggregate of the talks from this tour, may even be more important, because it actually contains outspoken, concrete guidance for how to build applications on today’s technology stack in order to be ready for Indigo. To summarize the core message of that deck in terms of appropriate use of the existing technology stack for distributed systems:

    ·         .NET Remoting: Use for “local”, on-machine, cross-app-domain communication.
    (In clear words: Remoting calls don’t leave the machine!)

    ·         Enterprise Services: Use for “near”, cross-process, cross-machine communication

    ·         ASMX: Use for “near” or “far”, cross-process, cross-machine communication. Prefer over Enterprise Services, unless you need the features or have pressing performance problems.

    Read. Understand. Absorb.


  • SOA: Checking postconditions is more important than checking preconditions

    Filed under:

    I see quite a few models for Service Oriented Architectures that employ pipelines with validating "gatekeeper" stages that verify whether inbound messages are valid according to an agreed contract. Validation on inbound messages is a reactive action resulting from distrust of the communication partner's ability to adhere to the contract. Validation on inbound messages shields a service from invalid input data, but seen from the perspective of the entire system, the action occurs too late.

    What I see less often is a gatekeeper on outbound channels that verifies whether the currently executing local service adheres to the agreed communication contract. Validation on outbound messages is a proactive action taken in order to create trust with partners about the local service's ability to adhere to a contract. Furthermore, validation on outbound messages is quite often the last chance action before a well-known point of no return: the transaction boundary. If a service is faulty, for whatever reason, it needs to consistently fail and abort transactions instead of emitting incorrect messages that are in violation of the contract. If the service is faulty, it must consequently be assumed that compensating recovery strategies will not function properly and with the desired result.

    Exception information that is generated on an inbound channel, especially in asynchronous one-way scenarios, vanishes into a log file at a location/organization that may not even own the sending service that's in violation of the contract. The only logical place to detect contract violations in order to isolate and efficiently eliminate problems is on the outbound, not on the inbound channel. Eliminating problems may mean to fix problems in the software, allow manual correction by an operator/clerk or an automatic rejection/rollback/retry of the operation yielding the incorrect result. None of these corrective actions can be done in a meaningful way by the message recipient. The recipient can shield itself, and that is and remains very important. However, it's just a desperate act of digging oneself in when the last line of defense did already fall.