WebSphere brand IBM WebSphere Presence Server, Version 7.0

Mapping and normalization

Using public identity mapping, Presence Server can tie together presence information from disparate sources that relate to the same person or presentity but use different, non-correlated identifiers. With identity mapping, presence information from different IDs for the same user are presented as a single aggregated presence document. When a subscriber subscribes to any one of these identities, the subscriber receives the aggregated document.

Presence Server begins by preloading the contents of white and black lists into memory. If public identity mapping is enabled for the white or black lists, Presence Server maps each identity to its fundamental identity and then manages it in memory. For incoming PUBLISH and SUBSCRIBE requests, the publisher/subscriber identity is mapped and the fundamental identity is compared to the identities in the white or black list. When the lists are updated (by default once an hour) the identities are mapped again.

PUBLISH operations

For PUBLISH operations, Presence Server verifies that the publisher is publishing his or her own presence document (unless the publisher in the white list). The identity comparison is based on the UIDNormalizer method for comparison identities without referring to their fundamental identity. The comparison is applied for the sender identity as taken from the WebSphere® Application Server principal (from the p-asserted-identity header) for the "To" header and for the entity attribute as specified in the presence document.

The published document is stored in the database based on the presentity's fundamental identity. Presence information published from different identities is aggregated into a single document according to their fundamental identity. In this way, a subscriber who is subscribing to any one of the user's public identities will receive the full information published for the presentity. As a result, it is possible to perform a modify/unpublish operation with a continued eTag from different public identities that map to the same fundamental ID. For example: user A publishes document X, user B can modify document X, provided A and B map to the same fundamental identity.
Note: In some cases Presence Server needs to compare contact addresses, mainly in merges of PIDF documents. For this purpose Presence Server uses case-sensitive string comparison only.
Presence Server manages all incoming subscriptions based on the fundamental identity of the user the subscription is on (as taken from the To header). Upon re-subscribing, the presentity is mapped again to its fundamental identity, and if the mapping has changed Presence Server handles this as follows: a full notification is sent with the presence information for the new presentity, and the winfo notifications are also generated if necessary. For URI-list subscriptions or group subscriptions, all members of the groups are also mapped to their fundamental identities in the same manner.

SUBSCRIBE operations

For SUBSCRIBE operations, if presence rules are disabled and the subscriber is not in the white or black lists, Presence Server verifies that the subscriber is allowed by comparing the sender presentity from the WebSphere Application Serverprincipal (as taken from the p-asserted-identity header) with the presentity in the To header, without regard to fundamental identity, and allows the subscription.

When presence rules are enabled, by default Presence Server does not use identity mapping for testing identity conditions. Presence Server tests identity conditions matching using original subscriber identity by applying the UIDNormalizer method for comparison without regards to the fundamental identity. The domain comparison is done using UIDNormalizer as well. The domain of the original subscriber public identity is used for testing the domain condition. A configurable option is provided to apply identity mapping when testing identity conditions. With this option, Presence Server considers fundamental subscriber identity when using UIDNormalizer for testing identity conditions. The domain of the subscriber fundamental identity is used for testing the domain condition in this case.

For a winfo subscription, if the subscriber is not in the white or black list, Presence Server verifies that the subscriber is allowed by comparing the sender presentity from the WebSphere Application Server principal (as taken from the p-asserted-identity header) with the presentity in the To header, without regard to fundamental identity. A watcher that subscribes on any of its public identities receives the document with aggregated watchers for all presentities relating to the same fundamental identity.

The Telecom Application Enablement Feature provides samples. For more information, refer to the IBM WebSphere Telecom Application Enablement Feature information center.




Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.