Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

rwandering.net

The blogged wandering of Robert W. Anderson

Archive for June, 2008

Totalled

image Last weekend, my parked Audi was hit by a speeding vehicle.  The damage was pretty major: body, mechanical damage, and a bent frame.

Thankfully nobody was hurt.

Yesterday, my insurance carrier has declared the car a total loss.

It was in good condition with only 48000 miles on it.  I planned on keeping the car for a few more years. 

These things happen.  On to plan B. 

But I am irked about the timing.  I planned to make my next car a hybrid.  Gas prices have spiked.  Hybrids have gone up in price and I understand that some models have wait-lists.  For example, if I want a Prius, I might have to wait months.

Now what do I do?

Tags: ,

OpenID and the Relying Party Patchwork

Recently I have been thinking and writing about OpenID.  My thoughts have centered around two topics:

  1. Sharing one credential across all of your Internet services is not a good idea.  See How many OpenIDs do I need?
  2. The OpenID vision isn’t ready because there is not yet an ecosystem for Internet services (i.e., Relying Parties) to rate the trust level of an arbitrary Identity Provider.  See OpenID isn’t ready for prime time.

This led to a conversation with Bill Washburn, Executive Director of the OpenID Foundation. He was a pleasure to talk to and receptive to my ideas and concerns.  I left that conversation with an interest in contributing to OpenID through my writing.  I have been pretty pegged lately on other activities, but found the Microsoft HealthVault announcement interesting because it is at the intersection of these two topics. 

What is the announcement?  That Microsoft’s HealthVault will become an OpenID Relying Party later this week. 

Very cool news.  Congratulations to Microsoft for becoming the first big player to be an OpenID Relying Party in a significant way.  Also, congratulations to the OpenID Foundation and Bill Washburn for their role in this.

Now how is this intersection of these two topics?

1. Sharing Credentials

I’ll start by partially answering my first question:

How many OpenIDs do I need?

Partial answer:

I need one for each health information provider; for exclusive use with that provider.

I just don’t want to share these with any other Internet service. 

So the premise that OpenID allows me to share credentials across sites is of no value to me here.  (Note: that said, there are good reasons I might choose other Identity Providers for this application).

2. How do Relying Parties know who to Trust?

There are a growing number of providers out there, new implementations of custom coded OpenID providers, established businesses, startups, etc.

So if you want to become a Relying Party, who do you trust?  Everyone?  No.  The answer is easy.  From Sean Nolan,

The deal is — as of our next release in the next few days, users will have a new way to identify themselves to HealthVault. In addition to Windows Live ID, they will be given the option of using OpenID accounts from Verisign or TrustBearer.

You, the Relying Party, choose an explicit list of trusted Providers.  This is a completely rational approach.  Especially if you are responsible for protecting confidential data. 

Before you know it, more and more companies/services will become Relying Parties.  Each service — at least those that protect valuable confidential data — will have to perform a risk analysis to determine which Providers to accept.  Each Relying Party will end up with a different set of accepted Providers — a different set in constant flux.

Earlier I suggested that I could choose how to consolidate my OpenIDs, but the reality may be much different where I have to choose OpenID providers based on the services I use.  This reality seems like a complicated, user-hostile patchwork of Identity.  Kind of like what we had before OpenID.  Only more complicated.

What do I think should be done about it? 

One answer is that the OpenID Foundation fast-track efforts to formalize trust and reputation resources for Relying Parties. Bill Washburn had some other ideas too, and maybe this Microsoft announcement is in support of that effort.

How long will any of this take?  Can’t say, but I will continue to look on with interest and write about OpenID.  Despite my criticism, I am a fan.

Tags: , , , , ,

Digipede + Velocity

Last week Microsoft released the first CTP of the Microsoft Distributed Cache (code-named Velocity). deatlefast2

I am definitely excited about this release.  While Microsoft is not breaking new ground here, the addition of a distributed cache to .NET is a great addition to the platform.  Certainly there are competing technologies, but Velocity will be a very simple choice for developers and ISVs because we’ll be able to count on its availability. 

This ISV is interested, so we tried it out.

We have many customers who use our Executive pattern to load and cache job-specific data for compute-intensive jobs on the Digipede Network.  These data are often fetched through WS calls or directly from SQL databases.  Often this is performed in the Executive.Start method.  Before Velocity, the code might look like this:

protected override void Start() {
    // read the CBOData object from the database.
    _cboData = ReadCboData(cache.Get(JobTemplate.Parameters["CBODataStore"].Value));
}

Including Velocity in this example is really easy.  The following snippet adds use of the Velocity cache:

protected override void Start() {
    // get cache
    CacheFactory factory = new CacheFactory();
    Cache cache = factory.GetCache("CBOCache");
    // see if our CBOData object is already there
    string key = JobTemplate.Parameters["CBODataKey"].Value;
    _cboData = (CBOData)cache.Get(key);
    // if not, read it from the database.
    if (_cboData == null) {
        _cboData = ReadCboData(cache.Get(JobTemplate.Parameters["CBODataStore"].Value));
        // store it in the cache for later use
        cache.Put(key, _cboData);
    }
}

With a few lines of code, we reduce the load on the database server and network and spend more time computing.  (I’m making an assumption with this simple code that all Executives don’t start at once, an assumption made obsolete by seeding the cache from a master application).

Of course, this is a simple example, but there are many other use cases.  For example,:

  • Digipede-enabled applications can share results; 
  • master applications can load the cache with job-specific data; and,
  • others where baking Velocity deeply into the Digipede Network start looking pretty interesting.

I have seen many posts on “must-haves” for a Velocity RTM.  I mostly agree with the lists I have seen.  I’ll have a list too mostly from the ISV perspective.

Cool stuff.

Tags: , , ,

Digipede on Mono

deatle_mono_logo I am routinely asked if the Digipede Network can run under Mono.  The main scenario people want is to run Digipede Agents on a mix of Windows and Linux boxes.

My answer has always been the same:

Not now, maybe never, but this would not be technically challenging.

A while back we researched what it would take to get the Digipede Agent working on Linux.  At the time, the Mono project was less mature.  Finding out what worked was mostly a game of just trying it.  We eventually gave up, because a dependency on WSE2 turned out to be a blocker.

A couple of weeks ago I decided to see what it would take to finish this task.  I haven’t paid much attention to the Mono project over the years, but Moonlight gave me hope that Mono has made a lot of advances since we tried last.

It has.  Still using Visual Studio, I #ifdef’ed out a few noncompliant functions and got it working with the Mono runtime.  It was surprisingly easy.  Kudos to Miguel de Icaza, Novell, and the Mono team. 

So now I have it working in the lab on a Linux VM.  Checking in to a Digipede Server, it is able to run our .NET development patterns.  Of course, it can also run command-line applications with Linux-specific binaries.  Pretty cool.

This is not ready for release.  Not only is a supported product more than just bits, but I took a few shortcuts in getting the bits to work! 

Now if someone asks me if it Digipede Network can run under Mono, I can say

It does in the lab, it may never get released, and this is ultimately a market and product decision. 

So now we can do it, what shall we do with it?

Tags: , , ,

Meeting Notes #1

On the phone with Steve Gillmor this morning talking about, among other things, Plan B

Here are my notes:

 MeetingNotes

Tags: , ,