Web services are a technology that invokes services or applications
using Internet standards and protocols. You can read this topic to learn about
the core technologies on which Web services are developed and implemented.
If you have an existing application, and you want to make the service that
your application provides available to others - either within your own organization
or beyond it - you can use Web services technologies to provide a standard
Web interface for your service. Web services can be defined as middleware
that connects applications together no matter how each application is implemented
or where it is located.
Web services operate at a level of abstraction that is similar to the Internet;
they can work with any operating system, hardware platform or programming
language that can be Web-enabled and are one of the technologies that you
can use to implement a service-oriented architecture (SOA).
The core technologies on which Web services are developed and implemented
include:
- XML (Extensible
Markup Language). XML solves the problem of data independence. You use it
to describe data, and also to map that data into and out of any application
or programming language.
- Web Services for Java 2 platform,
Enterprise Edition (J2EE) specification defines the programming model
and runtime architecture for implementing Web services based on the Java language.
WebSphere Application Server Version 6.0 is supports Web Services for J2EE
Version 1.1.
If you want to know how to implement a Web service interface
to an existing application, then deploy your Web service within the application
server, see Using Web services based
on Web Services for J2EE.
- Java API for XML-Based RPC
(JAX-RPC) enables you to develop SOAP-based interoperable and portable
Web services and Web services clients. WebSphere Application Server Version
6.0 supports JAX-RPC Version 1.1.
- WSDL (Web Services Description Language).
You use this XML-based language to create a description of an underlying application.
It is this description that turns an application into a Web service, by acting
as the interface between the underlying application and other Web-enabled
applications. WebSphere Application Server Version 6.0 and later supports
WSDL Version 1.1.
- SOAP is the core communications protocol
for the Web, and most Web services use this protocol to talk to each other.
- SOAP
with attachments API for Java (SAAJ) is used for SOAP messaging that
works behind the scenes in the Java API for XML-based RPC (JAX-RPC) implementation.
You can also use this API to directly write SOAP messaging applications rather
than using JAX-RPC. SAAJ allows you to do XML messaging from the Java platform
by making method calls by creating, sending and consuming XML messages over
the Internet. WebSphere Application Server Version 6.0 and later supports
SAAJ Version 1.2.
WebSphere Application Server also provides other mechanisms that can help
you get the most out of your Web services:
- A private Universal Description,
Discovery and Integration (UDDI) registry
- A private UDDI registry provides a way to publish and discover information
about Web services that are available within and through your organization.
You can use it to make your Web services available to people within your organization,
or beyond your organization. A group of companies can use it to share their
Web services, or to make them available to others outside the group. At its
simplest, a private UDDI registry does for Web services what a business telephone
directory does for business addresses and telephone numbers. However, a private
UDDI registry is much more than just a directory. It needs to be in order
to harness the considerable power and flexibility of Web services. If you
publish your Web service to UDDI, you make it available for other people or
applications to discover and reuse. This saves development time, effort and
cost, and helps minimize the need to maintain several different implementations
of the same application.
- A Web Services Invocation Framework
(WSIF)
- SOAP bindings for Web services are part of the WSDL specification. So
when you think of using a Web service, you probably think of assembling a
SOAP message and sending it across the network to the service endpoint, using
some SOAP client API. The WSDL specification allows for extensibility points
which can describe alternate ways of invoking a Web service. A WSIF client
can make use of these non-SOAP descriptions to invoke a service in a more
efficient way. For example, a Web service provider might offer a SOAP binding
for the service and a local Java binding that allows you to treat the local
service implementation (a Java class) as a Web service. If the client is deployed
in the same environment as the service, then the local Java binding for the
service can be used. This provides more efficient communication with the service
by making direct Java calls rather than sending and receiving SOAP messages.
- To deploy a Web service as a WSIF-enabled service, you first develop and
deploy the Web service, then you develop the WSIF client based on the WSDL
document for that Web service.
- Web services and service integration technologies
Web
services can use the service integration bus and the Web services gateway
to provide a single point of control, access, and validation of Web service
requests and to allow control of Web services that are available to different
groups of Web service users.
With service integration bus-enabled Web
services, you can achieve the following goals:
- Take an internally-hosted service that is available at a bus destination,
and make it available as a Web service.
- Take an externally-hosted Web service, and make it available internally
at a bus destination.
- Use the Web services
gateway to map an existing service - either an internal service, or an external
Web service - to a new Web service that appears to be provided by the gateway.
For more information, see Enabling Web services through service integration technologies.