Can iTunes Accomplish What Jini Couldn't?

Frank Sommers reflects on Walter Mossberg's. First Mossberg...

Out of the box, each copy of iTunes looks for other shared iTunes music libraries on your local network. It doesn’t share your library unless you authorize it to do so...

If you use Sharing, you’ll see in iTunes’ left-hand panel a list of shared libraries on other iTunes-equipped computers on your local network, whether they reside on Windows or Macintosh computers...

[As] I write this on a Mac laptop in my home office, I am playing a song that resides on a Windows Vista desktop PC in another room. To achieve this feat, I didn’t have to fiddle with the often confusing network settings... I just had to use iTunes on both machines and click a couple of buttons.

In effect, each copy of iTunes, with the user’s permission, broadcasts a sort of beacon that signals its presence to other copies of iTunes on a local network, regardless of the operating system underneath. It makes the operating system irrelevant.

And now on to Frank Sommers...

The notion of network services advertising and discovering each other, forming spontaneous, often impromptu, relationships, was at the heart of the Jini vision. While Jini may well experience a resurgence due to Sun recently donating the Jini codebase to the Apache Foundation, Jini itself never gained the wide distribution that Apple's similarly-purposed network technology already enjoys. The Jini community has debated for a long time Sun's role in Jini's general acceptance, or lack thereof. While licensing may have been an issue, in my opinion there have not been compelling enough Jini services to entice users to install and use Jini. By contrast, iTunes users who care only about being able to listen to or purchase music online, have downloaded and installed Bonjour to the tune of several hundred million hosts.

In addition to all those PCs, and every Mac, hundreds of different types of devices provide Bonjour-based networking capabilities, and new Bonjour devices come to the market all the time. Perhaps the most anticipated one will be Apple's own iPhone. Given all these devices, including a large number of PC desktops, it seems that a widely available spontaneous networking platform is now available. The question now is what developers will do with this new platform...

Adobe's Creative Suite 3 and Skype, to mention two examples, started to use Bonjour to facilitate local-area collaboration and discovery.

As Bonjour inventor Stuart Cheshire demonstrated in an hour-long Google TechTalk presentation (Flash video), Bonjour can be used to advertise and discover networked services over the WAN as well...

Bonjour simply extends the existing DNS mechanisms, and uses a service's protocol type, defined as a string, in service discovery. There are now several hundred service types described this way, from HTTP and SSL to the MYOB accounting software and the Sybase database server. If a client can talk a certain protocol, it can use Bonjour to discover and invoke services capable of communicating over that same protocol.

Bonjour goes beyond Jini's registration and lookup... Bonjour is zero config. Have you seen the Jini configuration mechanism?

Perhaps the next major revision of Jini, should there be one, would use Bonjour at least as an alternative to much of the Jini registration and lookup, and other configuration such as the various HTTP ports, etc. Bonjour uses DNS SRV records to indicate what port to use for what service, and so there is no fighting over port 80, or 8080, etc.

Stuart Cheshire points out in the video linked above, AppleTalk had all this zero configuration for network addressing, naming, and discovery. Bonjour is the result of figuring out that IP has the same capabilities...

And that was the breakthrough: realizing that we can do service discovery using the semantics of DNS queries, and we don't need to invent a new protocol. And then we can run that DNS over the multicast DNS support that we've already created.

Bonjour has each service run just a wee bit of DNS and negotiation among peers to avoid having a DNS server and configuration, etc. Amazing. It's probably time to begin incorporating this stuff into our systems.

And the WAN / unicast stuff can work the same way via the DHCP or other static information. Fun. We can accomplish what Jini couldn't, or hasn't yet.

Scala Implicits

I am continuing on my Scala learning curve. Scala continues to feel like a pragmatic sweet spot among programming languages. My most recent find is "implicits".

One of the pleasing aspects of dynamic languages like Common Lisp and Smalltalk (and so Python and Ruby) is the ability to extend objects that the system or some other programmers implemented, as if they were your own.

Languages without this capability force programmers to create "utility" classes. These extensions would have been in Object or String or Whatever, but the language would not allow extensions, so, here, take this StringUtils class or WhateverUtils class and use that with a String argument or a Whatever argument.

Scala is compile-time type checked (with type inference along the lines of ML and Haskell), so getting into the guts of a class and mucking at runtime is not so desirable from a type-safety point of view, and not so easy to make type-safe from an implementor's point of view. (Or maybe it's just not a priority for the language designers.)

Yet Scala does provide extensions of a sort, via a mechanism called "implicits". Extensions are defined in "wrapper" classes and an implicit type conversion is defined such that when an undefined method is encountered on an object, the defined implicit conversions are searched for a definition of that method. The object is essentially "wrapped" in an instance of that other class, and the method is invoked on the instance.

While this is type safe, it is not nearly as powerful as those mechanisms in the popular dynamic languages. (For one small example, it does not allow wrapping or replacing existing methods, as far as I can tell.) Still it does provide a fairly simple extension mechanism and so makes a fairly common situation much more pleasing than for the most popular type-checked languages.

