One of the fun parts of being a software architect is trying to figure out how to build whatever it is that you are supposed to build. It's even more fun when you look at the architecture for an entire enterprise, and have to make choices that integrate every complexity and account for every nuance of the portfolio, even if only long enough to get something in place before ripping something else out.

A couple of issues ago, I railed about the lack of Web services- based technology to provide the last hurdle of any service - representation in a user interface. While many Web services will only be accessed programmatically, still more are destined to find their way, one way or another, onto the screens of computers in front of human beings.

As I get ready to celebrate the holidays this year, I spent a little time reflecting on what I would like from the various Web services vendors. While a case of scotch was definitely tempting, what I really want is a better toolset.

One of the things I continually rail about in the Web services world is the lack of last mile technology - you know, the ability to get a Web service in front of a user. Even though a large number of Web services are designed solely for computer to computer communication the continuing reality is that more Web services are designed to interact directly or indirectly with human beings.

A few years ago, a heated debate raged over the benefits of two competing technologies: .NET versus J2EE. Microsoft advocates affirmed that .NET was superior and likewise Java enthusiasts asserted similar observations about J2EE. As it turns out, both camps were at least partially correct.

We've been covering Web services technologies for quite some time now, almost three years. In that time - I think it amounts to two eternities in Internet time - we've seen all sorts of interesting things occur. Cooperation, coopetition, even the creation of a group whose sole purpose is to make sure that the standards really are standard.

Yes, I know it's corny, but I've had a few things on my mind regarding service-oriented architecture, component-based development, and even the infamous enterprise service bus. (Hey, at least the title isn't 'Get on the Bus'). All of these have something to do with Web services. None of them are 'Web services,' at least not entirely. And yes, you guessed it, they're all part of this month's focus.

I was recently invited to be a guest speaker at the eBay Developers Conference, where I was part of a panel whose topic was 'Delivering the Promise of Web Services.' I found it particularly interesting, if slightly worrisome. What struck me most was the differentiation between Web services consumers and Web services authors.

Roughly last year at this time, as we covered the convergence of EAI and Web services, many people were asking about the ultimate survival of EAI as a software solution. In one sense, this was understandable, as the technologies that make up Web services provide significant amounts of functionality similar to that provided by EAI products, while achieving greater interoperability.

When I started to think about writing this month's column I looked on the Internet for a good way to define service-oriented architecture (SOA). Some of the definitions were interesting, like 'A Service Oriented Architecture is basically a Collection of Services' (www.service-architecture .com/). Others were a little bit more technical, such as 'SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents' (www.xml.com).

The saying goes, 'when all you have is a hammer, everything looks like a nail.' It comes from carpentry, where it implies a certain amount of limited capability for a craftsman, but it has applicability in a wide range of situations. In particular for the IT industry, it denotes that someone doesn't have all the tools they need to do a job well.

At one point in my career I worked right across the street from Enron. I used to pass the big E on the sidewalk as I made my way to the account I was working on. Like most of us, the fall of Enron surprised and angered me.

To quote the Scarecrow from the Wizard of Oz, 'There are pieces of me here. There are pieces of me there.' Thanks to years of independent evolution, user identity information also exists with bits and pieces in different places.

My involvement in Web services was a mistake. I don't mean that I regret it, just that I got involved in Web services because of a mistake I made. It actually started when I was preparing an executive presentation on the current trends in security. I came across one of those juicy statistics that security people (like me) love to use.

There's a joke in the industry that states that the only really secure computer is in a room where no one is allowed to go. It has no Internet connection, and no network connectivity. It has no monitor, so no one can peek over a user's shoulder to see what is on the screen. And it's not plugged in. And of course, it doesn't run Windows. And frighteningly enough, there are people who work in security who truly believe this.

One of the more interesting observations I've made in the past year concerns the model on which corporations base their IT strategies. I've visited a large number of major corporations, and there's a very strong trend. These corporations are large, with established business practices and IT organizations, and one of the things they all have in common is that no one is writing a new business application.

Every year about this time, I like to take a moment to reflect on things. Some people make resolutions, but I've never been very good at that, so instead I try to take a look forward and see where the year is going to take us, and what we need to accomplish.

Web Services Journal recently asked its editorial advisory board for their answers on several questions about where Web services is going next year.

Every now and then, I feel like two separate people. On one hand, I want to talk about services, pure and simple. I don't want to clutter it all up by discussing how to present the service to a user, or how to make it pretty, or how to make it cross platform. And yet, part of me realizes that there is a bigger picture to be considered.

Recently, I've been seeing some chatter around adding a programmatic aspect to Web services that is currently not part of the specifications - namely, adding object orientation (in particular inheritance, although I'm sure polymorphism is implied). I've thought about this, and I think it's a bad idea.

One of the most frustrating things I've ever encountered in my life is trying to loosen a nut using a socket from the wrong measurement system. You know, I've got a metric nut, but an English socket set. So I find a socket that's close, but it's loose, and inevitably I end up stripping the nut, bruising my knuckles, and generally using language I don't care to repeat. To paraphrase an old saw - the only thing worse than no standard is two standards.

