| Oracle® Enterprise Pack for Eclipse User's Guide Release 12.1.3.1 E53428-02 |
|
 Previous |
 Next |
OEPE lets you to build enterprise-class Web services that employ standard Web service technologies, such as XML, SOAP, and WSDL. OEPE simplifies Web service development by allowing you to focus on application logic, rather than the complex implementation details traditionally required by these technologies.
This document contains the following sections:
Section 8.1, "Starting Points of Web Services Development with OEPE"
Section 8.8, "Generating Web Services for Spring Service Beans"
This section describes how to get started with developing web services.
Using OEPE, you can generate a Web service from a WSDL file. The resulting Web service class will contain the public endpoint interface described by the WSDL without the implementation. After the Web service has been generated, you have to fill in the Web service implementation details.
To generate a Web service from a WSDL:
Create a new WSDL file or import an existing WSDL file into your project. For more information, see Section 8.1.6, "Creating a New WSDL File" and Section 8.1.5, "Imported WSDL Files."
In the Project Explorer, right-click the WSDL file and select WebLogic Web Services > Generate Web Service.
This opens the New Web Service from WSDL dialog that lets you specify many parameters for the generated Web service, including the port, the output locations, and Ant script generation options.
Selecting Keep generated Ant Script saves an Ant file for modification and reuse of the generation process.
In addition to the Web service implementation class, this will create a JAR file that contains a Web service interface class, as well as types referenced in the original WSDL file. The default location for the JAR file is the project's WEB-INF/lib directory. If you select a different location that is not on the class path, your Web service is unlikely to function properly.
You can test your Web service using the Test Client. For more information, see Section 8.1.8, "Testing Web Services."
You can also customize your Web service. For more information, see Section 8.1.1.1, "Customizing a Web Service."
You can customize your Web Service using the JAX-WS bindings file that points to an appropriate WSDL file.
A JAX-WS bindings file lets you change the shape of the Java Web service artifacts generated through WSDLC. The bindings allow you to modify class and method names, method signatures (wrapper versus non-wrapper), add Javadoc, and attach handlers. Sources of information on the bindings file specifications with examples can be found in the references section.
To create a bindings file:
Right-click in the Project Explorer and select New > Other from the drop-down menu. This opens the New dialog that lets you select a wizard to use.
Select Oracle > WebLogic > Web Services > JAX-WS Bindings Customization, and then click Next. This opens the New JAX-WS Bindings File wizard.
Specify the name and location for your bindings file, and click Next. This opens the New JAX-WS Bindings File dialog. Select the file from the list of WSDL files available in the project in which the bindings file will be generated.
Click Finish on the New JAX-WS Bindings File dialog to complete generation of the bindings file in the specified location.
Upon the completion, the new bindings open in the JAX-WS Bindings editor. The contents of the file is a basic bindings file shell with a wsdlLocation element pointing to the identified WSDL file.
Once created, you can customize the bindings file using the customizations editor. For more information, see Section 8.1.1.1, "Customizing a Web Service."
The customizations editor lets you define the contents of a JAX-WS external bindings file (not embedded in the WSLD file), while providing information on the possible XML elements within the file. Using the editor, you can specify a variety of customization options based on the shape of the generated Java code. Note that the editor allows you to define both server-side and client-side customization options.
The customizations editor shows which classes, methods, and parameters will be generated when you apply a particular bindings file's customizations.
You can use the to modify the following types of files:
A single WSDL file: the editor supports having all WSDL information defined within a single WSDL file. The editor will not load a secondary WSDL file imported through WSDL import or include mechanisms.
External bindings files: even though you can define JAX-WS bindings elements either within a WSDL file, or in an external file, the customizations editor only supports external bindings files, ignoring the JAX-WS bindings elements within the WSDL file. Note that, although ignored by the editor, those elements will not be ignored by the artifact generation tooling. Also note that you can use the editor to modify only one external bindings file at one time.
You can use the external bindings file to customize the shape of the generated Web service, customize specifics of the generated Web service client (for example, enable asynchronous clients), and add JAX-WS handlers.
Schema configurations: JAX-WS uses W3C Schema (XSD) elements to define the JAXB types that will be used by the generated Service Endpoint Interface-based Java Web service. You can include the schema information in the WSDL file either in line, or through different import or include mechanisms. The customization editor supports having WSDL type information defined through inline schemas, as well as external schemas imported using the schema import mechanism.
This example shows how inline types define the JAXB type information in an embedded schema element in the types section of the WSDL file.
This example demonstrates the case of imported schemas, where the customizations editor supports importing schemas directly from the WSDL file using the schema import mechanism. The import element must define a namespace and a schemaLocation attribute. Note that imports in the imported schemas will not be followed.
The customization editor consists of the following parts:
A tree control on the left - its nodes represent a combination of the WSDL and the Java artifacts that will be generated.
An edit page on the right - when you select a node in the tree, the editor will display an appropriate edit page where you can edit the properties (supported customization options), as follows:
The Global node and the corresponding page let you specify the following settings that apply to the editor in global scope (for example, to all generated Java artifacts):
WSDL URI - the URI to the WSDL file that this bindings file customizes. Note that, even though the JAX-WS 2.1 specification states that the URI can specify a local WSDL or a remote WSDL file, this editor supports only local WSDL files.
Package name and JavaDoc - the package name for the generated Java artifacts. A light-gray value in the name setting means that the default package name will be used. This default value is determined by the WSDL file's target namespace. The JavaDoc can only be specified if a package name other than the default is specified.
Wrapper Style (enableWrapperStyle customization option) - the wrapper style setting for Java method generation. Accepting the default value of true will result in wrapper style method generation only if the rules are satisfied, as defined in section 2.3.1.2 of the JAX-WS 2.1 specification, available at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html. This value applies to all endpoint interfaces and methods, however, each endpoint interface or method can override this setting.
Async Mapping (enableAsyncMapping customization option) - the async mapping setting for asynchronous method generation on the endpoint interfaces. The default value is true. The generated asynchronous methods can only be used on the client side. This value applies to all endpoint interfaces and methods, however, each endpoint interface or method can override this setting. For more information, see section 2.3.4.2 of the JAX-WS 2.1 specification, available at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html.
MIME content (enableMIMEContent customization option) - the MIME content setting for the use of the mime:content information. The default value is true. The client- and server-side settings must match. This value applies to all endpoint interfaces and methods, however, each endpoint interface or method can override this setting. For more information, see section 2.6.3.1 of the JAX-WS 2.1 specification, available at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html.
The Handler Chains node and the corresponding page, shown in the following figure, display existing, or let you define new handler chains consisting of either logical handlers, SOAP handlers, or a combination of both types. Note that Handler Chains sections on each page (if applicable) provide the same options. You can specify the following:
Type - A handler chain can apply to everything (Global), Services, Ports, or Protocol bindings. While this field is not editable in the editor design view, it can be changed in the source view, and the source changes will be reflected in the editor.
Applies To - the specific pattern (Services, Ports), bindings (Protocol), or global (All) to which this handler chain applies. While this field is not editable in the editor design view, you can modify it in the source view, and the source changes will be reflected in the editor.
Class name - Java class that implements LogicalHandler interface (for logical handlers), or SOAPHandler interface (for SOAP handlers).
Handler name - the name of the Handler that is unique within the module.
Initialization parameters for the Handler with editable names and values
Connection and/or binding setting
SOAP handler settings:
SOAP headers - information to identify which SOAP headers will be processed by the SOAP Handler.
SOAP roles - SOAP roles for the SOAP Handler. For more information, see section 10.1.1.1 of the JAX-WS 2.1 specification, available at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html.
The Endpoint Interface node and the corresponding page, shown in the next figure, represent the endpoint interface that will be generated from a WSDL Port Type after running WSDLC. This node lets you specify:
Interface name and JavaDoc - the name for the generated Java interface. A light-gray value in the name setting means the default interface name is being used. This default value is determined by a WSDL Port Type. You can only specify the JavaDoc if the specified interface name is other than the default.
Wrapper Style (enableWrapperStyle customization option) - the wrapper style setting for Java method generation on a specific endpoint interface. The default value is determined by the Wrapper Style setting on the Global node. This value applies to a particular endpoint interface and its methods, however, each method can override this setting.
Async Mapping (enableAsyncMapping customization option) - the async mapping setting for asynchronous method generation on a specific endpoint interfaces. The default value is determined by the Async Mapping setting on the Global node. This value applies to a particular endpoint interface and its methods, however, each method can override this setting.
Services - represents the implementing class that will be generated from a WSDL Port after running WSDLC:
Service class name and JavaDoc - the name for the generated Java class. A light-gray value in the name setting means the default class name is being used. This default value is determined by a WSDL Port Type. You can only specify the JavaDoc if the specified interface name is other than the default.
MIME content (enableMIMEContent customization option) - the MIME content setting for the use of the mime:content information on the specific Service. The default value is determined by the MIME Content setting on the Global node. The value in the editor screen applies to the particular Service only.
The Method node and the corresponding page, shown in the next figure, represent the method that will be generated from a WSDL operation after running WSDLC. This node lets you specify:
Method name and JavaDoc - the name for the generated Java method. A light-gray value in the name setting means the default method name is being used. This default value is determined by a WSDL operation. You can only specify the JavaDoc if the specified method name is other than the default.
Wrapper Style (enableWrapperStyle customization option) - the wrapper style setting for Java method generation on a specific method. The default value is determined by the Wrapper Style setting on a parent Endpoint Interface node. This value applies to a particular method only.
Async Mapping (enableAsyncMapping customization option) - the async mapping setting for asynchronous method generation on a specific method. The default value is determined by the Async Mapping setting on a parent Endpoint Interface node. This value applies to a particular method only.
Method parameters - represents the method's parameters and the customization that will apply on the parameter name. Only the name is editable.
The Faults node and the corresponding page will only appear if there are Faults on the WSDL operation. This node serves as a grouping node to show a list of all the defined Faults.This node lets you specify:
Fault Class name and JavaDoc - the name for the generated Java class. A light-gray value in the name setting means the default class name is being used. This default value is determined by a WSDL fault. You can only specify the JavaDoc if the specified class name is other than the default.
Notice that the editor pages open with default values already specified.
OEPE lets you generate Web services from Java using the following starting points:
From a Java class
From nothing
You can develop a JAX-WS-enabled Web service as a Java class, with methods becoming Web service operations, and method parameters and return types being Java beans. To indicate what methods should be exposed and to set other properties for the service, you use annotations.
To create a Web service from a Java class:
Right-click the class file, and select WebLogic Web Services > Generate Web Service. This opens the Generate Web Service from Existing Java Class wizard.
On the New JAX-WS Web Service page, enter the Web Service Name (corresponding to the @WebService serviceName attribute), the Port Name (corresponding to the @WebService portName attribute), and select Add SEI to optionally generate the endpoint interface.
On the Message Format page, select the SOAP Binding (default: 1.1), the SOAP Message Format (default: Document/Literal/Wrapped), and select Enable MTOM to optionally implement MTOM binary encoding.
On the Methods page, select methods for the web service to expose.
On the Selection WebLogic Web Service Policies page, select either No Policies, OWSM Web Service Policies, or WebLogic Service Policies.
|
Note: You cannot mix OWSM and WebLogic Policies. |
The Description section provides information about the currently selected policy. As you select available policies, they are validated against each other for compatibility. If incompatible policies are selected, a validation error is displayed. If you click on the error marker, text describing the validation error is displayed. Then click Finish.
See Section 8.1.7, "Understanding Policy Stores" for more information on configuring policy stores.
See Section 8.6, "Using WebLogic Web Services Annotations View" for information on adding and removing OWSM Web Service Policies and WebLogic Service Policies.
Having followed the preceding procedure, you created a Web service from a Java class. The resulting generated code has imports added, and the class annotated corresponding to wizard choices. You can run it by right-clicking the new class, and then selecting Run As > Run on Server from the drop-down menu.
Web services without security policies can be tested using the Test Client. For more information, see Section 8.1.8, "Testing Web Services"
Using OEPE, you can create a JAX-WS-enabled Web service for your Java project without taking any prior steps.
To create a Web service from scratch:
Create a new Web service project.
Right-click the project name in the Project Explorer and select New > Other from the drop-down menu. This will open the New wizard. Select Oracle > WebLogic > Web Services > WebLogic Web Service, and then click Next to open the New Web Service wizard.
On the Web Service page, provide a Package name and enter a Name for your new Web service. Optionally, click Enable MTOM to implement binary encoding. Optionally, click Generate Service Endpoint Interface to generate an endpoint interface. Click Next.
On the Selection WebLogic Web Service Policies page, select either No Policies, OWSM Web Service Policies, or WebLogic Service Policies.
|
Note: You cannot mix OWSM and WebLogic Policies. |
The Description section provides information about the currently selected policy. As you select available policies, they are validated against each other for compatibility. If incompatible policies are selected, a validation error is displayed. If you click on the error marker, text describing the validation error is displayed. Then click Finish.
See Understanding Policy Stores for more information on configuring policy stores.
Using OEPE, you can generate a WSDL file from a Java class for your project.
To generate a WSDL:
Create new or use an existing Web service project.
Right-click a Java class in your Web service project in the Project Explorer, and select WebLogic Web Services > Generate WSDL from the drop-down menu.
This generates a WSDL file in the same package as the Java class that you used as a starting point.
Files with the WSDL extension contain Web service interfaces expressed in the Web Service Description Language (WSDL). WSDL is a standard XML document type specified by the World Wide Web Consortium (W3C). For more information, see http://www.w3.org/TR/wsdl.
WSDL files communicate interface information between Web service producers and consumers. A WSDL description allows a client to utilize a Web service's capabilities without knowledge of the implementation details of the Web service.
A WSDL file contains the following information necessary for a client to invoke the methods of a Web service:
The data types used as method parameters or return values.
The individual methods names and signatures (WSDL refers to methods as operations).
The protocols and message formats allowed for each method.
The URLs used to access the Web service.
When you want to use an external Web service from within Eclipse, you should first obtain the WSDL file for the service you want to use, as follows:
For public Web services, the WSDL file will typically be available on the Web site of the organization that publishes the Web service.
For private Web services, contact the organization that supports the Web service to obtain the WSDL file.
WSDL files can also be found through both public and private UDDI registries. For more information about UDDI, see http://uddi.xml.org/.
Once you have the WSDL file, you may use Eclipse to create a Web service.
Some Web service tools produce WSDL files that do not contain an XML declaration. The XML declaration is just the first line of an XML file of the following form:
<?xml version="1.0" encoding="utf-8" ?>
If you receive a WSDL file that does not contain an XML declaration, you must add a declaration to the file using a text editor before you can use the WSDL file in Eclipse.
|
Note: The encoding attribute is not required. If an encoding attribute is not present, the default encoding is |
To create a WSDL file to use in your project:
Right-click the project in the Project Explorer and select New > Other from the drop-down menu. This opens the New dialog.
In the New dialog, select Web Services > WSDL, and then click Next. The New WSDL File dialog opens.
On the New WSDL File dialog, provide a name for the WSDL file, click Next, and then click Finish. This creates a WSDL file for your project.
|
Note: For a JAX-WS Web service project, you enable the Standard Annotated Web Services project facet option by right-clicking the project in the Project Explorer, selecting Properties from the drop-down menu, and then selecting Project Facets > Oracle WebLogic Web Services. |
Use to specify the policy store location for the WS Policy Store, which is where the Oracle Web Services Manager (Oracle WSM) policies are defined.
Policies, which are used to provide management and security functionality, are created and managed centrally in an organization by the web service policy manager or security architect, who provisions a set of policies using Oracle WSM. Policies can be updated without needing to modify the web services that use the policies.
OEPE comes with a default file-based policy store, which is part of Oracle WebLogic Server, which means that you can use policies out of the box. You apply policies in the Create Web Services wizards.
To configure the policy store in OEPE:
From the main menu, select Window > Preferences to open the Preferences dialog.
In the Preferences dialog, select WebLogic > WS Policy Store.
On the WS Policy Store page:
Click a Runtime to configure its corresponding policy store.
File Store: Click to use the default file-based policy store.
Override: Click to enter or browse to the fully-qualified path to the location of the policy store to be used in place of the default policy store, in the Override Location field.
Remote WebLogic: Click to enter the remote location of the WebLogic Server instance that contains the policy store.
Fore more information on policies in other contexts, see Securing WebLogic Web Services for Oracle WebLogic Services.
As you develop a Web service, you can test it directly by using the test client. The test client provides a user interface through which you can test Web service operations with parameter values you choose.
Using the test client, you can do the following:
Test a Web service from the project tree: When you test Web services with Eclipse, consider the following steps that launch the test client with a visual interface for invoking the Web service's operations:
Expand the project tree to display the Web service source file.
Right-click the source file, then click Run > Run on Server.
When the test client is displayed, choose the operation you want to test by clicking the button labeled with the operation's name. If the operation has parameters, the test client provides boxes for you to enter the values to test with. If an operation includes complex types as parameters, the test client will display an XML template with placeholders for your test values.
Examine the result of the test by looking at generated messages. When you execute an operation, the test client refreshes to display information about the message exchanged by the operation. The user interface provides a summary of message values, as well as the message XML itself. When an exception occurs, a fault message is displayed.
Use the Message Log list to view the results of multiple tests.
Click Show Operations to begin another test.
View the WSDL file for the Web service you are currently testing: click the WSDL URL provided at the top of the test client window.
Choose another Web service to test: You can test another Web service without closing the test client by clicking the Choose Another WSDL link at the top of the test client window. The test client will display a page with a box where you enter the WSDL URL, then click Test to display the test form for that Web service.
Alternatively, you can launch the test client without using Eclipse IDE by launching the client through a Web browser, as follows:
With the Oracle WebLogic Server running, open a browser window and navigate to http://localhost:7001/wls_utc to start the test client.
In the Enter WSDL URL box, enter the URL for the WSDL of the Web service you want to test, and then click Test.
Use web service projects to develop web services that conform to standards, such as SOAP for message exchange, XML for messages to or from the service, and a WSDL that specifies the web service's public interface.
Each Web service project produces a JEE module, each of which is included in the complete Eclipse application's EAR file when you build your application for deployment.
The contents of Web service projects are accessed through the test client which allows you to access each operation of the Web service by clicking on a button. For more information, see Section 8.1.8, "Testing Web Services.".
Using OEPE, you can create a Web service project.
To create a Web service project:
Right-click the Project Explorer and select New > Project from the drop-down menu. This opens the New Project dialog.
Select WebLogic > Web Services > Web Service Project from the list, and then click Next.
On the New Web Service Project dialog, provide a name and location for your project, select and configure your target runtime, specify your EAR and working sets settings, and then click Finish.
Using Eclipse IDE and Oracle WebLogic Server, you can create a Web service project from an existing dynamic Web project by adding a Web Services facet.
Dynamic Web projects are used to create Web applications.
User interface components are constructed from Java Server Pages (JSPs), which are Web pages that can interact with server resources to produce dynamic content.
Each dynamic Web project ultimately produces a J2EE module. Each J2EE module is included in the complete application's EAR file when the application is built for deployment.
The contents of Web projects are accessed through URLs.
A dynamic Web project has two core facets: the Dynamic Web Module (the enable facet) and the WebLogic Web App Extensions facets. This project may contain a number of optional facets, one of which is the Web Service facet.
To create a Web service project from an existing dynamic Web project:
Open your dynamic Web project in Project Explorer.
Right-click on the project name and select Properties from the drop-down menu. This will open the Properties dialog.
Select Project Facets from the tree-control on the dialog's left panel.
Select WebLogic Web Services from the Project Facet list on the dialog's right panel.
Click Apply.
You can generate client code to use with web services.
Using OEPE, you can generate the client code for the following types of projects:
Web service project
Dynamic Web project
EJB project
To generate the client code for your Web service:
Create new, or obtain an existing WSDL file for your target Web service project.
For more information, see the following:
Creating a new WSDL File
Generating a Web Service from a Java Class for JAX-WS
Create another Web service project, which will be your client project.
Copy the WSDL file (from step 1) located in the WebContent folder of your target Web service into the WebContent folder of your client project (from step 2).
Generate the client code as follows:
In the Project Explorer, right-click your client project's WSDL file, and then select WebLogic Web Services > Generate Web Service Client from the drop-down menu. This will open the New Web Service Client dialog.
On the New Web Service Client dialog, specify the service name, the output location of the generated JAR file, as well as Ant script generation options, and then click Next.
On the next New Web Service Client > Customization Options screen, you may choose to specify additional options, and then click Finish.
Upon completion of the preceding procedure, Eclipse does the following:
Creates the client JAR file in your client Web service project's WebContent/WEB-INF directory.
Modifies properties of your target Web service project, as necessary (sets the project facet, classpath, and so on).
If you deploy and run both your target and client Web service projects, your generated client code will successfully call your target Web service.
|
Note: Nondeployment-based applications, such as Java applications, may require additional manual configuration. |
You can reference the client from the target Web service using the template-based code snippets.
You can generate client code from Java classes.
To generate client code from a Java class:
On the Web Service Proxy Client Generation page, populate the following fields:
Project: Choose the project that will contain the proxy class as well as the class you want to generate the client invocation code from.
Client Proxy Class: Browse the current project for an existing WebService client, or choose to create a new webservice client using a local or remote WSDL.
Invocation Class: Choose a class file that you want to generate the client invocation into, or browse for an existing class.
Invocation Method: Choose the corresponding method that will contain the client invocation. The resulting code block will be generated at the end of the method block. You can also browse for existing methods.
On the Selection WebLogic Web Service Policies page, select either No Policies, OWSM Web Service Policies, or WebLogic Service Policies.
|
Note: You cannot mix OWSM and WebLogic Policies. |
Within the OWSM policy panel, you can choose compatible client policies based on a resolved WSDL location. The WSDL location is based on the client service selection specified in the previous page (Web Service Proxy Client Generation). If the WSDL is packaged with the service, OEPE evaluates the WSDL for policy declarations and a compatible client list is displayed. Otherwise, you are presented with the entire client store of policies.
As you select available policies, they are validated against each other for compatibility. If incompatible policies are selected, a validation error is displayed. If you click on the error marker, text describing the validation error is displayed. You will be required to resolve the validation errors prior to selecting Finish.
There are alternative entry points to the client code generation wizard. Instead of right-clicking your client project's WSDL file, and then selecting WebLogic Web Services > Generate Web Service Client from the drop-down menu, you can also right-click the Project Explorer area, select New > Other > WebLogic Web Services > Web Service Client, and then click Next. This opens the ClientGen Wizard > WSDL File dialog.
Using this dialog, select the WSDL file from which you want to generate the Web service client indicating if this file is local or remote (in this case, enter a remote URL), and then proceed with your other settings.
Typically, Eclipse builds your files automatically and you can deploy your application at any time. Note that in order to deploy, you must have a successful build completed.
You can start Oracle Weblogic Server in either development or production mode: in development mode, the server behaves in ways that make it easier to iteratively develop and test applications (for example, the server automatically deploys the current application in an exploded format and relaxes certain security restrictions on deployment); in production mode, WebLogic Web Service test client is not deployed. For more information, see Testing Web Services.
Application deployment consists of the following three steps:
Compilation of the Web service.
Publishing the files to the server.
Running the application.
Usually these steps are done seamlessly, by explosion of the WAR file.
When you deploy, all open projects associated with the server are deployed. To undeploy a project or prevent it from being deployed, remove it from the server. Alternatively, you can close projects by selecting Project > Close Projects from the menu. You can also specify working sets (see Eclipse help system in the Workbench User Guide) to control how many artifacts to build and deploy.
However, even though an entire application or group of projects was deployed, only the file or folder that you clicked on to trigger the deployment will display its results. When you deploy your Web service, the test client page for that Web service will run in a new tab in the editor area - you can use it to specify the parameters to an operation and make a request to that operation. The response from the operation is displayed in the same tab. If the page flow or Web service relies on other Web services to run correctly, it will still work because all components are deployed.
To deploy your Web service application, do one of:
Right-click your project in the Project Explorer and select Run As > Run on Server from the drop-down menu to start the server in normal mode (if it has not been started). This will deploy the application to its associated server; if the project is not associated with a server, make a server selection using the displayed dialog, and then run the application.
Right-click your project in the Project Explorer and select Debug As > Debug on Server from the drop-down menu to start the server in debug mode (if it is not already started), and run the application.
If you wish to simply publish your files to the server, you can use the Servers view by selecting Window > Show View > Servers from the main menu.
|
Note: This view also lets you undeploy applications from the server. |
After you deploy your application, the Servers view is displayed automatically.
Using OEPE, you can generate JAXB classes from an existing XML schema for your Web service project.
To generate JAXB classes:
In the Project Explorer, right-click the schema file (XSD file) in your Web service project, and then select WebLogic Web Services > Generate JAXB Types from the drop-down menu. This will open the New JAXB Types > Generated Artifacts dialog.
On the New JAXB Types > Generated Artifacts dialog, specify the output location of the generated JAR file, as well as the Ant script generation options, and then click Next.
|
Note: You can also save the generated Ant script for future modifications to the generation of the JAXB artifacts. To do so, select Keep generated Ant script to save the file. |
On the next New JAXB Types > Customization Options screen, you may choose to specify additional options, and then click Finish.
Upon completion of the preceding procedure, Eclipse creates the JAXB type JAR file in your Web service project's WebContent/WEB-INF/lib directory.
For information on using generated JAXB types with your Web service, see Web Services Development: Starting Points for JAX-WS.
OEPE provides a set of ready-to-use common code snippets that you can access through templates and insert in your JAX-WS-enabled Web services Java code. This is useful when you instantiate a Web service client.
To insert a code snippet:
Within your Web service project, open a Java file to which you want to add the code.
Place the cursor at a particular location, and then press Ctrl+Space. This opens a descriptive list of titles of the code snippets available for your code. To display a detailed description and the snippet itself, select an item from the list.
Double-click the snippet title to insert it in your code.
Using the following automatically-generated code snippets, you can reference new or modify an existing Web service client:
Default WSDL location client Web service - use this option to create a basic Web service client reference.
The generated code will be of the following format:
SomeService service = new SomeService(); SomePortType port = service.getSomePort(); port.someOperation();
Specify WSDL location client Web service - use this option to create a basic Web service client reference, with the local declaration allowing for the URL specification.
The generated code will be of the following format:
// variable declaration - implementation injected by container @WebServiceRef(wsdlLocation="http://localhost:7001/SomeProject/SomeService?wsdl") SomeService service; // Web service call in the method block SomePortType port = service.getSomePort(); port.someOperation();
Web service reference client service - use this option to create a basic Web service client reference field declaration, where you will be required to specify the URL.
The generated code will be of the following format:
SomePortType port = service.getSomePort();
Binding binding = port.getBinding();
// can create new list or use existing one
List handlerList = binding.getHandlerChain();
handlerList.add(new HandlerChainImplementation());
binding.setHandlerChain(handlerList);
port.someOperation();
Attach programmatic client-side handler chain - use this option to attach a handler chain programmatically for a locally declared client service.
The generated code will be of the following format:
SomePortType port = service.getSomePort();
Binding binding = port.getBinding();
// can create new list or use existing one
List handlerList = binding.getHandlerChain();
handlerList.add(new HandlerChainImplementation());
binding.setHandlerChain(handlerList);
port.someOperation();
Web service reference client service with a handler chain - use this option to create a basic Web service client reference field declaration, where you will be required to specify the URL and a handler chain file location.
The generated code will be of the following format:
// variable declaration - implementation injected by container @javax.jws.HandlerChain(file="myhandler.xml") @WebServiceRef(wsdlLocation="http://localhost:7001/SomeProject/SomeService?wsdl") SomeService service; // Web service call in the method block SomePortType port = service.getSomePort(); port.someOperation();
|
Note: With the exception of the template that you use to programmatically attach a handler chain for a locally declared client service, all other templates require a WebLogic Web service-generated client JAR with attached source located in the |
You use the WebLogic Web Services Annotation view to add new and edit existing annotations of a Java Web service within projects configured with WebLogic Web Services or WebLogic Web Service Clients facet. This view allows you to add annotations and their attributes without knowing the detailed information about which annotations and attributes are supported.
To activate the WebLogic Web Services Annotation view:
In the Project Explorer, open one of the source Java files from your project that contains a Web service. Use the Java code editor to open the file.
Select Window > Show View > Other from the top menu to open the Show View dialog. Select Web Services > WebLogic Web Service Annotations from the list, and then click OK to open the view.
The figure below shows the activated WebLogic Web Service Annotations view that makes the annotation selected in the Java source available for editing.
You use the WebLogic Web Services Annotations view as you would any other editor.
When using the WebLogic Web Services Annotations view, consider the following features:
When you select a valid Java element in the Java editor, a set of tabs is displayed, with each tab representing a supported annotation.
When you select an annotation in the Java editor, the corresponding tab is activated.
Each tab provides a property editor pertaining to the attributes for that particular annotation:
Each tab displays a link action to either Add or Remove the annotation from the Java source.
Annotations are automatically added when you start to edit an attribute on the property editor.
Annotations are automatically removed if all attributes are cleared from the property editor.
When you edit an attribute, the changes are immediately reflected in the Java source editor.
Edits in the Java source editor are immediately reflected in the WebLogic Web Services Annotations view's property editor.
You can clear the value or return to a default value by using the light bulb icon next to a field.
Default values are displayed in grey.
You can use the WebLogic Web Services Annotations view to edit the following annotations:
Class-level annotations:
WebService
SOAPBinding
HandlerChain
WebFault
ServiceMode
WebServiceClient
WebServiceProvider
BindingType
WebServiceRefs
SecurityPolicies
SecurityPolicy
Policies
Policy
Field-level annotations:
WebServiceRef
HandlerChain
Method-level annotations:
SOAPBinding
WebMethod
Oneway
WebResult
WebEndpoint
RequestWrapper
ResponseWrapper
Parameter-level annotations:
WebParam
|
Note: You can use some annotations, such as |
OEPE provides a validation utility for your WebLogic Web services projects that you develop in Eclipse IDE. Subject to validation are various artifacts and associations within the project, including compliance with specifications (for example, JSR-224), verification of referenced resources (for example, local and remote), and so on. The validation occurs by the means of a standard Eclipse validator that indicates errors in the Problems view, in the Project Explorer, and as markers in the source view, as Figure 1 and Figure 2 show.
When working with Java Web services in wls.web faceted projects, you can expect the following types of errors to be validated:
References:
annotations, with the following validation notes:
WebService - 1) Evaluate if name is specified as an attribute, in case of explicit service endpoint interface; 2) Evaluate if wsdlLocation declared differently on service endpoint interface and service implementation; 3) Evaluate if the referenced endpoint interface has the WebService annotation; 4) Evaluate if the referenced endpoint interface is an interface.
WebMethod - 1) Methods are not overridden; 2) Methods are public; 3) Method return type is not XmlBeans; 4) Method parameters are not XmlBean; 5) Non-WebMethod with WebService annotations;
SoapBinding - RPC encoded is not supported.
Exclude - Evaluate methods with this annotation for exclusion from WebMethod validation.
BindingType - HTTPBinding specified.
WebServiceProvider - Attribute wsdlLocation is required for Provider-based Web service when HTTPBinding type is not specified.
Runtime artifacts (context path):
Oracle WebLogic Server-specific errors.
Generated artifacts in synchronization.
To enable or disable validation:
Right-click your Web services project in the Project Explorer and select Properties from the drop-down menu. This opens the Properties dialog, as Figure 3 shows.
In the Properties dialog, expand the Validation node. The editor pane on the right displays all available validators whose settings you can modify (notice Web Services for WebLogic). From this pane, you can do the following:
Enable settings specific to your project.
Enable each particular setting.
Enable or disable all validators from the list.
Suspend validation.
Configure your workspace settings: this option becomes available if you select Suspend all validators, and then click Configure Workspace Settings. This opens the expanded Preferences > Validation dialog that Figure 4 shows.
|
Note: The default validation filters enable validation of Web services within a WebLogic Web services project (for example, those with the |
You can generate a WebLogic Web Service from an existing Spring service bean for your JAX-WS Web service project.
To generate the Web service:
Add the WebLogic Web Services facet to an Eclipse project configured with the Spring 2.5 facet and containing Spring service beans. For more information about configuring projects for Spring, see Generating Spring Artifacts.
In the Project Explorer, right-click your project, select New > Other from the drop-down menu, and then select Oracle > WebLogic > WebLogic Web Service for Spring Beans on the New dialog. This opens the Select Spring Service Bean dialog.
On the Select Spring Service Bean dialog, specify the Spring bean configuration. The list will be populated with Spring service beans defined in the configuration file. Select a service bean and service methods from the service interface that you want to expose as WebLogic Web Service, and then click Next.
|
Note: While one service bean can implement multiple interfaces, you can only select methods from one interface at a time. To expose methods in other interfaces, you need to generate a separate Web service. Also note that Spring ORM service beans implemented in Spring 1.n-style based on the |
On the next page, Web Service Class Name dialog, shown in Figure 4, you may choose to specify the Web service class name, package name and output directory, and then click Finish.
Upon completion of the preceding procedure, Eclipse creates the WebLogic Web Service class which is automatically wired up with Spring bean and delegate service calls to the Spring bean implementation.
Use the HTTPS Client Credentials page to specify the keystores Eclipse should use when handling HTTPS traffic.
HTTPS encrypts an HTTP message prior to transmission and decrypts it upon arrival. It uses a public key certificate signed by a trusted certificate authority. Use the HTTP Client Credentials tab to enter details of the certificate keystore for the client. The client keystore identity is used for configuring HTTPS.
For more information about keystores and keystore providers, see Understanding Security for Oracle WebLogic Server.
To configure credentials:
From the main menu, choose Window > Preferences.
In the Preferences dialog, select WebLogic > Credentials.
On the Credentials page, select a WebLogic Server runtime to configure its keystore and credential information or add a new runtime.
With a runtime selected, configure its HTTPS Client Credential information in the HTTPS Client Credentials section:
Client Trusted Certificate Keystore: Enter, or browse to, the location of the client certificate keystore.
Client Trusted Keystore Password: Enter the password for the client keystore. The default is DemoTrustKeyStorePassPhrase.
Edit Keystore: Click to add or remove entries in the keystore.
Client Keystore: Enter or browse to the location of the client keystore.
Client Keystore Password: Enter the password for the client keystore.
Client Private Key Password: Enter the client private key password.
Append default CA certificates: Select to add the CA certificates.
Restore Defaults: Click to restore default settings.
|
 Copyright © 2008, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|