WebSphere WebSphere Application Server Network Deployment, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

SIBWS body text entities


The service integration bus topic space is the primary messaging object upon which WS-Notification depends at run time.
When the http://www.ibm.com/websphere/webservices/wssecurity/dialect-was dialect value is selected, the following are valid keyword values:
The address at which external clients access the endpoint listener endpoint.
Modify the address at which external clients access the endpoint listener endpoint.
Type the address at which external clients access the endpoint listener endpoint.
Select or type the address at which external clients access the endpoint listener endpoint.
The URL root is the context root of the endpoint listener application, and provides the root of the Web address that is used to build the endpoint addresses within WSDL files to direct requesters to this endpoint listener.
If external clients access the endpoint listener through an HTTP server or server cluster, using default port 80, then specify the HTTP server name and no port number.
For example (for SOAP over HTTP endpoint listener 1):
For example (for this endpoint listener):
However, if you allow external clients to connect direct to your application server (for example in a development or test environment) then specify the application server host name and port number.
This example is based on using the Java API for XML-based remote procedure call (JAX-RPC) APIs in conjunction with code generated using the WSDL2Java tool (run against the Notification Broker WSDL generated as a result of creating your WS-Notification service point) and WebSphere Application Server APIs and SPIs.
This example is based on using the Java API for XML-based remote procedure call (JAX-RPC) APIs in conjunction with code generated using the WSDL2Java tool (run against the Subscription Manager WSDL generated as a result of creating your WS-Notification service point) and WebSphere Application Server APIs and SPIs.
See also Inbound ports settings.
An inbound port describes the Web service enablement of a service destination on a specific endpoint listener, with associated configuration.
Each inbound port is associated with an endpoint listener, and you can control which groups of users can access a particular inbound service by making the service available only through specific endpoint listeners.
You can use a JAX-RPC handler list to monitor activity at the port, and take appropriate action (for example logging, or re-routing) depending upon the sender and content of each message that passes through the port.
You can use WS-Security to set the levels of security to be applied to messages. The security level can be set independently for request and response messages.
The Java API for XML-based remote procedure calls (JAX-RPC) provides you with a standard way of developing interoperable and portable Web services.
A JAX-RPC handler is a Java class that performs a range of handling tasks.
A JAX-RPC handler interacts with messages as they pass into and out of the service integration bus, therefore you make the handler class available to the server or cluster that hosts the inbound or outbound port for the service that you want to monitor.
If you want to monitor an inbound port, make the handler class available to the server on which the endpoint listener for that port is located. If you want to monitor an outbound port, make the handler class available to the server on which the outbound port destination is localized.
This task assumes that you have already created your JAX-RPC handler. You can do this using WebSphere Studio Application Developer (WSAD) or a similar tool. For more information, see the IBM developerWorks article Support for J2EE Web Services in WebSphere Studio Application Developer V5.1  -- Part 3: JAX-RPC Handlers.
To make WebSphere Application Server aware of your JAX-RPC handler, and to make the handler available for inclusion in one or more handler lists, you use the administrative console to create a new JAX-RPC handler configuration.
The approach taken in WebSphere Application Server is therefore to apply handler lists (rather than individual handlers) at the ports, where each handler list contains one or more handlers.
A Java API for XML-based remote procedure calls (JAX-RPC) handler is a Java class that performs a range of handling tasks.
For example:  logging messages, or transforming their contents, or terminating an incoming request.
Handlers monitor messages at inbound and outbound ports, and take appropriate action depending upon the sender and content of each message.
To enable JAX-RPC handlers to perform more complex operations they can be chained together into handler lists.
You associate each JAX-RPC handler list with one or more ports, so that the handler list can monitor activity at the port, and take appropriate action depending upon the sender and content of each message that passes through the port
To create a JAX-RPC handler, you can use a tool such as WebSphere Studio Application Developer (WSAD).
For more information, see the IBM developerWorks article Support for J2EE Web Services in WebSphere Studio Application Developer V5.1  -- Part 3: JAX-RPC Handlers.
You can configure multiple instances of a handler by creating each instance with a different handler name, and pointing to the same handler class.
When you create a new proxy service configuration, the gateway takes no action with regard to that service other than to invoke it. When you configure a proxy service, you also configure a JAX-RPC handler list that uses the javax.xml.rpc.service.endpoint.address  to set the target endpoint for the service. You then attach the handler list to the inbound port for the proxy service.
A proxy service configuration has no actual target services and therefore no WSDL that the gateway can use to configure the service invocation. A generic proxy WSDL file is used to configure the basic parameters for the invocation call (for example which binding to use), but you can override the default by supplying your own equivalent generic proxy WSDL file.
If the JAX-RPC handler list is not deployed, then the gateway attempts to send all requests to the fake Web address specified in the <soap:target address> tag in the proxy WSDL file.
You can set the Web services gateway to act purely as a proxy for your service, then use JAX-RPC handler lists to set the endpoints for incoming request messages for the service.
You can create many to many relationships between the set of permanent topic namespaces defined in a cell (that is for all WS-Notification services defined in that cell) and the service integration bus topic spaces with which they are associated. These relationships can become quite complex depending upon the use patterns required by the applications that connect to the WS-Notification service.
request consumer, for use when consuming requests from a client to an inbound service.
request generator, for use when generating requests from an outbound service to a target Web service.
request receiver, for use when receiving requests from a client to an inbound service.
request sender, for use when sending requests from an outbound service to a target Web service.
response consumer, for use when consuming responses from a target Web service to an outbound service.
response generator, for use when generating responses from an inbound service to a client.
response receiver, for use when receiving responses from a target Web service to an outbound service.
response sender, for use when sending responses from an inbound service to a client.
You can use this information to see whether a given subscriber has been successfully initialized.
An icon indicator that displays either green or red to indicate whether the administered subscriber is OK or has failed. Hover over this icon to see a description of the current state. In the OK case, it describes the last successful operation - initially the time at which the subscription was contacted (for server startup) and subsequently the time the last message was received for this subscriber. In the failed case, it describes the details of the last failure.
You can view the basic properties of the registration record. You can also delete a publisher registration record.
The endpoint reference of the producer that created this registration.
You can view basic properties of the pull point such as the subscription with which it is associated and the time at which it is currently set to expire, and you can navigate to the associated subscriptions where appropriate. You can also delete pull points.
If the pull point has not yet been supplied to a subscription, the text "Not Associated" is displayed.
Choose between information for a particular service point, or information aggregated for all service points for a particular service, by completing one of the following substeps:
For run-time information for a particular service point, navigate to either Service integration > Web services > WS-Notification services > [Content Pane] service_name > WS-Notification service points > [Content Pane] point_name or Service integration > Buses > [Content Pane] bus_name > [Services] WS-Notification services > [Content Pane] service_name > WS-Notification service points > [Content Pane] point_name, then click the Runtime tab.
A panel is displayed that contains links to run-time information about subscriptions, registrations, pull points and administered subscribers for this WS-Notification service point.
For run-time information aggregated for all service points for a particular service, navigate to either Service integration > Web services > WS-Notification services > [Content Pane] service_name or Service integration > Buses > [Content Pane] bus_name > [Services] WS-Notification services > [Content Pane] service_name, then click the Runtime tab.
A panel is displayed that contains links to run-time information about subscriptions, registrations and pull points for this WS-Notification service.
This form shows all the currently active administered subscribers for this WS-Notification service point.
This form shows all the currently active pull points for this WS-Notification service point or service.
This form shows all the currently active publisher registrations for this WS-Notification service point or service.
This form shows all the currently active subscriptions for this WS-Notification service point or service.
This collection form contains the following information about each list item:
You can view the subscription name (ID), topic and other information associated with the subscription, and you can view messages held on the durable subscription pending delivery. You can also delete subscriptions.
For example, to tidy up after a badly-behaved application.
Using an authentication alias does not make your configuration more secure. However, you might want to use an alias for consistency of approach if you have other application servers running under WebSphere Application Server Version 6.0, or to support your internal business controls for use of IDs and passwords.
If you configure an authentication alias you need not also disable the default configuration. If an authentication alias exists, it overrides the default configuration.
However if you subsequently remove the authentication alias from the activation specification, the default configuration will again take control and (if not disabled) will allow the service integration technologies resource adapter to continue to access the bus.
By default, the Web services enablement of the service integration bus (SIBus) works when WebSphere Application Server security is enabled and every installed SIBus is secured.
You can override this default method by configuring an authentication alias that the service integration technologies resource adapter uses to access the bus.
If you specify a Username token or X.509 certificate security token, you do not need to specify a URI. If you specify a custom token, enter the URI of the QName for the value type. If you specify Lightweight Third Party Authentication (LTPA), enter the following WebSphere Application Server predefined value type URI: http://www.ibm.com/websphere/appserver/tokentype/5.0.2.

