Monday, October 31, 2005

It's not just Light vs. Heavy; It's Dynamic vs. Static. This entry is my response to an interesting thread spun out of a bet about the future of markup languages. It can be read standalone, but is probably easier to follow if you read the bet and the thread first. I believe that we will all author in something much closer to XHTML+microformats than we author in DocBooks or WordML or TeX, because the former better enables Tim Berners-Lee's vision of the two-way web: a web whose "interactive content" can be immediately edited using the same basic tools for browsing as for editing. I think the traditional "batch style" of authoring and publishing using "compiled markup languages" is giving way to the "interactive style" of authoring and publishing using "dynamic markup languages". [While "compiled markup language" seems to be in use, there does not yet appear to be any discussion of compiled vs. dynamic markup languages. So this may be the first.] The batch style is exemplified by the phrase "WYSIWYG": What You See Is What You Get. What has been compiled for rendering is what you get--take it or leave it. To put it more pejoratively "What You See Is What You Are Stuck With." The interactive style is exemplified by WYSIWYE ("What You See Is What You Edit"). [For about five minutes, I was pleased with myself for having of this succinctly insightful term; until I Googled it and got 200+ hits. Oh well, its still a great alternative term for Tim Berners-Lee's read write web.] So...because I believe that eventually we will be able to edit and annotate and cut and paste everything we SEE on the web, this leads me to believe that the language used to present such information will be the language we use to author it as well. Note that we may still use fancy WYS editors for authoring. But the author's mental model of the underlying representation will be based on a dynamic markup language. Blogs and wikis are heading in this direction. Few blog or wiki writers author in Word and then publish in XHTML. Instead, they author while thinking in much more HTML-native ways. For example, they use pidgen HTML markup languages (==header==) and viewers that can toggle between cooked (rendered) and raw views. Or go back even further when we used to author in long hand and a WP specialist would reproduce it in electronic format. Now almost all writers are expected to author in electronic format. So for me, the interesting question is: What will tomorrow's "dynamic markup language" look like? I'm betting it's going to look a lot more like today's XHTML+microformats than today's compiled markup languages", e.g., DocBooks, WordML, Postscript, TeX. (Note: I think a similar dialectic is happening between dynamic programming languages and compiled programming languages for similar reasons, i.e., the transition to WYRIWYE--What You Run Is What You Edit.) The other interesting question is how quickly will dynamic markup languages and the WYSIWYE interactive document lifecycle displace compiled markup languages and the WYSIWYG batch document lifecycle? Unfortunately, technical writing, which is often expected to be published and not changed much thereafter, e.g., academic journals, is probably the last form of writing to follow this trend. The biggest determinant of the pace of such change will be the change in thinking about academic collaboration. It's already changing with preprint archives like arXiv. The lines between preprint, print, and postprint are blurring because the relationships between the peer review process and the publishing process are in flux. However, given the pace of such cultural changes, I think five years is very optimistic--but still possible. 3:33:34 PM

Friday, July 08, 2005

Great WS-* Case Study. Tim Bray has done a great case study write up about WS-*. Here's the intro: Last week at Java One, Ashesh Badani, a Sun SOA marketing person, wanted to have lunch with me to talk about WS-*. He brought along T.N. Subramaniam, Director of Technology for RouteOne, a car-loan aggregator. (Sun loves RouteOne, they're a reference customer not only for us but for SeeBeyond, which we're in the process of acquiring). Anyhow, neither Ashesh nor Ashok Mollin, a Sun guy who's been engaged at RouteOne, got a chance to say much, because T.N. and I hit it off and had a good time talking about Web Services. Which RouteOne are doing, big time and for big bucks and successfully. They are exactly the kind of people that those of us struggling in the WS-* morass ought to be looking to for lessons. This, I think, will be the first ever ongoing piece structured as an interview; with T.N.'s help, I've tried to reconstruct our conversation at lunch. I think some conclusions are obvious, but I'll leave them for you to draw. I'd bottom line the advice from TN as "So far so good, but as you fill out WS-* KISS (instead of addressing marginal cases)." 11:29:20 AM

Wednesday, June 22, 2005

Cisco launches Application-Oriented Networking. Yesterday, Cisco finally announced AON (Application-Oriented Networking), which is basically the ability to process Web services in a Cisco router. I hope this will wake up the SOA/WS-* world to the fact that for Web services to be anywhere near as big a deal as we are all claiming, then it had better be understood as a new application-level network based the SOAP envelope. Web services is not an RPC, its not a bus (not even an ESB)--its a fully routable SOAP network with SOAP intermediaries handling both business as well as technical functions. Let me also remind everyone that AON also stands for Aspect-Oriented Networking. As I've mentioned before in my blog (see Endpoint services vs. protocol services and Aspect-oriented Networking), the SOAP header processing model enables SOAP features that are effectively aspects. Let me point out some others who are making the connection: Carlos Perez (twice),  Jason Brome, Michael Curry, and Loosely Coupled (sort of). And my favorite reference is this paper, Identical Principles, Higher Layers: Modeling Web Services as Protocol Stack, which I discussed in a previous entry. 7:55:03 AM

Friday, November 12, 2004

Some say, WS-* is too complex; I say, Compared to what? While the controversy over WS-Complexity (which seems to have been catalyzed by Tim Bray's Loyal WS-Opposition post; see these references to Tim's post; see also my collection of WS-Complexity references) seems to be dying down, I did want to add my two cents to the debate. In all the blog postings I've seen on the subject, not one has compared the current WS-* processes for developing, debating, and adopting Web Services and their output to the IETF standards processes and their output. Clearly, in terms of number of pages, the IETF specs far outweigh WS-* specs, yet few would argue that the IETF process of "rough consensus and working code" is a failure. Nobody complains that anyone can submit an RFC draft at the drop of a hat. How is that different from MSFT, IBM, et al announcing a proposed WS-* spec every week? I believe that the "federated" standards processes emerging around WS-* is a worthy successor to the IETF approach. I characterize it as "federated" because WS-* related standards are designed in different standards bodies and WS-I is emerging as the "meta-standards body" that integrates and interop-certifies the standards coming out of the other standards bodies. I characterize the WS-* federated standards processes as a "worthy successor" to the IETF, because the traditional approach to standards is a dead as the dodo. Ever since the US federal legislation enabling industry consortia in the 1990s, they have become the standards center of gravity, for better or worse. Standards setting bodies and their interactions has become the central domain of the emerging economic model of co-opetition. It just so happens that the Web and WS-* are the first major Guinea pigs of this new paradigm. The point I'm trying to make is to suggest that the current WS-* proliferation of WS-* specs is a sign of a vibrant, decentralized innovative community. The same is true of the proliferation of XML vocabularies across the board. This is a sign that this stuff is easy to design with. Let's declare victory and move on. The wheat will be separated from the chaff when such specs are put to use in the marketplace. 7:02:43 AM

Thursday, October 28, 2004

Pervasive integration requires pervasive intermediation. Jon Udell makes a great point about pervasive intermediation. His basic point is the architecture of SOAP processing model is necessary to generalize and extend the ad hoc intermediation architecture of HTTP, which has proved so essential to the web's scalability and flexibility. This is a fundamental point about SOAP intermediaries that I have been trying to drive home as well. This year's METAmorphosis conference has the theme pervasive integration, which leads to the "obvious" conclusion that pervasive integration requires pervasive intermediation. The web did not disintermediate, it is reintermediating (refactoring intermediation). 3:39:43 PM

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