Using Callbacks to Notify Clients of Events

Callbacks notify a client (caller) of your web service or Java control that some event has occurred. For example, you can notify a client when the results of that client's request are ready, or when the client’s request cannot be fulfilled.

You can easily add callbacks to the interface of your web service or custom Java control using the Add Callback action in Design View. However, you should be aware that doing so places demands on the client that not all potential clients will be able to meet. This topic describes callbacks and explains some of the things to keep in mind when working with them.

Understanding Callbacks: Messages to the Client

When you add a method to a web service or custom Java control, you implement a message that a client can send to the web service or Java control to perform some operation. When you add a callback to a web service or custom Java control, you are defining a message that the web service or Java control can send to the client notifying the client of an event that has occurred. So adding a method and defining a callback are completely symmetrical processes, with opposite recipients.

WebLogic Server allows a web service to receive XML and SOAP messages, and routes them automatically to your web service. In order to receive callbacks, the calling client must be operating in an environment that provides the same services. This typically means the client is a web service running on a web server. If the client does not meet these requirements, it is likely not capable of receiving callbacks from your web service. The same requirement applies for Java controls that may use XML and SOAP messaging, such as a web service control, and Java controls whose Java method and callbacks are triggered directly.

The notion that callbacks are messages to the client is important if you want to apply XML maps to callback parameters or return values. The parameters to a callback go into the outgoing message to the client, and the return value is converted from the resulting incoming message from the client. This can seem strange because programmers typically associate all parameters with incoming data and return values with outgoing data.

Maintaining Message Formats

For web services, as well as Java controls using XML messaging, the protocol and message format used for callbacks is always the same as the protocol and message format used by the conversation start method that initiated the current conversation. If you attempt to override the protocol or message format of a callback, an error is thrown.

Related Topics

Introduction to Asynchronous Interfaces

Designing Conversational Web Services

Using Polling as an Alternative to Callbacks