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 situations
typical of Movable Type and Blosxom blogs; I hope this serves as
provocation for someone on that side to nail down an alternative
authentication scheme. But even if not, at least everyone else
will have a minimal fallback for authentication.
Note that the proposal also allows servers to require authentication
for comments -- something that would be a helpful building block in
fighting comment spam.
Thursday, March 24, 2005
Friday, March 18, 2005
SD West: SOA: The Next Big Thing (Keynote)
Dave Chappell delivered an entertaining keynote.
Again, this was targeted squarely at enterprise application
developers. I felt a bit like a tourist in a foreign country -- happy
to be there, interested, but a bit puzzled and probably missing some of
the 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 oriented architecture ("the debate is both endless and pointless") by stating that it's defined by the dominant technologies: A service is what the dominant products say it is -- and WebSphere and .NET are the dominant products, so services means SOAP and WS-*. And I'm not sure, but I think he defines 'dominant products' as 'whichever platforms have the most market share among vendors selling tools to enterprise developers'. Which of course rules out anything that doesn't help sell platform tools :^). I glance at the Internet, which is mysteriously working again, and verify that Dave Chappell is an old-school DCOM guy. He seems very happy that the vendors are finally agreeing on a shared standard for communication; after the CORBA/DCOM/RMI wars, I imagine so.
He did have some useful points to make about moving to SOA within an organization, identifying two major approaches: Top down, in which you identify business needs, document requirements, design an architecture, and implement the services in a well planned, sensible way. The pros are that this is elegant, clean, and sensible; the cons are that it's (nearly) impossible. Requires high investment and long-term business buy-in. He recommended the bottom-up approach (just build one service, then another, then start thinking about central SOA issues such as security and management) as a practical if ugly approach.
He presented a toy example using C# code. Now, his main points were about the orthogonality of OO design and service architectures, which is all well and good. But I felt that the choice of an example class with "add(x,y)" and "subtract(x,y)" methods which get turned into web services sort of obscures the question -- why would we want to do that? It's a ridiculous web service. Why not pick a toy example that actually 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 such as Google, Yahoo!, etc. are using to expose services? Dave's answer was somewhat revealing, but as a tourist I'm not sure I can properly interpret 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 "get into SOAP vs. REST debates because the REST community..." and there he paused, and looked thoughtful, and then reiterated "I don't get into SOAP vs. REST debates". He sure seemed uncomfortable to me.
(Side note: My spell checker suggests "DOOM" as an appropriate substitute for "DCOM". Sometimes I think it's really acquired AI and it's just toying with me.)
Dave cut the Gordian knot involved in defining service oriented architecture ("the debate is both endless and pointless") by stating that it's defined by the dominant technologies: A service is what the dominant products say it is -- and WebSphere and .NET are the dominant products, so services means SOAP and WS-*. And I'm not sure, but I think he defines 'dominant products' as 'whichever platforms have the most market share among vendors selling tools to enterprise developers'. Which of course rules out anything that doesn't help sell platform tools :^). I glance at the Internet, which is mysteriously working again, and verify that Dave Chappell is an old-school DCOM guy. He seems very happy that the vendors are finally agreeing on a shared standard for communication; after the CORBA/DCOM/RMI wars, I imagine so.
He did have some useful points to make about moving to SOA within an organization, identifying two major approaches: Top down, in which you identify business needs, document requirements, design an architecture, and implement the services in a well planned, sensible way. The pros are that this is elegant, clean, and sensible; the cons are that it's (nearly) impossible. Requires high investment and long-term business buy-in. He recommended the bottom-up approach (just build one service, then another, then start thinking about central SOA issues such as security and management) as a practical if ugly approach.
He presented a toy example using C# code. Now, his main points were about the orthogonality of OO design and service architectures, which is all well and good. But I felt that the choice of an example class with "add(x,y)" and "subtract(x,y)" methods which get turned into web services sort of obscures the question -- why would we want to do that? It's a ridiculous web service. Why not pick a toy example that actually 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 such as Google, Yahoo!, etc. are using to expose services? Dave's answer was somewhat revealing, but as a tourist I'm not sure I can properly interpret 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 "get into SOAP vs. REST debates because the REST community..." and there he paused, and looked thoughtful, and then reiterated "I don't get into SOAP vs. REST debates". He sure seemed uncomfortable to me.
(Side note: My spell checker suggests "DOOM" as an appropriate substitute 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 some valuable points regarding the different views of what a 'requirement' is to different stakeholders. He presented a framework for separation into business (why), user (what), and functional (high-level how) requirements, and how to categorize requirements into this framework to help avoid confusion. This becomes particularly important when doing incremental development (which is what almost everybody does): It's OK to be fuzzy on some of the functional requirements before starting a project, but the business requirements had better be very clear and solid.
Regarding change control boards, I asked how one can scale a CCB so it doesn't become a bottleneck in a large program. He said (interpreting a bit) that the way to scale a CCB is to identify policies so that you can distribute responsibilities among CCBs -- only escalating change requests up to a central CCB if its scope truly warrants it.
The slightly depressing part about this talk was that I knew most of the solutions presented; however, none of them helped to solve the really hard people problems that actually are the root cause of most requirements issues.
On a side note, the wireless network stopped working for me during this talk. I started seeing packet round-trip times of >>1sec to reach what was supposedly our DNS server. I think this highlights one of the nonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Center network: When you build a wireless network for a convention center in the middle of Silicon Valley, make sure that it can handle a few thousand software engineers with laptops!
Lots of good advice and pointers to resources in the talk. He had some valuable points regarding the different views of what a 'requirement' is to different stakeholders. He presented a framework for separation into business (why), user (what), and functional (high-level how) requirements, and how to categorize requirements into this framework to help avoid confusion. This becomes particularly important when doing incremental development (which is what almost everybody does): It's OK to be fuzzy on some of the functional requirements before starting a project, but the business requirements had better be very clear and solid.
Regarding change control boards, I asked how one can scale a CCB so it doesn't become a bottleneck in a large program. He said (interpreting a bit) that the way to scale a CCB is to identify policies so that you can distribute responsibilities among CCBs -- only escalating change requests up to a central CCB if its scope truly warrants it.
The slightly depressing part about this talk was that I knew most of the solutions presented; however, none of them helped to solve the really hard people problems that actually are the root cause of most requirements issues.
On a side note, the wireless network stopped working for me during this talk. I started seeing packet round-trip times of >>1sec to reach what was supposedly our DNS server. I think this highlights one of the nonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Center network: When you build a wireless network for a convention center in the middle of Silicon Valley, make sure that it can handle a few thousand 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 are
concerned with automation of business processes -- in some ways, a
different world from where I operate most of the time. Mike's
definition of SOA is pretty much what either Microsoft or IBM are
offering as platforms (.NET or J2EE plus SOAP). Their main selling
point seems to be that once everything is exposed as web services,
business analysts will be able to create and manage business processes
by configuring services via graphical tools rather than by writing code
or even scripts. (This syncs up with the presentation later on by Dave
Chappell.) I am skeptical, but then again the problems these
developers have are not my problems.
Quick takes: Mike stated that UDDI is not used much outside the corporate firewall (my personal prediction: It never will be in its current form.) IBM and MSoft are repurposing existing applications, such as Tivoli, to help manage corporate web service networks. I asked about interoperability; monitoring and development tools based on one of the "big two" platforms will have a difficult time interoperating with the other, though the web services themselves should be able to run on either platform with "some data mapping."
The most interesting statements: Dave Chappell mentioned after the talk that things like security will only have shipping implementations in 2006 and reliable messaging doesn't have a final spec yet. Also, on a totally random tangent, I overheard someone behind me saying "XSLT makes all those lies about 'you can do anything with pointy brackets' true!".
Quick takes: Mike stated that UDDI is not used much outside the corporate firewall (my personal prediction: It never will be in its current form.) IBM and MSoft are repurposing existing applications, such as Tivoli, to help manage corporate web service networks. I asked about interoperability; monitoring and development tools based on one of the "big two" platforms will have a difficult time interoperating with the other, though the web services themselves should be able to run on either platform with "some data mapping."
The most interesting statements: Dave Chappell mentioned after the talk that things like security will only have shipping implementations in 2006 and reliable messaging doesn't have a final spec yet. Also, on a totally random tangent, I overheard someone behind me saying "XSLT makes all those lies about 'you can do anything with pointy brackets' true!".
Monday, March 14, 2005
Inductive Blacklisting?
It looks like someone is trying out some type of comment spam
on AOL Journals. Or was; it sounds like a straightforward Terms
of Service violation and I'd expect it to get yanked quickly.
Fortunately, Journals provides a way to both delete a comment and block the commenter's user id (screen name) from future comments to that Journal, which is handy in these situations. But perhaps it doesn't go far enough. Perhaps there should be an auto-blacklisting feature: If enough different people comment-block a user id, perhaps it should be blocked from any further comments anywhere for a significant period of time. It would at least slow down the spammers.
Fortunately, Journals provides a way to both delete a comment and block the commenter's user id (screen name) from future comments to that Journal, which is handy in these situations. But perhaps it doesn't go far enough. Perhaps there should be an auto-blacklisting feature: If enough different people comment-block a user id, perhaps it should be blocked from any further comments anywhere for a significant period of time. It would at least slow down the spammers.
Subscribe to:
Posts (Atom)