This address comprises the root of the HTTP address at which external clients access your endpoint listener application, followed by /sibws.
The WSDL serving HTTP URL root is only used internally by other components of IBM WebSphere Application Server (notably the IBM UDDI registry). For all other uses, you access the WSDL file through the endpoint listener endpoint for the inbound service.
To get the location details for a given inbound service WSDL file, publish the WSDL file to a zip file as described in Modifying an existing inbound service configuration, then look up the location within the exported WSDL file.
As part of the configuration of a WS-Notification service point you can configure any number of administered subscribers for that service point.
Topic expression describing the class of notification messages by which the list is filtered.
The namespace URI  by which the list is filtered.
This timeout minimizes the potential for orphaned subscriptions in the remote Web service if the local server is uninstalled. Note that this field does not indicate the actual time at which the remote subscription is due to expire. Set the timeout length to something larger than the maximum length of time that the server is expected to remain offline, otherwise the stream of messages from the remote Web service might be interrupted. While the server is running it occasionally renews the remote subscription termination time (with the specified timeout) to prevent it from expiring during normal operation.  If not specified, this timeout defaults to 24 (hours).
You should not define an administered subscriber for any of the endpoints exposed by the WS-Notification service on which it is being defined, because this would result in infinite looping of messages through the notification broker.
You should be wary of deleting and recreating messaging engines on bus members for which WS-Notification administered subscribers have been configured, because in some cases this can leave the remote Web service subscription active (and passing notification messages to the local server) even though there is no longer any record of it.
When you remove messaging engines from a cluster you should remove them in numerical order from highest to lowest, so as to avoid a situation where (for example) there are messaging engines numbered 001 and 002 and not 000. The reason for this is to provide additional surety when using WS-Notification, because WS-Notification attaches special significance to the "first" messaging engine in the cluster.
An administered subscriber contains the name of a NotificationProducer application or a (different) NotificationBroker endpoint and details of a subscription request (for example topic) that the WS-Notification service point should register as part of the server startup procedure. This allows you to pre-configure links between the NotificationBroker and a NotificationProducer, which can be a remote NotificationBroker or a NotificationProducer application.
That is, the endpoint reference (Web address) of a notification producer or notification broker application. For example http://remoteproducer.com.
The options are Simple, Concrete, or Full, as defined by the WS-Topics specification.
This describes the class of notification messages that are delivered to the WS-Notification service point. For example stock/IBM. This property can include wildcards if they are supported by the topic dialect that you select.
The remote Web service endpoint by which the list is filtered.
This parameter must be specified if the target type is WSNServicePoint, and must not be specified if a WSNAdministeredSubscriber target is supplied.
That is, the name of the chosen topic dialect as defined by the WS-Topics specification
Values of this parameter are SIMPLE, CONCRETE, FULL.
A dynamic topic namespace does not require manual administration through the administration console or scripting. A dynamic topic namespace is used automatically in response to a request from a WS-Notification application for a topic namespace URI that has not been defined as a permanent topic namespace (assuming the WS-Notification service has been configured to permit use of dynamic namespaces).
Use this option to tightly control the topic namespaces that are used when connecting to a particular WS-Notification service (for example for security or auditing requirements). If you 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.
You can only use WS-Notification in environments that support Java API for XML-based remote procedure calls (JAX-RPC).
WS-Notification enables Web services to use the "publish and subscribe" messaging pattern.
You use publish and subscribe messaging to publish one message to many subscribers. In this pattern a producing application inserts (publishes) a message (event notification) into the messaging system having marked it with a topic that indicates the subject area of the message. Consuming applications that have subscribed to the topic in question, and have appropriate authority, all receive an independent copy of the message that was published by the producing application.

