Atom Authentication

I've written up a replacement for the authentication section of the Atom protocol: http://intertwingly.net/wiki/pie/PaceAuthentication. It's simple but unusable by servers in restricted hosting situationstypical of Movable Type and Blosxom blogs; I hope this serves asprovocation for someone on that side to nail down an alternativeauthentication scheme.  But even if not, at least everyone elsewill have a minimal fallback for authentication.

Note that the proposal also allows servers to require authenticationfor comments -- something that would be a helpful building block infighting comment spam.


SD West: SOA: The Next Big Thing (Keynote)

Dave Chappell delivered an entertaining keynote. Again, this was targeted squarely at enterprise applicationdevelopers.  I felt a bit like a tourist in a foreign country -- happyto be there, interested, but a bit puzzled and probably missing some ofthe shared cultural nuances.  (Despite having created some enterprise development tools, I've never actually worked as an enterprise developer.)

Dave cut the Gordian knot involved in defining service orientedarchitecture ("the debate is both endless and pointless") by statingthat it's defined by the dominant technologies:  A service is what thedominant products say it is -- and WebSphere and .NET are the dominantproducts, so services means SOAP and WS-*.  And I'm not sure, but Ithink he defines 'dominant products' as 'whichever platforms have themost market share among vendors selling tools to enterprisedevelopers'.  Which of course rules out anything that doesn't help sellplatform tools :^).  I glance at the Internet, which is mysteriouslyworking again, and verify that Dave Chappell is an old-school DCOMguy.  He seems very happy that the vendors are finally agreeing on ashared standard for communication; after the CORBA/DCOM/RMI wars, Iimagine so.

He did have some useful points to make about moving to SOA within anorganization, identifying two major approaches:  Top down, in which youidentify business needs, document requirements, design an architecture,and implement the services in a well planned, sensible way.  The prosare that this is elegant, clean, and sensible; the cons are that it's(nearly) impossible.  Requires high investment and long-term businessbuy-in.  He recommended the bottom-up approach (just build one service,then another, then start thinking about central SOA issues such assecurity and management) as a practical if ugly approach.

He presented a toy example using C# code.  Now, his main points wereabout the orthogonality of OO design and service architectures, whichis all well and good.  But I felt that the choice of an example classwith "add(x,y)" and "subtract(x,y)" methods which get turned into webservices sort of obscures the question -- why would we want to dothat?  It's a ridiculous web service.  Why not pick a toy example thatactually makes some tenuous sense as a web service?  For example,a word definition lookup service?

In the short Q&A period, one person asked the obvious question: What about the REST-ish approaches that so many service providers suchas Google, Yahoo!, etc. are using to expose services?  Dave's answerwas somewhat revealing, but as a tourist I'm not sure I can properlyinterpret it.  He said, #1, web services are defined by SOAP and WS-*because that's what the dominant vendors say; and #2, he doesn't "getinto SOAP vs. REST debates because the REST community..." and there hepaused, and looked thoughtful, and then reiterated "I don't get intoSOAP vs. REST debates".  He sure seemed uncomfortable to me.

(Side note:  My spell checker suggests "DOOM" as an appropriatesubstitute for "DCOM".  Sometimes I think it's really acquired AI and it's just toying with me.)

SD West: Software Requirements: 10 Traps

Next up: Karl Wiegers talks about the 10 Traps of Software Requirements.  I plan to check out processimpact.com  for sample documents and spreadsheets (the requirements prioritization example spreadsheet sounds especially useful). 

Lots of good advice and pointers to resources in the talk.  He had somevaluable points regarding the different views of what a 'requirement'is to different stakeholders.  He presented a frameworkfor separation into business (why), user (what), and functional(high-level how) requirements, and how to categorize requirements intothis framework to help avoid confusion.  This becomes particularlyimportant when doing incremental development (which is what almosteverybody does):  It's OK to be fuzzy on some of the functionalrequirements before starting a project, but the business requirementshad better be very clear and solid.

Regarding change control boards, I asked how one can scale a CCB so itdoesn't become a bottleneck in a large program.  He said (interpretinga bit) that the way to scale a CCB is to identify policies so that youcan distribute responsibilities among CCBs -- only escalating changerequests up to a central CCB if its scope truly warrants it. 

The slightly depressing part about this talk was that I knew most ofthe solutions presented; however, none of them helped to solve thereally hard people problems that actually are the root cause ofmost requirements issues. 

On a side note, the wireless network stopped working for me during thistalk.  I started seeing packet round-trip times of >>1sec to reachwhat was supposedly our DNS server.  I think this highlights one of thenonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Centernetwork:  When you build a wireless network for a convention center inthe middle of Silicon Valley, make sure that it can handle a fewthousand software engineers with laptops!

SD West: Understanding SOA

First up: Mike Rosen presented Understanding SOA. This talk was oriented very much towards enterprise developers who areconcerned with automation of business processes -- in some ways, adifferent world from where I operate most of the time.  Mike'sdefinition of SOA is pretty much what either Microsoft or IBM areoffering as platforms (.NET or J2EE plus SOAP).  Their main sellingpoint seems to be that once everything is exposed as web services,business analysts will be able to create and manage business processesby configuring services via graphical tools rather than by writing codeor even scripts.  (This syncs up with the presentation later on by DaveChappell.)  I am skeptical, but then again the problems thesedevelopers have are not my problems.

Quick takes: Mike stated that UDDI is not used much outside thecorporate firewall (my personal prediction: It never will be in itscurrent form.)  IBM and MSoft are repurposing existing applications,such as Tivoli, to help manage corporate web service networks.  I askedabout interoperability; monitoring and development tools based on oneof the "big two" platforms will have a difficult time interoperatingwith the other, though the web services themselves should be able torun on either platform with "some data mapping."

The most interesting statements: Dave Chappell mentioned after the talkthat things like security will only have shipping implementations in2006 and reliable messaging doesn't have a final spec yet.  Also, on atotally random tangent, I overheard someone behind me saying "XSLTmakes all those lies about 'you can do anything with pointy brackets'true!".


Inductive Blacklisting?

It looks like someone is trying out some type of comment spamon AOL Journals.  Or was; it sounds like a straightforward Termsof Service violation and I'd expect it to get yanked quickly. 

Fortunately, Journals provides a way to both delete a comment and blockthe commenter's user id (screen name) from future comments to thatJournal, which is handy in these situations.  But perhaps itdoesn't go far enough.  Perhaps there should be anauto-blacklisting feature:  If enough different peoplecomment-block a user id, perhaps it should be blocked from any furthercomments anywhere for a significant period of time.  It would atleast slow down the spammers.