Version 8.2.7
 —  Business Services  —

Generating Java Clients and Web Services

After creating business services locally, or downloading them from an existing server installation, you can create Java clients and/or Web services for the services. This section covers the following topics:


Generate a Java Client

Using the Generate Java Client wizard, you can develop Java client applications that access Natural Business Services server components via dynamic RPC. The wizard creates Java clients from Natural Business Services objects in a NaturalONE project and then generates the Java client interface objects used by the Java client to access the server components.

Start of instruction setTo generate a Java client:

  1. Open the context menu for the business service in the Navigator view (i.e., the BusinessServiceName.bsrv file).

  2. Select Generate Java Client.

    The Configure Generated Class panel is displayed. For example:

    graphics/generate-java-client.png

    Using this panel, you can:

    Task Procedure
    Generate a Web service file (file with a .aar extension). Select Generate Web Service (.aar) file. The Web service file will be created when the class is generated.
    Deploy the generated Web service to a WS-Stack runtime environment. See Deploy a Generated Web Service.
    Suppress the generation of a JUnit test file containing test functions that correspond to each method in the business service. Deselect Generate JUnit test file.

    Note:
    For a description of the JUnit test file, see Test the Java Class.

    Redesign the interface for Natural subprograms, such as changing the default IDL directions or selecting which portions of a redefined field to use. See Redesign the Interface.
  3. Type the name of the source folder in Source folder or select Browse to browse for a folder.

    If you select a project as the source folder, the wizard will automatically create and use <projectname>/Java/src as the source folder. In addition, the wizard will set the output/compilation folder to the bin folder corresponding to the source. For example, if the source folder is set to Java/src, then the output/compilation folder will be set to Java/bin.

    Note:
    The folder must currently exist.

  4. Type the name of the package in Package name or select Browse to browse for a package.

    The package does not have to currently exist.

  5. Select Finish to generate the Java class.

    The class and associated files are displayed in the Navigator view. For example:

    graphics/navigator-java-class.png

    In this example, the following items were generated in the Calculator node:

    Item Generated Description
    Calculator node in src Java package.
    CalculatorData.java Java class containing the PDA for the business service, which is mapped to Java. This class has the same name as the business service and a suffix of "Data".
    CalculatorService.java Java class containing the code that communicates with the business service, as well as the Add method. This class has the same name as the business service and a suffix of "Service".
    CalculatorServiceTest.java JUnit class with the same name as the CalculatorService.java class and a suffix of "Test". For more information, see Test the Java Class.

    Note:
    This file is only generated when the Generate JUnit test file option is selected.

    nbs.properties file A .properties file for the business service. For more information, see Set the nbs.properties File to Run a Dynamic RPC Java Class.
    log4j-1.2.15.jar file in lib Library containing the logging functionality.
    wrappercore.jar file in lib Library containing the helper classes and functionality for the generated Java class.

The business service class is displayed in the editor view. For example:

graphics/editor-java-class.png

To display the JUnit class, select the CalculatorServiceTest.java tab. For example:

graphics/editor-java-class-test.png

Note:
This file is only generated when the Generate JUnit test file option is selected.

To display the properties file for the business service, select the nbs.properties tab. For example:

graphics/editor-java-class-nbs-properties.png

This section covers the following topics:

Deploy a Generated Web Service

This section describes how to deploy a generated Web service to a WS-Stack runtime environment.

Note:
To use this option, you must first select Generate Web Service (.aar) file on the Configure Generated Class panel.

Start of instruction setTo deploy a generated Web service:

  1. Select Deploy the generated Web Service.

  2. Select Next.

    The Deploy NaturalONE Web Service panel is displayed. For example:

    graphics/deploy-nat1-web-service.png

    This panel displays the default parameters for the WS-Stack runtime environment running in the default Tomcat servlet engine. The default user credentials are also displayed (these can be changed at first logon).

  3. Confirm the name and location of the WS-Stack runtime environment.

  4. Confirm the user credentials.

  5. Select Finish.

    For more information on deploying a Web service or changing logon credentials, refer to the Web Services Stack documentation.

Redesign the Interface

This section describes how to redesign the interface generated for a Java client.

Start of instruction setTo redesign the interface:

  1. Select Redesign the interfaces on the Configure Generated Class panel.

  2. Select Next.

    The Design Interface for Natural Subprogram panel is displayed. For example:

    graphics/design-interface-for-natural-subprogram.png

    The upper left pane on this panel displays the parameters for the Natural subprogram and allows you to select operations (for example, Map to In, Map to Out, Map to InOut, or Suppress). The upper right pane displays the IDL directions that will be inserted as top-level parameters (level 1) in the interface definition for the Natural subprogram. The bottom pane is used for reference purposes; it displays the Natural subprogram source and its PDA sources, each in a separate tab.

    Tip:
    To reserve more space for viewing the upper panes, you can close the bottom pane when it is not needed.

    Using this panel, you can:

    Task Procedure
    Define the direction of parameters in the interface. See Define the Direction of Parameters.
    Select which portions of redefined fields in the PDA to use. See Select Portions of Redefined Fields.
    Hide or suppress unneeded parameters in the interface. See Suppress Parameters.
  3. Select Finish.

    If you selected multiple Natural subprograms, you can now redesign the next interface. The current and total number of subprograms designed so far is indicated in the title (for example, 2/3).