At an application level, this enables a standardized approach for Web service applications to participate in the publish and subscribe messaging pattern, whether this be listening for notification of a particular event occurrence, or inserting event notifications into the system for consumption by other applications or system management tooling.
WS-Notification provides a standardized approach for Web service applications to participate in the publish and subscribe messaging pattern, whether this be listening for notification of a particular event occurrence, or inserting event notifications into the system for consumption by other applications or system management tooling.
The open-standards nature of this Web services specification mean that applications can communicate with each other irrespective of the underlying hardware platforms, software languages or vendor environments.
Within WebSphere Application Server, WS-Notification also allows interchange of event notification between WS-Notification applications and other clients of the service integration bus.
This support for WS-Notification also allows interchange of event notification between WS-Notification applications and other clients of the service integration bus.
By exploiting other service integration bus functionality you can also use this function to interchange messages with other IBM publish and subscribe brokers such as WBI Event Broker or Message Broker.
In this use pattern WebSphere Application Server is used solely as a notification broker to enable producing and consuming WS-Notification applications to communicate with each other. The applications are unaware that the NotificationBroker service is implemented by WebSphere Application Server.
In addition to the ability to pass information between WS-Notification producers and consumers, the WS-Notification support provided in WebSphere Application Server also acts as an entry or exit point to the service integration bus. Event notifications that are published by WS-Notification applications are inserted into the service integration bus where they can be modified, rerouted or consumed by any of the other applications that are connected to the bus. Equally, publications sent by service integration bus clients such as JMS can be received by WS-Notification consumers.
This use pattern shows the potential to deploy a WS-Notification service across multiple servers in a network deployment environment. In this pattern applications can connect to any WS-Notification service point and use them identically when inserting notifications, because WS-Notification topic namespaces are shared by all the WS-Notification service points of the WS-Notification service. Notification messages are propagated throughout the bus to any interested NotificationConsumers, regardless of the location where they attached to the bus (that is, regardless of the WS-Notification service point to which they are connected).
In this use pattern the administrator creates a cluster of servers containing a single messaging engine and WS-Notification service point, in order to ensure that should the server containing the messaging engine fail, the resources it manages (subscriptions, event notifications) remain available to the remote applications. The messaging engine is configured to fail over between the various servers in the cluster in order to provide highly available operation.
WebSphere Application Server-specific WS-Addressing support in the proxy ensures that Web services requests that have an affinity with a particular messaging engine (for example Resume or Destroy subscription flows) are routed back to the server in which the messaging engine is located.
In this use pattern the administrator aims to share client application requests across multiple servers in the cell without overloading any particular server. This requires that all WS-Notification service points of the WS-Notification service can be considered the same - in particular that all topic namespaces are available at every WS-Notification service point of the broker.
This use pattern is a combination of the load-balanced use pattern and the high-availability use pattern. In this use pattern there is more than one messaging engine in the cluster (where the number of messaging engines is less than or equal to the number of servers). Initial requests received by the proxy server are load balanced across the cluster, to those servers that host WS-Notification service points. Subsequent requests for a resource that is created by that request (that is a subscription) are routed back to the affine messaging engine, even where it might have failed across to a different server in the cluster.
Implementation of this use pattern uses existing functionality of the service integration bus. WS-Notification services are configured in each of two cells, and a service integration bus link is configured to link the service integration bus topic spaces between the two buses.
In this use pattern the service integration bus infrastructure is used to transmit event notifications between two cells (buses) through a network of WebSphere MQ queue managers.
A WS-Notification service provides the ability to expose some or all of the messaging resources defined on a service integration bus for use by WS-Notification applications.
That is, whether this service allows dynamic topic namespaces to be created at run time.
That is, the name of the bus topic space that is used to host the ad-hoc topic namespace, and to host dynamic topic namespaces if they are permitted.

