Eric Newcomer's Weblog

After the WS-CAF meeting in Paris, my mother and I took the train southwest to
Chartres to visit the famous cathedral.

Our guide said at one point that it was remarkable how quickly the main building was completed, especially without measuring standards. On the other hand (or is it foot?), perhaps that would account for how symmetric it all is.

Meaning that the same builder was involved for the whole time, and his foot could be used as the "standard" measure.

Thirty years seems like a long time to build anything. The World Trade Center was built in about four. (Of course it took more than 60 years to complete Chartres and more like 11 to complete WTC, but the structures were usable in 30 and 4, respectively.)

How many building items are of standard size now, compared to the 12th century? Never mind the basic invention of the measuring standard itself, the question is the purpose to which the standard has been put.

Many other industries have undergone standardization. It's funny to think that the time of day wasn't standard until about 120 years ago. Even then, it took another 34 years for the standard to be officially adopted by the U.S. government, and today's time zones ratified.

How many items in daily life today depend upon standard time? Travel schedules, phone calls across countries, meeting appointments, the order of stock transaction requests in the queue...

Usually an economic reason is needed to drive standards to widespread adoption. For Henry Ford and the Model T it was the effect on price of mass production. And the key was not the assembly line, but rather the standardized system of measuring and fastening parts that allowed for a division of labor. Until then, cars were built by hand-fitting parts.

So where are we in software? IT expenses are under tremendous pressure. Companies everywhere need to speed up results, improve success rates, and cut costs.

How many benefits would derive from the widespread adoption of software standards? How many items would use them? How much of daily life would change? Would we be building World Trade Centers in four years instead of cathedrals in 30?

Could we save the time and money we all spend on developing and marketing proprietary products? Would standard software "parts" help us build software systems faster and cheaper? Is Web services going to be the answer, finally, or just another proposal to use one person's "foot" size?

Hi,

I'd just like to thank everyone who voted for my book in this year's Reader's Choice Awards.

It's a tremendous honor, and it really comes at a good time since I'm currently struggling to finish up my new book, Web Services Integration, which I'm writing with Greg Lomow. I've just given the last chapter a final editorial pass so we can finally submit the manuscript.

While I'm at it, I'd like to thank Greg and Mary O'Brien at Addision Wesley for their patience. But I think in the end we're going to have a good book, one that talks about the advanced Web services features such as transactions, reliability, security, and orchestration and how to use them to integrate with any execution environment from CORBA to J2EE to .NET, MQ Series, databases and more.

One of the hardest parts about writing a book like this is to maintain a focus on the value of the technology as an independent layer on top of any other kind of software system. Software companies naturally tend to adapt Web services technologies to whatever software they've been selling rather than focus on them as an independent technology in its own right. Yet the value of Web services is almost completely tied to this independence.

I'd like to think that the independent view provided in my first Web services book is one of the main reasons it won your support. Greg and I are working hard to maintain the same perspective in the new book.

It was great to see a lot of old friends and former colleagues at the WS-Transaction Feedback Workshop last week. The transaction community is pretty small, and after having worked in and around it for more than 20 years, I saw a lot of familiar faces.

Some people are pretty cynical about these privately-sponsored workshops because they are not hosted by an independent industry consortium such as W3C or OASIS. The major complaint is that the copyright on the specifications remains under the control of the authors, and that any feedback provided also becomes the property of the authors. Another frequent complaint is that the group of authors is closed and self-selected.

But I take a more half-full glass view of these things. Any opportunity for collaboration is welcome, and important to take advantage of. And I'd that say the authors were very open to feedback, and seemed genuinely interested in the reactions of those present. I'm also sure that the specifications will be improved as a result of the feedback.

I was glad to be able to represent the WS-CAF TC and formally propose convergence between the WS-CAF set of specifications and the WS-AT, WS-BA, and WS-C specifications. I think that convergence would be really helpful to the industry, first of all, and I also think that the WS-CAF suite has some things to offer the WS-Transactions suite.

In particular, WS-CAF separates out context management as a generic function, so it can be applied not just to manage transactional context, but also to manage other types of context that need managing in a Web services environment. Many items in the Web services execution environment need managing besides transaction IDs, including security IDs, process IDs, device and file IDs, session IDs, and so on.

WS-CAF also defines a transaction model specifically for use in business process flows or Web service orchestrations. This model expands upon the idea of a transaction coordinator to help provide interoperability across transaction models (i.e. synchronous and asynchronous) and bridge recovery mechanisms, taking into account compensation, rollback, rollforward, and even human intervention as valid means to help obtain a consistent outcome on the results of a long running business process across arbitrary execution environments.

The remainder of the specifications could easily be merged, since they are technically similar: WS-AT is like the ACID model in the WS-CAF WS-TXM spec; WS-CAF's WS-CF is a superset of WS-C, and the WS-CAF Long Running Action is very similar to the WS-BA spec. When we were writing the WS-CAF specifications we intentionally aligned them with the BEA/IBM/Microsoft specifications and focused on (a) ensuring compatibility and (b) defining what we felt were useful extensions and additions.

It was great to have the feedback workshop, and it was great to have the opportunity to attend and propose convergence.

It also would be really great to be able to work together again with the old friends and colleagues in the room last Wednesday... and really get the community back together again.

Rich Bonneau and I taught the inagural Web services training class -- fittingly enough in Wasington, DC March 9. The feedback was all very, very positive, and encouraging for the next scheduled courses.

A version of the course has been given at Comdex last year, and was also well received. Recently we won an RFP to provide Web services training for Lockheed Martin.

The training course, like my best-selling book, is technology training, not product training.

Many people look toward graphic arts, line drawings, boxes, circles and arrows to find the future of software.

But I can't really see it.

Software has been language based since the beginning. Proposing that in the future, software will be written using UML and MDA is, to me, like saying books will be written entirely with pictures.

Ok, so some books are entirely pictoral, and icons are important if not critical to human life as we know it. But I can't really see how it's possible to impart real knowledge without using language. Or create precise enough computer instructions.

I can't see that the drawing approach will really work. I don't know of any graphical software development tool that has yet to address the entire lifecycle; or that generates code of sufficient quality.

I think it's just a problem that isn't meant to be solved.

Software is how humans tell computers what to do. During the past forty years or so one measure of the advancement in software is the level of abstraction at which humans are able to tell computers what to do. Assembler is higher level than machine language; COBOL is higher level than assembler, and so on.

The industry got kind of stuck on the "fourth generation" language problem during the late 80s, and I don't think you could say anything really succeeded (unless you count Visual Basic, which I don't, since it has so many purely language based extensions to the original form-based 4GL idea).

Now what we have is XML, which is certainly operating at a higher level of abstraction since it has to be parsed and interpreted, and executed by some other (arbitrary) language. Thus XML (and Web services, of course ;-) is truly language independent, and a major step forward.

In my view of the world, XML (and Web services) has a much better chance of solving the next level abstraction problem than UML or MDA.

(And no, I don't think either UML or MDA is very well suited to using for Web services, either. Class diagrams are just not the right metaphor, since Web services are not object-oriented, and the interaction diagrams aren't rich enough. Never mind the fact it doesn't make sense to use diagrams to create software in the first place ;-)