Mail Replication Service

• There exists no programmatic way to update the central VT mail server with Registry changes.

1. Ability to listen to a JMS topic for SPML messages.
2. Ability to parse a SPML message and apply the appropriate change to the mail server, supporting
   • add
   • modify
   • delete
3. Ability to guarantee that record processing is in strict chronological order.

1. Must be implemented as a clustered singleton service.

The Mail Replication Service is one of the Replication Services of the clients-repl subversion project. See Replication Services Overview for a description of the overall replication process. This documentation describes the target system specific processing referred to in that documentation.

The mail server target system specific processing is as follows:

1. Wait for an SPML message to be sent to its sendSPML() method.
2. Split the SPML Batch Request into single SPML Requests.
3. Process each SPML Request in turn.
   1. Send the message to the record processing part of this Replication Service.
   2. Handle any errors.
4. Go to 1.

Communication with the mail server uses an Ldap connection.

The Mail Replication Service includes the implementation of the record data processing, which usually is not part of the Replication Services in the clients-repl project. The record data processing is as follows:

1. Validate the record data received in the JMS message.
2. Parse from this record only those attributes that are included in a mail server record.
3. If no matching record exists in the mail server data repository, perform an add.
4. If a matching record does exist in the mail server data repository, perform a modify.
   • Update any changed fields.
     • The update processing is used for both modify and delete functionality.
     • Delete functionality for a mail server record is simply a modification of the status of the record.
     • Actual deletion from the mail server data repository is handled by the mail server.
   • Insert any new fields.
   • Delete any fields no longer included in the record.

Note that no Ldap calls are executed unless some data change is detected. This improves performance and does not unnecessarily change the modification timestamp of the mail server record.

• Person
  • Only those Person records in the Registry that have mail account(s) are replicated.
  • The selection of qualifying records is performed externally to the Replication Service processing, before the messages are added to the JMS Topic.
  • Therefore all messages in the JMS Topic are processed.

The selection is performed by the Registry Change Bean.

Template SPML Batch Requests:

<batchRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="http://www.dsml.org/DSML" onError="exit" processing="sequential">
  <spml:addRequest>
    <spml:identifier type="urn:vt.edu:SPML:person">
      <spml:id>uid=1234,ou=People,dc=vt,dc=edu</spml:id>
    </spml:identifier>
    <spml:attributes>
      <dsml:attr name="single-valued-attribute">
        <dsml:value>value</dsml:value>
      </dsml:attr>
      <dsml:attr name="multi-valued-attribute">
        <dsml:value>value1</dsml:value>
        <dsml:value>value2</dsml:value>
      </dsml:attr>
    </spml:attributes>
  </spml:addRequest>
</batchRequest>

1. problem communicating with the mail server
   • Exit from the sendSPML() method by throwing a ReplException.
   • This causes a resend of the SPML message.
   • This guarantees that no replication message is lost when the mail server is unavailable.
2. problem(s) specific to processing the requested change
   • Use the Registry Change Bean to log the SPML Request and details about the error.
   • This guarantees that all replication errors are logged.
   • Exit from the sendSPML() method using normal return because no retry is needed.

• Javadocs