The developerWorks web services content area contains literally hundreds of articles, tutorials, and tips to help a developer make the most of web services-related applications; but for users trying to find their way in a new topic, all of that information can be overwhelming. This page provides an overview for readers who would like to learn about web services but don't know where to start. It places all of the basics of web services technology into their proper context and ties together relevant developerWorks articles, tutorials and tips, IBM learning services education, webcasts, workshops, and IBM products for further investigation.

Web services is a technology that allows applications to communicate with each other in a platform- and programming language-independent manner. A web service is a software interface that describes a collection of operations that can be accessed over the network through standardized XML messaging. It uses protocols based on the XML language to describe an operation to execute or data to exchange with another web service. A group of web services interacting together in this manner defines a particular web service application in a Service-Oriented Architecture (SOA).

The software industry is finally coming to terms with the fact that integrating software applications across multiple operating systems, programming languages, and hardware platforms is not something that can be solved by any one particular proprietary environment. Traditionally, the problem has been one of tight-coupling, where one application that calls a remote network is tied strongly to it by the function call it makes and the parameters it requests. In most systems before web services, this is a fixed interface with little flexibility or adaptability to changing environments or needs.

Web services uses XML that can describe any and all data in a truly platform-independent manner for exchange across systems, thus moving towards loosely-coupled applications. Furthermore, web services can function on a more abstract level that can reevaluate, modify or handle data types dynamically on demand. So, on a technical level, web services can handle data much easier and allow software to communicate more freely.

On a higher conceptual level, we can look at web services as units of work, each handling a specific functional task. One step above this, the tasks can be combined into business-oriented tasks to handle particular business operational tasks, and this in turn allows non-technical people to think of applications that can handle business issues together in a workflow of web services applications. Thus, once the web services are designed and built by technical people, business process architects can aggregate them into solving business level problems. To borrow a car engine analogy, a business process architect can think of putting together a whole car engine with the car frame, body, transmission, and other systems, rather than look at the many pieces within each engine. Furthermore, the dynamic platform means that the engine can work together with the transmission or parts from other car manufacturers.

What rises from this last aspect is that web services are helping to bridge the gap between business people and technologists in an organization. web services make it easier for business people to understand technical operations. Business people can describe events and activities and technologists can associate them with appropriate services.

With universally defined interfaces and well designed tasks, it also becomes easier to reuse these tasks and thus, the applications they represent. Reusability of application software means a better return on investment on software because it can produce more from the same resources. It allows business people to consider using an existing application in a new way or offering it to a partner in a new way, thus potentially increasing the business transactions between partners.

Therefore, the primary issues that web services tries to tackle are the issues of data and application integration, and that of transforming technical functions into business-oriented computing tasks. These two facets allow businesses to communicate on a process or application level with their partners, while leaving dynamic room to adapt to new situations or work with different partners on demand.

Learn more about it

  • To learn about web services, you should first know how XML, the Extensible Markup Language, works. Introduction to XML is a good article to start with. While web services technology itself is language-independent there are many more tools and software implementations available in Java technology.

What can I do with web services?

While web services allows all these dynamic features to combine multiple services into applications, you still have to build the services first. Programming languages in Computer science is continually evolving. We began decades ago with the idea of a function whereby you provide it some parameters, it executes some operation on those parameters, and it returns a value based on its calculations. Eventually, this first concept evolved into the object where each object had not just a number of functions it can perform but also its own private data variables, rather than relying on external system-wide data variables that previously made it more complex to develop applications. As applications began communicating with each other, the concept of defined universal interfaces for objects became important, allowing objects on other platforms to communicate even if they were written in other programming languages and ran on other operating systems.

