David Pallmann's blog

Distilled ramblings on Distributed systems

  • This blog has moved

    David Pallmann's blog is now hosted at MSN Spaces. The new location is http://spaces.msn.com/members/davidpallmann

     

  • Programming Indigo: What it Covers

    A few people have asked me what my upcoming Indigo book covers.  I try to cover the full Indigo product from the standpoint of what an application developer needs to know to be effective. You could write a completely different book about internals and lower level programming, and probably someone will. My book is very task-oriented. Most chapters present conceptual material, followed by how-to information, followed by a programming exercise to drive it all home. This book covers Indigo beta 1 specifically.

    Here's the topical organization:

    1. Introducing Indigo
    2. Fundamentals
    3. The Programming Model
    4. Addresses & Bindings
    5. Contracts
    6. Clients
    7. Services
    8. Security
    9. Interop & Integration
    10. Hosting
    11. Management
    12. Deployment & Troubleshooting
    13. Case Study: business example
    14. Case Study: peer-to-peer example
    15. Case Study: real-time example

  • Upcoming Indigo Book: Programming Indigo

    People have asked me why my blogging has been so infrequent. I can now reveal the answer: I've been hard at work on a book about Indigo over the course of the last year (giving my day job priority of course). "Programming Indigo" is being published by Microsoft Press and has started showing up on various book sites as its publication date draws near. This book is targed toward application developers and reflects Indigo Beta 1. I'll be blogging more about the book shortly.

     

     

     

     

  • Indigo samples in the WinFX CTP

    Now that the March 2005 WinFX Community Technology Preview is going out, we're starting to ship samples with Indigo. This first CTP contains only 25 Indigo samples, but there will be increasing numbers over time.

    Finding and setting up the samples is a bit trickier than we'd wanted it to be, so I offer some tips and tricks below. This is something we'll improve on with each successive CTP release, so any pain or inconvenience should be temporary.

    First off, where are the Indigo samples? They are part of the WinFX SDK and you locate and install samples through the documentation. The first step to getting Indigo samples, then, is to install the WinFX SDK, go to the documentation, and locate the section for Indigo samples.

    You can install a sample in one of two ways:

    (1) When viewing the documentation for an individual sample, you can install that sample using download buttons on the page.

    (2) You can find the full set of samples for the WinFX SDK in a zip file named AllSamples.zip in the WinFX SDK folder under Program Files.

    The important thing to know about the Indigo samples in the March CTP is that they are designed to work in a particular folder hierarchy that looks like this:

        \Quickstarts
            \Binding
            \Client
            \Contract
            \GettingStarted
            \Management
            \Service
            \vroot

    The reason for this organization is so you only have to create a single virtual directory, once, for all of the Indigo samples. You name this vdir "Quickstarts", and you point it to the \Quickstarts\vroot folder. Note that the \vroot folder won't actually exist until you build one of the samples.

    The samples project files copy service binaries and config up to \Quickstarts\vroot, so if you don't respect the folder hierarchy you may experience errors during building and the samples won't run. There are post-build events that copy files up to \Quickstarts\vroot and make assumptions about the relative hierarchy.

    Given this scheme, I find it's generally easier to install the samples from the AllSamples.zip file rather than individually from the documentation pages, because it preserves the folder hierarchy. If you install a sample individually, you must create folders in the right structure yourself. The doc page for each sample tells you what that structure is, but it's easy to miss.

    Even if you do go the zip file route, there's another gotcha you need to be aware of. Because AllSamples.zip contains all samples for the SDK, you end up with some very long paths if you extract all of it to your hard drive. In fact, the paths are so long that the copy steps in the Indigo samples can fail on you. A good solution is to find the Indigo \Quickstarts section of the zip file and copy that portion to your root, so you end up with a c:\Quickstarts and everything underneath. A bit of work, but if you do this you will have maintained the proper hierarchy and the Indigo samples should build and run for you happily.

    Once you're past all of that, start with the GettingStarted sample. If you build this sample, you should end up with these files in your virtual directory:

        \Quickstarts
            \vroot  (<-- vdir Quickstarts points to here)
                \bin
                    service.dll
                service.svc
                Web.config

    After you get the sample running, working with any other Indigo sample is just a matter of building the sample. They all copy to this same area.

    Don't let a few rough edges deter you from installing and running the Indigo samples. I've always found samples to be one of the key ways to learn a new product.

    I'd love to hear any feedback you have on the Indigo samples. In particular I'd like to know about what kind of samples you think we should be including and how we can make the existing ones better.

  • Intelligent Agents: dead and buried, or due for a comeback?

    Intelligent agents are an interest and a specialization of mine. From 1995-2002 I worked to pioneer and productize the intelligent agent space. What's an intelligent agent? It's an automated, personal servant. Agents are a subset of bots, the general term for automated programs. Another subset of the bot category is spiders, used by search engines and portals to scour the Internet and intranets.

    What exactly differentiates an intelligent agent from other kinds of automated programs? The answer can be found in the term itself. "Intelligent" suggests good decision making capabilities. "Agent" suggests specialization combined with personalization. Think travel agent, insurance agent, accountant, attorney: people who are good at what they do and represent you personally. So, an intelligent agent works on your behalf, which means it has to know something about your wishes, is good at some specialized task, and makes good decisions. If an agent can't do something useful, makes poor choices, or isn't tuned in to your expectations, it's highly unlikely you will entrust it with anything meaningful, so these three areas need to be masterfully implemented. Note that the "personalization" aspect of intelligent agents doesn't limit their use to individuals; an agent might just as easily have marching orders to serve a department or an entire organization.

    Why intelligent agents? During the Internet boom, we saw a great focus on interactive technologies: browsable web sites and email. This made the web great for human beings, not so great for automated processing. There was clearly a demand for such automation. What was needed was an automated counterpart to the interactice side of the Web. In 1999, MS Press published my book, "Programming Bots, Spiders, and Intelligent Agents in Visual C++". A year later, my programming language for intelligent agents, Network Query Language, was released. Many other companies courted the same space.

    Automated retrieval, transformation, and delivery of information over the Internet turned out to be possible, especially with good tools, but there were some nagging problems. These included accepting the imperfections of such technologies as screen scraping or using fuzzy logic to guess interpret the format of web pages. Web content frequently changed, forcing constant revision of programs. Content providers were perfectly content to be accessed by millions of human beings but raised objections when accessed by automated software. The bottom line was, the lack of an infrastructure for automated access and a lack of supporting technologies by major vendors put a damper on convincing many organizations to go forward with the idea of intelligent agents, even though the interest was there.

    Fast forward a few years, and the industry starts to get it. Just about everyone embraces XML as a universal data sharing scheme and already has an HTTP web server: put them together with a few new standards such as SOAP and we have first-generation web services. Now we are seeing the next generation of services, with enterprise-ready sophistication. These new services are able to support multiple transports and provide features for security, reliable messaging, and transactions.

    What is the purpose of services? To provide automated access to web and enteprise resources, with great interoperability. Who will access services? Programs carrying out the wishes of their owners, in a competent way, with good decision making capabilities. This should sound familiar, it's the criteria for intelligent agents discussed earlier.

    So far, service orientation has been emphasizing the definition and merits of the service, a passive program that responds to messages. But we shouldn't forget the client, the active initiator of messages. That's where many intelligent agents are going be implemented, as the clients of web services. Eventually our attention will focus on the client, and the need to make them competent, specialized, and personalized will be quite apparent. Intelligent agents will make a comeback, though it's too soon to know if they'll retain that label. We already see agent offerings emerging on popular search engines and job sites, a trend sure to continue. At home and in the enterprise, it's becoming commonplace to use agents to scan for viruses, keep software up to date, and filter out spam. We can imagine agents that scour multiple web services to find you the lowest price, the best deal, the fastest delivery, the news that concerns you, and the entertainment that suits you best. We can imagine agent interfaces that are carefully designed to let agents run autonomously on your behalf, but give you fine control over monitoring their status and revising your instructions. We can imagine agents that earn your trust in greater and greater degrees by proving themselves reliable and competent.

    It's nice to have the infrastructure and industry support that will let intelligent agents flourish, but the industry still needs to address two important areas: legal issues and security. I have seen, countless times, where a company has no concerns about a human being regularly getting data from a web site interactively, but when contemplating replacing that person with an agent there are suddenly legal concerns left and right. We need some precedents set for what your designated automated agent is permitted to do on your behalf. From a security standpoint, we need to think about what aspects of its owner's identity and permissions an agent may exhibit for security authorization and authentication purposes. We also need a surefire way for users to precisely specify what information about them an agent shares with the outside world. Agents will need to be shrewd about the information they share and who they share it with. Both of these areas are going to need scrutiny, and soon.

    Agents are back, and it's about time.

  • Design Patterns in Product Testing

    Let's say you're testing a platform or framework that is going to be used broadly, where the number of application scenarios is huge. You can't possibly build all of the possible kinds of applications to test those scenarios, no matter what your resources are, so how do you attain reasonable coverage? One answer is to complement application building and individual test cases with something in-between: building blocks. And a very nicely documented type of building block is the design pattern.

    If you can implement design patterns successfully in your framework, that confirms a larger set of scenarios based on those patterns is achievable. If you can implement a complete suite of patterns, that really says a lot. There's a lot of bang for the buck here, because you don't have to go and build all those individual applications. There are two other valuable by-products of implementing design patterns: usability data and samples. You can grade the ease of implementation of patterns to identify usability issues. And the design pattern code may make great samples to include with your product.

    Where design pattern testing falls short is when you have a feature area that no body of design patterns have addressed yet. Security is a prime example of this, where it seems we're still waiting for consensus and documentation of what the essential design patterns are.


© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker