Creating a Skeleton enterprise bean (EJB) from a WSDL file using the WebSphere JAX-RPC runtime environment

The web service wizard assists you in creating a skeleton EJB from an existing WSDL document. The skeleton EJB contains a set of methods that correspond to the operations described in the WSDL document. When the EJB is created, each method has a trivial implementation that you replace by editing the bean.

Before you begin

Prerequisites:

About this task

To create a web service and skeleton EJB from a WSDL document:

Procedure

  1. Switch to the Java™ EE perspective (Window > Open Perspective > Java EE).
  2. In the Enterprise Explorer view, select the Web project in which you want to create the skeleton EJB web service.
  3. Click File > New > Other. Select Web Services in order to display the various web service wizards. Select the Web Service wizard. Click Next.
  4. Web Service page: select Top down EJB Web service from the Web service type drop down list. Enter the URI to the WSDL, WSIL, or HTML file that will be used to generate the EJB bean. Ensure that there are no spaces at the beginning of the URI or you may generate a null pointer exception. You can also do the following:
    1. Select the stages of web services development that you want to complete using the slider. This will set several default values on the remaining wizard panels.
      • Develop: this will generate the WSDL definition and implementation of the web service. This includes such tasks as creating the modules which will contain the generated code, WSDL files, deployment descriptors, and Java files when appropriate.
      • Assemble: this ensures the project that will host the web service or client gets associated to an EAR when required by the target application server. Router modules will be created in this stage.
      • Deploy: this will create the deployment code for the service.
      • Install: this will install and configure the Web module and EARs on the target server. If any changes to the endpoints of the WSDL file are required they will be made in this stage.
      • Start: this will start the server once the service has been installed on it.
      • Test: this will provide various options for testing the service, such as using the Generic Services Client, Web Service Explorer or sample JSPs. Note that you can only use the Web Services Explorer to test web services which use HTTP transports.
    2. Select your server: the default server is displayed. If you want to deploy your service to a different server click the link to specify a different server.
    3. Select your runtime environment: the default runtime environment is displayed. If you want to deploy your service to a different runtime environment click the link to specify a different runtime.
    4. Select the service project: the project containing the project selected in your workspace is displayed. To select a different project and EAR click on the project link. Ensure that the project selected as the Client Web Project is different from the Service Web Project, or the service will be overwritten by the client's generated artifacts.
    5. If you want to create a client, select the type of proxy to be generated and repeat the above steps for the client.
    6. Publish the Web service: this will launch the Web Services Explorer to publish your web service to a UDDI registry.
    7. Monitor the Web service: this will send the web service traffic through the TCP/IP Monitor, which allows you to watch the SOAP traffic generated by the web service and to test this traffic for WS-I compliance. Alternately you can manually set up a TCP/IP monitor as described in Using the TCP/IP Monitor to test web services. Note that you can only monitor web services which use HTTP transports. Additionally, if you are routing web service traffic through the TCP/IP monitor you cannot test the web service using the Universal Test Client.
  5. Web Service Skeleton EJB Configuration page:
    1. Select whether you want to use HTTP or JMS binding, and select the Router project.
    2. You can also optionally enable security for the server side of the web service.
    3. Add remote client view: beginning with the EJB 2.1 specification, stateless session beans can include a web service client view, as well as the local and remote views. A web service client view includes a single service endpoint interface.
    4. Define custom mapping for namespace to package: allows you to enter custom mapping pairs
  6. Web Service Namespace to Package Mappings page: The web services wizard generates a number of Java files from the specified WSDL. By default it will create package names based on the namespaces specified in the WSDL file. To override this default behavior you can specify your own package names for some or all of the namespaces in the WSDL file. If you selected Define custom mapping for namespace to package on the previous page, you can enter your custom mapping pairs on this page by clicking Add. Alternately, you can click Import to import custom mapping pairs from a .properties file. The content of the properties file must be of the format namespace=package . You will need to escape some special characters in the properties files. For example http://someNamespace=somePackage should be http\://someNamespace=somePackage. Otherwise, the colon (:) would be treated as delimiter resulting in trying to map http to //someNamespace=somePackage. For more information about formats for properties files in Java, refer to: Java Platform API documentation: java.util.Properties load method.
  7. Web Service Test page: If you want to test your web service in the Web Services Explorer or Generic Services Client click Launch. Select the operation you want to test, enter the required information, and click Go. The result will display in the Status pane.
  8. Web Service Proxy page: select if you want to generate a proxy, and select whether or not to enable security for this proxy. You can optionally select to enter custom namespace to package mappings.
  9. Web Service Client Namespace to Package Mappings page: if you selected Define custom mapping for namespace to package on the previous page, you can enter your custom mapping pairs on this page by clicking Add. Alternately, you can click Import to import custom mapping pairs from a .properties file. The content of the properties file must be of the format namespace=package. You will need to escape some special characters in the properties files. For example http://someNamespace=somePackage should be http\://someNamespace=somePackage. Otherwise, the colon (:) would be treated as delimiter resulting in trying to map http to //someNamespace=somePackage. For more information about formats for properties files in Java, refer to: Java Platform API documentation: java.util.Properties load method.
  10. Web Service Client Test page: Use this page to select the following options:
    • Select your test facility. You can test the generated proxy in the Universal Test Client or the Web Service Explorer, or you can generate a sample web service JSP. Note that if you are routing web service traffic through the TCP/IP monitor that you cannot test the web service using the Universal Test Client.
    • If you selected to test the proxy through a JSP, you can select the folder where the JSP will be located, and you can select the methods that will be included in the JSP.
  11. Web Service Publication page: Select whether or not you want to publish this web service to a UDDI registry. Click Finish.

Results

After the web service has been created, the following may occur depending on the options you selected:

For more information on EJBs, refer to the EJB application development documentation.

What to do next

Important: When creating a skeleton EJB from a WSDL file, no JNDI name is generated for the newly created EJB. When this EJB is run in the Unit Test Environment, a warning with code WSVR0038I is displayed in the console, saying "No JNDI name found for the EJB, a default binding name based on the home interface will be used." This error does not impact your web service. Use the J2EE tooling to assign a JNDI name to the EJB to avoid this problem.

Feedback