Input is sent as an XML request to given URI, and the output of this
filter is the parsed response to that request.
A connection is opened to the remote URI when the startDocument call is
issued through this filter, and the request is finished when the
endDocument call is issued. Events should be written quickly enough to
prevent the remote HTTP server from aborting the connection due to
inactivity; you may want to buffer text in an earlier pipeline stage.
If your application requires validity checking of such
outputs, have the output pipeline include a validation stage.
In effect, this makes a remote procedure call to the URI, with the
request and response document syntax as chosen by the application.
Note that all the input events must be seen, and sent to the URI,
before the first output event can be seen. Clients are delayed
at least by waiting for the server to respond, constraining concurrency.
Services can thus be used to synchronize concurrent activities, and
even to prioritize service among different clients.
You are advised to avoid restricting yourself to an "RPC" model
for distributed computation. With a World Wide Web, network latencies
and failures (e.g. non-availability)
are significant; adopting a "procedure" model, rather than a workflow
model where bulk requests are sent and worked on asynchronously, is not
generally an optimal system-wide architecture. When the messages may
need authentication, such as with an OpenPGP signature, or when server
loads don't argue in favor of immediate responses, non-RPC models can
be advantageous. (So-called "peer to peer" computing models are one
additional type of model, though too often that term is applied to
systems that still have a centralized control structure.)
Be strict in what you send, liberal in what you accept, as
the Internet tradition goes. Strictly conformant data should never cause
problems to its receiver; make your request pipeline be very strict, and
don't compromise on that. Make your response pipeline strict as well,
but be ready to tolerate specific mild, temporary, and well-documented
variations from specific communications peers.
getCallTarget
public final String getCallTarget()
Returns the call target's URI.
setCallTarget
public final void setCallTarget(String uri)
throws IOException
Assigns the URI of the call target to be used.
Does not affect calls currently being made.