Wavelet Submit Request / Response

In order for a wave service provider to make changes to a wavelet that is remote it sends a submit request message from its federation remote service to the hosting WSP's federation host service.

The submit request message is contained within a XMPP iq stanza of type set and has the following structure:
Most of this has been seen in the previous few posts, specifically look at Wavelet Update Operation for information on delta's, and signatures. The only new element in this message is the address access element which is used in access control (this will be discussed in a later post).

When the host receives this it responds to the remote with the submit response message. This message is contained within a XMPP iq stanza of type result and has the following structure:
Again all of the elements here have been seen before, so onto the more interesting part, how do we handle these two messages.

The following process is used when receiving a submit request:
The submit request message is sent from the federation remote to the federation host of the authoritative WSP. The host uses the controller to apply the delta to the given wavelet. The controller does this by loading the wavelet, creating an operation from the operation factory, and applying the operation to the wavelet. The wavelet is then stored back to the wave store and the host returns a submit response message to the remote.

There are obviously a few things missing from these processes as they have been given over the last few posts:

• how submit requests trigger wavelet updates
• version hashing / signatures
  
• error conditions

But these sequence diagrams will be the basis for the initial development of my wave service provider. From the sequence diagrams the main sub-systems of the system can be deduced, and a few facades can be defined for access to these sub-systems.

The next post will be summarizing these sub-systems, the facade's to them, and the technologies that will be used in creating this platform.