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.

While it doesn't get the press or the emphasis other parts of Web services do, the ability to finish the last mile, to put a human-accessible interface to the service, is an important part of what Web services are all about.

Most of the time, the user interface, or even the consumer of the Web service, is taken for granted as something about which we don't have to worry. And rightfully so, as Web services is first and foremost about plumbing.

Yes, I did say it's about plumbing. It's about connecting computer systems regardless of who made the system, what operating system it runs, and what programming languages are used. There are other things that go with it, as we've discussed over the course of this year within the magazine, such as business process management and security. But at its core Web services are about connectivity.

But somehow, some way, something has to use a Web service for something. And although in many cases the Web service is an intermediate part of a program, one that may never be directly interactive with a user, in some cases it will become necessary for the user to be able to invoke the service, even if indirectly.

Take a CICS transaction, for example (no, Sean, you take it). In many, many cases, a transaction represents the interaction of a 3270 screen, or its brethren, with a database. You could undoubtedly make a serious case for rewriting anything of that nature, but the reality for some organizations is that migrating hundreds, or thousands, of CICS transactions is not in the budget, and may never be. And while a 3270 screen is outmoded, the transactions behind it may not be. Putting a Web services interface on the transaction may enable multiple programs to get at it, but it still needs an interface.

That may not be the best example, but it certainly is a powerful one. The ability to put a modern face on legacy technology is definitely important. It's easy to discuss doing so in terms of deploying .NET, or a J2EE architecture with JSP pages. But the reality is that in some cases, the ability to directly expose a Web service using a simple mechanism would be extremely valuable.

Work is under way on some ways to do this, such as Web Services Remote Portal (WSRP). And portals are definitely a mechanism for providing services to a user, in convenient, bite-size packages. But since many companies don't have or use portal technologies, more than that is necessary.

It's debatable whether there needs to be a separate technology or standard for Web services user interfaces. It's difficult to imagine a broadly applicable technology, since the user interface is the last mile of the computing platform, and is intimately tied to the underlying desktop. Browser technology might be another answer, although it has its own problems with an anemic set of presentation tools. In most cases, we need to view the user interface as the domain of application programming languages and be thankful that most of the current generation of tools is able to interface fairly easily with Web services. But still, it's not too much to hope for to have a way to define the look and feel of an interface for a Web service, in XML of course, and leave it to the underlying virtual machine (or similar technique) to define the specific platform implementation. And it would make the last mile so much easier to walk.

I can't decide. Can you? Let me know. And happy holidays.

About the Author
Sean Rhody is the editor-in-chief of Web Services Journal. He is a respected industry expert and a consultant with a leading consulting services company. Sean@sys-con.com