+

Search Tips   |   Advanced Search

createWSNService command

Use the createWSNService command to create a new WS-Notification service and the associated objects that form the infrastructure of the WS-Notification configuration. A WS-Notification service provides access to service integration bus resources for web services publish and subscribe clients.

Create a new WS-Notification service using wsadmin.sh, or using the administrative console. See Create a new v7.0 WS-Notification service.

To run the command, use the AdminTask object of the wsadmin scripting client.

Command-line help is provided for service integration bus commands:

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

AdminConfig.save()

This command creates a new WS-Notification service on a service integration bus.


Target object

An existing service integration bus (conditional - must be provided if the bus parameter is not supplied).


Required parameters

-name

The name to be given to the new WS-Notification service. The name forms part of the endpoint on which the service is exposed (that is, the URL used to access the WS-Notification service points defined under the service).


Conditional parameters

-bus

The name of the service integration bus that is to host the WS-Notification service. This can be an existing bus, or the name of a new bus that we want the command to create for you. This parameter should only be specified if a Target object is not provided.


Optional parameters

-type

The type of WS-Notification service created.

v7.0: Compose a JAX-WS WS-Notification service with web service qualities of service (QoS) via policy sets, or to apply JAX-WS handlers to the WS-Notification service. IBM recommends this type of service for new deployments.

  • -jaxwsHandlerListName
  • -queryWSDL

-description

An optional description of the WS-Notification service.

-permitsDynamicTopicNamespace

Indicates whether dynamic topic namespaces can be used within the WS-Notification service. That is, whether this service allows dynamic topic namespaces to be created at run time. See Dynamic topic namespace. Permitted values are TRUE (the default) and FALSE

Use this option to tightly control the topic namespaces used when connecting to a particular WS-Notification service (for example for security or auditing requirements). If we deselect this option, any applications that connect to the WS-Notification service and request topics from a dynamic topic namespace are stopped from publishing or receiving messages.

All messages published to a dynamic topic namespace are inserted with the default message reliability setting of reliable persistent. If this value is not acceptable, create a permanent topic namespace and manually configure the attribute to the appropriate value.

The dynamic topic namespaces used on a particular WS-Notification service are backed by a service integration bus topic space created automatically when we create the topic namespace. The syntax of topics used within this topic space is internal to the WS-Notification service implementation.

-dynamicTopicSpace

The name of the service integration bus topic space to be used as the dynamic topic space for this WS-Notification service. That is, the name of the bus topic space used to host the ad-hoc topic namespace, and to host dynamic topic namespaces if they are permitted. If not specified, this value defaults to WSN_dynamic_this_service_name.

-requiresRegistration

Boolean flag. Indicates whether publisher applications are required to register with the broker before they can publish notifications. Permitted values are TRUE and FALSE (the default).

-jaxwsHandlerListName

The JAX-WS handler list applied to outbound requests from the WS-Notification service. A handler list defines the handlers that are applied when making outbound web service invocations, for example monitoring outbound event notification (in response to a subscribe operation) and controlling demand-based publishers (subscribe, pause and resume). For more information about handler lists, see Configure JAX-WS handlers.

Only specify this parameter for v7.0 WS-Notification services.

-jaxrpcHandlerListName

The JAX-RPC handler list applied to outbound requests from the WS-Notification service - for example the broker delivering notifications to a consumer. For more information about handler lists, see Work with JAX-RPC handlers and clients.

Only specify this parameter for v6.1 WS-Notification services.

-outboundSecurityRequestBindingName

The security binding to be used with consumer notifications and remote publisher requests sent by this WS-Notification service.

Only specify this parameter for v6.1 WS-Notification services.

-outboundSecurityResponseBindingName

The security binding to be used with remote publisher responses received by this WS-Notification service.

Only specify this parameter for v6.1 WS-Notification services.

-outboundSecurityConfigName

Details of how security is applied to requests and responses.

Only specify this parameter for v6.1 WS-Notification services.

-queryWSDL

Boolean flag. Indicates whether the v7.0 WS-Notification service queries the WSDL of other WS-Notification web services when interacting with them. Permitted values are TRUE (the default) and FALSE.

By setting this parameter to FALSE we can improve performance by avoiding expensive WSDL queries. However, we should note the following considerations when WSDL querying is not enabled:

  • WS-Notification attempts to discover binding information (which is usually discovered through the WSDL) using other means. WS-Notification uses the SOAP version associated with the WS-Notification service point where subscriptions were made (by other web services), or where administered subscriptions were created (by an administrator).

  • There are some circumstances in which WS-Notification might be unable to determine binding information. This can happen when cleaning up subscriptions where the associated service point has been deleted and configuration information is no longer available. Under these circumstances WS-Notification makes a "best guess" at binding information to use to clean up the subscriptions.

  • There is one scenario where incorrect binding information is used. That is, when a subscriber subscribes to use a particular SOAP binding, on behalf of a NotificationConsumer that expects notifications through a different SOAP binding.

Only specify this parameter for v7.0 WS-Notification services.


Examples

Create a v6.1 WS-Notification service (equivalent to omitting the -type parameter):

newService = AdminTask.createWSNService(["-bus", "bus1", "-name", 
"NewWSNService", "-type", "V6.1"] )

Create a Version 7.0 WS-Notification service that allows composition with WS-ReliableMessaging:

newService = AdminTask.createWSNService(["-bus", "bus1", "-name", 
"NewWSNService", "-type", "V7.0"] )

Create a Version 7.0 WS-Notification service with a non-null handler list:

newService = AdminTask.createWSNService(["-bus", "bus1", "-name", 
"NewWSNService", "-type", "V7.0", "-jaxwsHandlerListName", "myHandlerList"] )

Create a v7.0 WS-Notification service that does not query WSDL:

newService = AdminTask.createWSNService(["-bus", "bus1", "-name", 
"NewWSNService", "-type", "V7.0", "-queryWSDL", "false"] )

Set the custom property to enable strict topic checking on this WS-Notification service: