Recently SOA World Magazine was the host of a conference on SOA and Web 2.0 in New York City. SOA World 2007 brought together an amazing group of IT professionals who helped describe and expand the definitions of SOA.

One of the most interesting challenges faced by IT is the role of Web 2.0 in service-oriented architecture. This is caused in part by the fact that you can do Web 2.0 without service-oriented architecture, and you can also do service-oriented architecture without Web 2.0. And yet, the key question becomes should you or will you?

I've long gone on record as saying we need something better than the browser to truly deliver zero footprint Internet-based applications. We need an independent platform specification accompanied by platform-specific implementations that allow for the best of all worlds, not the least. The browser must die (I've said this before), and from its ashes we need a true application platform.

That being said, Web 2.0 is a step in the right direction. AJAX adds asynchronous communication and frees us from the dreaded refresh tag. That's not the only thing AJAX provides, but that alone makes the world a better place. We've long needed a way to get data back to the screen without having to repaint it. Seems simple, but look how long it took.

Web 2.0 is more than just AJAX. RSS feeds and blogs provide new ways to publish and edit Internet-based content and form communities. Flash and a host of other technologies are going a long way to provide the rich Internet application landscape that may make the browser truly useable instead of downright annoying. In time, the plug-ins may replace the browser entirely, which would be a godsend (in my opinion at least).

Yet none of these things is inherently service based. Or, rather, they don't have to be used that way. They can be combined with today's typical application style - that of a silo application that has no concept of service - without penalty or fear. Whether that's the best approach is not really the issue.

SOA does not come with the concept of a user interface, at least by most definitions. Services are defined, producers produce, and consumers consume, but the concept of actually defining a human interaction layer seems to get lost in the shuffle. As important as SOA has become in rescuing the enterprise from the failure of EAI and allowing computer-to-computer communication across boundaries, the average SOA proponent tends to view the human user as unimportant. Like our text books used to say, "That's left as an exercise for the reader."

That's a problem. SOA is not a god, and while IT is right to move to it for many things, it's important to realize that every service we build is going to ultimately be used for the benefit of some end user. The lack of a user interaction layer within SOA is a flaw that may ultimately limit the applicability of SOA as an enterprise architecture approach.

We need a human / user interaction layer as a core concept within the SOA technology stack. As tempting as it is to relegate that to the actual implementers and pass on it as too complex a task to standardize, it's exactly that complexity that cries out for some common definition and rigor.

We need the vendors who are bringing SOA to the market to coordinate with the Web 2.0 community. We need the intersection of service and interface, that place in the middle where SOA includes a user interface and Web 2.0 defines itself as a service consumer (and also a provider of services within the user interface layer, since the concept of service can be expressed at multiple levels). This issue addresses those challenges and provides some insight into making these two technologies co-exist.