Scala

As an erlang fan, and a jvm critic, a few people have asked me whether or not I have tried the programming language scala which compiles to the jvm and integrates with java. I had not, and was not motivated in spite of their attempts.

Then fuzzy came across scala and asked me the same question last week or so. I gave him the same reply, and felt no more motivation to do so than ever.

But you see, fuzzy is my boss and (moreover?) one of my co-workers and collaborators. This week I went on one of those web-based hunts for something unspecified that lead here and there. This time, almost out of time, and remembering fuzzy's email about scala, "there" led to http://www.scala-lang.org.

OK, playing with scala for just a couple of hours forces me to take back all the crap I have dished out about the futility of the jvm when it comes to erlang-like programming, which I think we all should be doing. (Note: I said we all should be doing erlang *like* programming, not *erlang* programming per se!)

Someone suggested some time ago I should look at scala's actor library. Now I am deeply sorry so much time has passed since I followed that suggestion. Maybe I should have given some credit to the primary author, Martin Odersky, since years ago (nearly ten???) I used his pizza language extension / compiler for java quite a bit.

I am not a terrific fan of ML-like, Haskell-like type-inferencing, etc. languages. OK, but I never got over the curve enough to feel up to my level of ease with the smalltalk/lisp-like approach. Scala is along the lines of ML and Haskell, but that is not really a turn-off for me, more of a "so what".

Like some implementations of Haskell (at least the one I used the most, hugs), scala comes with a read-eval-print loop. That helps me a *lot*. Also scala supports the conventional unix syntax for writing executable scripts. Well, it is a *little* unconventional.

Scala feels pretty good even without its actors library. But actors...

Scala's actors (and remote actors) implement a pretty good chunk of erlang-like processes, process management, and message passing. And the performance on an unmodified jvm is beyond impressive. I guess it makes sense since event-oriented java library implementations have done the same. Scala takes that somewhat clumsy approach (in java) and wraps it up in a much nicer language and a richer erlang-like library.

Nicely done. Nice mix of objects and modern functional programming with pattern matching, etc. Message passing, pattern matching, and scalable "actors" -- that's a good mix for the future.

Scala is fairly new and mature: hopefully more people will take a look at it without hestiating like I did. The lift web framework is another reason to look, although not what I am after at this point.

Offline Problems

Now that Apollo, Gears, etc. will finally bring disconnectedness to the forefront of applications, here's a useful reference. I've used Paul Dourish's ideas in several settings both for hands-off and hands-on divergence and synchronization. It's not just about "offline" and "online" -- there are all kinds of divergence and synchronization in distributed systems.

The basis of this model is the explicit management of divergence between potentially simultaneous streams of activity over a shared workspace. Streams of activity correspond to user and system actions at one user’s node. Divergence occurs when actions across the shared workspace are unsynchronised, and hence two user’s views (or copies) of the shared workspace differ. Cooperation and coordination is achieved through the periodic synchronisation of streams. In the model, a collaborative system regulates divergence and synchronisation through the use of general consistency guarantees. The mechanisms by which divergence is admitted, consistency guarantees made, and later synchronisation achieved, are points within this model where a different strategies can be adopted. This openness leads to a wide range of resultant tools applicable in different situations, and supporting different working styles.

Competing With Fun

From Cory Foy (corrected spelling, sorry!), in response to Martin Fowler's recent "Microsoft and Ruby" observation...

Just like it is hard to compete with Apple because they are cool, it's hard to compete with Ruby because it is fun.

A funny comment to that post though...

I think Fowler time is over. It was about time, frankly I think he has lost it.

Let's hope not. His message, as usual, was "spot on" for Microsoft.

ws-bandwagon-decision-making

No surprise, but I have problems with Mike Champion's recent argument in favor of WS-*...

WS-Management is widely used today in situations where the web-scale alternatives really don't fit, such as deep within operating systems or in the firmware of chips.

My main problem with his argument is this: I do not believe technical reasoning was used in the decisions to use WS-* in these apparently "non-HTTP" situations. To some degree my beliefs are based on direct conversations with people involved with WS-Management.

The decision to go WS-* in this case was made like this: WS-* is the future for integration, system management requires integration, so we'll use WS-*.

This is not to mention the fact that ws-management is essentially a shell of a solution with little agreement on what goes in that shell.

Other problems with his argument include no explanation about what "where the web-scale alternatives really don't fit". I am not necessarily of the sort that everything has to be HTTP, but then again, HTTP has been implemented on some pretty tight spaces and processors. I'd like to see the evidence that HTTP is not suitable for certain ws-management scenarios. I assume ws-management still specifies a fair bit of verbose XML over those supposedly tight spaces. Hmm.

It is precisely this lack of rigor that has failed ws-* from the start. There's nothing new or significant in Mike's argument that I can see.