Ask 10 different people to define Web Services, and I guarantee that you will get ten different answers. Given the amount of hype in the marketplace about Web Services, why are they so difficult to define? The reason is not only that marketing hype machines are working overtime in order to enable vendors to jump on the Web Services bandwagon, but also because Web Services covers a wide spectrum of uses and facilities; and it's not easy to define these capabilities in a single sentence.

We can break Web Services into two words: "Web" and "services." The word "Web" means that all operations are performed using the technology and infrastructure of the World Wide Web. A "service" is an activity or processing performed on behalf of a requestor such as a person or application. There are two different aspects of Web services ­ one with a lowercase "s" (i.e., Web services), and one with an uppercase "S" (i.e., Web Services). Web services have been around since the Web was invented. The ability of a Web-browser user to access e-mail or to order a product on the Internet is an example of Web services. Web Services, on the other hand, involve the use of XML; and it is better, therefore, to think of the current industry hullabaloo in terms of XML Web Services.

XML Web Services enable any form of distributed processing to be performed using a set of standard Web- and XML-based protocols and technologies. To quote W3C (the World Wide Web Consortium): A Web Service is a software system identified by a Universal Resource Identifier (URI) whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web Service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.

In theory then, the only requirements for implementing a Web Service are: 1) A technique for formatting service requests and responses; 2) A way to describe the service; 3) A method to discover the existence of the service; and 4) The ability to transmit requests and responses to and from the service across a network. The main approaches to implementing these requirements are XML, WSDL, UDDI and SOAP. There are, however, many more capabilities (authentication, security and transaction processing, for example) required to make Web Services viable in the enterprise; and there are numerous protocols in development to provide these capabilities. Some of these protocols are specific to enterprise portals.

It is important to emphasize that one key characteristic of Web Services is that they are platform-neutral and vendor-independent. They are also somewhat easier to understand and implement than earlier distributed processing standards efforts such as CORBA. Of course, Web Services will still need to be implemented in specific vendor environments, and this is the focus of efforts such as IBM Web Services, Microsoft .NET and Sun ONE.

It is not only important to understand the Web Services standards efforts currently underway and how they are being implemented by vendors, but also to have an enterprise architecture that specifies how your organization will evolve toward the use of Web Services. This is particularly important when employing Web Services for enterprise integration. Web Services can be used at all four levels of enterprise integration – at the user interface, business process, application and data levels.

An enterprise portal supports integration at the user-interface and business-process levels. It provides internal and external users with a personalized and integrated view of the business content (information, applications and services) that they need to do their jobs. However, an enterprise portal is more than just a Web interface to business content. It also offers a rich set of services to gather, categorize, integrate and personalize this content.

Business content viewed through a portal is accessed via adapters known as portlets. Each portlet provides an interface to a specific piece of business content such as a Web document or server, or an enterprise application. If this business content is defined in terms of a Web Service, then any portal product from any vendor can access that content using Web Services. One key industry effort in support of this is the WSRP (Web Services for Remote Portals) protocol.

Heterogeneous portals can also communicate with each other using Web Services in support of a federated portal architecture. Services provided by the portal itself such as search or content management can also be defined and accessed as Web Services, which makes it easy to integrate third-party portal capabilities into different vendors' portal products.

Although they are in their infancy, Web Services will become the primary way in which business processes are exposed and accessed in the enterprise. As these processes are exposed, it will become easier for organizations to integrate their business operations with those of their partners. At the same time, enterprise portals have rapidly emerged to become the Web-user interface of choice for accessing enterprise-wide heterogeneous data, applications and services. It is a natural fit, then, for portals to become the main user interface for interacting with Web Services-based business processes, both inside and outside the enterprise. By making business processes more accessible to internal users, customers and trading partners, portals put a "human face" on Web Services. As portal technology proliferates throughout the enterprise and offers increasing functionality to users, portal creators will need to understand the impact that Web Services and underlying standards have on the portal design and development process.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access