+

Search Tips   |   Advanced Search

Add an EBA asset to a composition unit using wsadmin commands

Use the addCompUnit command and the AdminConfig commands to add a composition unit that consists of a previously-imported enterprise bundle archive (EBA) asset plus configuration information. The configuration information can include HTTP session management, context roots, virtual hosts, security roles, run-as roles, JNDI mappings for Session enterprise beans, JNDI mappings for EJB references, and web application or Blueprint resource reference bindings for our OSGi application.

We can add an EBA asset to a business-level application using wsadmin commands as described in this topic, or using the administrative console as described in Add an EBA asset to a composition unit by .

An EBA asset can be added to only one business-level application. A business-level application is scoped to cell scope, therefore only one instance of an OSGi application can be deployed in a cell.

This task makes the following assumptions:

An OSGi composition unit consists of an EBA asset, (optionally) one or more composite bundle extensions, and some or all of the following configuration information:

To create and configure all elements of the composition unit except the HTTP session manager, we use the addCompUnit command. To configure the HTTP session manager, we use the AdminConfig commands to configure the deployed object represented by the appDeploy variable. The composition unit must be created before the session management options can be applied to it, so run the addCompUnit command before configuring the HTTP session manager.

In addition to specifying the configuration information for the EBA asset through the following procedure, we can also change it later as described in Modify the configuration of an OSGi composition unit using wsadmin commands. For example, if you update a bundle in an EBA asset, or replace a composite bundle extension, we might introduce a resource that requires additional configuration, such as a new or changed Blueprint resource reference, or security role mapping.


