+

Search Tips   |   Advanced Search

Task overview: Implement web services applications

IBM WAS supports JAX-WS and JAX-RPC. JAX-WS is the next generation web services programming model extending the foundation provided by JAX-RPC. Using the strategic JAX-WS programming model, development of web services and clients is simplified through support of a standards-based annotations model.

Implement web services applications is an way to integrate application systems together within or outside our business infrastructure that function as stand-alone systems. For example, our customer information database is a stand-alone application, but we want our accounting application to access the customer data. 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, we 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.

Use web services applications with the application server by following the steps provided:


Tasks

  1. Plan to use web services. Review all the components of web services to learn how we can make our Web services plan more robust.
  2. (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.

    Existing JAX-RPC applications wanting to use JAX-WS features must be rewritten using JAX-WS.

    If we have used web services based on Apache SOAP and now want to develop and implement Web Services for Java EE specification, we 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.

  3. Develop web services applications. We can develop web services in one of the following ways:

    1. Develop web services from existing WSDL files using JAX-WS.

      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.

    2. Develop web services applications using JAX-WS.

      Use JAX-WS 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.

      v9.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, we can expose the bean as a JAX-WS web service using annotations. Adding the @WebService or @WebServiceProvider annotation to the bean defines the bean as a JAX-WS web service. Enterprise beans 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 we are starting with the implementation rather than starting with an existing service or Web Services Description Language (WSDL) file.

    3. 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 EE specification. The application server supports Enterprise JavaBeans™ (EJB) clients, Java EE application clients, JavaServer Pages (JSP) files and servlets that are based on JAX-WS.
    4. Develop Web services applications from existing WSDL files with JAX-RPC.

      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.

    5. Develop web services applications with JAX-RPC.

      Use JAX-RPC to develop web services. When developing a JAX-RPC web service starting from existing JavaBeans or enterprise beans, we need develop a WSDL file. Use existing JavaBeans or enterprise beans and then enable the implementation for web services.

    6. Develop and deploy JAX-RPC web services clients We can develop web services clients based on the Web Services for Java EE specification and the JAX-RPC specification. The application server supports Enterprise JavaBeans™ (EJB) clients, Java EE application clients, JSP files and servlets that are based on the JAX-RPC programming model.
    7. Enable web services through service integration technologies

      Use the web services enablement of the service integration bus to achieve the following goals:

      • Make an internally hosted service 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 provided by the gateway.

    We 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.

      We 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, we 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 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.

  4. Assemble web services.

    Read about what we need to assemble a web service and the order in which to assemble the parts, for example an EAR file.

  5. Deploy Web services.

    Read about the steps necessary to deploy the EAR file configured and enabled for web services.

  6. Administer deployed web services.

    Once our web services application is deployed, we 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.

  7. Secure web services.

  8. Publish the WSDL file.

    After installing a web services application, and optionally modifying the endpoint information, we might need WSDL files containing the updated endpoint information. Read about the steps necessary to publish the WSDL files so that this information is available.

  9. 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.

  10. 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 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 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.

Use 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.


Related:

  • Service-oriented architecture
  • Web services
  • Web Services for Java EE specification
  • JAX-RPC
  • WSDL
  • JAX-WS
  • JAXB
  • SOAP
  • SOAP with Attachments API for Java interface
  • Message Transmission Optimization Mechanism
  • Overview: Online garden retailer web services scenarios
  • WS-I Basic Profile
  • RMI-IIOP using JAX-RPC
  • WS-I Attachments Profile
  • Overview of standards and programming models for web services message-level security
  • Web services approach to a service-oriented architecture
  • Web services business models supported in SOA
  • Planning to use web services
  • Migrate Apache SOAP web services to JAX-RPC web services based on Java EE standards
  • Implement web services applications with JAX-WS
  • Implement web services applications from existing WSDL files with JAX-WS
  • Implement static JAX-WS web services clients
  • Use JAXB for XML data binding
  • Use handlers in JAX-WS web services
  • Running an unmanaged web services JAX-WS client
  • Implement web services applications with JAX-RPC
  • Implement web services applications from existing WSDL files with JAX-RPC
  • Implement JAX-RPC web services clients
  • Running an unmanaged web services JAX-RPC client
  • Use HTTP to transport web services
  • Use SOAP over JMS to transport web services
  • Developing applications that use Web Services Addressing
  • Create stateful web services using the Web Services Resource Framework
  • Add assured delivery to web services through WS-ReliableMessaging
  • Use WS-Transaction policy to coordinate transactions or business activities for web services
  • Use WS-Policy to exchange policies in a standard format
  • Assembling web services applications
  • Deploy web services applications onto application servers
  • Administer deployed web services applications
  • Making deployed web services applications available to clients
  • Create a monitor for WAS for WSDM resources (deprecated)
  • Secure web services applications at the transport level
  • Authenticating web services clients using HTTP basic authentication
  • Manage policy sets
  • Testing web services-enabled clients
  • Monitoring the performance of web services applications
  • Tune Web Services Security for v9.0 applications
  • Configure the Kerberos token for Web Services Security
  • Troubleshoot web services
  • Example: Installing a web services sample with the console
  • Enable web services through the service integration bus
  • Use WS-Notification for publish and subscribe messaging for web services
  • Web services migration scenarios: JAX-RPC to JAX-WS and JAXB
  • Web services migration best practices
  • IBM proprietary SOAP over JMS protocol (deprecated)
  • Programming model APIs and specifications
  • WAS roles and goals
  • Web services hints and tips: JAX-RPC vs JAX-WS
  • Web services hints and tips: JAX-RPC vs JAX-WS Part 2