ActiveSocket allows instant Service Oriented Architecture (SOA). ActiveSocket::Base extends ActiveRecord::Base, and over-rides only where necessary. The actual model resides on the ActiveSocket server and the client (say, a rails app) hits the server when the model (service) is needed. There is no API to create/learn (no REST methods to write, no Sinatra app to maintain, etc…); simply treat the ActiveSocket model as if it were local.
Any internal web-service can be replaced with ActiveSocket. On the client side, you may replace client code with a simple model declaration (a blog service, an authentication service, etc…) and work against it (see Usage below.)
Model (server side):
class Blog < ActiveRecord::Base def self.find_most_popular_blog #returns most popular blog… end
def determine_ranking #returns ranking of this blog end end
Model (client side):
class Blog < ActiveSocket::Base active_socket_settings :host => “188.8.131.52”, :port => 4001 end
Usage (client side):
b = Blog.new => #<Blog id: nil, owner_id: nil, name: nil, created_at: nil, updated_at: nil>
#all AR find features supported, including dynamic methods… b = Blog.first b = Blog.find_by_name “foo” b = Blog.find_by_sql “Select * from blogs where id = 27”
#custom class methods identified and passed back to server, returning response b = Blog.find_most_popular_blog
#custom instance methods identified and passed back to server, returning response ranking = b.determine_ranking
As you can see, the usage is transparent. Same for other CRUD operations:
b.name = “New Name” => “New Name” b.save => true
The client is currently a plugin:
script/plugin install firstname.lastname@example.org:keithmgould/ActiveSocket.git
All you need to do on the server is:
#require your environment (this should setup ActiveRecord and pull in your models) require(File.join(File.dirname(__FILE__), 'config', 'environment'))
#Require ActiveSocket module (this can be in environment.rb) require File.join('/path/to/ActiveSocket/server/active_socket.rb')
#This can also be in environment.rb include ActiveSocket
#start her up! ActiveSocketServer.new(4001)
Here is a blog post describing an authentication server (with source code zipped at bottom): http://www.activesocket.org/2009/06/authentication-with-activesocket.html
Logs are found in the ActiveSocket directory as log.log, both client and server side. By default ActiveSocket is in production mode, and only logs fatal errors. However, if you want verbose logging:
# Server: ActiveSocketServer.new(4001,:development) # Client: # To place client-side ActiveSocket logging in development mode # place the following at the bottom of your environment file ActiveSocket::ENV = :development
As SOA becomes more prevalent in the Rails community, we need tools to allow us to build services quickly and easily. Micro web-frameworks such as Sinatra are good when the service is offered to strangers. However when both the service and client are inside our control, there is no need to waste time with XML over HTTP over TCP/IP. Furthermore, there is no need to waste time on routing (URL parsing), which is notoriously expensive.
ActiveSocket Knows Your Models
Client side, at model initialization (which is app initialization in Rails production), ActiveSocket models hit the AS-server to determine the model's structure. This means your ActiveSocket models will not only have proper columns defined (to assist with AR goodies), but any custom methods defined on your model server-side will be identified locally and properly handled (see example below.)
ActiveSocket vs Net/HTTP (xml web-service) yields a 3x speed performance, end to end.
Lines of Code
Currently, both client plugin and server are under 200 LoC.
Copyright © 2009 Keith Gould, released under the MIT license