Using a Constructed Document Key to Manage Profile Data

Developing Custom Profile Service Providers 13-3

13.3 Configuring and Packaging Profile Providers

Providers must be deployed as a shared Java EE library, because all other deployed applications must be able to access the implementation. See Creating Shared Java EE Libraries and Optional Packages. For most profile providers, you can simply package the implementation classes in a JAR file. Then register the library with OWLCS using the instructions in See Deploying Shared Java EE Libraries and Dependent Applications. After installing the provider as a library, you must also identify the provider class as a provider in a profile.xml file. The name element uniquely identifies a provider configuration, and the class element identifies the Java class that implements the profile service API interfaces. One or more context parameters can also be defined for the provider, which are delivered to the implementation class in the register method. For example, context parameters might be used to identify backing stores to use for retrieving profile data. Example 13–1 shows a sample configuration for a provider that accesses data using XCAP. Example 13–1 Provider Mapping in profile.xml profile-service xmlns=http:www.bea.comnswlcpwlssprofile300 xmlns:sec=http:www.bea.comnsweblogic90security xmlns:xsi=http:www.w3.org2001XMLSchema=instance xmlns:wls=http;www.bea.comnsweblogic90securitywls mapping map-byprovider-namemap-by mapping provider namexcapname provider-classcom.mycompany.profile.XcapProfileProviderprovider-class param nameservername valueexample.comname param ... provider profile-service

13.3.1 Mapping Profile Requests to Profile Providers

When an application makes a request using the Profile Service API, OWLCS must find a corresponding provider to process the request. By default, OWLCS maps the prefix of the requested URL to a provider name element defined in profile.xml. For example, with the basic configuration shown in Example 13–1 , OWLCS would map Profile Service API requests beginning with xcap: to the provider class com.mycompany.profile.XcapProfileProvider. Alternately, you can define a mapping entry in profile.xml that lists the prefixes corresponding to each named provider. Example 13–2 shows a mapping with two alternate prefixes. Example 13–2 Mapping a Provider to Multiple Prefixes ... mapping map-byprefixmap-by provider 13-4 Developers Guide provider-namexcapprovider-name doc-prefixsipdoc-prefix doc-prefixsubscribedoc-prefix provider by-prefix mapping ... If the explicit mapping capabilities of profile.xml are insufficient, you can create a custom mapping class that implements the com.bea.wcp.profile.ProfileRouter interface, and then identify that class in the map-by-router element. Example 13–3 shows an example configuration. Example 13–3 Using a Custom Mapping Class ... mapping map-by-router classcom.bea.wcp.profile.ExampleRouterclass map-by-router mapping ...

13.4 Configuring Profile Providers Using the Administration Console

You can optionally use the Administration Console to create or modify a profile.xml file. To do so, you must enable the profile provider console extension in the config.xml file for your domain. Example 13–4 Enabling the Profile Service Resource in config.xml ... custom-resource nameProfileServicename targetAdminServertarget descriptor-file-namecustomprofile.xmldescriptor-file-name resource-classcom.bea.wcp.profile.descriptor.resource.ProfileServiceResourcere source-class descriptor-bean-classcom.bea.wcp.profile.descriptor.beans.ProfileServiceBeande scriptor-bean-class custom-resource domain The profile provider extension appears under the SipServer node in the left pane of the console, and enables you to configure new provider classes and mapping behavior.