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.
Initializes a call filter so that its inputs are sent to the
specified URI, and its outputs are sent to the next consumer
provided.
Returns the call target's URI.
Returns the content handler currently in use.
Returns the DTD handler currently in use.
Returns the declaration or lexical handler currently in
use, or throws an exception for other properties.
Assigns the URI of the call target to be used.
Does not affect calls currently being made.
Assigns the error handler to be used to present most fatal
errors.
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.