At the most recent step, web services has moved towards the concept of XML-defined interfaces and communications, finally uniting any kind of application with another, as well as providing the freedom to change and evolve over time, as long as they are designed to the appropriate interface. The versatility of XML is what makes web services different from previous generation component technologies. It allows the separation of grammatical structure (syntax) and the grammatical meaning (semantics), and how that is processed and understood by each service and the environment it exists in. So now, objects can be defined as services, communicating with other services in XML-defined grammar, whereby each service then translates and analyzes the message according to its local implementation and environment. Thus a networked application can truly be composed of multiple entities of various makes and designs as long as they conform to the rules defined by their service oriented architecture.

Thus, with this in mind, web services allow you to:

  • Interact between services on any platform, written in any language.
  • Conceptualize application functions into task, leading to task-oriented development and workflows. This allows a higher abstraction of software that can be employed by less software-technical users that work on business level analytics.
  • Allow for loose-coupling, which means that interactions between service applications may not break each time there is a change in how one or more services are designed or implemented.
  • Adapt existing applications to changing business conditions and customer needs.
  • Provide existing or legacy software applications with service interfaces without changing the original applications, allowing them to fully operate in the service environment.
  • Introduce other administrative or operations management functions such as reliability, accountability, security, etc., independent of the original function, thus increasing its versatility and usefulness in the business computing environment.

Learn more about it

What are web services' component technologies?

Web services involves a family of related protocols to describe, deliver, and interact with services. This family can be further subdivided into groupings based on common functions and uses. The first group handles the issues of messaging, interface description, addressing and delivery. The most well-known is the messaging protocol known as Simple Object Access Protocol (SOAP). This protocol encodes messages so they can be delivered over the network using a transport protocol such as HTTP, IIOP, SMTP, or others.

The web Services Description Language (WSDL) is represented as a series of XML statements that constitute the definition for the interfaces of each service. Another specification currently in progress is WS-Addressing that defines how to uniquely address and identify web services in a distributed architecture. Another popular specification is the Web Services Invocation Framework, where you can define WSDL interfaces for any type of component even those that do not use the same messaging protocols.

The next group of protocols and specifications define how services advertise themselves and can find each other on the network. For services to locate each other, the Universal Description, Discovery and Integration (UDDI) protocol defines a registry and associated protocols for locating and accessing services. The Web Services Inspection Language is an alternative mechanism to UDDI that works without the use of a registry.

The Security protocols for web services begin with the WS-Security specification that defines a token based architecture for secure communications. Built on this base, there are six major component specifications:

  • WS-Policy and its related specifications that define the policy rules on how services interact.
  • WS-Trust that defines the trust model for secure exchange.
  • WS-Privacy that defines how privacy of information is maintained.
  • WS-Secure Conversation that defines how to establish a secured session between services for exchanging data using the rules defined in WS-Policy, WS-Trust, and WS-Privacy.
  • WS-Federation that defines the rules of distributed identity and how its managed.
  • WS-Authorization that handles the processing for authorization to access and exchange data.

Beyond the Security model are the application specific specifications including the Business Process Execution Language for Web Services (BPEL4WS) defines workflow operations, and WS-Transaction and WS-Coordination that work together to handle distributed transactional processing.

Currently in the works is a specification for Web Services Distributed Management for software administrative management of all services and the service-oriented architecture. Finally there are specifications for user interfaces (WS-InteractiveApplications) and remote access of Web services (WS-RemotePortals).

The specifications and protocols for web services are still being defined at the time of writing and only begin to explain how services should interact with each other. However, they cannot cover every single scenario and combination possible. Thus, the Web Services Interoperability Group (WS-I) consisting of members from practically all major and minor vendors involved in web services development, has taken on the task of developing case studies, sample applications, implementation scenarios, and test tools to ensure that these standards and specifications will truly work with each other irrespective of vendor product implementations.

WS-I has defined their first Basic Profile 1.0 for web services as well as released their Scenarios, Sample Applications and Test Tools to evaluate and compare results of various implementations according to the Scenarios.

In addition to the WS-I a significant amount of the standards work is being developed by the Organization for the Advancement of Structured Information Standards (OASIS), the World Wide Web Consortium (W3C), and the Internet Engineering Task Force (IETF).

Learn more about it

