Wednesday, February 18, 2004

Contingency, Irony, and Fashion! I love this concept. Open a store for only a year, even if it is doing great business. Turn retailing into a limited time event. Highlight the ephemeral nature of fashion with an ephemeral store. The article also highlights the solidarity aspect of the approach. These "Guerrilla Stores" rely on the solidarity of personal word-of-mouth for marketing/advertising. Very retro. 5:21:56 PM

My definition of Service-Oriented Architecture I recently realized that I had never given my definition of Service-Oriented Architecture (SOA) on my blog. Here it is: [SHORT DEFINITION] An SOA is a dynamic, modular, general purpose, extensible, federated, interoperability architecture based on internetwork concepts such as identifiers, formats, protocols, envelopes, and intermediaries. [LONG DEFINITION] An SOA is a dynamic, modular, general purpose, extensible, federated interoperability architecture that defines all processes as services delegated to service providers via generic envelope-based service interfaces. Such generic interfaces describe only the interactions between service providers and service consumers and solely in terms of extensible identifiers, formats, and protocols (IFaPs). Such generic service interfaces are intended to be dynamically bound to a diverse array of specific concrete service transport technologies and endpoint service provider technologies that are both federated by envelope-processing service intermediaries. The advantage of my definition is that it is general enough to encompass the Internet Architecture, the Web Architecture, the Web Services Architecture (aka WS-*) and even the (Intermodal) Containerized Shipping Architecture (where the container is the envelope and the "envelope-processing service intermediaries" are intermodal hubs) as SOAs. What distinguishes the Web Services Architecture from the rest is simply the degree to which it is dynamic, modular, general purpose, extensible, and federated. 6:26:24 AM

Building block standards. I am following up on my federated specifications entry with a new term that seems to have a fair amount of use: building block standards. Its google number is 199. I came across it reading the intro to the XLANG spec: Full specification of business processes requires the specification of a number of different aspects: document schemas, message envelopes, reliable delivery, security, endpoint properties such as certificates, reliability requirements and service windows, and even legal agreements and personal contact information. Many of these aspects are involved in multiple web service usage domains. Building monolithic standards that address entire usage domains invariably creates egregiously different standards for requirements that are common to many domains. We believe it is better to develop a collection of building block standards that can be combined into domain specific standards as required. This simplifies implementation, interoperability, and compliance verification, making the development of web services standards and infrastructure much more practical and cost effective. This one paragraph weaves together much of my thinking on the topic. First, it points out the "full specifications" require the specification of a variety of "aspects". (This led me to think of the terms "aspect-oriented specifications and "aspect-oriented standards". Although no one appears to be using "aspect-oriented standards" yet, "aspect-oriented specifications" is widely used -- its google number is 799.) Second, it points out the core problem with "monolithic standards": it fragments requirements common to many domains. My favorite example of this are the thousands of "specs" for mailing address -- one for each spec that has a mailing address in it (e.g. PO, Shipping Notice, Invoice). Instead of embedding a mailing address subspec, these specs should reference something like the OASIS eXtensible Address Language (xAL) to deal uniformly with the address aspect. Third, it highlights that the building block standards can be combined into domain specific standards, which is in line with my belief, and apparently Microsoft's (see Steve Cook's article on Domain-Specific Modeling. Note however, that the building block standards are also "domain specific standards." Thus they are another example of what is often referred to as general specialties, which include as a subset general purpose technologies. (See Langlois, Knowledge, consumption, and endogenous growth.) (Note to self: need to clarify general specialties. Two dimensions are being described: vertically, the spec does only a specific function, but horizontally, it has general applicability.) 5:53:23 AM