Service Oriented Enterprise

Saturday, November 08, 2003

Chris Sells and the Royal *We*  

I just saw where Chris Sells of Microsoft was being questioned about the use of the word 'we':
In the '90s, we invented component technologies, like COM and Java, to bring DLLs into memory and we were very proud of ourselves.

Some of the readers were confused, thinking that Microsoft was claiming that they invented Java. But I understood, instead of "we", he meant to say, "people other than me and my company".

But then he goes on...
Unfortunately, we were so proud that we stretched the metaphor too far with technologies like DCOM, CORBA, and Java RMI. The problem is the idea of a proxy, which was designed to serve as an in-process stand-in for the remote code, hiding the fact that each method call was a round-trip of uncertain duration and uneven reliability. Indigo, on the other hand, is a platform technology that breaks from this metaphor to use a decidedly different way of connecting applications together. Specifically, Indigo uses services, not components, to model reusable units of code.

Holy shit - MICROSOFT USES SERVICES - why didn't the CORBA people think of that??? ROTFL
That's great... unlike DCE and CORBA, we (Chris + Microsoft + Indigo) use services.

Chris, with all due respect, it would be reading a book on the history of distributed computing, then rewriting your article.

posted by jeff | 6:41 AM

Friday, November 07, 2003

Don Box on XAML  

Don recently posted on XAML.

Take a good look at the source and the build code. Now ask yourself, are you excited to go out and whip up some XAML?

posted by jeff | 6:54 AM

I.T. Doesn't Matter - Business Process Do  

A few days back I mentioned that the new Howard Smith book came out called, "I.T. Doesn't Matter - Business Processes Do". I've had enough conversations with Howard to believe that he is one of the best minds in process driven, service oriented thinking. However, this book was quite disappointing.

Don't get me wrong. I think that Nicholas Carr is an incompetent pansy with a silver spoon stuck up his ass. As far as I can tell, Nicholas has never worked in an I.T. department, been a vendor to an I.T. department, or been the user of an I.T. department. He is a professional writer that gets paid by the word, regardless of the truth in the word.

Unlike Nicholas, Howard is an innovator, a practitioner and an evangelist. However, his critical analysis of Nicholas Carr's work was shabby at best. It appears as though he cranked out 120 pages of material while his emotions had control of him, and bitter emotions at that. It was clear to me that he was racing a publication to press while the Carr episode remained hot in peoples mind.

Save your money. Here are a couple great books:
For business dudes: "Designing and Managing the Supply Chain"
For geeks: "Non Functional Requirements in Software Engineering"

posted by jeff | 6:26 AM

Wednesday, November 05, 2003

Is John Udell Confused?  

Is John Udell Confused? If not, I am.

A while back, a librarian wrote to me asking how she could integrate her OPAC with LibraryLookup. I investigated and found that her vendor's implementation was based on a Java applet, and there was no way to link into it. As I mentioned to Eric Rudder and Don Box at a meeting in Redmond, this librarian later posted to a mailing list that her OPAC couldn't support LibraryLookup because it was built on the "wrong kind" of software, where "wrong" meant -- though she wouldn't have called it this -- non-RESTful. For her, the richer experience of that Java applet was a poor tradeoff, since it precluded LibraryLookup's lightweight style of integration.

Is John confusing open systems with "a RESTful" approach? I might be confused... but it sounds like the librarian had an open integration problem - not something that necessarily demanded a RESTful solution. Let's see... if the year was 1993, the librarian may have had a 'CORBAful' issue... or if it was 1990, she had a 'DCE-ful' issue. Maybe what John is trying to say is that we finally have a quick & easy way to store off profile information - - kind of like the 'Win.ini' file in early versions of Windows. It smells like John is wanting to solve some problem with REST, or I could be confused.

posted by jeff | 6:07 PM

Novell Wakes Up  

After a long, long, long sleep - it appears as though the team at Novell has woken up and decided to get in the game.

First, Novell acquires Ximian which gives them Mono, a platform for running .Net applications on a Linux platform.
Now, Novell is acquiring SuSE Linux for $210 million in cash.

The way I see it, IBM will be encouraged to remain pure Java - while Microsoft will be encouraged to remain pure .Net. This leaves the 'neutral' ground in the middle wide open.

So, where does Novell go from here? I see more acquisitions. My conversations with people close to Novell lead me to believe that Novell really believes that web services are the *network operating system*. Thus, the Ximian and SuSe acquisitions were only laying the foundation for a distributed computing platform. I would look for Novell to continue down the M&A path, but this time moving up the stack - taking a hard look at web service platform vendors and perhaps even tool vendors like Borland.

But the real question deals with timing. Is it too late for Novell? Did they already lose the hearts and minds of the developer? I personally don't think that it is too late - remember, Novell was the company that forged programs like 'Gold Certified Novell Partner'. If Novell continues to make bold moves, they will attract the talent to create new developer-community offerings.

To Novell - Congratulations. I hope all that sleep you took gave you the rest needed to get into the next big battle.

posted by jeff | 6:36 AM

Tuesday, November 04, 2003

Orchestrating BPEL Validation  

This is a repost from the SOA news group:

We have been testing our implementations against some pretty large bpel documents with good results. Also, it is easy enough to enforce syntactic validation as a web service. Thus, each vendor (OpenStorm, Collaxa, Vitria, etc.) would expose a service to validate a bpel, then we would publish a simple "validation orchestration" that tested the syntax against each vendors implementation. The customer builds the bpel schedule and then calls the orchestration, which in turn calls each vendors validator. The results are aggregated and returned to the vendor. I can not commit on behalf of any other vendors, but I can commit that OpenStorm will offer this as a service.

The service world (and orchestration) may force standards to remain, well... standards.

I would bet that my esteemed colleagues at Collaxa are game for an open validation service / orchestration as well.

posted by jeff | 6:01 PM