Tasks

  1. Create and configure all elements of the composition unit except the HTTP session manager.

    Each of the following substeps describes the syntax for adding a single element to the composition unit. However, to create the composition unit we run the addCompUnit command only once. Therefore, when running the command, we must combine these elements together. An example of the combined syntax is given after the separate substeps.

    For several of the elements, the values we specify include bundle identifiers. If our EBA asset includes or references composite bundles, the command syntax is slightly different. For clarity, the differences for composite bundles are described, step by step, in a linked topic.

    1. Add the previously-imported asset (the EBA file) as a deployed asset.

      The parameters for this aspect of the command are as follows:

      -blaID

      Configuration ID of the business-level application.

      -cuSourceID

      ID of the EBA asset being used added to the business-level application.

      -CUOptions

      Following additional properties for the composition unit.

      • parentBLA
      • backingID
      • name
      • description
      • startingWeight
      • startedOnDistributed
      • restartBehaviorOnUpdate

      -MapTargets

      Specifies additional properties for the composition unit target mapping. That is, it specifies the deployable unit URI (which, for an EBA asset, is ebaDeploymentUnit) and the target node and server, or the target cluster. To add an additional target, we use the plus sign character ( + ) as a prefix.

      -ActivationPlanOptions

      Specifies additional properties for the composition unit activation plan. That is, it specifies the deployable unit URI and a list of runtime components. For an EBA asset, use default values as shown in the example that follows.

      If the target is one cluster, the Jython syntax for this aspect of the command is as follows:

      AdminTask.addCompUnit('[
        -blaID WebSphere:blaname=bla_name
        -cuSourceID WebSphere:assetname=asset_name.eba
        -CUOptions [
          [WebSphere:blaname=bla_name.eba 
          WebSphere:assetname=asset_name.eba 
          cu_name "optional_cu_description" 1 false DEFAULT]] 
        -MapTargets [[ebaDeploymentUnit WebSphere:cluster=cluster_name]] 
        -ActivationPlanOptions [[default ""]]  
        ...
      ]') 
      
      For example:
      AdminTask.addCompUnit('[
        -blaID WebSphere:blaname=helloWorldService 
        -cuSourceID WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba
        -CUOptions [
          [WebSphere:blaname=helloWorldService.eba 
          WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba 
          com.ibm.ws.eba.helloWorldService_0001.eba "" 1 false DEFAULT]] 
        -MapTargets [[ebaDeploymentUnit WebSphere:cluster=cluster1]] 
        -ActivationPlanOptions [[default ""]]  
        ...
      ]') 
      

      If the target is two servers, the Jython syntax for this aspect of the command is as follows::

      AdminTask.addCompUnit('[
        -blaID WebSphere:blaname=bla_name
        -cuSourceID WebSphere:assetname=asset_name.eba
        -CUOptions [
          [WebSphere:blaname=bla_name.eba 
          WebSphere:assetname=asset_name.eba 
          cu_name "optional_cu_description" 1 false DEFAULT]] 
        -MapTargets [
          [ebaDeploymentUnit WebSphere:node=node,server=server+
                             WebSphere:node=node2_name,server=server2_name]] 
        -ActivationPlanOptions [[default ""]]  
        ...
      ]') 
      
      For example:
      AdminTask.addCompUnit('[
        -blaID WebSphere:blaname=helloWorldService 
        -cuSourceID WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba
        -CUOptions [
          [WebSphere:blaname=helloWorldService.eba 
          WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba 
          com.ibm.ws.eba.helloWorldService_0001.eba "" 1 false DEFAULT]] 
        -MapTargets [[ebaDeploymentUnit WebSphere:node=node01,server=server1+
                                        WebSphere:node=node01,server=web1]] 
        -ActivationPlanOptions [[default ""]]  
        ...
      ]') 
      
    2. Map context root for web modules.

      Context roots determine where the web pages of a particular web application bundle (WAB) are found at run time. The context root specified here is combined with the defined server mapping to compose the full URL that you enter to access the pages of the WAB. For example, if the application server default host is www.example.com:8080 and the context root of the WAB is /sample, the web pages are available at www.example.com:8080/sample.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Map context root for web modules in composite bundles. The list of bundles under the ContextRootStep must contain all the WABs contained in the OSGi application.

      AdminTask.addCompUnit('[
        ... 
        -ContextRootStep [
          [bundle_symbolic_name_1 bundle_version_1 context_root_1]
          [bundle_symbolic_name_2 bundle_version_2 context_root_2]]
        ...
      ]') 
      
      For example, for an EBA file containing two WABs (com.ibm.ws.eba.helloWorldService.web at version 1.0.0, which is to be mapped to /hello/web, and com.ibm.ws.eba.helloWorldService.withContextRoot at version 0.9.0, which is to be mapped to /hello/service), this aspect of the command is as follows:
      AdminTask.addCompUnit('[
        ... 
        -ContextRootStep [
          [com.ibm.ws.eba.helloWorldService.web 1.0.0 "/hello/web"] 
          [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "/hello/service"]]
        ...
      ]')
      
    3. Bind listeners for message-driven beans

      For each message-driven bean (MDB) defined in either an ejb-jar.xml file or in an @MessageDriven annotation in the composition unit, we can specify the settings necessary to bind an MDB listener to the MDB. By binding a listener to an MDB, we configure the association of the MDB with the JMS destination from which the MDB receives messages.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Bind listeners for message-driven beans in composite bundles

      AdminTask.addCompUnit('[
        ... 
        -MDBBindingsStep [
          [bundle_symbolic_name_1 bundle_version_1 uri_1
             activation_spec_1 destination_jndi_name_1 authentication_alias_1]
          [bundle_symbolic_name_2 bundle_version_2 uri_2
             activation_spec_2 destination_jndi_name_2 authentication_alias_2]]
        ...
      ]') 
      
      In the following example, an EBA file contains two EJB bundles, com.ibm.ws.eba.currencyService at version 1.0.0, and com.ibm.ws.eba.accountService at version 0.9.0. The currencyService bundle contains a message-driven bean called ExchangeRateMDB, bound to an activation specification with a JNDI name of eis/ExchangeRate_Act_Spec; the destination JNDI name defined in the activation specification is overridden by a destination whose JNDI name is jms/ExchangeRateQueue, and the authentication alias defined in the activation specification is overridden by an authentication alias called ExchangeRate_Auth_Alias. The accountService bundle contains an MDB called CustomerDetailsMDB, bound to an activation specification with a JNDI name of eis/CustomerDetails_Act_Spec; the destination JNDI name defined in the activation specification is overridden by a destination whose JNDI name is jms/CustomerDetailsQueue, and the authentication alias defined in the activation specification is overridden by an authentication alias called CustomerDetails_Auth_Alias.
      AdminTask.addCompUnit('[
        ... 
        -MDBBindingsStep [
          [com.ibm.ws.eba.currencyService 1.0.0 META-INF/ejb-jar.xml/ExchangeRateMDB 
            eis/ExchangeRate_Act_Spec jms/ExchangeRateQueue ExchangeRate_Auth_Alias] 
          [com.ibm.ws.eba.accountService 0.9.0 META-INF/ejb-jar.xml/CustomerDetailsMDB 
            eis/CustomerDetails_Act_Spec jms/CustomerDetailsQueue CustomerDetails_Auth_Alias]]
        ...
      ]')
      

    4. Provide EJB JNDI names

      For each Session enterprise bean in the composition unit, we can specify the JNDI name by which the enterprise bean is known in the runtime environment.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Provide EJB JNDI names in composite bundles

      AdminTask.addCompUnit('[
        ... 
        -EJBMappingsStep [
          [bundle_symbolic_name_1 bundle_version_1 ejb_name_1
             ejb_interface_1 ejb_iterface_type_1 jndi_name_1]
          [bundle_symbolic_name_2 bundle_version_2 ejb_name_2
             ejb_interface_2 ejb_iterface_type_2 jndi_name_2]]
        ...
      ]') 
      
      In the following example, an EBA file contains two EJB bundles, com.ibm.ws.eba.currencyService at version 1.0.0, and com.ibm.ws.eba.accountService at version 0.9.0. The currencyService bundle contains an enterprise bean called ExchangeRate_ejb, with a Local interface called com.ibm.ws.eba.ejb.ExchangeRate, that is mapped to a JNDI name of ejb/ExchangeRate. The accountService bundle contains an enterprise bean called CustomerDetails_ejb, with a Remote interface called com.ibm.ws.eba.ejb.CustomerDetails, that is mapped to a JNDI name of ejb/CustomerDetails.
      AdminTask.addCompUnit('[
        ... 
        -EJBMappingsStep [
          [com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate_ejb
            com.ibm.ws.eba.ejb.ExchangeRate Local ejb/ExchangeRate] 
          [com.ibm.ws.eba.accountService 0.9.0 CustomerDetails_ejb
            com.ibm.ws.eba.ejb.CustomerDetails Remote ejb/CustomerDetails]]
        ...
      ]')
      
    5. Map EJB references

      For each EJB reference defined in either an ejb-jar.xml file, a web.xml file, or an @EJB annotation in the composition unit, we can specify the JNDI name by which the EJB reference is known in the runtime environment.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Map EJB references in composite bundles

      AdminTask.addCompUnit('[
        ... 
        -EJBRefStep [
          [bundle_symbolic_name_1 bundle_version_1 uri_1
             ejb_reference_name_1 business_interface_1 jndi_name_1]
          [bundle_symbolic_name_2 bundle_version_2 uri_2
             ejb_reference_name_2 business_interface_2 jndi_name_2]]
        ...
      ]') 
      
      The uri parameter specifies the location where the EJB reference is defined.

      In the following example, an EBA file contains two bundles, com.ibm.ws.eba.currencyService at version 1.0.0, and com.ibm.ws.eba.accountService at version 0.9.0. The currencyService bundle contains an EJB reference called ExchangeRate, from the CurrencyExchange enterprise bean, defined in META-INF/ejb-jar.xml, that is mapped to a JNDI name of ejb:ExchangeRate. The accountService bundle contains an EJB reference called CustomerDetails, defined in web.xml, that is mapped to a JNDI name of ejb:CustomerDetails.

      AdminTask.addCompUnit('[
        ... 
        -EJBRefStep [
          [com.ibm.ws.eba.currencyService 1.0.0 META-INF/ejb-jar.xml/CurrencyExchange
            ExchangeRate com.ibm.ws.eba.ejb.ExchangeRate ejb:ExchangeRate]
          [com.ibm.ws.eba.accountService 0.9.0 WEB-INF/web.xml
            CustomerDetails com.ibm.ws.eba.ejb.CustomerDetails ejb:CustomerDetails]]
        ...
      ]')
      
    6. Map EJB resource references to resources

      Binding a resource reference maps a resource dependency of an enterprise bean to an actual resource available in the server runtime environment. At a minimum, we can be achieve this mapping by specifying the JNDI name under which the resource reference is known in the runtime environment. By default, the JNDI name is retrieved from pre-existing bindings, or set to the value of the mapped-name specified in the resource reference definition. Use this option to bind resources of type resource-ref (resource reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Map EJB resource references to resources in composite bundles

      AdminTask.addCompUnit('[
        ... 
        -EJBResourceRefs [
          [
          bundle_symbolic_name
          bundle_version
          ejb_name
          resource_reference_id
          resource_type
          target_jndi_name
          resource_authentication_method
          mapping_properties
          extended_properties
          ]]
        ...
      ]')
      

      The mapping_properties parameter defines arbitrary name and value pairs for extended data source properties, in the following format (one continuous string):

      WebSphere:name=property_name1,value=property_value1,description=property_description1
      +WebSphere:name=property_name2,value=property_value2,description=property_description2
      + ...
      

      The extended_properties parameter defines extended data source custom properties in the following format (one continuous string):

      property_name1=property_value1+property_name2=property_value2+ ...
      

      For example:

      AdminTask.addCompUnit('[
        ... 
        -EJBResourceRefs [
          [com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate
           dataSource1 javax.sql.DataSource ref/ds1 ClientContainer
           "WebSphere:name=mprop1,value=val1,description=desc1"
           "exprop1=expropval1+exprop2=expropval2"] 
          [com.ibm.ws.eba.accountService 0.9.0 CustomerDetails
           dataSource2 javax.sql.DataSource ref/ds2 WSLogin "" ""]]
        ...
      ]') 
      
    7. Bind EJB message destination references to administered objects.

      Binding a message destination reference or resource environment reference maps a resource dependency of an enterprise bean to an actual resource available in the server runtime environment. At a minimum, we can achieve this mapping by specifying the JNDI name under which the message destination reference or resource environment reference is known in the runtime environment. By default, the JNDI name is retrieved from pre-existing bindings, or set to the value of the mapped-name specified in the message destination reference definition. Use this option to bind resources of type message-destination-ref (message destination reference) or resource-env-ref (resource environment reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Bind EJB message destination references to administered objects in composite bundles.

      AdminTask.addCompUnit('[
        ... 
        -EJBMsgDestRefs [
          [
          bundle_symbolic_name
          bundle_version
          ejb_name
          resource_reference_id
          resource_type
          target_jndi_name
      	   ]]
        ...
      ]')
      
      For example:
      AdminTask.addCompUnit('[
        ... 
        -EJBMsgDestRefs [
          [com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate
           jms/myQ javax.jms.Queue jms/workQ] 
          [com.ibm.ws.eba.accountService 0.9.0 CustomerDetails
           jms/myT javax.jms.Topic jms/notificationTopic]]
        ...
      ]') 
      
    8. Map EJB environment entries.

      For each simple environment entry defined in either an env-entry element in an ejb-jar.xml file or in an @Resource annotation in the composition unit, we can specify the value of the environment entry.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Map EJB environment entries in composite bundles.

      AdminTask.addCompUnit('[
        ... 
        -EJBEnvEntryStep [
          [
          bundle_symbolic_name
          bundle_version
          ejb_name
          env_entry_name
          env_entry_type
          env_entry_description
          env_entry_value
          ]]
        ...
      ]')
      
      For example:
      AdminTask.addCompUnit('[
        ... 
        -EJBEnvEntryStep [
          [com.ibm.ws.eba.currencyService 1.0.0
           ExchangeRate CommissionRate java.lang.Double
           "Commission rate applied to currency exchange transactions." 5.75]]
        ...
      ]') 
      
    9. Map virtual hosts for web modules.

      We use a virtual host to associate a unique port with a web application. The aliases of a virtual host identify the port numbers defined for that virtual host. A port number specified in a virtual host alias is used in the URL used to access artifacts such as servlets and JavaServer Page (JSP) files in a web application. For example, the alias myhost:8080 is the host_name:port_number portion of the URL http://myhost:8080/sample.

      Each WAB contained in a deployed asset must be mapped to a virtual host. WABs can be installed on the same virtual host, or dispersed among several virtual hosts.

      If we specify an existing virtual host in the ibm-web-bnd.xml or .xmi file for a WAB, the specified virtual host is set by default. Otherwise, the default virtual host setting is default_host, which provides several port numbers through its aliases:

      80

      An internal, insecure port used when no port number is specified

      9080

      An internal port

      9443

      An external, secure port

      Unless we want to isolate your WAB from other WABs or resources on the same node, default_host is a suitable virtual host. In addition to default_host, WebSphere Application Server provides admin_host, which is the virtual host for the administrative console system application. admin_host is on port 9060. Its secure port is 9043. Do not select admin_host unless the WAB relates to system administration.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Map virtual hosts for web modules in composite bundles.

      AdminTask.addCompUnit('[
        ... 
        -VirtualHostMappingStep [
          [bundle_symbolic_name_1 bundle_version_1 
          web_module_name_1 virtual_host_1]
          [bundle_symbolic_name_2 bundle_version_2 
           web_module_name_2 virtual_host_2]]
        ...
      ]') 
      
      For example, for an EBA file containing two WABs (com.ibm.ws.eba.helloWorldService.web at version 1.0.0, which is to be mapped to default_host, and com.ibm.ws.eba.helloWorldService.withContextRoot at version 0.9.0, which is to be mapped to test_host), this aspect of the command is as follows:
      AdminTask.addCompUnit('[
        ... 
        -VirtualHostMappingStep [
          [com.ibm.ws.eba.helloWorldService.web 1.0.0 
          "HelloWorld service" default_host]
          [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 
          "HelloWorld second service" test_host]]
        ...
      ]') 
      
    10. Map security roles to users or groups.

      The Jython syntax for this aspect of the command is as follows:

      AdminTask.addCompUnit('[
        ... 
        -MapRolesToUsersStep [
          [role_name everyone? 
          all_authenticated_in_realm? 
          usernames groups all_authenticated_in_trusted_realms?]]
        ...
      ]') 
      

      Key:

      • role_name is a role name defined in the application.
      • everyone? is set to Yes or No, to specify whether everyone is in the role.
      • all_authenticated_in_realm? is set to Yes or No, to specify whether all authenticated users can access the application realm.
      • usernames is a list of WAS user names, separated by the "|" character.
      • groups is a list of WAS groups, separated by the "|" character.
      • all_authenticated_in_trusted_realms? optionally set to Yes or No, to specify whether all users authenticated in a trusted realm can access the resource.

      For usernames, and groups, the empty string "" means "use the default or existing value". The default is usually that no users or groups are bound to the role. However, when an application contains an ibm-application-bnd.xmi file, the default value for usernames is obtained from this file. If we are deploying an application containing an ibm-application-bnd.xmi file, and we want to remove the bound users, specify just the "|" character (which is the separator for multiple user names). This setting explicitly specifies "no users", and therefore guarantees that no users are bound to the role. For example:

      AdminTask.addCompUnit('[
        ... 
        -MapRolesToUsersStep [
          [ROLE1 No Yes "" ""] 
          [ROLE2 No No WABTestUser1 ""] 
          [ROLE3 No No "" WABTestGroup1] 
          [ROLE4 Yes No "" ""]]
        ...
      ]')
      
      For more information about the -MapRolesToUsersStep option, see the information for the $AdminApp install command "MapRolesToUsers" option. This is the equivalent option for Java EE applications. For more general information, see Security role to user or group mapping.
    11. Map RunAs roles to users

      We can map a specified user identity and password to a RunAs role. This mapping enables us to specify application-specific privileges for individual users, so that they can run specific tasks using another user identity. The Jython syntax for this aspect of the command is as follows:

      AdminTask.addCompUnit('[
        ... 
        -MapRunAsRolesToUsersStep [
          [role_name user_name password]]
      ]') 
      
      For example:
      AdminTask.addCompUnit('[
        ... 
        -MapRunAsRolesToUsersStep [
          [Role1 User1 password1]
          [AdminRole User3 password3]]
      ]')
      
      For more information about the -MapRunAsRolesToUsers option, see the information for the $AdminApp install command "MapRunAsRolesToUsers" option. This is the equivalent option for Java EE applications. For more general information, see Map RunAs roles to users.

    12. Add authentication aliases to Blueprint resource references.

      Blueprint components can access WAS resource references. Each reference is declared in a Blueprint XML file, and can be secured using a Java EE Connector Architecture (JCA) authentication alias. Each bundle in an OSGi application can contain any number of resource reference declarations in its various Blueprint XML files.

      When we secure resource references, those resource references can be bound only to JCA authentication aliases that exist on every server or cluster on which the application is deployed. An OSGi application can be deployed to multiple servers and clusters in the same security domain. Therefore, each JCA authentication alias must exist in either the security domain of the target servers and clusters, or the global security domain.

      We must declare the resource references in the Blueprint XML file. For example:

      <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" 
        xmlns:rr="http://www.ibm.com/appserver/schemas/8.0/blueprint/resourcereference">
        <!-- Other Blueprint declarations ... -->
        
        <rr:resource-reference id="resourceRef" 
                interface="javax.sql.DataSource"
                filter="(osgi.jndi.service.name=jdbc/Account)">
          <rr:res-auth>Container</rr:res-auth>
          <rr:res-sharing-scope>Shareable</rr:res-sharing-scope>
        </rr:resource-reference>
      </blueprint>
      
      This declaration includes the resource reference ID (for example resourceRef), the service filter (for example jdbc/Account), the authentication type (for example Container), and the sharing setting (for example Shareable).

      The Blueprint resource references to authentication alias bindings for each bundle are stored in a file ibm-eba-bnd.xml in the META-INF directory of that bundle. If an OSGi application contains any of these files when it is deployed as an asset, these files provide the default authentication alias values used when binding the resource references. For example:

      <eba-bnd>
        <resource-ref>
          <jndi-name>jdbc/Acount</jndi-name>
          <authentication-alias>Alias1</authentication-alias>
          <interface>javax.sql.DataSource</interface>
          <authentication>Container</authentication>
          <sharing-scope>Shareable</sharing-scope>
          <id>resourceRef</id>
        </resource-ref>
      </eba-bnd>
      

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Add authentication aliases to Blueprint resource references in composite bundles.

      AdminTask.addCompUnit('[
        ... 
        -BlueprintResourceRefBindingStep [
          [
          bundle_symbolic_name 
          bundle_version 
          blueprint_resource_reference_id 
          interface_name 
          jndi_name 
          authentication_type 
          sharing_setting 
          authentication_alias_name
          ]]
        ...
      ]')
      

      The value for jndi_name must match the JNDI name that you declare in the filter attribute of the resource reference element in the Blueprint XML file. For example, for an EBA file containing a bundle com.ibm.ws.eba.helloWorldService.properties.bundle.jar at Version 1.0.0, which is to be bound to authentication alias alias1, the command is as follows:

      AdminTask.addCompUnit('[
        ... 
        -BlueprintResourceRefBindingStep[
          [com.ibm.ws.eba.helloWorldService.properties.bundle 1.0.0 resourceRef 
          javax.sql.DataSource jdbc/Account Container Shareable alias1]]
        ...
      ]')
      
    13. Bind web module message destination references to administered objects.

      Binding a resource reference maps a resource dependency of the web application to an actual resource available in the server runtime environment. At a minimum, we can achieve this mapping by specifying the JNDI name under which the resource is known in the runtime environment. By default, the JNDI name is the resource ID specified in the web.xml file during development of the web application bundle (WAB). Use this option to bind resources of type message-destination-ref (message destination reference) or resource-env-ref (resource environment reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Bind web module message destination references to administered objects in composite bundles.

      AdminTask.addCompUnit('[
        ... 
        -WebModuleMsgDestRefs [
          [
          bundle_symbolic_name
          bundle_version
          resource_reference_id
          resource_type
          target_jndi_name
      	   ]]
        ...
      ]')
      
      For example:
      AdminTask.addCompUnit('[
        ... 
        -WebModuleMsgDestRefs [
          [com.ibm.ws.eba.helloWorldService.web 1.0.0 
          jms/myQ javax.jms.Queue 
          jms/workQ] 
          [com.ibm.ws.eba.helloWorldService.web 1.0.0 
          jms/myT javax.jms.Topic 
          jms/notificationTopic]]
        ...
      ]') 
      
    14. Map web module resource references to resources.

      Binding a resource reference maps a resource dependency of the web application to an actual resource available in the server runtime environment. At a minimum, we can achieve this mapping by specifying the JNDI name under which the resource is known in the runtime environment. By default, the JNDI name is the resource ID specified in the web.xml file during development of the web application bundle (WAB). Use this option to bind resources of type resource-ref (resource reference), as defined in the Java specification JSR-250: Common Annotations for the Java Platform.

      The Jython syntax for this aspect of the command is as follows.

      For composite bundles, the syntax is slightly different. See Step: Map web module resource references to resources in composite bundles.

      AdminTask.addCompUnit('[
        ... 
        -WebModuleResourceRefs [
          [
          bundle_symbolic_name
          bundle_version
          resource_reference_id
          resource_type
          target_jndi_name
          login_configuration
          login_properties
          extended_properties
      	   ]]
        ...
      ]')
      
      For example:
      AdminTask.addCompUnit('[
        ... 
        -WebModuleResourceRefs [
          [com.ibm.ws.eba.helloWorldService.web 1.0.0 
          jdbc/jtaDs javax.sql.DataSource 
          jdbc/helloDs "" "" ""] 
          [com.ibm.ws.eba.helloWorldService.web 1.0.0 
          jdbc/nonJtaDs javax.sql.DataSource 
          jdbc/helloDsNonJta "" "" "extprop1=extval1"]]
        ...
      ]') 
      

      If we use multiple extended properties, the jython syntax is "extprop1=extval1,extprop2=extval2".

    In the following example, the jython syntax from the previous individual substeps is combined so that, by running the addCompUnit command once only, a composition unit is created and added to a business-level application.

    If our EBA asset includes or references composite bundles, the command syntax is slightly different. For an equivalent example, see Example: Using the addCompUnit command to add an EBA asset that includes composite bundles.

    AdminTask.addCompUnit('[
      -blaID WebSphere:blaname=helloWorldService 
      -cuSourceID WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba
      -CUOptions [
        [WebSphere:blaname=helloWorldService.eba 
        WebSphere:assetname=com.ibm.ws.eba.helloWorldService.eba 
        com.ibm.ws.eba.helloWorldService_0001.eba "" 1 false DEFAULT]] 
      -MapTargets [[ebaDeploymentUnit WebSphere:cluster=cluster1]] 
      -ActivationPlanOptions [[default ""]]  
      -ContextRootStep [
        [com.ibm.ws.eba.helloWorldService.web 1.0.0 "/hello/web"] 
        [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 "/hello/service"]]
      -EJBMappingsStep [
        [com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate_ejb
          com.ibm.ws.eba.ejb.ExchangeRate Local ejb/ExchangeRate] 
        [com.ibm.ws.eba.accountService 0.9.0 CustomerDetails_ejb
          com.ibm.ws.eba.ejb.CustomerDetails Remote ejb/CustomerDetails]]
      -EJBRefStep [
        [com.ibm.ws.eba.currencyService 1.0.0 META-INF/ejb-jar.xml/CurrencyExchange
          ExchangeRate com.ibm.ws.eba.ejb.ExchangeRate ejb:ExchangeRate]
        [com.ibm.ws.eba.accountService 0.9.0 WEB-INF/web.xml
          CustomerDetails com.ibm.ws.eba.ejb.CustomerDetails ejb:CustomerDetails]]
      -EJBResourceRefs [
        [com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate
         dataSource1 javax.sql.DataSource ref/ds1 ClientContainer
         "WebSphere:name=mprop1,value=val1,description=desc1"
         "exprop1=expropval1+exprop2=expropval2"] 
        [com.ibm.ws.eba.accountService 0.9.0 CustomerDetails
         dataSource2 javax.sql.DataSource ref/ds2 WSLogin "" ""]]
      -EJBMsgDestRefs [
        [com.ibm.ws.eba.currencyService 1.0.0 ExchangeRate
         jms/myQ javax.jms.Queue jms/workQ] 
        [com.ibm.ws.eba.accountService 0.9.0 CustomerDetails
         jms/myT javax.jms.Topic jms/notificationTopic]]
      -VirtualHostMappingStep [
        [com.ibm.ws.eba.helloWorldService.web 1.0.0 
        "HelloWorld service" default_host]
        [com.ibm.ws.eba.helloWorldService.withContextRoot 0.9.0 
        "HelloWorld second service" test_host]]
      -MapRolesToUsersStep [
        [ROLE1 No Yes "" ""] 
        [ROLE2 No No WABTestUser1 ""] 
        [ROLE3 No No "" WABTestGroup1] 
        [ROLE4 Yes No "" ""]]
      -MapRunAsRolesToUsersStep [
        [Role1 User1 password1]
        [AdminRole User3 password3]]
      -BlueprintResourceRefBindingStep[
        [com.ibm.ws.eba.helloWorldService.properties.bundle 1.0.0 resourceRef 
        javax.sql.DataSource jdbc/Account 
        Container Shareable alias1]]
      -WebModuleMsgDestRefs [
        [com.ibm.ws.eba.helloWorldService.web 1.0.0 
        jms/myQ javax.jms.Queue 
        jms/workQ] 
        [com.ibm.ws.eba.helloWorldService.web 1.0.0 
        jms/myT javax.jms.Topic 
        jms/notificationTopic]]
      -WebModuleResourceRefs [
        [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/jtaDs javax.sql.DataSource 
        jdbc/helloDs "" "" ""] 
        [com.ibm.ws.eba.helloWorldService.web 1.0.0 jdbc/nonJtaDs javax.sql.DataSource 
        jdbc/helloDsNonJta "" "" "extprop1=extval1"]]
    ]')
    

  2. Configure the HTTP session manager.

    To configure the HTTP session manager, we use the AdminConfig commands to configure the deployed object represented by the appDeploy variable. Session management for OSGi applications is configured in the same way as for enterprise applications, except for a minor difference in syntax when getting the deployed object.

    1. Get the deployed object.

      Use the instructions given in Configure applications for session management using scripting. Note that, for enterprise applications, we use the following two line script:

      deployments = AdminConfig.getid('/Deployment:myApp/')
      appDeploy = AdminConfig.showAttribute(deployments, 'deployedObject')
      
      For OSGi applications, the equivalent script is the following single line:
      appDeploy = AdminTask.getOSGiApplicationDeployedObject('-cuName cu_name')
      
      where cu_name is the name of the composition unit. For example:
      appDeploy = AdminTask.getOSGiApplicationDeployedObject('
        -cuName com.ibm.ws.eba.helloWorldService_0001.eba')
      

    2. Create the session management options.

      Use the instructions given in Configure applications for session management using scripting. The command usage for creating the session management options is exactly the same for enterprise applications and OSGi applications.


What to do next

After using these commands, save the changes to the master configuration using the following command:

AdminConfig.save()

After we import the enterprise bundle archive (EBA) file for our OSGi application as an asset, we can update versions of existing bundles but we cannot add extra bundles to the asset. However, after we have added the asset as a composition unit to a business-level application, we can extend the business-level application by adding one or more composite bundles to the composition unit. See Add or removing extensions for an OSGi composition unit using wsadmin commands.

We are now ready to start a business-level application.


Subtopics


Related:

  • JMS and OSGi Applications
  • Assets
  • Business-level applications
  • Composition units
  • Virtual hosts
  • Security domains
  • Add an EBA asset to a composition unit by
  • Manage composition units
  • Configure applications for session management using scripting
  • Update bundle versions for an EBA asset
  • Secure OSGi applications
  • BLAManagement .
  • Options for the AdminApp object install
  • Blueprint resource references [Settings]
  • Context root for web modules [Settings]
  • Security role to user or group mapping [Settings]
  • RunAs roles for users [Collection]
  • Virtual hosts for web modules [Settings]
  • Web module message destination references [Settings]
  • Web module resource references [Settings]
  • Web module resource references: Available resources [Collection]
  • EJB JNDI names [Settings]
  • EJB references [Settings]
  • EJB message destination references [Settings]
  • EJB resource references [Settings]
  • EJB environment entries [Settings]




    File name: was3413.html

    prettyPrint();