Note:
For more information about using this panel, refer to the EntireX documentation.

Define the Direction of Parameters

This section describes how to change the default IDL directions for the generated Java client.

Start of instruction setTo define the direction of parameters:

  1. Expand the INPUT-OUTPUT and OUTPUT nodes in the upper left pane of the Design Interface for Natural Subprogram panel.

    For example:

    graphics/design-interface-for-natural-subprogram-expanded.png

    Note:
    Natural parameters that are mapped in the interface are marked with a green circle.

  2. Open the context menu for the first level 1 parameter you want to define.

  3. Select one of the following options:

    The operation is reflected in the IDL Library pane.

  4. Continue defining level 1 parameters as desired.

  5. Select Finish.

Select Portions of Redefined Fields

This section describes how to select which parameters redefined in the Natural PDA are used in the interface.

Start of instruction setTo define which portions of a redefined field to use:

  1. Expand the INPUT-OUTPUT and OUTPUT nodes in the upper left pane of the Design Interface for Natural Subprogram panel.

    For example:

    graphics/design-interface-for-natural-subprogram-redefine.png

    Redefined fields are identified by the graphics/redefine-icon.png icon.

  2. Open the context menu for the REDEFINE base parameter or any REDEFINE path.

  3. Select Map to InOut.

  4. Select Finish.

Suppress Parameters

This section describes how to suppress unnecessary parameters, which creates a less cluttered IDL client interface and minimizes the amount of data transferred at runtime.

Start of instruction setTo suppress parameters in the interface:

  1. Open the context menu for the parameter in the upper left pane.

  2. Select Suppress.

  3. Select Finish.

    Natural parameters suppressed in the interface are displayed in italic type.

Set the nbs.properties File to Run a Dynamic RPC Java Class

You can set the nbs.properties file to run a dynamic RPC Java class. The settings to run the Java class are loaded by the NBSSettings class. This class will try to find the nbs.properties file using the following search order:

  1. nbs_properties Java system property pointing to the file

  2. nbs_properties environment variable pointing to the file

  3. class loader for NBSSettings

  4. class loader for context for current thread

The entries in the nbs.properties file are:

Setting Description Default
broker.id Broker connection ID. localhost:1971
broker.service Broker service endpoint. RPC/SRV1/CALLNAT
user.id User ID to use with Broker. GUEST
password Password to use with Broker. blank/empty string

For example:

broker.id=BKR13003:4010
broker.service=RPC/NBS53DEV/CALLNAT
user.id=PWRUSR
password=

Note:
If the generated code will be used in AXIS2, you must copy the nbs.properties file to the <WebApp>/classes folder.

Warning:
For security reasons, it is recommended that the password not be set in the nbs.properties file. It is much more secure to set the Broker credentials programmatically.

Define Different User IDs and Passwords for Web Services

Both the user.id and password properties can use a Java class suffix (for example, package.MyService), which allows the client to use different user IDs and passwords for different services and/or groups of services. For example:

user.id.package.name.MyService=USERIDA
password.package.name.MyService-PWDA
user.id.package.name=USERIDB
password.package.name=PWDB
user.id=PWRUSR
password=

When the MyService Web service in the package.name Java package is invoked, the USERIDA user ID and PWDA will be used. When any other service within the package.name Java package is invoked, the USERIDB user ID and PWDB password will be used. All other services will use the PWRUSR user ID and no password.

Use log4j Logging Statements in a Runtime Environment

The generated Java classes support log4j logging statements for advanced diagnostics at runtime. If logging is being used, there is the potential for data to be visible in the log files produced in the runtime environment. To avoid this problem, configure the com.softwareag.naturalone.gen.dynamicrpc.core logger file to only display warnings and above. For example:

log4j.logger.com.softwareag.naturalone.gen.dynamicrpc.core=WARN

Test the Java Class

When you select Generate JUnit test file on the Configure Generated Class panel before generating the class, a JUnit class is also generated. This class contains test functions that correspond to each method in the business service. For example:

@Test
	public void testAdd() throws Exception {
		Calculator service = createService();
		CalculatorData data = new CalculatorData();
		//TODO populate data
		CalculatorData result = service.add(data);
		Assert.assertNotNull("Result is null", result);
		//TODO check result
	}

//TODO comments have been added in the source to indicate where additional information is added for the test. By default, the test succeeds if no errors occur during the call to the business service and if data is returned.

Data can be added before the service method is invoked. For example:

		//TODO populate data
		data.getCalcInput_data().set_first_num(new BigDecimal(2));
		data.getCalcInput_data().set_second_num(new BigDecimal(2));

In addition, an assert clause can be included to verify that the result is correct. For example:

		//TODO check result
		Assert.assertEquals(new BigDecimal(4), 
			result.getCalcOutput_data().get_result());

