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" in Developing Applications for Oracle WebLogic Server for information on how to assemble Java EE libraries. For most profile providers, you can simply package the implementation classes in a JAR file and then register the library with Converged Application Server.

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 12-1 shows a sample configuration for a provider that accesses data using XCAP.

Example 12-1 Provider Mapping in profile.xml

<profile-service xmlns="http://www.bea.com/ns/wlcp/wlss/profile/300"
                 xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema=instance"
                 xmlns:wls="http;//www.bea.com/ns/weblogic/90/security/wls">
 <mapping>
   <map-by>provider-name</map-by>
 </mapping>
 <provider>
    <name>xcap</name>
    <provider-class>com.mycompany.profile.XcapProfileProvider</provider-class>
    <param>
       <name>server</name>
       <value>example.com</name>
    </param>
    ...
 </provider>
</profile-service>

Mapping Profile Requests to Profile Providers

When an application makes a request using the Profile Service API, Converged Application Server must find a corresponding provider to process the request. By default, Converged Application Server 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 12-1, Converged Application Server 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 12-2 shows a mapping with two alternate prefixes.

Example 12-2 Mapping a Provider to Multiple Prefixes

...
<mapping>
   <map-by>prefix</map-by>
      <provider>
          <provider-name>xcap</provider-name>
          <doc-prefix>sip</doc-prefix>
          <doc-prefix>subscribe</doc-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 12-3 shows an example configuration.

Example 12-3 Using a Custom Mapping Class

...
<mapping>
   <map-by-router>
      <class>com.bea.wcp.profile.ExampleRouter</class>
   </map-by-router>
</mapping>
...