How does web services relate to other technologies?

Web services is primarily an integration technology. However, it is independent of form in itself. The component technologies for web services are commonly defined and interact in XML, as mentioned earlier. However, since XML itself is language independent, so is web services. Thus web services can be developed in a number of programming languages including Java, Python, Perl, C#, Basic, and others.

The origins of web services lie in trying to find a better way for the architecture of Internet and web applications to better communicate and interact with each other. Thus, most web services today are based on programs that run on application server environments like WebSphere, Apache, and others. They are not required to but some of the best web services tools are designed for such environments.

By providing simpler, universal interfaces, web services is also helping to improve how the pervasive computing model works for mobile and portable environments. Software for mobile computing is quickly adopting the web services model of communicating while also helping to improve the interface issues of visual web services.

Grid computing has adopted web services as part of the Open Grid Services Architecture, a new model for this type of distributed computing that uses web services to communicate how the grid operates.

Even Autonomic computing which is an interesting new way to how computers can maintain and manage themselves has some applications for Web services.

Learn more about it

How can I use web services in an application?

There are several ways to think about web services when building applications. At the most basic level it is an advanced communications protocol family allowing applications to talk to each other. This level has progressed quite significantly over the past few years with many tools that allow software developers to write interacting web services and build complex applications. This level is often characterized by direct one-on-one interactions between services or relatively few services interacting with each other.

However, just using web services as a communications protocol belies its true power, that of the service-oriented architecture (SOA). The SOA describes an entire system of services dynamically looking around for each other, getting together to perform some application, and recombining in many ways. This model encourages the reuse of technology and software that evolves the way applications are designed, developed and put to use. It brings the world of distributed computing to a closer reality. At this level software developers need to think of the SOA model and design their distributed application across the model. This level is characterized by the use of technologies to allow distributed communications of services such as the use of an Enterprise Service Bus (ESB), which is a common distribution network for services to work with.

Finally, the highest level is to look at this SOA model and the many component services as building blocks, that can be assembled in whole sections into full applications instead of the traditional method of writing line after line of code. By examining the connecting interfaces, we can build whole applications without ever really writing code. For that matter direct code may even get in the way since the services may be written in numerous different languages and platforms. The blocks can be put together into a workflow of operations that define how the application performs, and other tools can be used to monitor the effectives of the workflow at each service or group of services. At this level, developers can put away the use of regular programming languages and work in a Model-Driven Architecture that helps them to build applications more accurately to a design. This design then runs on top of a distributed system like an ESB.

Learn more about it

  • To learn more about workflow and business process with web services you should read about the BPEL4WS specification in the BPEL4WS column written by some of the specification authors.

How can I improve my web services skills?

The best way to keep up with web services is to read the latest technical articles and work with the various tools that are available for it. Since the technology itself is evolving, this information and these tools provide the latest interpretations of the best ways to work with web services. Additionally, toolkits like the Emerging Technology Toolkit, leap a few steps ahead into the cutting edge of these technologies to allow you to experiment on the same technologies that the experts are working on. These tools are described in the next section.

Currently, web services has been progressing significantly and the diversity of information on this topic is exploding. There is a significant amount of technical content on the first level of developing web services for direct interaction that can be found on the web services site. Even protocols like SOAP which have been around for over three years are still being improved on. Since this topic is a moving target, it is useful to come back to web services content area on a regular basis.

Another good way of improving your skills is to participate in the discussion forums directly listed on the zone. Here you can find the practitioners who are actively working in this area, and even help directly from the research and development staff that are designing the technologies and building the products.

For the advanced developers, you can participate in the development and evolution of the web services specifications themselves by participating the various workshops that occur monthly.

Learn more about it

  • The web services area regularly adds new tutorials that explain how to perform useful tasks in web services in detail.
  • The Best Practices for web services column on developerWorks examines the real world situations that team members from the IBM JStart program for early technology implementation are encountering along their path to successful project implementation. Learning these best practices can help you assess and adapt to your own project situation.