Archive for August, 2005

Since May, I have been commuting from my home in Colorado to northern Virginia for a project. Being a road warrior is not something that is unfamiliar to me having spent the first 9 years of my career working for large consulting firms. It was good, however, to start a new phase of the project yesterday that will will allow me to do most of the work from my home office.

Our home (and therefore my home office) is in the foothills of Colorado west of Denver at about 8,000 feet above sea level. I was on two conference calls yesterday in which I spent most of the time during the call on my deck enjoying the fresh air and cool(er) temperatures. During the afternoon call a herd of elk wandered by with several new calves in tow.

It was very strange to be listening to a conversation about the typical events of the first week of testing while watching the pastoral scene of recently born wildlife grazing in my yard.

I think I’m going to like this.


Comments No Comments »

I wrote a while back about my frustrations with UDDI as an adequate repository for web services metadata. Recently, Ascential’s Michael Curry wrote in his SOA Blog recently

From what I’ve seen, UDDI is very seldom used by most companies beyond departmental implementations. The real problem is that the information in a UDDI directory is not very useful, or not useful enough, and therefore developers don’t bother using it to find services.

He received a bit of pushback from Systinet’s Tom Erickson who wrote

Most of our customers are certainly looking for capabilities beyond UDDI, thus our development efforts to create Systinet Registy 5.0 a year ago and 6.0 which we announced last week. Our new platform Blizzard, available in early access next month, takes things a step further by adding a repository and capabilities to model the SOA

I think both of these guys are saying similar things. UDDI as it exists today is woefully inadequate for most large-scale users. Sure some will use it, but not happily and not without building a long list of complaints.

As I design and build intelligent intermediary-style SOA architecture, I almost always need a services repository that goes far beyond what is offered by UDDI today.

Vendors, left to their own devices, will solve this problem by releasing products that create rich services metadata repository while providing a UDDI API to fill the “checkbox” requirement.

This is better than making their customers roll this on their own as I’ve been forced to do, but not nearly as useful as banding together to create a better UDDI and then tweak their new registry tools to adhere to a new spec.

I know that, in the real world, specs like UDDI often significantly lag industry and vendor best practices. Playing the specs and standards game is also a constant balance between creating competitive advantage with your own implementation and generating enough standardization to drive broad adoption of your, now-compliant, product.

UDDI just seems to be a particularly painful example of this.

Comments No Comments »

The primary purpose of an Enterprise Services Bus or ESB is to implement a layer of enterprise-class infrastructure that provides a standard way for an organization to expose services so that they can be discovered and executed by authorized users.

The services exposed by an ESB can be created by web-service enabling portions of existing applications, leveraging new web-services API’s provided by existing packaged apps or creating new web services from scratch.

The combination of development language, hardware platform or package vendor on which a service depends is not important to the ESB other than that the combination must provide a satisfactory level or service to consumers.

One approach for implementing ESB infrastructure is to create an “intelligent intermediary” (or fabric of intermediaries) through which all requests for services are routed.

This approach enables consistent implementation of the organization’s security framework, provides a mechanism to seamlessly fail over to a new instance of a requested service and supports horizontal scalability by routing requests to “farms” or “grids” of enterprise services.

The intelligent intermediary provides these things without impacting the individual services or the legacy applications and COTS packages that provide them. In essence, the ESB becomes a loosely coupled “container” for enterprise services analogous in many ways to a J2EE application server but without the restrictions of developing the services themselves as Enterprise Java Beans.

The intelligent intermediary approach is often criticized because it adds a layer between the service consumer and the service provider. This layer seems (and probably is) excessive when only a few departmental-class services need to be exposed and consumed. However, when one measures the work (and heavy handed enforcement) required to push enterprise security, transparency and quality of service standards to each developer or provider of a service, the so-called overhead looks like a bargain by comparison.

For years organizations have been creating rat’s nests of point-to-point integrations that were a nightmare to maintain. Creating a point-to-point mesh of web services invocations is just this generation’s way of re-inventing the wheel. Try adding a WS-Security based security framework to one of those messes. It can be done, but at much greater cost (time and money) than spending upfront to design and build or acquire an ESB to act as the intelligent intermediary.

We’re still in the intense hype phase of the Enterprise Services Bus and Service Oriented Architecture adoption cycle. Organizations are struggling to plot a course that avoids pitfalls of being an early adopter, emergent vendors are slapping out immature products to gain market and mind share and the mature integration vendors are adapting their core products to address the space through new releases and acquisitions.

While the product cycle takes its normal course, organizations can continue to web-service enable existing applications that provide value as enterprise services. During this preparation phase, however, organizations should implement an intermediary of some sort even if it does nothing but get developers (and vendors) in the habit of routing requests there first.

The initial version of the intermediary may not have all of the organizations desired capabilities, but it will help avoid pushing complexities of enterprise class infrastructure down to individual services and pave the way for the (perhaps not-so-distant) future when the tool vendors have once again caught up with the needs of their customers.

Comments No Comments »

It turns out that Ray Moser and I have been working on projects located literally across the street from one another in Arlington, Virginia for a month and didn’t know it.

We met for lunch yesterday at a nearby asian restaurant. As I was walking to meet Ray, I realized that even though we have talked on the phone, emailed and traded WM Users posts for years now, we had never met in person.

So what did we talk about? webMethods, of course, but also family, international travel and a few other odds and ends.

Well met indeed!

Comments No Comments »