DMS

Actors

• Client (aka SubmittingParty)
• Server (aka ReceivingParty, RespondingParty)
• Beneficiary (aka RequestingParty, RespondToParty)

Description
A Client requests a service from a Server on behalf on a beneficiary party.

Assumptions and Preconditions

• There are no connectivity or configuration issues.
• The Client can provide a set of input data and/or documents that the service can use in order to produce a resulting set of output data and/or documents (the payload).

Postconditions
The Client and its Beneficiary receive the benefit of the service.

1. The Client sends a request to the Server. The request includes:
   1. A set of input data, including documents if appropriate
   2. Explicit or implied requirements for what the Client expects the service to do (the task).
   3. Credentials to allow the Server to identify Client and verify that the Client is entitled to make the request.
2. The Server receives and interprets the request message.
3. The Server may reject the request because it does not understand, has conflicting information, or is otherwise unable to perform the requested task.
4. If the Server accepts the task, there are two basic methods of reacting:
   1. Synchronous: The Server performs the task while the Client waits and creates a response message containing the payload result. The payload can include one or more statuses, a set of output data, and documents if appropriate.
   2. Asynchronous: If the task will take too long for the Client to wait, the Server creates a response acknowledging the request, and provides one or more tokens to identify the Server’s task and to allow the Client to claim the full result when it is ready. It may also provide an estimated time for completion.
5. The Server sends the response it created, including one or more status, error and warning messages.
6. The Client receives and interprets the response.
7. For asynchronous methods, the Client periodically sends a polling request, including the tokens furnished in the Server’s acknowledging response.
8. The Server responds to the polling request. If the payload result is ready, the Server may send it as part of the response.

Commentary

I think that most of the services supported by the MISMO data model can be based upon this use case, and as a result, messages that support this use case can be used as a basis for each service type, including Document Management Services. Here are samples:

Request:

<<MESSAGE xmlns="http://www.mismo.org/residential/2009/schemas">
  <DATA>
    <DEAL>
      <!-- Input data related to the request -->
      <PARTIES>
         <!-- all parties related to the message -->
      </PARTIES>
      <SERVICE>
          <SPECIFIC_SERVICE label="MyServiceRequest">
            <SPECIFIC_SERVICE_REQUEST>
              <!-- Requirements and identifiers of the request -->
              <ServiceRequestIdentifier>xxx</ServiceRequestIdentifier>
            </SPECIFIC_SERVICE_REQUEST>
          </SPECIFIC_SERVICE>
        <SERVICE_REQUEST>
        </SERVICE_REQUEST>
      </SERVICE>
    </DEAL>
  </DATA>
  <DOCUMENT_SETS>
     <!--... all input documents needed for this request -->
  </DOCUMENT_SETS>
  <RELATIONSHIPS>
    <!-- links relating across DATA and DOCUMENT_SETS containers -->
  </RELATIONSHIPS>
</MESSAGE>
<MESSAGE>       

Response:

<MESSAGE xmlns="http://www.mismo.org/residential/2009/schemas">
  <DATA>
    <DEAL>
      <PARTIES>
         <!-- All returned parties -->
      </PARTIES>
      <SERVICES>
        <SERVICE label="YourRequestedService">
          <SPECIFIC_SERVICE>
            <SPECIFIC_SERVICE_RESPONSE>
              <!-- Descriptions and identifiers of the response -->
              <ServiceResponseIdentifier>xxx</ServiceResponseIdentifier>
              <ServiceProgressDescription></ServiceProgressDescription>
              <ServiceEstimatedProcessingMinuteCount></ServiceEstimatedProcessingMinuteCount>
            </SPECIFIC_SERVICE_RESPONSE>
          </SPECIFIC_SERVICE>
          <STATUSES>
            <STATUS label="Primary">
              <StatusCode/>
            </STATUS>
            <STATUS label="Piece1">
              <StatusCode></StatusCode>
            </STATUS>
            <STATUS label="Piece2">
              <StatusCode></StatusCode>
            </STATUS>
          </STATUSES>
        </SERVICE>
      </SERVICES>
    </DEAL>
  </DATA>
  <DOCUMENT_SETS>
     <!--... all documents returned from this response -->
  </DOCUMENT_SETS>
  <RELATIONSHIPS>
    <!-- links relating across DATA and DOCUMENT_SETS containers -->
  </RELATIONSHIPS>
</MESSAGE>