Fieldbus clients are often interested in value changes. An example would be an alarm system that logs the value of a sensor that reports whether a door is open or closed. Many fieldbus systems support this technique by so-called ``System Notifications''.
This mechanism cannot be mapped directly to the communication between Internet/fieldbus gateways and their clients, as the underlying protocols differ. HTTP is a request/response protocol and does not provide means for system notifications. The only way for HTTP-based communication is polling, which means periodically reading data from the gateway. Implementing system notifications by periodic polling contains the following problems:
This problem may be solved by implementing buffers in the gateway, which store all datapoint changes until they are fetched by a client. The appropriate size of these buffers is related to the time between the polls. More information about buffering can be found in [OPCXMLDA].
Notifying the client by other means than polling is only possible in the following two ways:
[OPCXMLDA] introduces an interesting technique, called ``Advanced Subscription'', as described in chapter 3, where HTTP requests are not answered immediately. Instead, the connection is held open until a value changes, or a timeout occurs. This method greatly reduces the network and gateway load. However, HTTP was never designed for such a case and it is possible that other timeouts83 could lead to unexpected problems.
Theoretically, it would be possible to use other protocols for transporting SOAP messages that keep an open connection between the client and the server. However, such protocols are not supported by current SOAP frameworks, moreover, security regulations will eventually block these protocols.
SOAP messages may also be transported by other means than HTTP. Therefore it is possible to choose another protocol that is more suitable for system notifications. One possible protocol is SMTP, which is well known for transporting E-Mails over the Internet. SMTP is simple and a lightweight protocol and it is widely adopted. Moreover, some SOAP frameworks already support SMTP.
Clients would request to be informed, whenever certain datapoint values change. In such a case, the gateway would encapsulate the SOAP message with the fieldbus data in the SMTP protocol and send it to the client, just like an ordinary E-Mail. This way, the gateway load will be greatly reduced, as there is no polling.
The problem with SMTP is that the delay cannot be predicted in any way. SMTP messages may be routed over various relay stations, which may delay them for an unknown time. In case of errors, the sender is notified - but this may also take considerable time. Moreover, the client also has to poll some server for the SMTP message84, which adds an additional delay.