For more information about handler lists, see Working with JAX-RPC handlers and clients.
For more information about Web services security resources, see Configuring secure transmission of SOAP messages using WS-Security.
Create a new WS-Notification service and the associated objects that form the infrastructure of the WS-Notification configuration.
Use a command script to create a new WS-Notification service and the associated objects that form the infrastructure of the WS-Notification configuration.
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 that are defined under the service).
A JAX-RPC handler list and WS-Security bindings define the parameters and security policy that are used when making outbound Web service invocations. These invocations include operations such as outbound event notification (in response to a subscribe operation) and controlling demand based publishers (subscribe, pause and resume).
You can define any number of WS-Notification service points for a given WS-Notification service. Each service point defined for the same WS-Notification service represents an alternative entry point to the service. Event notifications published to a particular WS-Notification service point are received by all applications connected to any service point of the same WS-Notification service (subject to subscription on the correct topic) regardless of the particular service point to which they are connected.
When you create a WS-Notification service point you select a bus member on which the WS-Notification service point is created. You allocate a service point to a given bus member by specifying an endpoint listener that is configured for that bus member. You also choose the type of Web service binding (SOAP over HTTPS or SOAP over JMS) that is used for the WS-Notification service point.
The existence of a WS-Notification service point causes Web service endpoints for the  notification broker, subscription manager and publisher registration manager for this WS-Notification service to be exposed on the server with which the service point is associated. WS-Notification applications use these endpoints to interact with the WS-Notification service.
You use a permanent topic namespace to statically define the association between a WS-Notification topic namespace URI and a service integration bus topic space destination.
The Web address that was used to load the XML document.

