Welcome to Web services
Web services are services that you use over the Internet. 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. Used in this manner, Web services can be defined as middleware.
You can connect applications together no matter how each application is implemented
or where it is located.
Middleware is not new, but what is new is Web services technology and its
power to connect by using open standards. 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.
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 run-time architecture for implementing Web
services based on the Java language. WebSphere Application Server Version
5.0.2 and 5.1 supports Web Services for J2EE Version 1.0. 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 5.0.2 and 5.1 supports JAX-RPC Version 1.0.
- 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
5.0.2 and 5.1 supports WSDL Version 1.1.
- SOAP (Simple Object
Access Protocol). SOAP is the core communications protocol for the Web, and
most Web services use this protocol to talk to each other. WebSphere Application
Server Version 5.0.2 and 5.1 supports SOAP Version 1.1.
- 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 5.0.2 and 5.1 supports
SAAJ Version 1.1.
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 - as it needs to be 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.
- You publish your Web service to UDDI after you
have deployed it to the application server - unless you are also using the
Web services gateway, in which case you use the gateway to publish the service
to UDDI.
- 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 - unless you are also using
the Web services gateway, in which case the gateway automatically redeploys
your Web service as a WSIF-enabled service.
- A Web services gateway
- You use the gateway to handle Web service invocations between Internet
and Intranet environments. You use it to make your internal Web services available
externally, and to make external Web services available to your internal systems.
You also use it to specify:
- The transport mechanisms (or channels) on which messages can be carried
to and from the service.
- The filters or handlers (if any) that act upon these incoming and outgoing
messages.
- The UDDI registries (if any) to which you want the service to be published
- The levels of security that you want to apply to the service.
- When you deploy a Web service to the gateway, the gateway creates a copy
of the WSDL file for that service and stores it at a new Web address. Users
of the service through the gateway then use the gateway copy of the WSDL file.
You should therefore (if possible) decide whether or not you want to use the
gateway before you make the Web addresses of your deployed services available
to others.
Searchable topic ID:
welcwebsvcs
Last updated: Jun 21, 2007 4:55:42 PM CDT
WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welcwebsvcs.html