Wiki
Notification

Essentially what notification amounts to, is dealing with the fact that a Web Service is a client initiated interface, so there’s no obvious way for the server to “push” information back without expecting more from the client . There are at least four options in this regard

  1. Polling for completion. Not really a ‘notification’ mechanism in the strictest sense, but the easiest way to connect systems without placing any requirements on the client. Regardless of other mechanisms available, there should generally be a Query Status mechanism to facilitate this as the most basic fallback.
  2. Email notification. A return email address could be presented by the client, when accepting the quote. There would then be a standard notification message sent (we would have to define the format, which would include the job ticket) to this address on job completion (or on job error ? query ?)
  3. Presentation of a return Web Service. We would have to define another standard service that could be offered by a client for return notification. The idea is that the client would simply have to supply the URL at which this service is available. This is more flexible, but many users may not be in a position to supply it. There are three reasons for this
    1. Smaller users may not be hosting their own sites, or may not even have a fixed URL
    2. Corporate users may have a large security overhead in presenting an external web service.
    3. Users in general may not want to have to present a specific service, just so they can use this one.
  4. BPEL4WS notification messages. Needs more detail, but BPEL4WS mechanisms exist for just such notification.

Most workflows should be able to work off email notification, but it’s low-tech and can be awkward. Probably a requirement to support this for lower tech users however, even if we do the return service in addition.