Enterprise Rails

The Client Plugin

Accessing an XML-RPC service from another Rails application—presumably a thin front-end—is, like all things Rails, extremely easy. If we’re within a controller, such as ApplicationController, the following line is all we need:

web_client_api :movies,
               :xmlrpc,
               "http://localhost:3000/movies_service/api",
               :handler_name => "movies",
               :timeout => 5

If we’re working from a model class, we can create a client by directly instantiating an instance of ActionWebService::Client::XmlRpc:

movies = ActionWebService::Client::XmlRpc.new(
           MoviesApi, "http://localhost:3000/movies_service/api",
           {:handler_name => 'movies', :timeout => TIMEOUT_SECONDS}
         )

In both cases, we then call methods on the local variable movies. In the first example, the first parameter to web_client_api defines both the local variable name of the client to be created, as well as which API file to look for, in this case, MoviesApi. In the second example, each of these is explicit.

Hopefully this seems strange. Why does the client need access to the MoviesApi class defined on the server? Such a constraint doesn’t seem like it provides the loose coupling we are after with a service-oriented architecture.

In reality, we don’t need to share any files between the client and server, but doing so is what allows the Rails client configuration to be so simple. In cases where we have control over both the client and server, and we are building both with Rails, it’s not hard to share the API definition class. For non-Rails clients, ...