4 Developing Custom Web Services

Signature Components

A web service operation signature contains the following:

• Operation name

  The pattern for defining an operation name is [action][EntityName] where action represents a verb action (such as create, update, delete) and the EntityName represents the entity acted upon (such as Equipment, LogicalDevice, TelephoneNumber). For example:

  • createEquipment

  • updateLogicalDevice

  • deleteTelephoneNumber

• Request type

  The pattern for defining a request type is operationNameRequestType. A single request type is defined per operation. For example:

  • CreateEquipmentRequestType

  • UpdateLogicalDeviceRequestType

  • DeleteTelephoneNumberRequestType

• Response type

  The pattern for defining a response type is operationNameResponseType. A single response type is defined per operation. For example:

  • CreateEquipmentResponseType

  • UpdateLogicalDeviceResponseType

  • DeleteTelephoneNumberResponseType

• Fault types

  The pattern for defining a fault type is businessFaultFaultType, where businessFault represents a specific business fault that might be thrown back to the user. Multiple business faults can be defined per operation. For example:

  • EquipmentNotUniqueFaultType

  • EquipmentNotFoundFaultType

  • NotAuthorizedFaultType

  Fault types contain the error codes and stack trace set by the business logic. One-to-one mapping between thrown business logic exceptions and the defined business faults is required to capture the different exceptions.

Signature Pattern and Examples

The signature pattern of an operation in the Reference Web Service is defined as follows:

public OperationNameResponseType operationName(
        OperationNameRequestType operationNameRequest) throws
            businessFault1FaultType,
            businessFault2FaultType,
            businessFaultNFaultType

For example, the createLogicalDevice method is defined in the LogicalDeviceAdapter.java file as the following:

public CreateLogicalDeviceResponseType createLogicalDevice(
                        CreateLogicalDeviceRequestType createLogicalDeviceRequest)                      throws
            InventoryFaultType,
            ValidationFaultType

Table 4-2 shows the operation signature pattern on commonly used actions. In the table, Entity represents the name of the entity (such as Equipment, LogicalDevice, TelephoneNumber) acted upon by the operation.

CreateEntityResponseType createEntity
   (CreateEntityRequestType request) throws
   businessFault1FaultType,
   businessFault2FaultType

FindEntityResponseType findeEntity
   (FindEntityRequestType request) throws
   businessFault1FaultType, 
   businessFault2FaultType

UpdateEntityResponseType updateEntity
   (UpdateEntityRequestType request) throws
   businessFault1FaultType, 
   businessFault2FaultType

DeleteEntityResponseType deleteEntity
   (DeleteEntityRequestType request) throws
   businessFault1FaultType, 
   businessFault2FaultType

CalculateEntityResponseType calculateEntity
   (CalculateEntityRequestType request) throws
   businessFault1FaultType, 
   businessFault2FaultType

WebLogic Server

You must install Oracle WebLogic Server locally. This installation provides the correct version of the JDK. Depending on the references in your code, you should determine the specific WebLogic files that are required from the installation to build the web services project.

You can also run WebLogic Server locally; however, UIM is not supported on Windows. Therefore, UIM can run on Windows for development purposes only. You can optionally run WebLogic Server remotely.

UIM

To build your project, you must have access to some of the UIM installation files. You can copy these files from a UIM installation on a UNIX machine to your machine, or you can install UIM locally. The following UIM files are needed:

• UIM_SDK_Home/webservices/reference_webservice.zip

• UIM_Home/app/custom.ear or inventory.ear

