|
Nick Gall's Weblog
 |
Monday, September 27, 2004 |
GM's reuse strategy.This article
about GM's efforts to increase reuse of part designs, touches on several
very timely topics. First, software designers are not alone in preferring to
design unique parts, rather than use existing ones. I find it the epitome of
irony that the industry that IT seeks to emulate in its use of interchangeable
parts, itself struggles with the issue! Second, to enable reuse, even of
physical part, requires substantial IT investment to enable designers to simply
find a part to reuse. Third, it touches on the "monoculture" issue
being debated with regard to widespread use of Windows. In GM's case, when more
product lines share a common part, design flaws in the part have wider
repercussions.
5:25:19 AM 
|
|
|
Wednesday, September 22, 2004 |
Endpoint services vs. protocol services.It recently stuck me that the WS-* architecture
is implicitly based on two distinct notions of "service", only one of
which is explicitly referred to as a service. The obvious type of service is one
defined using WSDL. Let's call these "endpoint" services. The subtle
type of service is the kind provided by a SOAP node when it acts on a SOAP
header. For example, when a WS consumer receives a SOAP envelope containing a
WS-Security header, it must invoke a "service" to process the header,
e.g., decrypt the SOAP body. Let's call these "protocol" services.
What's interesting is that endpoint services are
"first class" services--they are getting all the attention and there
is active work in improving the description of such services. They are also the
services that one typically implies when one speaks of "composing
services". Protocol services on the other hand are clearly "second
class" services--hardly anyone is focused on them. However, there is
growing discussion of "protocol
composability" : "Web service protocol composition is based on the
modular architecture of SOAP. SOAP's architecture anticipates the composition of
infrastructure protocols through the use of a flexible header mechanism".
Of course, as I pointed out previously, such protocol composition essentially
enables "aspect-oriented
protocols". (Thus, one might think of "protocol services" as
"aspect services".)
Now the obvious language for describing a
composition of endpoint services is BPEL. In fact, BPEL requires "atomic
actions" to be described via WSDL interfaces. But there is no language for
describing a composition of protocol services. The SOAP spec gets confusing
here. It speaks about "features" and requires that new features
describe how they affect other headers (i.e., other protocol services).
It is my belief that WS-* architecture must be
generalized to provide a unified concept of service that encompasses both
protocol and endpoint service descriptions as "first class" concepts.
This might entail generalizing WSDL and BPEL. BPEL would then be used to
describe the processing dependencies among various protocol services, e.g.,
WS-Security service is invoked first, then WS-Reliability, then WS-BusinessActivity.
Where different protocol services do not have sequencing dependencies, the BPEL
operator for simultaneous execution would indicate that. BPEL would then serve
as both a functional composition language (in the case of composing endpoint
services) and an aspect composition language in the case of composing protocol
services (aka aspect services).
9:57:07 AM
|
|
|
Monday, September 20, 2004 |
Mass amateurization.The issue of Mass Amateurization came up in a
client discussion. Thought I'd pass along the links and thoughts I'd collected
so far. Sorry for the endnotes, but I wrote it for ASCII email.
Here's Clay Sharky's blog posting that (seems to
have) first articulated the concept.[1] He had this to say about the
amateurization of travel planning:
Mass amateurization is the web's normal
pattern. Travelocity doesn't make everyone a travel agent. It undermines the
value of being travel agent at all, by fixing the inefficiencies travel agents
are paid to overcome one booking at a time. Weblogs fix the inefficiencies
traditional publishers are paid to overcome one book at a time, and in a world
where publishing is that efficient, it is no longer an activity worth paying
for.
Tom Coates then expanded the concept to "(Weblogs
and) The Mass Amateurisation of (Nearly) Everything..."[2] For example, he
states:
But it's not just publishing or journalism
that are going through a process of mass amateurisation at the moment. In fact
over the last fifteen years or so pretty much all media creation has started
to be deprofessionalised. We only have to look around us to see that this is
the case - as individually created media content that originated on the
internet has started to infect mass media. Hard-rocking poorly-animated
kittens that once roamed e-mail newsletters (http://www.b3ta.com) are now
showing up in adverts and credit-sequences, pop-songs written on home
computers are reaching the top of the charts, weblog commentators in Iraq are
getting columns in the national and international newspapers, music is being
hybridised and spliced in the home for competitions on national radio
stations. The whole of the mainstream media has started to look towards an
undercurrent of individual amateur creation because of the creativity that's
bubbling up from this previously unknown swathe of humanity. Mass-amateurisation
is EVERYWHERE.
And Ted Leung correctly applies the same concept
to open source[3]:
Tom Coates notes that just about everything
is becoming amateurised. I think that there are parallels with open source.
... I wish that we could find better terminology. After all, the software
running 64% of the web servers on the Internet was written by
"amateurs".
Perhaps a better word is semiprofessional:
everyone becomes semiprofessional across several professions.
A different perspective on the same phenomenon
goes by various names: "hacks"[4], "home hacking"[5][6], and
"consumer hacking."[7] As the editor of the O'Reilly "Hacks"
series explains[8]:
What happens if you expose the rich mountain
of Google data to hackers via a programmatic interface (the Google Web API)?
How do you turn a store-front like Amazon's into a syndicated e-commerce
engine? (Take a gander at the Amazon Associates program for the answer.)
Think about it. eBay has turned legions into
amateur merchants. 40% of eBay's listing come through its Web services APIs[9],
of which about 20% are initiated by 3rd parties.[10] Amazon's APIs tell a
similar story.[11] The same thing is happening with advertising. Google's
AdSense has turned everyone's personal web sites into ad revenue generating
machines.[12] All you have to do is insert a sliver of simple HTML boilerplate
into your page design (and free up some page real estate), and whenever that
page is displayed, Google will automagically post ads that are directly relevant
to the content on the page!. For a case study in the airline biz, check out
SeatGuru.com. It a favorite of mine because it lets you see the seating
configuration for all aircraft models across the major airlines! No more first
or last rows! Google even uses the site as a case study.[13]
This ability for consumers to customize their
software-driven devices and appliances and even cars is what accounts for the
popularity of ring tones ($3 billion business), skinning, and car hacking.
The phenomenon has even been written up in the
Wall Street Journal.[14] A related phenomenon, user exchanges, where users
exchange their extensions or add ons, has been around for a long time.[15] And
here's this month's Communications of the ACM with a special issue on "End
User Development" aka "Do it yourself" (DIY) development. [16]
Note, in some ways this mass amateurization trend
is nothing new. Note that all managers became amateur "secretaries"
when word processing made it possible for everyone to do his or her own typing.
Did it eliminate secretaries? No. They went on to do more complex things. It did
put a big dent in typing pools though. <grin>
[1] [2]
[3]
[4]
[5]
[6]
[7] [8]
[9] [10] [11]
[12]
[13]
[14] [15]
[16]
6:29:58 AM
|
|
|
Thursday, September 16, 2004 |
Aspect-oriented Networking.Its happening. Here's someone else making the
connection between the SOAP processing model and Aspect-Oriented Programming (or
more generally Aspect-Oriented Principles) in Identical
Principles, Higher Layers: Modeling Web Services as Protocol Stack:
[T]here is a fundamental difference between
the layered encoding of data within network systems (see Section Summary ) and
the SOAP approach of encoding layer-specific information in the header of a
SOAP message. While in strict layering, each layer adds a new envelope to the
data received from the layer above, thereby creating a multi-layer envelope
structure around the data, the SOAP approach uses XML's Namespace mechanism to
add new information to the SOAP message. Thus, the SOAP approach can be
seen as being comparable with the general idea of Aspect-Oriented Programming
[AOP] . AOP claims that closed components in software systems are not a
good idea, because there may be aspects cross-cutting through several
components. In the same way as AOP enables code to be written in a way that
transcends usual component boundaries, SOAP enables components on top of
SOAP to access component-specific information independent from the traditional
strict layering enforced by opaque data chunks with layer-specific headers.
The question of AOP vs. Layering and possible problems with one of the
approaches [Jung] is an interesting one and is a profound question of
the most appropriate way to model complex systems.
...
AOP and its remarkable similarity to the
way SOAP carries additional information in its header is something that we are
interested in investigating in more detail. It is possible that the strict
layering we describe in the Web Services layers 3-5 could and should be
replaced by something more flexible, so that the layering structure of
communicating Web Service peers must not match structurally, but only
semantically (in the spectrum allowed by constraints such as SOAP's
mustUnderstand attribute). It is possible that alternative models of protocol
structuring, such as the protocol graphs used in the context of Dynamic
Protocol Configuration [Plagemann] , provide a more appropriate way of
protocol modeling for the Web Services layers 3-5.
Emphasis added. See my last entry on this
subject, ESB vs.
ESN: Yet another end-to-end debate, which has references to previous
entries.
4:55:47 PM
|
|
|
Thursday, September 02, 2004 |
Deconstructing Internet Protocols.I thought *I* was pushing the interdisciplinary
envelope pretty far, but someone else seems to be *way* out there. Alexander R.
Galloway, Assistant Professor of Media Ecology at New York University (my law
school alma mater), has recently written a book called Protocol,
which appears to apply critical
theory (a descendent of deconstruction a la Derrida) to Internet
Protocols! Here is the book's blurb:
Is the Internet a
vast arena of unrestricted communication and freely exchanged information or a
regulated, highly structured virtual bureaucracy? In Protocol, Alexander
Galloway argues that the founding principle of the Net is control, not
freedom, and that the controlling power lies in the technical protocols that
make network connections (and disconnections) possible. He does this by
treating the computer as a textual medium that is based on a technological
language, code. Code, he argues, can be subject to the same kind of cultural
and literary analysis as any natural language; computer languages have their
own syntax, grammar, communities, and cultures. Instead of relying on
established theoretical approaches, Galloway finds a new way to write about
digital media, drawing on his backgrounds in computer programming and critical
theory. "Discipline-hopping is a necessity when it comes to complicated
socio-technical topics like protocol," he writes in the preface.
Galloway begins by examining the types of protocols that exist, including
TCP/IP, DNS, and HTML. He then looks at examples of resistance and subversion
-- hackers, viruses, cyberfeminism, Internet art -- which he views as
emblematic of the larger transformations now taking place within digital
culture. Written for a nontechnical audience, Protocol serves as a necessary
counterpoint to the wildly utopian visions of the Net that were so widespread
in earlier days.
It seems somewhat related to Code
and Other Laws of Cyberspace by Lawrence Lessig, which according to
reviews I've read, has a thesis that plays on the dual meaning of code as
computer software and code as a body of law. We'll see.
I found Alexander's home page, which has
links to several essays, including an essay with the same title as the book. I
liked it so much, I emailed him at NYU to see if we might collaborate on
something.
7:25:29 AM
|
|
|