Tests can be invoked using standard Eclipse JUnit functionality (i.e., run as Junit test). The environment for the test is contained in this function in the test file. For example:

	private Broker createBroker() throws BrokerException {
		String userID = "GUEST";
		String password = "";
		Broker broker = 
new Broker(Demotest.DEFAULT_BROKERID, userID,
				Demotest.DEFAULT_SERVER);
		broker.logon(password);
		return broker;
	}

Write an Application to Use the Generated Java Class

After generating a Java class, you can write an application that uses the class to invoke a business service. Use the following code as a template for writing the application; read the comments for additional information:

// Create the EntireX Broker object
Broker b = new Broker("localhost:1971","GUEST");
// Create the service class.
Calculator calcservice = new Calculator(b, "RPC/SRV1/CALLNAT");
// Create the service data class
CalculatorData calcdata = new CalculatorData();
// Set input values for the call
calcdata.getCalcInput_data().set_first_num(new BigDecimal(2));
calcdata.getCalcInput_data().set_second_num(new BigDecimal(2));
calcdata.getCalcInput_data().set_function("Add");
// Invoke a service method, passing in the data class
// make sure to catch any errors that might happen.
CalculatorData calcresult = null;
try {
	calcresult = calcservice.add(calcdata);
} catch (DataException e) {
	e.printStackTrace();
} catch (BrokerException e) {
	e.printStackTrace();
} catch (ServiceException e) {
	e.printStackTrace();
}
// Examine the result
System.out.println("Result is:"
		+ calcresult.getCalcOutput_data().get_result());

Top of page

Generate a Web Service

Using the Generate Java Client wizard, you can generate a Web service from business service object in a NaturalONE project. The generated Web service objects are WS-Stack Web service archive files (files with a .aar extension) and can be deployed in a Web services Stack runtime environment and registered in CentraSite. Web service client applications can then access these Web services and expose business logic implemented by the Natural server components.

Start of instruction setTo generate a Web service:

  1. Open the context menu for the business service in the Navigator view (i.e., the BusinessServiceName.bsrv file).

  2. Select Generate Web Service.

    The Configure Generated Class panel is displayed. For example:

    graphics/generate-web-service.png

    Using this panel, you can:

    Task Procedure
    Change the source folder in which to generate the Java class. Type the name of the source folder in Source folder or select Browse to browse for an existing project. The folder must currently exist.
    Change the name of the Java package or select another package. Type the name of the Java package in Package name or select Browse to browse for an existing package. The package does not have to currently exist.
    Suppress the deployment of the generated Web service to a WS-Stack runtime environment. Deselect Deploy the generated Web Service.
    Register the Web service after it has been generated and deployed. Select Register the generated and deployed Web Service.

    Note:
    To select this option, Deploy the generated Web Service must also be selected.

    Suppress the generation of a JUnit test file containing test functions that correspond to each method in the business service. Deselect Generate JUnit test file.

    Note:
    For a description of the JUnit test file, see Test the Java Class.

  3. Select Next.

    The Deploy NaturalONE Web Service panel is displayed. For a description of this panel, see Deploy a Generated Web Service.

  4. Select Finish to generate the Java class for the Web service.

Configure the Web Service to Use WS-Security

All generated services extend "com.softwareag.naturalone.gen.dynamicrpc.core.AbstractService". The default constructor for the generated service determines which Broker credentials to use based on the following rules:

  1. When WS-Security is turned on and the credentials are passed in the SOAP header, they will be used in the call to Broker.

  2. In all other cases, the settings in the nbs.properties file will be used. For information, see Set the nbs.properties File to Run a Dynamic RPC Java Class.

Start of instruction setTo configure a Web service to use WS-Security:

  1. Open the context menu for a business service in the Navigator view.

  2. Select Generate Web Service.

    The Configure Generated Class panel is displayed. For example:

    graphics/generate-web-service.png

  3. Deselect Deploy the generated Web Service.

  4. Select Finish.

    The generated Web service files are displayed in the Navigator view. For example:

    graphics/generate-web-service-files-generated.png

  5. Open the generated .aar file in the editor view.

  6. Select the Services tab.

  7. Select Enable WS-Security in the Modules section.

    The settings in the Security section are displayed. For example:

    graphics/ws-security-settings-in-aar-file.png

  8. Select the following settings.

  9. Save the changes to the .aar file.

  10. Open the context menu for the .aar file.

  11. Select Web Service Stack > Deploy Web Services Package.

    The Deploy Your Web Services panel is displayed. For a description of this panel, see Deploy a Generated Web Service.

On the client, the following SOAP header must be included with the correct credentials specified:

<soapenv12:Envelope xmlns:soapenv12="http://www.w3.org/2003/05/soap-envelope">
      <soapenv12:Header>
            <wsse:Security xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
            >
                  <wsse:UsernameToken>
                        <wsse:Username>MyUser</wsse:Username>
                        <wsse:Password>MyPassword</wsse:Password>
                  </wsse:UsernameToken>
            </wsse:Security>
      </soapenv12:Header>
      <soapenv12:Body>

Note:
Since user credentials will be included in the SOAP header, it is highly recommended that you use HTTPS. For instructions on how to configure AXIS2 to use HTTPS, refer to the AXIS2 documentation.

Top of page