|< Day Day Up >|| |
The W3C's Web Services Architecture Working Group has jointly come to agreement on the following working definition of a Web service:
"A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols."
Basic Web services combine the power of two ubiquitous technologies: XML, the universal data description language, and the HTTP transport protocol widely supported by browser and Web servers.
Web services = XML + transport protocol (such as HTTP)
Some of the key features of Web services are the following:
Web services are self-contained.
On the client side, no additional software is required. A programming language with XML and HTTP client support, for example, is enough to get you started. On the server side, merely a Web server and a servlet engine are required. It is possible to Web service enable an existing application without writing a single line of code.
Web services are self-describing.
Neither the client nor the server knows or cares about anything besides the format and content of request and response messages (loosely coupled application integration).
The definition of the message format travels with the message. No external metadata repositories or code generation tools are required.
Web services are modular.
Web services are a technology for deploying and providing access to business functions over the Web; J2EE, CORBA, and other standards are technologies for implementing these Web services.
Web services can be published, located, and invoked across the Web.
The standards required to do so are:
Simple Object Access Protocol (SOAP), also known as service-oriented architecture protocol, an XML-based RPC and messaging protocol
Web Service Description Language (WSDL), a descriptive interface and protocol binding language
Universal Description, Discovery, and Integration (UDDI), a registry mechanism that can be used to look up Web service descriptions
Web services are language independent and interoperable.
The interaction between a service provider and a service requester is designed to be completely platform and language independent. This interaction requires a WSDL document to define the interface and describe the service, along with a network protocol (usually HTTP). Because the service provider and the service requester have no idea what platforms or languages the other is using, interoperability is a given.
Web services are inherently open and standards-based.
XML and HTTP are the technical foundation for Web services. A large part of the Web service technology has been built using open source projects. Therefore, vendor independence and interoperability are realistic goals.
Web services are dynamic.
Dynamic e-business can become a reality using Web services because, with UDDI and WSDL, the Web service description and discovery can be automated.
Web services are composable.
Simple Web services can be aggregated to more complex ones, either using workflow techniques or by calling lower-layer Web services from a Web service implementation.
WebSphere V5.0 provides support for Web services. WebSphere applications can send and receive SOAP messages and also communicate with UDDI registries to publish and find services.
For detailed information on Web services, check out the following:
WebSphere Version 5 Web Services Handbook, SG24-6891
The World Wide Web Consortium (W3C) Web site at:
There are two ways of binding to Web services: static and dynamic.
In the static process, the binding is done at design time. The service requester obtains a service interface and implementation description through a proprietary channel from the service provider (by e-mail, for example), and stores it in a local configuration file. No private, public, or shared UDDI registry is involved.
The dynamic binding occurs at runtime. While the client application is running, it dynamically locates the service using a UDDI registry and then dynamically binds to it using WSDL and SOAP.
This requires that the contents of the UDDI registry be trusted. Currently, only private UDDI networks can provide such control over the contents.
The Apache Web Services Invocation Framework (WSIF) provides a standard Java API to invoke services, no matter how or where the service is provided, as long it is described in WSDL.
WSIF enables the developer to move away from the native APIs of the underlying service, and interact with representations of the services instead. This allows the developer to work with the same programming model regardless of how the service is implemented and accessed.
WSIF is WSDL-driven and provides a uniform interface to invoke services using WSDL documents. So if a SOAP service you are using becomes available as an EJB, for example, you can change to RMI/IIOP by just modifying the WSDL service description, without needing to modify your applications that use the service.
This API is used by tools such as WebSphere Studio Integration Edition and runtimes such as WebSphere Application Server to construct and manipulate services defined in WSDL documents. The architecture allows new bindings to be added at runtime.
WSIF has the following advantages:
Multiple bindings can be offered for services, and bindings can be decided at runtime.
Services can be used either by a set of stub classes (static) or by a dynamic interface invocation (dynamic).
You can switch protocols, location, and so forth, without having to recompile your client code.
For more details on the Web Services Invocation Framework see:
Service-oriented architectures (SOAs) support a programming model that allows service components residing on a network to be published, discovered, and invoked by each other in a platform, network protocol, and language-independent manner.
The origin of SOA can be traced back to Remote Procedure Calls (RPCs), distributed object protocols such as CORBA and Java RMI, and component-based architecture such as J2EE/EJBs (Sun) and (D)COM/COM+/.Net (Microsoft).
Using XML over HTTP, Web services extend the SOA programming model into the global Internet, allowing the publication, deployment, and discovery of service applications over the Internet.
For more information on SOA and Web services, refer to:
This Web site provides a collection of IBM resources on this topic. For example, there is an introduction to the SOA in a white paper titled Web Services Conceptual Architecture (WSCA 1.0).
In April 2002, IBM and Microsoft proposed a technical strategy and roadmap for "addressing security within a Web service environment." The Web services security specifications define a comprehensive Web service security model that supports, integrates, and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner.
The Web services security specification provides a broad set of specifications that cover security technologies, including authentication, authorization, privacy, trust, integrity, confidentiality, secure communications channels, federation, delegation, and auditing across a wide spectrum of application and business topologies. These specifications provide a framework that is extensible and flexible, and that maximizes existing investments in security infrastructure. By leveraging the natural extensibility that is at the core of the Web services model, the specifications build upon foundational technologies such as SOAP, WSDL, XML Digital Signatures, XML Encryption, and SSL/TLS.
As shown in Figure 7-2, this set includes a message security model (WS-Security) that provides the basis for the other security specifications. Layered on this, we have a policy layer that includes a Web service endpoint policy (WS-Policy), a trust model (WS-Trust), and a privacy model (WS-Privacy). Together these initial specifications provide the foundation upon which we can work to establish secure interoperable Web services across trust domains.
Figure 7-2: The evolving WS-Security roadmap
For more information, see the IBM developerWorks® article Security in a Web Services World: A Proposed Architecture and Roadmap:
Web Services Security (WS-Security) Version 1.0 was jointly developed by IBM, Microsoft, and VeriSign, and was released in April 2002. It was submitted to OASIS by 18 companies, and now involves over 50 companies.
WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity and message confidentiality. Also, this specification defines how to attach and include security tokens within SOAP messages. Finally, a mechanism is provided for specifying binary encoded security tokens (for example, X.509 certificates). These mechanisms can be used independently or in combination to accommodate a wide variety of security models and encryption technologies.
For more information, see the IBM developerWorks article Web Services Security (WS-Security):
Web services technology enables businesses to:
Deliver new IT solutions faster and at lower cost by focusing their code development on core business, and using Web services applications for non-core business programming.
Protect their investment in IT legacy systems by using Web services to wrap legacy software systems for integration with modern IT systems.
Integrate their business processes with customers and partners at less cost. Web services make this integration feasible by allowing businesses to share processes without sharing technology. With lower costs, even small business will be able to participate in B2B integration.
Enter new markets and widen their customer base. Web services listed in UDDI registries can be "discovered" and thus are "visible" to the entire Web community.
Some Web services issues to consider are:
Binding to Web services dynamically requires that the contents of the UDDI registry be trusted. Currently, only private UDDI networks can provide such control over the contents.
The SOAP server footprint is significant and the technology is relatively new, so adding the Web service provider stack to existing enterprise systems can be a problem.
There are often comparisons made between CORBA, RMI and SOAP, but such comparisons can be misleading. CORBA and RMI are technologies describing the whole communication process for publishing, finding, and invoking methods on remote objects.
In contrast, SOAP describes only the format of the data exchange for communication. Even the transport protocol is not compulsory. To understand comparisons between these technologies it is important to realize that SOAP does not cover the whole interaction process, as the other technologies do.
There are a lot of articles on the Web describing the pros and cons of using one of these technologies. One aspect worth further consideration is object references. In SOAP Web services there are no object references! This basic characteristic of SOAP has far-reaching consequences for the programming model, for security, and for the coupling strength between requestor and provider. The simplest effect is that parameters in Web services are in-parameters and never in-out-parameters. To return a response value you have to use the return value of the method.
The security impact results from the fact that in the case of CORBA or RMI the client is remotely acting in the address space of the server application. Reference errors can lead to server-side memory access exceptions or data corruption, for example.
Furthermore, in the case of CORBA and RMI the structures of the stub objects are identical to those on the server side. Changing the object structure on the server side needs a refactoring of the clients. In the case of SOAP, no object structures are exposed, except for methods which can have objects as parameters and return values. Changing the object structure on the server side need not lead to a refactoring of the client as a direct consequence.
|< Day Day Up >|| |