(September 22, 2003) - According to a study by industry analyst firm Gartner, IT budget cutbacks are forcing organizations to reduce Web services spending. After surveying 111 North American companies, Gartner reports that 48% of respondents cut spending on Web services application development projects due to the current economic climate.

This past August, I celebrated a major milestone - 10 years in the publishing business. Over the last decade, I've had the opportunity to participate in, and in some cases, even anticipate major technology changes. First with client/server, then with the Internet and Java, and now with Web services.

In June I attended the JavaOne conference out in San Francisco, to keep up with what the Java world was doing, and to see how it impacted Web services. I see a number of parallels between Web services and the way that the various Java specifications have been created, and some key differences.

My dictionary defines service as the work provided by one that serves. Sometimes it seems that you have to define something by itself, even when you don't want to. Web services provide the ability for an organization to expose its business processes for consumption, either public or private. And they do so in a vendor-, platform-, and language-neutral format, as opposed to proprietary attempts at similar solutions over the past two decades.

When I was a kid, I loved to put things together. I especially liked building things with LEGO. Never mind the TV, dump a huge pile of LEGO blocks in front of me and I'd be quiet for hours, building a LEGO version of the Eiffel Tower, or some other construct that only a kid could imagine.

Back in the old days, when you needed to communicate with someone distant, you usually had to send a letter. There was no instant response, and there was no way to tell when your message was received. Now we have always-on e-mail, BlackBerrys, and assorted other devices to make what was once a leisurely (or agonizingly slow) process instantaneous, and synchronous.

When I was younger, I found out the hard way that I was allergic to certain medications - I got three shots and went into shock. It left me deeply afraid of needles. To this day, doctors need to give me something to bite on when they give me a shot. Dentists, well, let's just say they need to count their fingers.

What's in a name? A rose by any other name will still smell as sweet. Well, perhaps in the world of horticulture, but in the information technology arena, I'm not sure that aphorism applies. I'm sure you all realize that I'm referring to the recent purchase of Rational Software by IBM for approximately $2.2 billion dollars. This acquisition leaves me wondering what Rose will smell like a year from now.

It's not unusual for the January issue of a magazine to have a column discussing the past, or predicting the future. This year, I thought we might try something a little different. Rather than reminisce or prognosticate, I thought I'd toss out my list of Web service needs in the form of a holiday wish list.Here goes:

There's an expression in the industry - 'putting lipstick on a pig.' It's used to signify a task, or project, that has only cosmetic value and doesn't address the real issues of a situation - it merely makes the pig look a little better. But after all, it's still a pig. Sometimes as we discuss Web services, we tend to think of the user interface as lipstick. It's an easy trap to fall into; after all, Web services are about communication between machines, so no user interface is actually necessary. Of course, that's a great fallacy.

There's an old expression - 'When all you have is a hammer, everything looks like a nail.' There's a wealth of applicable comment in this expression. It's an admonition to see the bigger picture as well as a suggestion that to be a true craftsman, one must have the right tools.

There's a lot going on in the world of Web services these days, so much so that it's almost hard to keep track of it. And there is definitely enough to make it difficult to make sense of competing initiatives. But it certainly makes for interesting watching. Case in point is the Web Services Interoperability organization (WS-I). Chartered as an open standards group whose purpose is to increase the interoperability of Web services across platforms, languages, and systems, the group counts IBM, BEA, and Microsoft amongst its members.

Web services are demonstrating their value and exhibiting the potential to substantially enhance enterprise productivity and reduce operating costs. But they will never reach their full potential without two things: trust and security. That's because Web services are based on open, dynamic exchange of valuable data and services. But for everything to work the way it's intended, those deploying Web services must be able to ensure that the data or services being exchanged are kept confidential, secure, and reliable.

We aren't a news magazine, and we don't cover current events except as they relate to our industry, so I had to think long and hard about what to say in this edition. Nevertheless, I decided that at least in my editorial, we would remember September 11th.

In the world of Web services, the question of the month is about platforms. Does the Web services world resemble the political system of the United States, with a two-party system, or is it a more free-wheeling system of coalitions and multiple interests?

I guess the title begs the question, if this is the end of the beginning, is it the beginning of the end? Hardly. But it is time to close the book on the first phase of Web services - the beginning of the hype curve.

Based on the number of questions I get on the subject, quite a few people think that SOAP isn't secure. It's a bit hard to answer these questions because SOAP is neither secure nor insecure. It's not within the scope of SOAP to implement security. SOAP is simply a mechanism to package information to send between two applications. Even so, it's easy to secure SOAP messages, and SOAP provides an extensible mechanism that allows you to convey security information in your messages.

Like many IT professionals, I'm an amateur musician. As such, I know how much effort it can be to get a group of people to work together, start together, end together and make a pleasant sort of noise together. And I play in a small group, so I can imagine the coordination effort of something like a symphony orchestra.

Remember that kid in the neighborhood - the one who had the bat and ball, and if you wanted to play together, you had to use his stuff? Even if he was a pretty nice kid, there was always a time when you longed for the ability to play on your own, or at least use a bat that was more your size.