Service Interaction Unit


The user must provide some fields in order to feed a service. After providing the information, if valid, the service will be executed in the system.


Data input, functionality invocation.



Design a logical form asking for each field. Group them logically in terms of the domain of the application.

Provide interaction controls to allow the user:

It is handful to provide validation through the interaction to help to prevent & and fix data-entry errors. Depending on the capabilities of the implementation, different techniques of validation are avaliable:

  1. On the fly: fields been edited are validated on the fly. Errors are reported to the user as soon as the user has input an erroneous item in-context (as near as possible to the offending entry-data).
  2. Pre-check: fields are checked before trying to execute the command. If errors exist, they are reported and the service is not launched till errors are fixed and a relaunch is again requested.
  3. Postmortem: fields are not checked, and the service is launch directly. If errors exits, they will appear as a result of a failure in the invocation. The service will provide the errors and the UI will be responsable to show them.

In terms of usability, on the fly validation is the best for the user, but at the same time, the expensive one: errors are reported as soon as possible. Pre-check validation is also a must, especially when the data needs to be cross-checked as a whole on confronted with other information. Postmortem is the ugly one: you will not know in advance if the service will succeed till you try it. If it fails you will get the final cause. Anyway, errors during execution can happen to any service on any conditions: system fails, so be prepared for the worst case and provide postmortem validation to let know the user what happened.


Users keep focused in providing the data to launch an complete a service invocation. If data-input is defective, errors will be prompted as soon as possible and in-context.

After completing the data, users still have the control to launch or cancel in case of hesitation the whole operation.


Business software is full of example of this pattern. ERP systems like SAP, on-line store web forms, & web bank-transfer services are clear examples of this pattern.


The Service Interaction Unit is binded to a service definition. This pattern will carry the responsibility to create a User Interface to mediate between the service and the user.


An Service Interaction Unit is represented by a wireframe box showing its name with a small black triangle in the upper-right corner.

Root CUIP Metalevel

Valid XHTML 1.0 Strict Valid CSS