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.

Web services are seen by many as a mechanism for independent communication between systems, but also as a means of connecting divisions within a company, and enterprises within an industry. In many cases, Web services are an Edge technology - meaning that they exist at the boundary of an information system.

And although the primary technologies in Web services are not user interface elements, the fact that the service sits at the boundary of a system often means that it will end up as a client-facing service. And some clients want to interact directly with the service, not through a programmatic API.

Which is where Web service user interfaces come into play. We need to acknowledge the fact that many Web services are going to be acted upon by user interfaces which sit in front of human beings, as opposed to being invoked by some automated process. Some, not all. But a significant number.

And that's the basic premise of this month's issue. User interfaces, and Web services. I see interfaces as the part of Web services that gets overlooked while we concentrate on making sure that we can execute complex business logic, or create a business transaction, or ensure that our service is secured from unwarranted usage. And it's true that there is no widespread agreement on Web services interface standards (although work is underway on several). But that doesn't remove the need to address the issue. Actually, it's probably better that no one standard exists - it would defeat the machine-independent premise of Web services. But at the same time, as architects and developers, it is necessary to recognize that many Web services will require a user interface, and to understand how to use them effectively. Whether it's JSP; ASP on the Web; or Java or C# creating a thick client; or some other programming language, we need to investigate how to put a face on our service.

So in this issue we're exploring various facets of user interface interaction with Web services, including tools and technologies that make our lives easier. While it may not be a core part of Web services, it's still very necessary.

It's not just lipstick on a pig.