PlServer(3)
NAME
Apache::RPC::Server - A subclass of RPC::XML::Server tuned for mod_perl
SYNOPSIS
# In httpd.conf:
PerlModule Apache::RPC::Server
PerlSetVar RpcMethodDir /var/www/rpc:/usr/lib/perl5/RPC-shared
PerlChildInitHandler Apache::RPC::Server->init_handler
...
<Location /RPC>
SetHandler perl-script
PerlHandler Apache::RPC::Server
</Location>
</Location /RPC-limited>
SetHandler perl-script
PerlHandler Apache::RPC::Server
PerlSetVar RPCOptPrefix RpcLimit
PerlSetVar RpcLimitRpcServer Limited
PerlSetVar RpcLimitRpcMethodDir /usr/lib/perl5/RPC-shared
</Location>
# In the start-up Perl file:
use Apache::RPC::Server;
DESCRIPTION
The Apache::RPC::Server module is a subclassing of RPC::XML::Server
that is tuned and designed for use within Apache with mod_perl.
Provided are phase-handlers for the general request-processing phase
("PerlHandler") and the child-process initialization phase ("PerlChil-
dInitHandler"). The module should be loaded either by inclusion in a
server start-up Perl script or by directives in the server configura-
tion file (generally httpd.con). One loaded, the configuration file may
assign the module to handle one or more given locations with the gen-
eral set of "<Location>" directives and familiar options. Additional
configuration settings specific to this module are detailed below.
Generally, externally-available methods are provided as files in the
XML dialect explained in RPC::XML::Server. A subclass derived from this
class may of course use the methods provided by this class and its par-
ent class for adding and manipulating the method table.
USAGE
This module is designed to be dropped in with little (if any) modifica-
tion. The methods that the server publishes are provided by a combina-
tion of the installation files and Apache configuration values. Details
on remote method syntax and semantics is covered in RPC::XML::Server.
Methods
In addition to inheriting all the methods from RPC::XML::Server, the
following methods are either added or overloaded by
Apache::RPC::Server:
handler
This is the default content-handler routine that mod_perl expects
when the module is defined as managing the specified location. This
is provided as a method handler, meaning that the first argument is
either an object reference or a static string with the class name.
This allows for other packages to easily subclass
Apache::RPC::Server.
This routine takes care of examining the incoming request, choosing
an appropriate server object to actually process the request, and
returning the results of the remote method call to the client.
init_handler
This is another Apache-level handler, this one designed for instal-
lation as a "PerlChildInitHandler". At present, its only function
is to iterate over all server object currently in the internal
tables and invoke the "child_started" method (detailed below) on
each. Setting this handler assures that each child has a correct
impression of when it started as opposed to the start time of the
server itself.
Note that this is only applied to those servers known to the master
Apache process. In most cases, this will only be the default server
object as described above. That is because of the delayed-loading
nature of all servers beyond the default, which are likely only in
child-specific memory. There are some configuration options
described in the next section that can affect and alter this.
new(HASH)
This is the class constructor. It calls the superclass "new"
method, then performs some additional steps. These include
installing the default methods (which includes an Apache-specific
version of "system.status"), adding the installation directory of
this module to the method search path, and adding any directories
or explicitly-requested methods to the server object.
The arguments to the constructor are regarded as a hash table (not
a hash reference), and are mostly passed unchanged to the construc-
tor for RPC::XML::Server. Three parameters are of concern to this
class:
apache The value associated with this key is a reference to an
Apache request object. If this is not passed, then it is
assumed that this is being called in the start-up phase of
the server and the value returned from "Apache-"server>
(see Apache) is used.
server_id
This provides the server ID string for the RPC server (not
to be confused with the Apache server) that is being con-
figured.
prefix The prefix is used in retrieving certain configuration set-
tings from the Apache configuration file.
The server identification string and prefix concepts are explained
in more detail in the next section. See RPC::XML::Server for a full
list of what additional arguments may be passed to new for eventual
proxy to the parent class constructor.
child_started([BOOLEAN])
This method is very similar to the "started" method provided by
RPC::XML::Server. When called with no argument or an argument that
evaluates to a false value, it returns the UNIX-style time value of
when this child process was started. Due to the child-management
model of Apache, this may very well be different from the value
returned by "started" itself. If given an argument that evaluates
as true, the current system time is set as the new child-start
time.
If the server has not been configured to set this at child initial-
ization, then the main "started" value is returned. The name is
different so that a child may specify both server-start and child-
start times with clear distinction.
version
This method behaves exactly like the RPC::XML::Server method, save
that the version string returned is (surprisingly enough) for this
module instead.
Apache configuration semantics
In addition to the known directives such as "PerlHandler" and
"PerlChildInitHandler", configuration of this system is controlled
through a variety of settings that are manipulated with the "PerlSet-
Var" and "PerlAddVar" directives. These variables are:
RPCOptPrefix [STRING]
Sets a prefix string to be applied to all of the following names
before trying to read their values. Useful for setting within a
"<Location>" block to ensure that no settings from a higher point
in the hierarchy influence the server being defined.
RpcServer [STRING]
Specify the name of the server to use for this location. If not
passed, then the default server is used. This server may also be
explicitly requested by the name """<default>""". If more than one
server is going to be created within the same Apache environment,
this setting should always be used outside the default area so that
the default server is not loaded down with extra method defini-
tions. If a sub-location changes the default server, those changes
will be felt by any location that uses that server.
Different locations may share the same server by specifying the
name with this variable. This is useful for managing varied access
schemes, traffic analysis, etc.
RpcMethodDir [DIRECTORY]
This variable specifies directories to be scanned for method
"*.xpl" files. To specify more than one directory, separate them
with "":"" just as with any other directory-path expression. All
directories are kept (in the order specified) as the search path
for future loading of methods.
RpcMethod [FILENAME]
This is akin to the directory-specification option above, but only
provides a single method at a time. It may also have multiple val-
ues separated by colons. The method is loaded into the server ta-
ble. If the name is not an absolute pathname, then it is searched
for in the directories that currently comprise the path. The direc-
tories above, however, have not been added to the search path yet.
This is because these directives are processed immediately after
the directory specifications, and thus do not need to be searched.
This directive is designed to allow selective overriding of methods
in the previously-specified directories.
RpcDefMethods [YES|NO]
If specified and set to "no" (case-insensitive), suppresses the
loading of the system default methods that are provided with this
package. The absence of this setting is interpreted as a "yes", so
explicitly specifying such is not needed.
RpcAutoMethods [YES|NO]
If specified and set to "yes", enables the automatic searching for
a requested remote method that is unknown to the server object han-
dling the request. If set to "no" (or not set at all), then a
request for an unknown function causes the object instance to
report an error. If the routine is still not found, the error is
reported. Enabling this is a security risk, and should only be per-
mitted by a server administrator with fully informed acknowledge-
ment and consent.
RpcAutoUpdates [YES|NO]
If specified and set to "yes", enables the checking of the modifi-
cation time of the file from which a method was originally loaded.
If the file has changed, the method is re-loaded before execution
is handed off. As with the auto-loading of methods, this represents
a potential security risk, and should only be permitted by a server
administrator with fully informed acknowledgement and consent.
Specifying methods to the server(s)
Methods are provided to an Apache::RPC::Server object in three ways:
Default methods
Unless suppressed by a "RpcDefMethods" option, the methods shipped
with this package are loaded into the table. The
Apache::RPC::Server objects get a slightly different version of
"system.status" than the parent class does.
Configured directories
All method files (those ending in a suffix of "*.xpl") in the
directories specified in the relevant "RpcMethodDir" settings are
read next. These directories are also (after the next step) added
to the search path the object uses.
By specific inclusion
Any methods specified directly by use of "RpcMethod" settings are
loaded last. This allows for them to override methods that may have
been loaded from the system defaults or the specified directories.
If a request is made for an unknown method, the object will first
attempt to find it by searching the path of directories that were given
in the configuration as well as those that are part of the system
(installation-level directories). If it is still not found, then an
error is reported back to the requestor. By using this technique, it is
possible to add methods to a running server without restarting it. It
is a potential security hole, however, and it is for that reason that
the previously-documented "RpcAutoMethods" setting is provided.
Usage Within <Perl> Sections
To truly unlock the power of having the RPC server attached to a
mod_perl environment, the application and configuration of the server
should be done within Perl-configuration blocks on the Apache server
itself.
In doing this, two immediate benefits are gained:
(1) The rpc-server object gets created in the master Apache process,
rather than within each child as a side-effect of the first
request. Especially in cases where there are going to be more than
one server in use within the Apache environment, this boosts per-
formance by allowing newly-created children to already have the
server object and method table readily available.
(2) It becomes possible to exert more detailed control over the cre-
ation and configuration of each server object. Combining the
get_method and add_method operations permits "sharing" (of a sort)
of methods between server objects. Recall from the RPC::XML::Server
documentation that, when a method is invoked, the first argument is
the server object that is marshalling it.
The following example illustrates these concepts in a fairly simple
environment:
# In httpd.conf:
<Perl>
# First, create and configure some Apache::RPC::Server objects
# One regular one, with the standard settings:
$main::defobj = Apache::RPC::Server->new(path => '/RPC',
auto_methods => 1,
auto_updates => 1);
# One version without the default methods, and no auto-actions
$main::secobj = Apache::RPC::Server->new(no_default => 1,
path => '/rpc-secured');
# Imagine that add_method and/or add_methods_in_dir has been used to
# add to the methods tables for those objects. Now assign them to
# locations managed by Apache:
$Location{'/RPC'} =
{
SetHandler => 'perl-script',
PerlHandler => '$main::defobj'
};
$Location{'/rpc-secure'} =
{
SetHandler => 'perl-script',
PerlHandler => '$main::secobj',
AuthUserFile => '/etc/some_file',
AuthType => 'Basic',
AuthName => 'SecuredRPC',
'require' => 'valid-user'
};
</Perl>
Note that the assignment of the "PerlHandler" value was a string repre-
sentation of the object reference itself. mod_perl performs a sort of
"thaw" of this string when the location is accessed. Since this class
implements itself as a method handler, this causes the "handler()"
method for each of the locations to be handed the Apache::RPC::Server
object directly. Note also that the value assigned to "PerlHandler"
cannot be a lexical variable, or it will be out of scope when the han-
dler is called.
DIAGNOSTICS
All methods return some type of reference on success, or an error
string on failure. Non-reference return values should always be inter-
preted as errors unless otherwise noted.
Where appropriate, the "log_error" method from the Apache package is
called to note internal errors.
CAVEATS
This began as a reference implementation in which clarity of process
and readability of the code took precedence over general efficiency. It
is now being maintained as production code, but may still have parts
that could be written more efficiently.
CREDITS
The XML-RPC standard is Copyright (c) 1998-2001, UserLand Software,
Inc. See <http://www.xmlrpc.com> for more information about the XML-
RPC specification.
LICENSE
This module is licensed under the terms of the Artistic License that
covers Perl. See <http://www.opensource.org/licenses/artis-
tic-license.php> for the license itself.
SEE ALSO
RPC::XML::Server, RPC::XML
AUTHOR
Randy J. Ray <rjray@blackperl.com>
perl v5.8.8 2005-05-02 Apache::RPC::Server(3)
See also Apache::RPC::Status(3)
See also RPC::PlClient(3)
See also RPC::PlServer(3)
See also RPC::XML(3)
See also RPC::XML::Client(3)
See also RPC::XML::Function(3)
See also RPC::XML::Method(3)
See also RPC::XML::Parser(3)
See also RPC::XML::Procedure(3)
See also RPC::XML::Server(3)
Man(1) output converted with
man2html