When you create a new permanent WS-Notification topic namespace, you specify the namespace and associate it with one of the service integration bus topic spaces configured on the bus on which the parent WS-Notification service is defined. You cannot modify a permanent topic namespace after it has been created, other than to apply or remove topic namespace documents.
That is, the namespace URI by which WS-Notification applications refer to topics hosted by this namespace. For example http://widgetproducer.com/prices.
That is, the bus topic space that is used by this topic namespace.
Each value represents one of the service integration bus message reliability levels.
You can also set a configuration attribute of a permanent topic namespace to control the reliability (persistence or non persistence) setting that is applied to any messages inserted using a given topic namespace.

To specify a timeout time for outbound requests sent from this WS-Notification service, set the following custom property:
outbound.timeout
The value of this property is the timeout time in milliseconds. If the property is not set, a default timeout of 2 minutes is used.
To determine the strictness of the syntax checking of topics used under this WS-Notification service, set the following custom property:
com.ibm.ws.sib.wsn.strictTopicChecking
Valid values for this property are TRUE and FALSE:
  • If the property value is set to TRUE, the topic syntax rules defined in the WS-Topics specification are strictly enforced. Note that there is a performance overhead compared to the default setting, because each character of a topic is validated against a large list of permitted Unicode characters.
  • If the property is omitted or set to FALSE, syntax checking only ensures that the basic topic structure is valid, and character checking is relaxed to allow any character exception "*" and "." as a topic name part.

http://www.yourcompany.com/wsgwsoaphttp1

http://www.yourcompany.com/wsgwsoaphttp2

http://your.server.name:9080/wsgwsoaphttp1

http://your.server.name:9080/wsgwsoaphttp2

WebSphere Application Server has the following predefined local name value types:
Username token
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken
X509 certificate token
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509
# X509 certificates in a PKIPath
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1
A list of X509 certificates and CRLs in a PKCS#7
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#PKCS7
LTPA
For Lightweight Third Party Authentication, the local name value type is LTPA.
Attention:
  • If you enter LTPA in the Local name field, you must also specify the URI value http://www.ibm.com/websphere/appserver/tokentype/5.0.2 in the URI field.
  • If you enter any of the other predefined local name value types, you can leave the URI field blank. For example, to specify "Username token", enter http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken in the Local name field and do not enter a value in the URI field.
  • If you specify a custom value type for a custom token, you must specify the local name and the URI of the Quality name (QName) of the value type. For example, you might enter Custom in the Local name field, and http://www.ibm.com/custom in the URI field.
