| Building Web Services |    
|
| Building Web Services |
|
| C H A P T E R 2 |
|
Building a Web Service |
This chapter describes the tools and procedures that you can use to develop a web service. The procedures assume that you have available a business component, such as an enterprise bean, whose methods you want to expose in the web service.
The following tasks are interdependent but not strictly sequential. For example, you can add a method reference while creating a web service or afterward. Web service development is an iterative process.
There are two approaches to developing a web service. In the bottom-up approach, you use the IDE to build the web service by adding method references from an existing business component such as an enterprise bean. In the top-down approach, you use the IDE to generate both the web service and an EJB session bean from WSDL. You can then customize the generated objects.
This chapter describes the following tasks:
To create a new web service from Java methods:
1. Open the New Web Service wizard.
In the Explorer, right-click the Java package in which you want to create the web service, and choose New 
Web Services Web Service.
You can also navigate to the same wizard by choosing File New Template Web Services Web Service from the IDE's main window.
The New Web Service wizard is illustrated in FIGURE 2-1.
|
Note - The wizard has radio buttons that enable you to choose the web service architecture: Multitier (the default) or Web centric. The distinction between these architectures is explained in Sun ONE Studio 4 Java Web Services. If your application uses only EJB business components, both architectures work. Multitier is preferred because it puts the generated support structure in the same EJB container as the business components. |
2. Ensure that the Create From Java Methods radio button is selected.
The alternatives, Create From Local WSDL File and Create From URL for WSDL File, are explained in Creating a JAX-RPC Web Service from WSDL.
3. Ensure that the Package field specifies the correct location in which to create the web service.
If a Java package is currently selected in the Explorer when you open the New Web Service wizard, the name of the package appears in the Package field of the wizard. You can click Browse in the wizard to find and select a package of your choice.
4. In the Name field, type a name for the web service.
If you enter the name of a web service that already exists in the package designated in the wizard, the IDE displays a highlighted message: A web service with this name already exists in package.
5. Click Finish to create the web service, or click Next to add method references.
If you click Finish, your new web service is displayed in the Explorer. It appears under the designated package as a node with a blue sphere icon (
).
If you click Next, the IDE displays a Methods browser. Select one or more methods and click Finish in the browser to add method references to your web service. Then click Finish to create the web service.
You can add method references after creating a web service (see Adding References to Methods, XML Operations, and JAR Files.
6. In the Explorer, right-click the web service and choose Properties.
The SOAP RPC URL property has the following default form:
http://hostname:portnum/webserviceName/webserviceName
Set the values of hostname and portnum to match your server installation. The first instance of webserviceName in the URL is called the context root or web context. You can change it to any value of your choice, but it must match the web context property of the J2EE application WAR node that you create in a later step (see Assembling the J2EE Application).
|
Note - If you have more than one web service, make sure that each of the SOAP RPC URLs is unique. |
FIGURE 2-2 shows the properties of a web service in which the context root of SOAP RPC URL has been changed from the default value to StockApp.
The XML operation is a means of combining multiple business method calls into a higher-level method call for the web service. You do not need XML operations if your web service simply exposes individual methods of a business component.
For information about the role of XML operations, see XML Operations. For information on how to develop XML operations, see Chapter 4.
|
Note - You must have available in the IDE an enterprise bean or other business component whose methods you want to expose in the web service. |
To add a reference to a web service:
1. In the Explorer, right-click the web service and choose Add Reference.
2. Select the desired business methods, XML operations, and JAR files.
You can select more than one item by holding down the Control key while clicking.
Be sure to select EJB methods from the logical EJB node (the node with the bean icon 
), not the nodes that represent the EJB bean class or the home or remote interfaces. By adding a method from the logical EJB node, you provide the runtime information needed to call the method. FIGURE 2-3 shows examples of logical EJB nodes.
References added to a web service are displayed in subnodes of the web service, as illustrated in FIGURE 2-4.
References are organized as follows:
The IDE prefixes references with the names of the packages containing the referenced objects. The IDE prepends the arrow symbol (->) to XML operation references and JAR references.
1. In the Explorer, select the reference you want to delete.
2. Right-click the reference and choose Delete.
To create a new web service from WSDL:
1. Open the New Web Service wizard.
In the Explorer, right-click the Java package in which you want to create the web service, and choose New Web Services Web Service.
You can also navigate to the same wizard by choosing File New Template Web Services Web Service from the IDE's main window.
The New Web Service wizard is illustrated in FIGURE 2-5.
2. Check the radio button for Create From Local WSDL File, click Next, and select the desired WSDL file from the browser, as illustrated in FIGURE 2-6.
Alternatively, check the radio button for Create From URL for WSDL File, enter a URL, and click Next.
The IDE displays the Specify New EJB window, as illustrated in FIGURE 2-7.
3. Specify the desired EJB name, select the target package, and click Finish.
The IDE creates the new web service and the new EJB, placing each in the package that you designated in the wizard, as illustrated in FIGURE 2-8.
The new web service and EJB session bean have the methods designated in the WSDL. The web service references those methods in the generated session bean.
For information on this task, see Instantiating Objects and Resolving References. This step is necessary only if you are using XML operations, and if the default references are not satisfactory.
Environment entries are data that you store in your web service's EJB module deployment descriptor. Environment entries are available to your web service for use as parameters to the methods that create or find target objects.
If a method specified in the Method, Constructor, or Static Method fields of the Resolve Objects dialog box takes a parameter, you can map that parameter's value to an environment entry. Because environment entries are stored in the deployment descriptor, they can be configured at deployment time to values appropriate for the runtime environment.
1. Right-click your web service node and choose Properties.
The IDE displays the web service properties, as illustrated in FIGURE 2-2.
2. Click the Environment Entries property value, then click the ellipsis (...) button.
The Environment Entries dialog box is displayed, as illustrated in FIGURE 2-9.
The Add Environment Entry dialog box is displayed, as illustrated in FIGURE 2-10.
4. Fill out the fields in the Add Environment Entry dialog box.
The environment entry is created. The next time you generate runtime classes for your web service, the environment entry will be propagated to the web service's EJB module deployment descriptor.
Before you can assemble your web service as a J2EE application and deploy it for testing, the IDE must generate your web service's runtime classes.
The IDE places the generated runtime classes in the same package as the web service, under a node named xxxGenServer, where xxx is the name of the web service. The generated classes differ depending on whether the architecture is multitier or web-centric. For example, in the multitier case, some of the runtime classes are for the generated EJB component.
The IDE generates one additional class for each XML operation, if any. For more information about XML operations, see Chapter 4.
To generate a web service's runtime classes:
1. Select your web service in the Explorer.
2. Right-click and choose Generate Web Service.
Your web service's runtime classes are generated and compiled. The resulting Explorer display is illustrated in FIGURE 2-11.
A WSDL node appears in the Explorer hierarchy, at the same level as the web service node and in the same package. The WSDL node has the same name as your web service, but it is distinguished by a different icon, with a green sphere (
).
You can also generate the WSDL file and node manually by selecting the Generate WSDL menu item from the web service node. For further information about using WSDL files, see Generating WSDL.
The explanation in this section assumes that the EJB modules needed by your web service are available to the IDE, and that you have generated the runtime classes of your web service.
The deployment steps are described for the J2EE Reference Implementation. Deployment should be similar for other application servers, but you might need to consult the person responsible for your application server for information such as host name, port number, and any special requirements.
The assembly and deployment procedure is simplified if your web service has the web-centric architecture and does not reference EJB business methods. The following explanation starts with the simpler web-centric case and then presents the procedure for a web service that is assembled and deployed as a J2EE application.
If your web service has the web-centric architecture, the IDE creates only a WAR file. In this case, you do not have to create a J2EE application.
If a web service has the web-centric architecture, the web service node has the Deploy and Execute menu items enabled in the Explorer.
Right-click the web service node and choose Execute.
If you are using the default Tomcat web server, the IDE assembles and deploys the WAR file and displays the default test web page in a browser. See Creating a Test Client for further information.
|
Note - If you are using the Sun ONE Application Server 7 server, Execute does not automatically deploy the WAR file. You must right-click the web service node and choose Deploy and then Execute. |
Alternatively, you can use the following procedure:
1. Right-click the web service node and choose Assemble WAR File.
The IDE creates a WAR file in the same package as your web service and displays the WAR node in the Explorer.
2. Right-click the WAR file node and choose Unpack as Web Module.
The IDE unpacks the WAR file into the directory of your choice and mounts the directory to the IDE filesystem.
3. Navigate to the unpacked web module in the Explorer, right-click the WEB-INF node, and choose Properties.
4. Change the Context Root property to match the SOAP RPC URL property of your web service (see FIGURE 2-2).
The context root value appears in the SOAP RPC URL, which has the following form: http://hostname:portnum/contextRoot/webservicename.
|
Note - You must give the Context Root property value of WEB-INF a leading slash (/), as follows: /contextRoot. |
5. Deploy the web module to a web server.
See Building Web Components in the Sun ONE Studio 4 Programming series for instructions on how to do this.
The following procedure assumes that your web service uses EJB business components.
To create a J2EE application containing your web service and its referenced components:
1. Right-click the package in which you want to create the J2EE application and choose New J2EE Application.
The New Application wizard is displayed.
2. Type a name for the application in the Name field and click Finish.
A J2EE application node is added to the package.
3. Right-click the application node and choose Add Module.
The Add Module to Application dialog box is displayed.
4. Select the web service and all EJB modules referenced by it, and click OK.
FIGURE 2-12 shows a J2EE application node with these subordinate nodes:
5. Edit the Web Context property of the web service WAR node, if necessary.
A default web context property is assigned to the web service WAR node. The value of this property is part of the URL used to access your web service. The value must match the context root value in the SOAP RPC URL property of your web service (see FIGURE 2-2).
a. Right click the web service WAR node and choose Properties.
b. Click the Web Context property, type a new value, and press Enter.
FIGURE 2-13 shows the properties of a web service WAR file in which the Web Context value has been changed to StockApp, to match the context root value in the SOAP RPC URL property of the web service.
6. Edit the Application Server property of the J2EE application, if necessary.
This property should specify the desired application server instance for deployment. The property defaults to the default application server of the IDE, which you can set in the Explorer window's Runtime tab.
To edit the property, right-click the J2EE application node and choose Properties. Click the Application Server property value, and click the ellipsis (...). The IDE displays a dialog box in which you can select any available application server instance, as illustrated in FIGURE 2-14.
|
Note - If you are using the RI server that comes installed with the Sun ONE Studio 4, Enterprise Edition for Java IDE, skip Steps 1-5 of the following procedure. |
To configure an external RI application server:
1. Click the Runtime tab in the Explorer window.
2. Expand the Server Registry node, and then expand the Installed Servers node.
3. Add a J2EE Reference Implementation server instance by right-clicking the J2EE Reference Implementation node and choosing Add Server Instance.
The Explorer window's Runtime tab is illustrated in FIGURE 2-15.
4. Open the property sheet for the J2EE Reference Implementation.
Right-click the J2EE Reference Implementation node again and choose Properties.
5. Set the value of the RIHome property to the directory where the J2EE SDK is installed.
6. (Optional) Configure database access.
Most EJB components require that you configure the RI server for database access. Edit the J2EE_HOME/config/resource.properties file and add the necessary drivers and data sources. (J2EE_HOME is an environment variable and refers to the directory where your J2EE SDK is installed.)
You can use RI server administration commands to edit the resource.properties file. For example, open a command window and enter the following commands:
j2eeadmin -addJdbcDriver yourDriver
j2eeadmin -addJdbcDatasource yourDatasource
See the Sun ONE Studio 4, Enterprise Edition for Java Getting Started Guide for a more complete description of this subject.
To deploy your web service application to the J2EE RI server:
1. Right-click the J2EE application node and choose Deploy.
This action starts the packaging process. When the IDE has finished packaging the application, it deploys the application to the RI server.
2. Watch for packaging and deployment status messages.
The process might take a few minutes. The IDE status line displays messages indicating the packaging progress. The console of the RI server indicates the deployment progress.
When deployment has completed, your web service is ready to be tested.
This section lists the client development features of the Sun ONE Studio 4, Enterprise Edition for Java IDE, and describes how to create a test client. See Chapter 3 for more information and procedures on how to create web service clients.
The IDE supports the following tasks through interactive dialog boxes and menu commands:
When you use the IDE to generate a client from your web service, the New Client dialog box displays a checkbox that enables you to make that client the default test client for the service.
To change the default test client, right-click the web service node in the Explorer, choose Properties, and edit the Test Client property.
You can use a default test client to test your web service. There are two procedures, depending on the architecture of your web service.
If your web service has a multitier architecture or has a web-centric architecture and uses EJB business methods:
1. Generate a client and make that client the default test client for your web service.
2. Assemble your web service into a J2EE application.
3. Right-click the application node and choose Execute. Alternatively, right-click the test client node and choose Execute.
The IDE deploys the web service application, runs it in the J2EE application server that is specified in the J2EE application, and executes the default test client. If your web service is assembled without a default test client, the IDE displays a page saying that there is no input page.
Alternatively, you can deploy the web service application, then right-click the test client node and choose Execute. The IDE assembles the test client, deploys its WAR file to the IDE's default Tomcat web container, and executes the client.
If your web service has a web-centric architecture and does not use any EJB business methods, there is no J2EE application. In this case, you can:
1. Generate a client and make that client the default test client for your web service.
2. Make sure the SOAP RPC URL property of the web service refers to the port of the internal Tomcat web server installation (8081).
To view or change the SOAP RPC URL property, right-click the web service node in the Explorer and choose Properties.
3. Right-click the web service node and choose Execute.
The IDE assembles a WAR file, deploys it to the default Tomcat web server, and runs the web service. To view the WAR properties, right-click the WAR node in the Explorer and choose Properties.
|
Note - If you are using the Sun ONE Application Server 7 server, Execute does not automatically deploy the WAR file. You must right-click the web service node and choose Deploy and then Execute. |
Testing is an iterative process. Edit your web service, regenerate the runtime classes and client, and test until satisfied.
This section explains how to use the IDE to make your web service available to other developers through a UDDI registry.
Several basic tasks are required:
1. Deploy your runtime web service to an application server or web server that is accessible to other developers and end-users over a network.
2. Generate WSDL from your web service and publish the WSDL to a web server that is accessible to other developers over a network.
3. Publish your web service to a UDDI registry that is accessible to other developers over a network.
The IDE does tasks 1 and 2 when you deploy your web service. The IDE provides a wizard for task 3, which is the main subject of this section.
|
Note - Client development is described in Chapter 3, including information about how to find a web service in a UDDI registry and how to generate a client that can use the web service. |
You can share WSDL files with other developers without necessarily using a UDDI registry. WSDL files can be put on a shared drive or sent as email attachments. For information about how to generate a client from WSDL (without a UDDI registry), see Creating a Client From WSDL.
When you generate the runtime classes for your web service, the IDE automatically creates a WSDL file and displays it as a node in the Explorer. You can also generate and view a WSDL file as follows:
1. Right-click your web service node in the Explorer and select Generate WSDL.
A WSDL node appears in the Explorer hierarchy, at the same level as the web service node and in the same package. The WSDL node has the same name as your web service, but it is distinguished by a different icon, with a green sphere (
).
2. Right-click your WSDL node in the Explorer and select Open.
The Source Editor window is displayed in read-only mode. You can read and copy the WSDL, which is an XML document. You can also find the WSDL file in your directory hierarchy, under the directory of your web service package. The file is webserviceName.wsdl.
|
Note - If you deploy your web application and use the IDE to publish the web service to a UDDI registry, the IDE's deployment and publication processes manage the WSDL for you. |
The IDE keeps a list of known UDDI registries and information (such as URLs, userid, and password) needed to access each registry. The IDE also keeps default information (such as business, categories, and identifiers) that is used when you create a web service client or publish a web service to a registry.
To manage UDDI registry options, choose Tools Options Distributed Application Support UDDI Registries from the IDE's main window. The Options dialog box is displayed, as illustrated in FIGURE 2-16.
The publish categories and publish identifiers associated with your web service are saved in a UDDI registry when you publish the web service.
An identifiers is a data element that is unique to a business or technical model (tModel). A category is a data element that classifies a business, service, or tModel. Categories or identifiers can be specified in user queries to locate a business, service, or tModel in a registry.
To set default publish categories, click the Publish Categories value in the UDDI registries Options dialog box (see FIGURE 2-16) and click the ellipsis (...) button that appears. The Publish Categories dialog box appears, as illustrated in FIGURE 2-17.
Click the Use for Service checkbox or the Use for tModel checkbox to set a category as a default for services or tModels when you publish them to a registry.
Click Delete to delete a category.
Click Add to add a category. The UDDI Categories (taxonomies) dialog box appears, as illustrated in FIGURE 2-18. The categories are industry standards.
Expand the nodes, select the desired category, and click OK. The category appears in the Publish Categories dialog box. To select more than one item, hold down the Control key while clicking. To select a range of items, hold down the Shift key while clicking.
To set default publish identifiers, click the Publish Identifiers value in the UDDI registries Options dialog box (see FIGURE 2-16) and click the ellipsis (...) button that appears. The Publish Identifiers dialog box appears, as illustrated in FIGURE 2-19.
You can delete an identifier, add an identifier, or set an identifier as a default for tModels.
To delete an identifier, select the identifier and click Delete.
To add an identifier, click Add. The UDDI Add Identifier dialog box appears, as illustrated in FIGURE 2-20. The identifier types and tModel UUIDs are industry standards.
Select Type. The IDE displays the tModel UUID for the selected type. You can specify your own user-defined type if you know and enter the tModel UUID (the registry key) of your user-defined type.
Specify Name and Value, and click OK. The IDE returns you to the Publish Identifiers dialog box.
Click OK. The IDE returns you to the UDDI Set Categories and Identifiers dialog box.
To edit information about registries known to the IDE, click the ellipsis (...) button of the Registries property in the UDDI registries Options dialog box (see FIGURE 2-16). The Property Editor dialog box is displayed, as illustrated in FIGURE 2-21.
The property editor displays known registries and detail information for the selected registry. The top portion of the screen is a table of known registries. Click a registry name to display its detail information in the bottom portion of the screen.
You can edit registry information as follows:
You can also set a business that the IDE will use as a default in its UDDI wizards. To set a default business, specify values for Name and Key.
|
Note - You can edit UDDI registry properties while you are publishing a web service or searching the registry for the purpose of generating a client. See Creating a Client: Procedure. |
In order to access a UDDI registry, you have to provide the IDE with certain information (see Editing Registries Information in the IDE).
To search a registry and generate a web service client, you need the Query URL. To publish a web service to a registry, you need the Publish URL. Get this information from the registry operator, that is, the organization managing the registry.
Security can vary from one registry to another. You might need a login name and password to publish to a registry. Get this from the registry operator. Some public registries provide tools that you can run from a web browser to set up your own account.
This section begins by explaining publication tasks and terminology, and then describes the publication procedure.
A web service entry in a UDDI registry is associated with a business entry, a technical model (tModel) entry, and optional categories and identifiers. When you publish a web service to a UDDI registry, the IDE wizards help you to carry out the following tasks:
The business is the organizational entity that contains the web service. Each business entry in the registry has a unique key.
The tModel is a registry entry that contains a URL (called the overviewURL) pointing to your WSDL, which describes the external interfaces of your web service. This information is used by the IDE or other developer software to create clients that can call methods on your web service at runtime.
The web service entry in a UDDI registry specifies an entry point, also called the endpoint URL or service URL. The URL is used by a client to find a runtime instance of your web service. During publication, the IDE sets this URL by default to the value of the SOAP RPC URL property of the web service. You can edit the value.
Standard industry categories and identifiers can be associated with your web service entries and tModel entries in a UDDI registry to facilitate subsequent searches. For more information about UDDI registry searches, see Creating a Client From a UDDI Registry.
A business can publish many different services to a UDDI registry, where each service is described structurally by WSDL associated with a tModel entry. There can be many service entries that reference the same tModel. For example, as a service provider you might support one instance of a service for use within your enterprise, another instance for business partners, and another instance for the general public. The various instances have the same external interface, as described in the WSDL referenced by the tModel, but they might have different performance or availability characteristics.
When you publish a web service, the IDE automatically includes a reference to its tModel.
Before starting this procedure, you must deploy your web service application. The IDE places a copy of the service's WSDL file in the deployed service. When you publish the service, the tModel refers to this WSDL file.
To publish a web service to a UDDI registry:
1. Right-click your web service node in the Explorer and select Publish to UDDI.
The Publish New Web Service to UDDI dialog box is displayed, as illustrated in FIGURE 2-22.
|
Note - The host name in Address URL defaults to localhost. Change this to the network machine name of the host. |
2. Click Next to display the UDDI Login and Business Information dialog box, as illustrated in FIGURE 2-23.
If you previously set default values for userid, password, and business for the selected UDDI registry, the default values are displayed. You can override a default value by typing or pasting a different value in each field.
To specify a business, type a value for Business Name. The Find and Add buttons become active.
Click Edit to edit information for the selected UDDI registry. The IDE displays the UDDI Registries Property Editor. This enables you to change registry default values during the publication process. See Editing Registries Information in the IDE.
[ D ]
3. Click Next to display the UDDI tModel selection dialog box, as illustrated in FIGURE 2-24.
In this step you specify what you want to publish and provide details. You can create a new tModel in the registry or find an existing tModel, and associate the new or existing tModel with your web service.
If you create a new tModel, the IDE attempts to derive the WSDL File URL from the Address URL of your deployed web service (see FIGURE 2-22), based on IDE naming conventions. If you changed the Address URL, or if you deployed your web service outside the IDE, the IDE leaves the WSDL File URL value blank.
You can change the URL by typing a different value.
You can specify text for the tModel Description.
[ D ]
If you use an existing tModel in the UDDI, type the tModel Name and click Find.The IDE will display the tModel Key. If more than one tModel in the registry matches the value of tModel Name, the IDE displays the first tModel Key value returned by the registry server. If you already have the key value, type or paste it into the tModel Key field.
|
Note - If you are publishing your web service to a UDDI registry that provides browser tools, you can use those tools to search for the tModel key. Click Launch Browser. The IDE opens your default web browser at the web page specified by the Browser Tools URL of the UDDI registry (see FIGURE 2-21). |
The IDE displays the UDDI Set Categories and Identifiers dialog box, as illustrated in FIGURE 2-25.
The dialog box shows your default categories and identifiers. Click Edit to add or delete categories or identifiers, as described in Setting Default Publish Categories and Identifiers.
[ D ]
The IDE publishes your web service to the UDDI registry. This can take several minutes. A success message is written to the IDE's top window status line.
The UDDI registry server from Sun's Java
Web Services Developer Pack (Java WSDP) is integrated with the IDE as a single-user, internal UDDI registry is bundled with the IDE as a convenience for end-to-end testing of your development process. This registry consists of a servlet that runs in a dedicated Tomcat web server (different from the internal Tomcat server used for web application development) and uses an XML database for persistent storage. The IDE automatically starts and stops the Tomcat server and the database server when you start and stop the registry server.
|
Note - The internal UDDI registry is configured with a single user. The name is testuser and the password is testuser. Set this name and password as the default for the internal registry. |
To start the internal UDDI registry server:
1. Expand the UDDI Server Registry node in the Explorer Runtime tabbed pane.
You should see the Internal UDDI Registry node.
2. Right-click the Internal UDDI Registry node and choose Start Server, as shown in FIGURE 2-26.
The IDE output window displays server startup messages. You might also see messages stating that the IDE is stopping a previous Tomcat server process.
|
Note - If the internal UDDI registry server is already running, the Start Server menu item is inactive. |
To stop the internal UDDI registry server:
1. Expand the UDDI Server Registry node in the Explorer Runtime tabbed pane.
You should see the Internal UDDI Registry node.
2. Right-click the Internal UDDI Registry node and select Stop Server.
The IDE output window displays server startup messages. You might also see messages stating that the IDE is stopping a previous Tomcat server process.
|
Note - If the internal UDDI registry server is not running, the Stop Server menu item is inactive. |
The Java WSDP provides a sample registry browser, which has additional features beyond those included in the Sun ONE Studio 4, Enterprise Edition for Java IDE.
The sample registry browser enables you to delete a service from the internal registry, to add business information beyond name and key, and other actions not provided in the IDE wizards. However, as its name suggests, the sample registry browser is not a complete, full-function tool. For example, it does not enable you to view or delete tModels.
Java WSDP software and sample programs are in the jwsdp directory under your IDE home directory. Sample program source is in the wsdp/samples directory.
For further information and a downloadable tutorial, see the Java WSDP web site at http://java.sun.com/webservices/webservicespack.html.
The purpose of this section is to help you get started setting up and using the sample registry browser, not to describe all of its features.
Before starting the sample registry browser, use the IDE to start the internal UDDI registry, as explained in Starting and Stopping the Internal UDDI Registry Server.
To start the sample registry browser:
1. Open a command window and change your current directory to s1studio_HOME/jwsdp/bin.
2. Type the following command:
The sample registry browser is displayed, as illustrated in FIGURE 2-27.
To configure the sample registry browser for your internal registry:
1. Select the last URL in the Registry Location list, as illustrated in FIGURE 2-28.
2. Change the port number in the URL from 8080 to the correct port number for the internal registry Tomcat web server, as illustrated in FIGURE 2-29.
The IDE is configured with 8089 as the default port number for this server.
The sample registry browser main window has, on the left side, a tabbed pane with Browse and Submission tabs. The main window has, on the right side, a pane that displays detail information about the object that is selected in the tabbed pane. The upper left area of the main window has buttons for Search, Submit, and other context-sensitive actions.
An example showing the result of a search by company name is illustrated in FIGURE 2-30.
An example using the Submissions tabbed pane is illustrated in FIGURE 2-31.
You can explore additional features of the sample registry browser on your own, or download and work through the tutorial provided at the Java WSDP web site: http://java.sun.com/webservices/webservicespack.html.
When developing an XML operation, you specify which methods the XML operation calls. To call these methods at runtime, the web service requires certain objects. For each method call, it locates or instantiates:
To perform this task, the web service maintains a reference to each of these target objects and a definition of how to instantiate an object of the appropriate class should the target object not exist. As you add method calls to an XML operation, default object references and target object definitions are automatically added to the web service. These defaults are usually appropriate and do not need editing.
However, you can manually specify the target of an object reference, and you can edit and create new target object definitions to suit your requirements. You might need to manually resolve object references to enterprise beans that were created outside of the IDE.
For further information on this subject, see Appendix B.
When you generate runtime classes for your web service, a web module and EJB module deployment descriptor are also generated. When you assemble your web service J2EE application, these deployment descriptors are included in the application. The deployment descriptors are XML files used to configure runtime properties of the application. The J2EE specification defines the format of these descriptors.
You can view the deployment descriptors in the Source Editor at any time during development. You can also edit the deployment descriptors. However, deployment descriptors that you edit are not regenerated if you regenerate runtime classes. Deployment descriptor edits are thereby preserved. However, changes you make to your web service after editing a deployment descriptor will not be propagated to your deployment descriptor. You should, therefore, take care to edit deployment descriptors only at the end of your development cycle.
For further information on this subject, see Appendix C.
This section summarizes the support for input and output data of types Array and Collection. For further information on this subject, see Chapter 4.
The IDE supports arrays as follows:
A collection is a Java class that implements java.util.Collection. The IDE supports collections as follows:
A collection might contain objects of types defined by user classes that are not otherwise referenced in the web service. For a user-defined object, you must add the serialization data type to the JAX-RPC type registry, so that it is handled properly by the JAX-RPC runtime. The IDE provides a web service property for adding serialization classes.
1. Right-click the web service node, choose Properties, click the value of the Serialization Classes property, then click the ellipsis (...) button.
The IDE displays any existing serialization classes and provides Add and Remove buttons, as illustrated in FIGURE 2-32.
The IDE opens a browser in which you can select one or more classes from any mounted packages. The selected classes should be JavaBean components.
3. Select the desired classes, using ctrl-click to select more than one, then click OK.
The IDE displays the serialization classes.
| Building Web Services | 816-7862-10 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.