Dynamic and static models: creating new entities and properties at runtime

Express (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select a registry or repository > Manage realms in a federated repository > Virtual member manager > Develop with virtual member manager > Extend virtual member manager functionality in the application > Dynamic model schema loading process

Dynamic and static models: creating new entities and properties at runtime

Virtual member manager is configured to use either the dynamic model or the static model. We can create at runtime new entity types, new property types and add existing or new property types to the new entity types.

About this task

You need to call the virtual member manager createSchema API to create new entity types, new property types and add existing or new property types to the new entity types at runtime without restarting virtual member manager. Out-of-the-box, both the LDAP Adapter and the DB Adapter supports this type of procedure. For this example to create a new entity type called ContactPerson which extends from the virtual member manager built-in entity type PersonAccount. You also want to create a new property type called cellPhone and add this property type to this entity type. This example uses the LDAP Adapter.
Perform the following:

Procedure
If the underlying adapters include LDAP Adapter, ensure that the corresponding LDAP attribute schema of the new property type is defined on LDAP server and contained by the LDAP object classes of entity type. Virtual member manager does not provide function to create and update LDAP schema on LDAP server. In this example, the object class eContactPerson and the attribute cellularTelephoneNumber need be created if they are not predefined.
If underlying adapters include DB Adapter, no extra preparation is needed.
On the client side, construct a data graph to create the new property type.
The data object EntitySchema is used for creating the new entity type and the data object PropertySchema is used for creating the new property type. Both data objects need to specify the namespace URI that the new entity and property type are created under. The new entity type needs to specify the parent entity type that it extends from.
Besides the schema information, both data objects specify the configuration information needed for virtual member manager and the underlying adapter (LDAP Adapter) to support the new entity types and property types. For example, the default parent and RDN property are needed to add this new entity to the virtual member manager configuration XML file (wimconfig.xml). The default parent defined in the realm is created through the Configuration Manager. The attributes objectClasses and objectClassForCreate are needed by the LDAP Adapter to map the new entity to the corresponding LDAP object classes. For a new property, the LDAP Adapter needs the name of the corresponding LDAP attribute, which might not be the same as the property name. If they are not the same, add an LDAP attribute configuration and specify the name of the corresponding virtual member manager property name. For information on configuring this using command-line interface, read about the addIdMgrLDAPAttr command in IdMgrRepositoryConfig command group , in the WAS information center.
The following is the sample data graph. The element entitySchema is used to define the schema for entity ContactPerson. The element entityConfig contains the configuration information for the entity type. For example, the element actionNotAllow is used to specify that this type of entity can not be deleted. The element propertySchema is used to define the schema for property cellPhone.
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo"
    xmlns:wim="//www.ibm.com/websphere/wim">
<wim:Root>
<wim:schema>
<wim:entitySchema entityName="ContactPerson"
                        nsPrefix="yourext"
                        nsURI="//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  ://www.yourco.com/wim/yourext"
          parentEntityName="PersonAccount">  
<wim:entityConfiguration defaultParent="cn=users,dc=yourco,dc=com"
                                 rdnProperty="uid">    
<wim:actionNotAllow actionName="delete"/>    
<wim:metaData name="objectClasses">      
<wim:values>eContactPerson
</wim:values>    
</wim:metaData>    
<wim:metaData name="objectClassesForCreate">      
<wim:values>eContactPerson
</wim:values>      
<wim:values>inetOrgPerson
</wim:values>    
</wim:metaData>    
<wim:metaData name="rdnProperties">      
<wim:values>uid
</wim:values>    
</wim:metaData>  
</wim:entityConfiguration>
</wim:entitySchema>
<wim:propertySchema nsURI="//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  ://www.yourco.com/wim/yourext"
                          dataType="STRING"
                          multiValued="true"
                          propertyName="cellPhone">  
<wim:applicableEntityTypeNames>yourext:ContactPerson
</wim:applicableEntityTypeNames>
</wim:propertySchema>
</wim:schema>
</wim:Root>
</sdo:datagraph> 
For more information about using the propertySchema and extensionPropertySchema data objects, see the section, Extend property schema in the topic, Program prerequisites. Also read about Configure a property extension repository in a federated repository in the WebSphere Application Server information center.
Results

On the client side, the exploiting virtual member manager application calls the virtual member manager createSchema API through the Local Service Provider. Local Service Provider detects that this call changes the schema and updates the local schema (ECore) after the createSchema API call is finished.
On the server side, the Schema Manager receives the API call from client. The Schema Manager first checks if the new entity types and property types already exist and throws an exception if they do. Then the Schema Manager creates a new ECore model (EPackage) with namespace URI (//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/ ://www.yourco.com/wim/yourext) if it does not already exist. Then it will add the schema of the new entity types and property types to the ECore model in the memory.
The Schema Manager adds the schema of the new entity type and property type to wimxmlextension.xml. If this file does not exist, a new file is created. The following is the sample content of the wimxmlextension.xml after this operation is finished.
The configuration information is not written to this XML file.
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo"
    xmlns:wim="//www.ibm.com/websphere/wim">
<wim:schema>
<wim:entitySchema nsPrefix="yourext"
                      nsURI="//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  ://www.yourco.com/wim/yourext"
                      entityName="ContactPerson"
                      parentEntityName="PersonAccount"/>
<wim:propertySchema nsURI="//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/  ://www.yourco.com/yourext"
                        dataType="STRING"
                        multiValued="true"
                        propertyName="cellPhone">
<wim:applicableEntityTypeNames>ContactPerson
</wim:applicableEntityTypeNames>
</wim:propertySchema>
</wim:schema>
</sdo:datagraph> 
The Schema Manager then calls Configuration Manager.
The Configuration Manager adds the configuration information of the new types to the virtual member manager configuration XML file (wimconfig.xml). The following are the sections added for this new entity type ContactPerson in wimconfig.xml after this operation is finished.
<config:supportedEntityTypes defaultParent="cn=users,dc=yourco,dc=com"
                             name="yourext:ContactPerson">

<config:rdnProperties>uid
</config:rdnProperties>
</config:supportedEntityTypes>

<config:repositories xsi:type="config:LdapRepositoryType" ...>

<config:EntityTypesNotAllowDelete>yourext:ContactPerson
</config:EntityTypesNotAllowDelete>

<config:ldapEntityTypes name="yourext:ContactPerson">  
<config:rdnAttributes name="uid"/>  
<config:objectClasses>eContactPerson
</config:objectClasses>  
<config:objectClassesForCreate>eContactPerson
</config:objectClassesForCreate>  
<config:objectClassesForCreate>inetOrgPerson
</config:objectClassesForCreate>
</config:ldapEntityTypes>
</config:repositories> 
The Schema Manager then calls the Repository Manager.
The Repository Manager calls the createSchema SPI method of all the adapters. Adapters that support creating schema, then perform any necessary operations to support the new schema. As examples, the LDAP Adapter refreshes the cache to reflect the changes in schema and configuration. The DB Adapter creates the schema of the new entity and property in database and refresh the caches.
Adapters that do not support creating schema, for example the File Adapter which does not support creating new types at runtime, throw an OperationNotSupportedException.
If at least one repository adapter supports creating new entities and does not throw the OperationNotSupportedException, Virtual member manager returns the repository IDs of these repositories in the output data graph.
At the client side, after the createSchema API call is returned, the Local Service Provider calls the getEPackages API to retrieve the latest schemas. The Local Service Provider reregisters the schemas in the client JVM. Exploiting applications can call the virtual member manager create API to create a new entity of type ContactPerson with property cellPhone. Virtual member manager does not need to restart for the schema change to become active.

Parent topic: Dynamic model schema loading process

+
Search Tips | Advanced Search