If external clients access the endpoint listener through an HTTP server or server cluster, typically using default port 80, then this URL root includes the HTTP server name and no port number. For example:
http://www.yourcompany.com/sibws
However, if you allow external clients to connect direct to your application server (for example in a development or test environment) then this URL root includes the application server host name and port number. For example:
http://your.server.name:9080/sibws
The root of the HTTP address at which external clients access your endpoint listener application, followed by /sibws. For example:
http://www.yourcompany.com/sibws
or
http://your.server.name:9080/sibws
A dynamic topic namespace has the following characteristics:
  • It does not support interoperation between WS-Notification applications and other clients of the bus such as JMS.
  • It is not possible to apply topic namespace documents to this topic space, and thus the structure and content of the topic space are unrestricted.
  • It cannot be used as part of the configuration of service integration bus links or a publish and subscribe bridge.
A permanent topic namespace has the following characteristics:
  • It enables you to expose an existing service integration bus topic space for use by WS-Notification clients, thus permitting interoperation between the WS-Notification applications and existing publish and subscribe applications connected to the Bus such as JMS.
  • It allows you to restrict the structure and content of the topic namespace by applying one or more topic namespace documents that describe the required structure.
  • It allows the topic namespace to be used as part of a topic space mapping configured on a service integration bus link (between two service integration buses) or a topic mapping as part of a publish and subscribe bridge between a service integration bus and a WebSphere MQ network.
Note: Both the WS-Notification subscription and publisher registration resources include the concept of scheduled termination, in which the application indicates a period of time after which the resource is destroyed. "Badly-behaved" in this case describes an application that requests an infinite lifetime for a resource and then does not explicitly delete the resource before it goes away (never to return).
Note: The dynamic topic namespaces used on a particular WS-Notification service are backed by a service integration bus topic space that is created automatically when you create the topic namespace. The syntax of topics used within this topic space is internal to the WS-Notification service implementation.
action
Specifies the wsa:Action element.
body
Specifies the SOAP body element.
dsigkey
Specifies the key information element, which is used for digital signature.
enckey
Specifies the ds:KeyInfo element, which is used for encryption.
messageid
Specifies the wsa:MessageID element.
relatesto
Specifies the wsa:RelatesTo element.
securitytoken
Specifies any security token elements, for example the wsse:BinarySecurityToken element.
timestamp
Specifies the wsu:Timestamp element. This element determines whether the message is valid based upon the time that the message is sent and then received.
to
Specifies the wsa:To element.
When the http://www.w3.org/TR/1999/REC-xpath-1999116 dialect value is selected, then the keyword value can be any valid XPath expression that points to a part of the message. For example:
/*[namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' and local-name()='Envelope']
/*[namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' and local-name()='Body']
The expires value is defined as a type of xsd:Duration, and the format must match the following regular expression:
-?P([0-9]+Y)?([0-9]+M)?([0-9]+D)?(T([0-9]+H)?([0-9]+M)?([0-9]+(\\.[0-9]*)?S)?)
For example, to specify a timestamp expiration of three minutes, enter PT3M.

For a high-level task view of how you configure the Web services gateway as part of an overall SIBus Web services configuration, see Enabling Web services through service integration technologies.

Before you can work with the Web services gateway you must install the SIBus Web services applications and resources.

Depending upon which template WSDL location type you specified in the previous field, enter either the URL location or the service-specific part of the UDDI service key for the template WSDL file.

Depending upon which WSDL location type you specified in the previous field, enter either the URL location or the service-specific part of the UDDI service key for the service provider WSDL file.

This is the service-specific part of the UDDI service key.

When a service is published to UDDI, the registry assigns a service key to the service.

The UDDI registry assigns a service key to your service, and publishes the service.

After the service has been published you can get the service key from the target UDDI registry.

This is either a Web address or the service-specific part of a UDDI service key. If you specify a UDDI reference, the WSDL location is assumed to be a UDDI service key.

Here is an example of a full UDDI service key:
uddi:blade108node01cell:blade108node01:server1:default:6e3d106e-5394-44e3-be17-aca728ac1791
The service-specific part of this key is the final part: 6e3d106e-5394-44e3-be17-aca728ac1791.

Reference topic

Terms of Use | Feedback

Last updated: 15 Mar 2007
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc\share\sibws_entities.html

© Copyright IBM Corporation 2004, 2007. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)