• WebLogic Server patch files, if applicable, which are located in UIM_Home/lib/*.jar

Design Studio

Install and configure Design Studio to work with the Reference Web Service, and to develop new custom web services. See UIM Developer's Guide for information about using Design Studio to extend UIM, including information about installing and configuring Design Studio.

You must also set the ANT_HOME system variable. See UIM Developer's Guide for more information.

Configuring the COMPUTERNAME.properties File

You set the variables in the COMPUTERNAME.properties file as the first step in configuring your project. This file contains the values that vary between projects, such as path names and the WSDL name. To configure the reference_webservice/etc/COMPUTERNAME.properties file:

1. Copy and rename the COMPUTERNAME.properties file to reflect the name of the computer on which you have Design Studio installed. You can determine your computer name by running the following DOS command:

   echo %COMPUTERNAME%
    
   

   An example of the resulting file name is xlc123tx.properties.

2. Update the parameter values defined in the file to reflect the information appropriate to the computer on which you are developing custom web services.

   Table 4-4 file defines the following parameters for the properties file:

   Table 4-4 COMPUTERNAME.properties File Parameters

   Parameter	Description
   WSDL_NAME=ReferenceUim	The name of the WSDL file without the file extension. It is also used for deriving the context path and service URI for the generated web services WAR file. For example, in this case the web service context path and URI for the HTTP protocol is: /ReferenceUim/ReferenceUimHTTP and for JMS protocol is: /ReferenceUim/ReferenceUimJMS
   QUEUE_NAME=inventoryCustomWSQueue	The name of the JMS Web Service Queue. It matches the name of the queue used in the WSDL for the SOAP <address> element for the service port. If you package your custom web service in an EAR file other than the provided custom.ear file, you must create your own message queue and configure your custom web service to use that queue by changing the QUEUE_NAME. See "Packaging the WAR File in the EAR File" for more information.
   MODULE_NAME=reference_webservice	The name of the web service module. The name is used for creating the distributable web service cartridge. It is also the name of the directory where the generated web service WAR file is stored.
   FMW_HOME=C:/Oracle/Middleware/Oracle_Home	The Fusion Middleware WebLogic Server installation directory name.
   WL_HOME=${FMW_HOME}/wlserver_Release	The WebLogic Server installation path that incorporates the FMW_HOME parameter, where Release is the directory version name portion of the WebLogic Server library files if needed given the installation.
   DOMAIN_HOME=C:/Oracle/Middleware/Oracle_Home/projects/domains	The directory path of the WebLogic Server domains.
   DOMAIN_NAME=uim_Release	The domain name where uim_Release is the domain name with the UIM release number.
   UIM_HOME=${DOMAIN_HOME}/${DOMAIN_NAME}/UIM	The UIM home path. The DOMAIN_HOME, DOMAIN_NAME and UIM_HOME parameters collectively specify the UIM installation path.
   APP_LIB=${UIM_HOME}/lib	The working directory to which dependent JAR files are extracted from the inventory.ear file. This working directory is automatically created for you based on the name provided here.
   EAR_PATH=${UIM_HOME}/app/custom.ear	The directory where the custom.ear file is located. If you package your custom web service in a custom EAR file other than the provided custom.ear file, you must configure your custom web service to use your custom EAR file by changing the EAR_PATH value. See "Packaging the WAR File in the EAR File" for more information.
   POMS_ROOT=C:/uim/OracleCommunications/POMSClient/lib	The location of the POMS JAR file.
   PLATFORM=C:/uim/OracleCommunications/commsplatform/ws	The location of the Platform web service JAR file.
   PATCH_CLASSPATH=pathFileDirectoryAndFile	The path to any WebLogic patch files, if applicable. You must replicate this parameter for each WebLogic patch file to specify the path and specific patch file name.

   
   

Configuring the web.xml File

The web.xml file must be modified to contain the listener class reference. To configure the reference_webservice/WEB-INF/web.xml file, add the following:

<listener>
    <listener-class>
        oracle.communications.inventory.api.framework.listener.
        InventoryWebApplicationListener
    </listener-class>
</listener>

Configuring the Project Library List

The project library list of JAR files does not indicate the location of the files, so you must configure the project library list to point to the location of the JAR files.

Figure 4-8 shows the imported project library list, which includes the JAR files needed to compile the project.

Figure 4-8 Project Library List Before Configuring

Description of ''Figure 4-8 Project Library List Before Configuring''

The required JAR files can be categorized into three groups:

• WebLogic files (FMW_LIB)

• Platform files (POMS_LIB and POMS_PLIB)

• UIM files (UIM_LIB)

You perform the following to configure the Design Studio project:

• Add new variables named FMW_LIB, POMS_LIB, POMS_PLIB, and UIM_LIB to your project.

• Define these variables to point to the directories listed in Table 4-5.

For detailed instructions on how to configure the project library list, see the Design Studio Help.

Result of Configuring Project Library List

Figure 4-9 shows the project library list after the variables are added. Notice that the library list now includes the location of the JAR files, not just the JAR file names.

Figure 4-9 Project Library List After Configuring

Description of ''Figure 4-9 Project Library List After Configuring''

Adding the variables is one way to configure the library list; you can alternatively perform the following:

1. Write down the names of the required files.

2. Click Add External JARS.

3. Navigate to the directory location of JAR files.

4. Add it directly to the library list.

Either way, the result is the same. The library list has the location to the files needed to compile the project.

Information to Capture

You must capture a specific set of information to create a new web service. This information is available in the Javadoc after locating the method you plan to wrap. Capture the following information:

• Class name that defines the method to wrap

• Package in which the class resides

• Method signature information:

  • Method name

  • Input parameters

  • Return values

  • Exceptions thrown

For example, the CreateLogicalDevice web service operation wraps the createLogicalDevice() API method. The following information was used to define this web service in the LogicalDeviceAdapter.java file:

• LogicalDeviceManager is the UIM manager class that defines the createLogicalDevice() method.

• LogicalDeviceManager resides in the package oracle.communications.inventory.api.logicaldevice.

• The method signature information includes:

  • Method name: createLogicalDevice

  • Input parameters: Collection of LogicalDevice objects

  • Return values: List of LogicalDevice objects

  • Exceptions thrown: ValidationException

Creating the WSDL File

The imported project contains the ReferenceUim.wsdl file, which defines the example web service operation. Model your custom WSDL file after the ReferenceUim.wsdl file. For more information, see the W3C Web Services Description Language website at:

http://www.w3.org/TR/wsdl

WSDL Naming Conventions

The ReferenceUim.wsdl file uses WSDL_NAME variable in the COMPUTERNAME.properties file for naming its various SOAP elements. This naming convention allows the build.xml Ant targets to parse these elements consistently, and to generate the correct source files for the web service interfaces and implementation. Consider the following list of naming conventions for the WSDL file:

• ReferenceUim

  This is the name of the WSDL file without the file extension as set by the WSDL_NAME variable in the COMPUTERNAME.properties file. This name is also used to automatically set other important variables in the build.xml file, such as SERVICE_NAME and PORT_NAME. This name is assumed to be the name of the root definitions element in the WSDL file. This name identifies the name of the following files, which are generated later in the process: ReferenceUimPort.java, ReferenceUimPortImpl.java, ReferenceUim.war, ReferenceUimHTTP.war, and ReferenceUimJMS.war.

• ReferenceUimPort

  This is the name of the PortType that is generated for the implementation later in the process. It is used by the generated source ReferenceUimPort.java and ReferenceUimPortImpl.java.

• ReferenceUimHTTPSoapBinding

  This is the name of the SOAP binding for web service operations that are exposed through the HTTP transport protocol. The list of operations identified in this binding element can be a subset of the operations identified in the <PortType> element. The list of operations can be the same as or different from the JMS protocol operations.

• ReferenceUimJMSSoapBinding

  This is the name of the SOAP binding for web service operations that are exposed through the JMS transport protocol. The list of operations identified in this binding element can be a subset of the operations identified in the <PortType> element. The list of operations can be the same as or different from the HTTP protocol operations.

• ReferenceUimHTTPPort

  This is the name of the HTTP transport port used in the UIMReference service definition.

  It references the ReferenceUimHTTPSoapBinding binding element identified earlier. Also, the SOAP address location uses the following for the context path (HTTP):

  http://localhost:7001/ReferenceUim/ReferenceUimHTTP
  

• ReferenceUimJMSPort

  This is the name of the JMS transport port used in the UIMReference service definition.

  It references the ReferenceUimJMSSoapBinding binding element identified earlier. Also, the SOAP address location uses the following for the context path (JMS):

  jms://localhost:7001/ReferenceUim/ReferenceUimJMS?URI=inventoryCustomWSQueue
  

For example, if you create a new file named MyInventoryWs.wsdl, the naming conventions result in:

• MyInventoryWsPort

• MyInventoryWsHTTPSoapBinding

• MyInventoryWsJMSSoapBinding

• MyInventoryWsHTTPPort

• MyInventoryWsJMSPort

Creating Schema Files

The imported project provides supporting schemas for the Reference Web Service operation. The schemas define the inputs, outputs, and faults of the wrapped methods. The schemas are used to generate the Java representation of the incoming/outgoing XML, which can then be mapped to an internal Java entity class (see "EntityMapper.java"). The Java representation is generated by the generate-from-wsdl Ant target.

For a new web service, new schemas must be written that reflect the inputs and outputs of the wrapped method.

Modifying the Mapping File

The imported project provides the type-mapping.xsdconfig mapping file. This file maps XML namespaces to Java packages. For a new web service, you modify the mapping file to update the namespace-to-Java package mappings.

Creating Java Source Files

The imported project provides the supporting Java code for the Reference Web Service operation. The following list of Java files is a recommended set of classes to implement.

• ReferenceUimPortImpl.java

• AdapterRouter.java

• EntityAdapter.java

• EntityValidator.java

• EntityUtils.java

• EntityWorker.java

• EntityMapper.java

• EntityException.java

• FaultFactory.java

The following sections describe detailed information about the recommended Java source files.

ReferenceUimPortImpl.java

The ReferenceUimPortImpl class is the entry point into the web service logic. This class calls the AdapterRouter class.

ReferenceUimPortImpl.java is a generated source file with the content based on the ReferenceUim.wsdl file. This file is generated by the generate-from-wsdl Ant target and is placed in the following directory:

codegen/WebServiceImpl/oracle/communications/inventory/webservice/ws

Copy this file to the following destination directory:

src/oracle/communications/inventory/webservice/ws

You use this destination directory as a starting point for the implementation of the web service calling the respective adapter classes.

This class must be modified to call the AdapterRouter for each new web service operation. Because this is a generated file, the modifications are based on the WSDL file.

AdapterRouter.java

The AdapterRouter class routes the call to a specific adapter. If the input from the external source requires mapping, the corresponding mapper class is the input/output parameter for this AdapterRouter class.

This class must be modified for each new web service operation.

EntityAdapter.java

Adapter classes extend the InventoryAdapterRoot class, which extends the Platform-owned AdapterRoot class. The UIM Reference Web Service provides the LogicalDeviceAdapter class as an example. Adapters wrap the calls to the UIM API methods. Typically, one adapter class exists per manager class, such as EquipmentAdapter.java and TelephoneNumberAdapter.java. However, one adapter class can wrap multiple methods from different manager classes.

Oracle recommends that adapters be as thin as possible. They should simply contain a call to the Manager API or to other worker classes.

An adapter calls EntityValidator and, if validations pass, calls the business layer API method.

An existing adapter class must be modified, or a new adapter class written, for each new web service operation.

EntityValidator.java

Validator classes define an input validation method per a web service operation (where applicable). The adapter classes call the corresponding input validation method before calling the wrapped API method. The throw an error if the validation is not passed.

For cases where input data is passed in, a new validator class is needed per entity. The UIM Reference Web Service example does not contain this type of class file.

EntityUtils.java

Utils classes define common utility methods used by the Reference Web Service operations.

The existing EntityUtils class can be extended or a new utils class written, as needed during the development of a new web service.

EntityWorker.java

Worker classes define methods used by the web service operations.

EntityWorker classes can be written as needed during the development of a new web service. The UIM Reference Web Service example does not contain this type of class file.

EntityMapper.java

Mapper classes map the generated object representation of the schemas (external) to the Java entity class (internal) for input parameters. Mapper classes map the Java entity class (internal) to the generated object representation of the schemas (external) for output parameters. One mapper class maps a single entity. A mapper class can be shared across methods in an adapter class if the methods use the same entity.

For cases where the source code references the entity data, a new mapper class is needed per entity.

EntityException.java

Exception classes define exceptions specific to a web service.

The existing EntityException classes can be extended or a new exception class written, as needed during the development of a new web service.

FaultFactory.java

The FaultFactory class maps Exception objects thrown by the API method to InventoryFaultType objects returned by the web service.

You may need to modify this class for a new web service; it depends on whether the API method introduces any new Exception objects that are not already mapped.

Extracting and Updating the application.xml File

Every EAR file contains an application.xml file, which defines the WAR files that comprise the EAR file. Regardless of which packaging option you choose, the custom web service WAR file needs to be included in the EAR file, so the application.xml file must be updated to include the name of the custom web service WAR file.

Extracting the File

The provided custom.ear file contains an application.xml file that you can manually extract, use as a starting point, and modify as needed.

If you are using the provided custom.ear file to package your custom web service, you can use the extract.ear Ant target to automatically extract the application.xml file. The EAR file is specified by the EAR_PATH parameter in the COMPUTERNAME.properties file. The XML file is extracted into the reference_webservice_home/META-INF directory, where reference_webservice_home is the location of the extracted reference_webservice.zip file. See "About the Ant Build File" for more information on the Ant targets.

Updating the application.xml File

Example 4-4 shows the original application.xml file from the custom.ear file. For the custom web service, you add the following information to the <module> element to identify the following for the custom web service:

• The WAR file name, such as ReferenceUim.war

• The WSDL file prefix, such as ReferenceUim

You add the <web-uri> item for the WAR file name and the <context-root> item for the WSDL name, as shown in Example 4-5.

<?xml version = '1.0' encoding = 'windows-1252'?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" version="5" xmlns="http://java.sun.com/xml/ns/javaee">
    <display-name>oracle.communications.inventory.customear</display-name>
    <module>
        <java></java>
    </module>
</application>

<?xml version = '1.0' encoding = 'windows-1252'?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" version="5" xmlns="http://java.sun.com/xml/ns/javaee">
    <display-name>oracle.communications.inventory.customear</display-name>
    <!-- Custom Web Service WAR -->
    <module>
        <web>
            <web-uri>ReferenceUim.war</web-uri>
            <context-root>ReferenceUim</context-root>
        </web>
    </module>
</application>

Additional Custom Work

This section describes additional work you must perform when packaging your custom web services in your own custom EAR files.

Example 4-6 shows the custom.ear file content with a view of the notable directories and files. An EAR file format is similar to a ZIP file format.

01      META-INF
02          application.xml
03          weblogic-application.xml
04      InventoryCustomQueueMDB.jar
05          META-INF
06              ejb-jar.xml
07              weblogic-ejb-jar.xml
08          oracle
09              communications
10                  inventory
11                      ejb
12                          message
13                              custom
14                                  impl
15                                      InventoryCustomQueueListener.class
16      poms-ejbs.jar

Your custom EAR file content must use the custom.ear file content as a template to apply your modifications. Your modifications may include the following:

• Referencing corelib and customlib

• Creating a Message Queue

• Creating a Listener Class

• Configuring the Listener Class

Referencing corelib and customlib

Each custom EAR file must contain a reference to the following libraries:

oracle.communications.inventory.corelib
oracle.communications.inventory.customlib

You reference these libraries within the META-INF/weblogic-application.xml file (line 03 in Example 4-6).

For an example to emulate, see the weblogic-application.xml file in the custom.ear file. Example 4-7 shows the contents of the weblogic-application.xml file.

<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-application">
<!-- Use the common Oracle Platform Security Services -->
<!-- oracle.communications.inventory application policies -->
  <application-param>
    <param-name>jps.policystore.applicationid</param-name>
    <param-value>oracle.communications.inventory</param-value>
  </application-param>
  <library-ref>
      <library-name>oracle.communications.inventory.corelib</library-name>
      <specification-version>7.3</specification-version>    
      <implementation-version>7.3.1.0.0</implementation-version>    
      <exact-match>false</exact-match>
  </library-ref>
  <library-ref>
      <library-name>oracle.communications.inventory.customlib</library-name>
      <specification-version>7.2</specification-version>    
      <implementation-version>7.2.0.0.0</implementation-version>    
      <exact-match>false</exact-match>
  </library-ref>
</weblogic-application>

Creating a Message Queue

If you create multiple custom web services, Oracle recommends they reside in different EAR files. Web services that reside in different EAR files cannot listen to the same queue, so you must create a message queue for each web service. In addition, Oracle recommends that you provide a message-driven bean (MDB) to dispatch requests for multi-threaded processing to ensure optimum performance of your custom web service.

See the WebLogic Server Administration Console documentation for information about creating message queues. See the Java Platform, Java EE Tutorial website at:

https://docs.oracle.com/javaee/7/tutorial/ejb-intro003.htm

for more information on message-driven beans.

Creating a Listener Class

You must create one listener class for every message queue you create. Example 4-8 shows a custom listener class named MyCustomQueueListener. The listener classes implement MessageListener.

Your custom listener class must reside within your custom EAR file. Specifically, it must reside within the oracle/communications/inventory/ejb/message/custom/impl directory (lines 08-14 in Example 4-6), within a custom MDB JAR file (line 04 in Example 4-6).

package oracle.communications.inventory.webservice.mdb;
 
import java.util.HashMap;
import java.util.Set;
 
import javax.ejb.MessageDrivenContext;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.persistence.PersistenceContext;
 
import oracle.communications.inventory.api.framework.logging.Log;
import oracle.communications.inventory.api.framework.logging.LogFactory;
import weblogic.wsee.server.jms.JmsWebservicesMessageDispatcher;
 
@PersistenceContext(name = "persistence/EntityManager", unitName = "default")
public class MyCustomQueueListener implements MessageListener
{
    private static Log log = LogFactory
        .getLog( MyCustomQueueListener.class );
    private static final String CONNECTION_FACTORY = "inventoryWSQueueCF";
    private HashMap<String, JmsWebservicesMessageDispatcher> listeners = 
         new HashMap<String, JmsWebservicesMessageDispatcher>();
    private MessageDrivenContext context;
 
    public void setMessageDrivenContext(
        MessageDrivenContext messageDrivenContext )
    {
        this.context = messageDrivenContext;
    }
 
    public void onMessage( Message message )
    {
        try
        {
            String uri = message.getStringProperty( "URI" );
            JmsWebservicesMessageDispatcher listener = getListener( uri );
            if( log.isDebugEnabled() )
            {
                log.debug( "", "Thread " + Thread.currentThread().getId() + " "
                    + Thread.currentThread().hashCode()
                    + ": calling onMessage()..." );
            }
            if( listener != null )
            {
                listener.dispatchMessage( message );
            }
        }
        catch( Exception e )
        {
            log.error( "", "Failed to process JMS message: " + e.getMessage() );
            e.printStackTrace();
        }
    }
 
    public void ejbCreate()
    {
    }
 
    public void ejbRemove()
    {
        Set<String> keys = listeners.keySet();
        try
        {
            for( String key : keys )
            {
                JmsWebservicesMessageDispatcher listener = listeners.get( key );
                listener.shutdown();
            }
        }
        catch( Exception e )
        {
            log.error( "", "Error closing the listener: " + e.toString() );
        }
        listeners.clear();
        listeners = null;
    }
 
    private JmsWebservicesMessageDispatcher getListener( String uri )
    {
        JmsWebservicesMessageDispatcher listener = null;
        Object obj = listeners.get( uri );
        try
        {
            if( obj == null )
            {
                listener = new JmsWebservicesMessageDispatcher( uri,
                    CONNECTION_FACTORY );
                listeners.put( uri, listener );
            }
            else
            {
                listener = (JmsWebservicesMessageDispatcher) obj;
            }
        }
        catch( Exception e )
        {
            e.printStackTrace();
        }
        return listener;
    }
}

Configuring the Listener Class

After you create one or more listener classes, you must configure them to listen to their respective queues. This is accomplished by modifying the ejb-jar.xml and weblogic-ejb-jar.xml files, as shown in Example 4-9 and Example 4-10.

The ejb-jar.xml and weblogic-ejb-jar.xml files must reside within your custom EAR file. Specifically, they must reside within the META-INF directory (line 05 in Example 4-6), within a custom MDB JAR file (line 04 in Example 4-6).

<?xml version = '1.0' encoding = 'windows-1252'?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd"
version="3.0">
  <enterprise-beans>
    <message-driven>
      <ejb-name>MyCustomQueueListener</ejb-name>
      <ejb-class>
        oracle.communications.inventory.webservice.mdb.MyCustomQueueListener
      </ejb-class>
      <transaction-type>Bean</transaction-type>
      <message-destination-type>javax.jms.Queue</message-destination-type>
    </message-driven>
  </enterprise-beans>
</ejb-jar>

<?xml version = '1.0' encoding = 'windows-1252'?>
<weblogic-ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-ejb-jar
http://www.bea.com/ns/weblogic/weblogic-ejb-jar/1.0/weblogic-ejb-jar.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-ejb-jar">
    <weblogic-enterprise-bean>
        <ejb-name>MyCustomQueueListener</ejb-name>
        <message-driven-descriptor>
            <destination-jndi-name>MyCustomQueue</destination-jndi-name>
        </message-driven-descriptor>
    </weblogic-enterprise-bean>
</weblogic-ejb-jar>

Importing the WAR File into the EAR File

After you determine which EAR file is to contain the custom web service WAR file, import the WAR file into the appropriate EAR file.

The imported project contains the build.xml file, which defines the update.ear Ant target. The update.ear Ant target updates the EAR file by adding the custom web service WAR file and the edited application.xml file. The update.ear Ant target determines the location of the EAR file to be updated by using the path you specified in the COMPUTERNAME.properties EAR_PATH parameter. Run the update.ear Ant target to automatically perform these updates to the EAR file.

See "About the Ant Build File" for more information on Ant targets.

Verifying the Deployment

After you have deployed the updated EAR file, verify that the deployment includes the custom web service by viewing the web services in the WebLogic Server Administration Console. See "Verifying Deployments" for more information.

Specifying a Deployment Plan

If you placed your custom web service in the custom.ear file, or in any custom EAR file, you must specify a deployment plan for the updated EAR file.

Specifying a deployment plan enables the EAR file to retrieve property values from the UIM_Home/app/AppFileOverrides/platform/runtime-poms.properties file, which defines property values that are used by the persistence framework for cache coordination.

To specify a deployment plan:

1. Log in to the WebLogic Server Administration Console.

2. In the left panel, under Domain Structure, click the Deployments link.

   The Summary of Deployments page appears.

3. In the left panel, under Change Center, click Lock & Edit.

4. Select the check box next to the updated EAR file that contains your custom web service.

5. Click Update.

   The Update Application Assistant page appears.

6. Click Change Path.

7. Change the path to UIM_Home/app/plan.

8. Choose Plan.xml, and click Next.

9. Choose Redeploy this application using the following deployment files, and click Finish.