One of the things that made my trip to India and England so successful was seamless wireless connectivity. I thought I'd go into some detail about this, because it might be useful for future travellers.
As I've described before, my phone is a Palm Treo 650 *, with service from Cingular. It's a quad-band GSM phone, and supports GPRS (IP over PPP) Internet access. (This is critical: if you plan to travel to most parts of the world, you must get a GSM phone. It's the standard; just get over it.) The Treo includes a basic but adequate email client called Versamail, which can handle POP, IMAP, and SMTP with and without SSL. This means that I can access both my Sun email (Edgemail via secure IMAP) and my personal ISP account (via POP). There's also a web browser called Blazer which does a reasonable job of rendering complex web sites on the 320x320 screen. And since it's a PalmOS device it also supports a wide range of applications; the one that I used most often was World Clock, without which it would have been really hard to keep track of the 101/2 hour time difference between Boston and Bangalore. (I also installed Bejeweled 2 as a superior time-waster to solitaire.)
As I noted earlier, I called Cingular to enable international roaming before leaving the US. Everywhere I went - in India and in the UK - I established a usable roaming connection when I turned on the phone. However the automatic choice was not always the best one. Several of the providers didn't support GPRS (or didn't allow GPRS roaming), which meant that I couldn't get my email. After manually selecting each of the available providers, I eventually determined that the best choices were Airtel in India and Orange in the UK.
Looking back on this trip, I cannot emphasize too strongly how important it was to have a working cellphone (with web and email) while travelling in India. It's not cheap, but roaming calls back to the US and UK were certainly less expensive than hotel phone rates. The normal way of getting around in India is to book a driver and car for the day; your driver will expect you to contact him by cell phone whenever you need him. When the power goes out (rarely, but inevitably), or when that WiFi hotspot turns out to require the use of a prepaid coupon that can only be purchased somewhere else, you can still use email. And most important, the successful resolution of my Mumbai connection situation depended heavily on the use of voice, email, and web; first in Bangalore airport, then on the shuttle bus to Mumbai's international terminal, and finally as I stalked the corridors of Mumbai airport at 3am.
One final thought. I packed my iSight camera in the hope of using iChatAV to videoconference with friends and family rather than using the phone. Well, it didn't work out. The main reason was that most of the hotels used firewalls that blocked several of the TCP ports needed by iChatAV. Maybe a simple VoIP system would have been better....
--
*One point worth noting is that the Treo 650 includes a camera, albeit a fairly basic one. Photography is forbidden in many places in India, and you will frequently be required to check any cameras or camera-equipped phones. If I were buying now, I'd be tempted by the Siemens SX66, which doesn't have a camera but does include WiFi - and it's only 2.1 ounces!
I recently installed the Netcraft Toolbar in the copy of Firefox that I use on my home machine. Hitherto I have mostly used Netcraft for their What's That Site Running? service (as a remote ping or to check a netblock owner). The Toolbar is new.
Every time you hit a new site, the toolbar displays five pieces of information:
- a "risk rating" (questionable)
- the date that the domain name was first noticed by Netcraft (highly unreliable)
- the rank ordering of the site by hits
- a link to a "Site Report"
- the netblock owner
I have to say that it's changing the way I surf the web. I find myself looking at a site's ranking, trying to understand why it's so high (or so low). For example, my blog ranking is (at this moment) 197836. Is that good? Well, here are the top 100. Other interesting sites: Neil Gaiman's blog is 69787, Planet Sun is 126763, and Alec Muffett's crypticide ranks 127559. But I'm closing in on Majikthise (182579), and I'm way ahead of Simon's Webmink (807108). Meaningful? Of course not, but it's fun. However it only aggregates at the domain level, so all of the Sun bloggers at blogs.sun.com are going to have to share their collective ranking of 19723....
Dion Hinchcliffe is embarking on a project which I think I'm going to watch with morbid fascination: Taking Stock of Web Service Description. Specifically, he's going to put up a simple order entry web service, and publish a description of the service in a number of different candidate service description languages (SDLs). The mind-boggling part is the list of candidate SDLs:
"The list of SDLs to try to use is: WSDL 1.1, WSDL 2, NSDL, SSDL, WRDL, RSWS, WADL, Resedel, SMEX-D, RDF, RDF Forms, OWL/OWL-S, WSML, and WDL."
That's fourteen different languages. Plus he's going to explore how to use these with three different programming languages: Java, C#, and Ruby.
Back in the Craig McMurtry blog entry that I cited recently, he wrote: "One must grant though, that a primary and very good idea behind Jini lives on in Indigo. That idea is that there should be an excellent, simple programming model usable across any kind of networking infrastructure. In the years since Jini, though, we have learned a lot about how NOT to design those programming models, and those lessons suffuse Indigo." With all due respect, Dion's experiment demonstrates pretty clearly that there is no consensus whatsoever on the "how not to" question. It also seems to confirm what I said: that one size will not fit all, and that we're going to need a variety of technical solutions ranging from Jini to WRDL and beyond.
In Craig McMurty's blog entry that stirred up discussion of Indigo and Jini, he mentions a piece by Don Box, in which "the four fundamental tenets" of service-oriented development are laid down. Craig further asserted that 'The "services" that one can construct with Jini do not conform to any of those four tenets'. Really? Well, given how badly Craig seems to have misunderstood Jini, I decided to go back to the source and see what the good Mr. Box has to say for himself.
So what exactly are Don's four fundamental tenets?
Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Service compatibility is determined based on policy
Plausible? Well, the first two are unexceptional, and describe Jini services quite nicely. I suspect the devil may be in the details. The third seems unduly coupled to a particular technology and language; if we replace "schema" with "interface" and "class" with "implementation", it feels OK - and describes Jini very well. And the fourth? I have no idea what it means, but on the surface it seems to conflict with the second (autonomy) and to overlap with the third. Perhaps we can resolve these conflicts later on. Let's dig into each of these ideas.
Boundaries are explicit: Back in the early days of distributed computing, it was considered a good idea to hide the boundaries, to make remote resources look just like local ones. This is what gave us remote file systems and early RPC schemes; in extremis it gave us things like Locus. Over time the wisdom of folks like Peter Deutch and Jim Waldo cured us of this. These days we all believe in explicit boundaries.
Box, however, introduces what seems to me like a non-sequitur: "Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation." Now this is bizarre. He's saying that because an interaction may be expensive, we have to describe it explicitly at the lowest level. Even if one is performing a higher-level pattern, such as a method invocation, one is required to unpack it by describing the individual message patterns and how they are correlated. While sometimes this may be appropriate, it hardly seems fundamental. For a start, it conflicts with the notion of autonomy. Why should a client and service, mutually consenting adults, be required to describe their interaction in such detail in advance? Why could they not negotiate a mechanism on the fly, using available resources?
Box goes on to say, "the fact that a given interaction may be implemented as a method call is a private implementation detail that is not visible outside the service boundary". But this is disingenuous. How detailed, how explicit is the message description? Either we give up on type (or schema) based notions of compatibility, or every interface requires a detailed description of request and response messages which will make the "private implementation detail" instantly public (and will significantly constrains the ways client and service can interact).
A final thought on boundaries: while they may be explicit, they are not necessarily static. Refactoring is a fact of life. In practice this means that software components will be constructed in such a way that potential boundaries are declared as such (using, for instance, the remote interface in Java), and services will be assembled and composed in terms of such interfaces. Describing a service in terms of a low-level message exchange pattern then becomes one technique among many for defining service boundaries, and one that is generally effected by a design tool of some kind. It's an implementation artefact, not a design principle.
Services are autonomous: Box's account of service autonomy is excellent. He discusses version skew, the dynamic nature of the aggregations that comprise a system, the effects of unintended usage, partial failure, and security. (He could also have said something about dynamic discovery, self-healing, the use of patterns such as broker and facade, and the use of techniques such as introspection to perform dynamic adaptation.) There is nothing here that a Jini enthusiast would disagree with.
Services share schema and contract, not class: Earlier I wondered if this referred simply to a separation between interface and implementation. This understates Box's position. He writes, "services interact based solely on schemas (for structures) and contracts (for behaviors). Every service advertises a contract that describes the structure of messages it can send and/or receive as well as some degree of ordering constraints over those messages." And he also says that "the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code". So what we are dealing with here are relatively simple interfaces, evolving slowly, with weak consistency and ad hoc extensions.
Now there are plenty of situations where this kind of approach is just fine. As Box notes earlier, it's the kind of thing that made Amazon.com's services the success that they are today. But for other applications, this kind of thing is hopelessly inefficient or inflexible. For the vast majority of intranet services, for instance, the most common way to invoke a service isn't going to be by parsing its description and constructing a new client stub ab initio: it's going to be by invoking a copy of the stub code generated when the service was created. And if you're going to do that, why not take advantage of it - not just at compile time, but dynamically, so that the interactions with the service can reflect the characteristics of the deployed service? As for the suggestion that one needs more flexibility than "traditional object-oriented interfaces", mechanisms like introspection allow for powerful and robust run-time flexibility, without sacrificing type safety.
It seems to me that the fundamental principle involved here is the one I alluded to earlier: establishing a clear separation between interface and implementation. How we do that seems to depend on the application and context; there is no reason to believe that one size fits all.
Service compatibility is determined based on policy: It turns out that what Box is talking about here is the distinction between structural compatibility and semantic compatibility. The latter is familiar and unremarkable: XML schemas, class signatures, on-the-wire encodings, that kind of thing. But what Box is interested in is "[s]emantic compatibility... based on explicit statements of capabilities and requirements in the form of policy". He gives a few hints about what he's thinking of, but at this stage I think it's safe to say that he raises more questions than answers. Suffice it to say that this whole area is in its infancy, and it's not an immediately important issue. By the time we figure out exactly how to express such things (OWL-S?), how and when services get to " apply simple propositional logic to determine service compatibility", and exactly what customers want to use this for, our initial expectations are likely to change significantly. There's certainly nothing here that is incompatible with Jini.
So what's the verdict? Was Craig correct to claim that Jini doesn't conform to Box's "tenets"? Unambiguously not: Jini absolutely conforms to every aspect of Box's "autonomy" tenet. How about the others? Well, it all depends on whether you read the interface or the implementation: whether you concentrate on the broad principle, or how Box chooses to implement it. Jini is entirely compatible with the broad principles, but not surprisingly it's not going to conform to Box's Procrustean Bed of message-based service patterns. But why should it? Box gives us no reason to believe that this technology is the only way to realize the principles. It's just the way Microsoft chose.
I've already discussed why Microsoft took this path, but it's important to recognize that it's not the only - or even the best - approach. There are more powerful, elegant, and efficient models for realizing the principles of service-oriented distributed computing, and Java and Jini represent such a model. For Box and McMurty to argue that only one technology fulfills these principles is self-serving, not to mention ahistorical. The wide range of problems to be solved, the variety of contexts in which the solutions must operate, and the kinds of constraints and requirements that must be met, are such that multiple technologies will clearly be needed. As Jim Waldo pointed out, the "Highlander Principle" ("there can be 'only one'") is a fallacy.
My colleague Warren posted a thoughtful and comprehensive response to Craig McMurty's piece on Jini and Indigo. I just wanted to point out another angle on one of Craig's assertions.
Craig says, "In the years since Jini, though, we have learned a lot about how NOT to design those programming models, and those lessons suffuse Indigo". Now from the Microsoft perspective, I'm sure that this is true. Over many years they had pushed a distributed programming model (under various names) that was inextricably tied to the Windows OS. (Yeah, I know about Mono - wake me up when it's real.) I'm quite sure that their customers told them that this was a bad idea; I know that some of them have said to me, face to face, "We have to work with you, because Microsoft doesn't understand decoupling and layering." But because of their obsession that Windows was The One and Only True Platform, Microsoft decided - incorrectly - that the only solution was to move to a (relatively) platform-neutral approach. As a result we got the wholesale shift to WSDL and XML web services. But because Microsoft still believed in the old COM model, and didn't want to give up any of the functionality, they were forced to layer tons of new protocols, starting with SOAP and ending with the WS-splat Tower of Babel. (And while some of these are open, not all of the schemas will be.)
What's wrong with this picture? First, most customers weren't asking for a new pile of stuff to learn! They simply wanted a distributed computing model that was decoupled from the OS and hardware platform, to give them some choice up and down the stack. And the technology to do that already exists: it's called Java.
Short digression: I spent some of the last year talking to large IT organizations (not all Sun customers) about their distributed computing plans. One of the questions that I regularly raised was, "How are you planning to integrate your existing applications into your future architecture?" And the answer that I heard over and over again was, "We're going to wrap them in Java." Never "Wrap them with .NET". (OK, one company was planning to implement a SOAP interface in Cobol, but...)
At the end of the day the idea of platform neutrality looks pretty lame anyway. The whole WS-splat mess has grown so complex that customers are going to be forced to treat it as another platform in its own right. And given the competitive sniping and politicking that seems to characterize these "standards", it's unclear if the result will be any less proprietary than before. The upshot is likely to be either (1) customers will focus on a small subset of the whole steaming pile (perhaps RESTful), or (2) they'll shrug, push the button in Visual Studio, and treat it all as COM++, just another proprietary stack.
The Jini proposition is very simple. If you are developing in Java - and many people are - it makes sense to use Java as your distributed service model as well as your application platform. You avoid the problem of lossy mappings between different representations, you get end-to-end type safety, you don't need to learn new languages, or exception models, or security frameworks. And as a bonus, you can use the best protocol for the job: you don't have to reduce everything to the lowest denominator of XML.
We wouldn't claim (most of us :-) that Jini was right for every case. Always mistrust sweeping generalisations! On the other hand, Craig seems to be doing exactly that: asserting that Indigo reflects the one true way. That's utter nonsense. In fact it smacks of an Aesop's Fable. Microsoft was assailed for coupling their programming model to a monopoly OS on a monopoly chip. Since they were incapable of distingishing between platform and OS, they were forced to go "platform neutral", and wound up creating another platform (and a depressingly baroque one at that).
Java and Jini suggest a different approach: make the programming platform independent of the host OS and hardware. It meets many of the customers' needs (as we've seen), and seems to represent a more elegant way of doing things. (And for those who argue that elegance is an inappropriate property, I recommend Samuel Florman's wonderful book The Existential Pleasures of Engineering.)
[Hmmm. On re-reading this, let me draw your attention to the disclaimer at the top of the sidebar, for what it's worth.]
Over in ongoing · Java, the Grid, and Rio, Tim was "thinking about how you’d run a big distributed Java system as a service across a whole lot of networked computers". Dan Templeton pointed him at Rio, and I followed up with a link to the papers from last December's Jini Community Meeting in London. And I remembered a comment by Rob Gingell, adapting Santayana: "Those who do not use Jini are doomed to reinvent it."
AOL reacted pretty quickly to all the negative publicity about their AIM Terms of Service. The new language is much better. The power of the web, eh?
The new text (with my emphases):"You or the owner of the Content retain ownership of all right, title and interest in Content that you post to public areas of any AIM Product. However, by submitting or posting Content to public areas of AIM Products (for example, posting a message on a message board or submitting your picture for the 'Rate-A-Buddy' feature), you grant AOL, its parent, affiliates, subsidiaries, assigns, agents and licensees the irrevocable, perpetual, worldwide right to reproduce, display, perform, distribute, adapt and promote this Content in any medium. Once you submit or post Content to any public area on an AIM Product, AOL does not need to give you any further right to inspect or approve uses of such Content or to compensate you for any such uses. AOL owns all right, title and interest in any compilation, collective work or other derivative work created by AOL using or incorporating Content posted to public areas of AIM Products."
Welcome to the revised AIM Terms of Service from AOL. The interesting thing is that AOL wants the benefits of being a common carrier (e.g. they disclaim all responsibility for what passes through their system) while at the same time gaining full rights over that content. Would you use a VoIP service from somebody that reserved the right to record your conversations and publish them? If these various communications media (POTS, VoIP, IM, email, etc.) are really converging, let's make sure that AOL doesn't set the standard for privacy:
"Although you or the owner of the Content retain ownership of all right, title and interest in Content that you post to any AIM Product, AOL owns all right, title and interest in any compilation, collective work or other derivative work created by AOL using or incorporating this Content. In addition, by posting Content on an AIM Product, you grant AOL... the irrevocable, perpetual, worldwide right to reproduce, display, perform, distribute, adapt and promote this Content in any medium. You waive any right to privacy. You waive any right to inspect or approve uses of the Content or to be compensated for any such uses."
(Via BoingBoing.)
I stumbled across this piece in Jamie Zawinski's blog pointing off to a longer article entitled Groupware Bad. He discusses the history of collaboration and calendaring software, and why it sucks. (There are a bunch of really interesting responses on the blog; see also here.) Direct and to the point (and, apparently, widely linked). Money quote:
If you want to do something that's going to change the world, build software that people want to use instead of software that managers want to buy. When words like "groupware" and "enterprise" start getting tossed around, you're doing the latter, [and] nobody would ever work on it unless they were getting paid to, because it's just fundamentally not interesting to individuals.
So I said, narrow the focus. Your "use case" should be, there's a 22 year old college student living in the dorms. How will this software get him laid?
That got me a look like I had just sprouted a third head, but bear with me, because I think that it's not only crude but insightful. "How will this software get my users laid" should be on the minds of anyone writing social software (and these days, almost all software is social software). [It's] about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.
(Linked from Many-to-Many, which is fascinating in its own right.)