Use this topic as an introduction to using web services. WebSphere® Application Server supports Web services that are developed and
implemented based on various Java™ programming models. Use web services when operating across multiple
platforms, including Java Platform, Enterprise Edition (Java EE) and non-Java EE
platforms.
Before you begin
Decide if a web services implementation benefits your business process.
About this task
Best practice: IBM®
WebSphere Application Server supports the Java API for XML-Based Web Services (JAX-WS) programming model and
the Java API for XML-based RPC (JAX-RPC) programming model.
JAX-WS is the next generation web services programming model extending the foundation provided by
the JAX-RPC programming model. Using the strategic JAX-WS programming model, development of web
services and clients is simplified through support of a standards-based annotations model. Although
the JAX-RPC programming model and applications are still supported, take advantage of the
easy-to-implement JAX-WS programming model to develop new web services applications and clients.best-practices
For a complete list of the supported standards and specifications, see
the web services specifications and API documentation.
Implementing web services applications
is an easy way to integrate application systems together within or outside your business
infrastructure that function as stand-alone systems. For example, your customer information database
is a stand-alone application, but you want your accounting application to access the customer data.
You can create a web service for the customer database and then enable the accounting application as
a web service client. The accounting application can now access the customer information. By
implementing a web service, these two applications can share information in an efficient
way.
Because web services are easily applied to existing applications and information
technology assets, you can develop, deploy, and recompose new solutions quickly to address new
opportunities. As web services become more popular, the pool of services grows, promoting
development of more robust models of just-in-time application and business integration over the
Internet.
You can use web services applications with the application server by following the
steps provided:
Procedure
- Plan to use web services. Review all the
components of web services to learn how you can make your Web services plan more robust.
- (Optional) Migrate
existing web services.
Because Java EE environments emphasize compatibility, most application servers that offer support
for the newer JAX-WS and JAXB specifications continue to support the older JAX-RPC specification. A
consequence of this is that, existing web services are likely to remain JAX-RPC based while new ones
are developed using JAX-WS and JAXB.
However, as time passes and applications are revised and rewritten, there might be times when the
best strategy is to migrate a JAX-RPC based web service to one based on JAX-WS and JAXB. This might
result from a vendor choosing to provide enhancements to qualities of service that are only
available in the new programming models. For example, SOAP 1.2 and SOAP Message Transmission
Optimization Mechanism (MTOM) support are only available within the JAX-WS 2.x and JAXB 2.x
programming models and not JAX-RPC. Read about web services migration best practices to learn more
about best practices and examples when migrating JAX-RPC web services to JAX-WS and JAXB web
services.
Note: Existing JAX-RPC applications wanting to use JAX-WS features must be rewritten using the
JAX-WS programming model.
If you have used web services based on Apache SOAP and now want to develop and implement Web
Services for Java EE specification, you need to migrate client applications developed with all
versions of 4.0, and versions of 5.0 before 5.0.2. To learn more, see the migrating Apache SOAP web
services to JAX-RPC web services based on Java EE standards information.
- Develop web services applications. You can develop web services in one of the following ways:
- Develop web services from existing WSDL
files using JAX-WS.
You can create a JAX-WS web service by starting with an existing Web Services Description
Language (WSDL) file describing the service interface for a JavaBeans or enterprise
beans application. Typically, the WSDL file is defined as part of the application modeling process.
Using an existing service definition or WSDL file to generate a new application is called a top-down
approach to developing Web services.
- Develop web services applications using
JAX-WS.
You can use the Java API for XML-Based Web Services (JAX-WS) programming model to develop web
services. JAX-WS simplifies application development through a standard, annotation-based model to
develop web services applications and clients. A common set of binding rules for XML and Java objects
make it easy to incorporate XML data and process functions in Java applications. A further set
of enhancements help you optimally send binary attachments, such as images or files, with the web
services requests.
Version 9.0 includes support for singleton session
enterprise beans as JAX-WS endpoints. Singleton session beans are useful in situations where a
single instance of a web services endpoint implementation bean is needed to process all requests
that are received for a particular web services endpoint. Perhaps, the single instance of the bean
needs to share state information across requests. Typically, a new instance of a web services
endpoint implementation bean is created to process each request.
When developing a JAX-WS Web service starting from existing JavaBeans or from stateless
or singleton session enterprise beans, you can expose the bean as a JAX-WS web service by using
annotations. Adding the @WebService or @WebServiceProvider annotation to the bean defines the bean
as a JAX-WS web service. Enterprise beans that are exposed as JAX-WS web services must be packaged
in EJB 3.0 or higher modules.
Transforming an existing application into web services is called a bottoms-up approach to
developing web services. This process is called bottoms-up because you are starting with the
implementation rather than starting with an existing service or Web Services Description Language
(WSDL) file.
- Develop and deploy JAX-WS web services
clients. Web services clients that can both access and invoke JAX-WS web services are developed based
on the Web Services for Java Platform, Enterprise Edition (Java EE) specification. The application
server supports Enterprise JavaBeans™ (EJB) clients, Java EE application clients, JavaServer Pages
(JSP) files and servlets that are based on the JAX-WS programming model.
- Develop Web services applications from existing WSDL
files with JAX-RPC.
You can create a JAX-RPC web service by starting with an existing WSDL file describing the
service interface of an enterprise bean implementation using a top-down approach to developing web
services.
- Develop web services applications with
JAX-RPC.
You can use the Java API for XML-based RPC (JAX-RPC) programming model to develop web
services. When developing a JAX-RPC web service starting from existing JavaBeans or enterprise
beans, you need develop a WSDL file. You can use existing JavaBeans or enterprise
beans and then enable the implementation for web services.
- Develop and deploy JAX-RPC web services
clients You can develop web services clients based on the Web Services for Java Platform, Enterprise
Edition (Java EE) specification and the Java API for XML-based remote procedure call (JAX-RPC)
specification. The application server supports Enterprise JavaBeans™ (EJB) clients, Java EE
application clients, JavaServer Pages (JSP) files and servlets that are based on the JAX-RPC
programming model.
- Enable web services through service
integration technologies
You can use the web services enablement of the service integration bus to achieve the following goals:
- Make an internally hosted service that is available at a bus destination available as a web
service.
- Make an external web service available internally at a bus destination.
- Use the web services gateway to map an existing service, either an
internally-hosted service or an external web service, to a new web service that is provided by the
gateway.
You can develop web services to take advantage of Web Services Addressing (WS-Addressing), Web
Services Resource Framework (WSRF), and Web Services Transaction (WS-Transaction) support.
- Use the WS-Addressing SPI: Performing more advanced Web
Services Addressing tasks.
You can develop web services to take advantage of Web Services
Addressing (WS-Addressing), which aids interoperability between web services using a standard way to
address web services and providing addressing information in messages.
- Create stateful web services using the Web Services
Resource Framework.
With the Web Services Resource Framework (WSRF) support in the
application server, you can implement a stateful web service as a WS-Resource, and reference that
service it using a WS-Addressing endpoint reference.
- Use WS-Transaction policy to coordinate transactions
or business activities for web services.
WS-Transaction is an interoperability standard
that includes the WS-AtomicTransaction, WS-BusinessActivity, and WS-Coordination specifications. The Web Services Atomic Transaction (WS-AT) support in the application
server provides transactional quality of service to the web services environment. Distributed web
services applications, and the resources they use, can take part in distributed global
transactions.
With Web Services Business Activity (WS-BA)
support in the application server, web services on different systems
can coordinate activities that are more loosely coupled than atomic
transactions. Such activities can be difficult or impossible to roll
back atomically, and therefore require a compensation process if an
error occurs.
- Use WS-Policy to exchange policies in a standard
format.
WS-Policy is an interoperability
standard that is used to describe and communicate the policies of
a web service so that service providers can export policy requirements
in a standard format. Clients can combine the service provider requirements
with their own capabilities to establish the policies required for
a specific interaction.
- Assemble web services.
Read about what you need to assemble a web service and the order in which to assemble the parts,
for example an enterprise archive (EAR) file.
- Deploy Web services.
Read about the steps necessary to deploy the EAR file that has been configured and enabled for
web services.
- Administer deployed web services.
Once your web services application is deployed, you can configure security settings, view
deployment descriptors and WSDL documents, set the scope of a Web service port, and manage policy
sets and service providers. These tasks can be done using the administrative console or with
command-line tools.
- Secure web services.
- Publish the WSDL file.
After installing a web services application, and optionally modifying the endpoint information,
you might need Web Services Description Language (WSDL) files containing the updated endpoint
information. Read about the steps necessary to publish the WSDL files so that this information is
available.
- Monitor the performance of web services
applications.
Read about using the Performance Monitoring Infrastructure (PMI) to measure the time required to
process web services requests.
- Troubleshoot web services.
Read about troubleshooting different processes used to develop, implement and use web services,
including command-line tools, Java compiling errors, client runtime errors and exceptions, serialization and
deserialization errors, and authentication challenges and authorization failures with Web Services
Security.
Example
The following example illustrates how a business might use web services.
The
owner of a flower shop wants to start receiving orders from customers through the Web. This owner
starts the process by finding wholesale flower suppliers, pricing the product, and completing
contracts for future flower orders.
Using web services, the flower shop owner can find wholesale
flower suppliers. One way to find new suppliers is to use a Universal Description, Discovery and
Integration (UDDI) registry to search for potential suppliers. When the suppliers are chosen, the
registry sends back information about how to contact the flower distributors that meet the criteria
of the flower shop owner.
The flower shop owner can request price lists from each of the
suppliers by obtaining a WSDL file for each potential supplier. The WSDL can be downloaded from the
web page of the supplier, received through email, or retrieved from the UDDI registry entry of the
supplier.
The WSDL describes the procedure call. When using the application server, the
procedure call is a JAX-RPC or a JAX-WS procedure call. Either of these procedure call types
retrieves the price list. The WSDL file also specifies the Universal Resource Locator (URL), where
the request is sent.
The flower shop owner now has to compare the prices received from each
supplier, decide which suppliers to do business with, and make arrangements for future orders to
fill. The flower shop can now sell merchandise through the web by using web services to communicate
with suppliers for the best prices and complete the ordering processes. The merchandise price lists
need publishing to the website and a mechanism is needed for customers to order flowers.
The
web services clients of the flower supplier are deployed on the flower shop server. When a customer
makes a transaction to purchase flowers through the Web, the order is sent to the supplier through
the procedure call. The supplier responds by sending a confirmation with the order number and
shipping date. The suppliers maintain the inventory and the flower shop owner handles billing and
customer order management.
Similarly, the flower shop catalog can be composed automatically
from the catalogs of each supplier. If the supplier delivers directly to the customer, then the
order tracking inquiries can pass directly to the order tracking system of the supplier. The
supplier can also use web services to send invoices for orders by the flower shop. Processes that
previously required forms to fill manually, and fax or mail, can now be done automatically, saving
labor costs for both the flower shop and the supplier.
Using web services is beneficial
because a much larger inventory is made available to the flower shop. No merchandise maintenance
overhead exists, and the flower shop can offer their customers products that they otherwise might
not have. Selling flowers through the web increases capital for the flower shop without overhead of
another store or resources invested into additional products.
For a more detailed scenario,
see the information for the web services scenario overview which tells the story of a fictional
online garden supply retailer, Plants by WebSphere, and how they incorporated the web services
concept.
Refer to the Samples section of the Information Center for additional Samples that
demonstrate JAX-WS and JAX-RPC web services.