view release on metacpan or  search on metacpan

examples/jrpc-requester.pl  view on Meta::CPAN

# jrpc-requester.pl
# Jabber-RPC requester

use strict;
use Jabber::RPC::Client;

my $client = new Jabber::RPC::Client(
  server    => 'localhost',
  identauth => 'client:pass',
  endpoint  => 'jrpc.localhost/the-server',
);

my $result;

# Call component-based Jabber-RPC responder
# (the responder is jrpc-responder-component.pl)
# ----------------------------------------------
$result = $client->call('examples.getStateName', 5);
print "getStateName: ", $result || $client->lastfault, "\n";


# Call client-based Jabber-RPC responder
# (the responder is jrpc-responder-client.pl)
# -------------------------------------------
$client->endpoint('jrpc@localhost/jrpc-server');
$result = $client->call('examples.getStateList', [12, 28, 33, 39, 46]);
print "getStateList: ", $result || $client->lastfault, "\n";


# Call HTTP-based responder (via HTTPgate)
# (the responder is states-daemon.pl)
# ----------------------------------------
$client->endpoint('jrpchttp.localhost/http://localhost:8000/RPC2');
$result = $client->call('examples.getStateStruct', 
                            {  state1 => 18, state2 => 27, state3 => 48 } );
print "getStateStruct: ", $result || $client->lastfault, "\n";

lib/Jabber/RPC/HTTPgate.pm  view on Meta::CPAN

=head1 DESCRIPTION

Jabber::RPC::HTTPgate is an experimental gateway that provides
a conduit service between 'traditional' (HTTP-transported) 
XML-RPC encoded requests/responses and Jabber-RPC (XML-RPC
encoded requests/responses transported over Jabber).

The idea is that you can start a gateway, that connects as
a component to the backbone of a Jabber server, and it proxies
Jabber-RPC to HTTP-based XML-RPC endpoints, and vice versa.
That means that your Jabber-RPC client can not only make XML-RPC
encoded calls to a Jabber-RPC endpoint but also to a 'traditional'
HTTP-based XML-RPC endpoint. And it also means that your 
'traditional' HTTP-based XML-RPC client can make XML-RPC encoded
calls to a Jabber-RPC endpoint.

=head2 Jabber -> HTTP

When you create and start up a gateway, it listens for Jabber-RPC
calls, just like a normal Jabber-RPC responder. On receipt of such a
call, the gateway creates an HTTP request and sends this
request on to the HTTP-based XML-RPC endpoint. The response 
received back from this HTTP call is relayed back to the original
Jabber-RPC requester. 

While a Jabber-RPC endpoint address is a Jabber ID (JID), an 
traditional XML-RPC endpoint address is a URL. So all the Jabber-RPC
client needs to do is specify the URL in the I<resource> part of
the gateway's endpoint JID. 

=head2 HTTP -> Jabber

As well as listening for Jabber-RPC calls, a gateway will also 
service incoming HTTP requests that can be made to the HTTP
component that this gateway uses. The HTTP component (called
simply 'http') can be downloaded from the normal Jabber software
repository. 

On receipt of an HTTP request (passed to it by the HTTP component),
the gateway creates a Jabber-RPC request containing the XML-RPC
encoded payload, and sends it on to the Jabber-RPC responder 
endpoint. This endpoint is identified (via a JID) by the I<path>
part of the URL used in the call by the traditional client.

=head2 Diagram

Here's what it all looks like:


                     +---+   2-----------+            3-----------+
 Jabber backbone ----->  l   | http      |<-- HTTP -->| HTTP      |
                     l   l===| component |            | responder |