Permalink
Browse files

further along

  • Loading branch information...
1 parent 229b879 commit 1a1e2367db05ca0d8febe126ed107dccf063bb31 Martin Logan committed Oct 15, 2010
Showing with 1 addition and 1,303 deletions.
  1. +0 −38 ebin/resource_discovery.app
  2. +0 −6 include/resource_discovery.hrl
  3. +0 −140 overview.edoc
  4. +1 −1 sinan.cfg
  5. +0 −258 src/rd_core.erl
  6. +0 −114 src/rd_heartbeat.erl
  7. +0 −266 src/rd_store.erl
  8. +0 −86 src/rd_sup.erl
  9. +0 −394 src/resource_discovery.erl
@@ -1,38 +0,0 @@
-%%% -*- mode:erlang -*-
-{application, resource_discovery,
- [
- % A quick description of the application.
- {description, "Resource discovery & management"},
-
- % The version of the applicaton
- {vsn, "0.2.0.0"},
-
- % All modules used by the application.
- {modules,
- [
- resource_discovery,
- rd_core,
- rd_heartbeat,
- rd_store,
- rd_sup
- ]},
-
- % All of the registered names the application uses.
- {registered, []},
-
- % Applications that are to be started prior to this one.
- {applications,
- [
- kernel,
- stdlib,
- gas
- ]},
-
- % configuration parameters
- {env, []},
-
- % The M F A to start this application.
- {mod, {resource_discovery, []}}
- ]
-}.
-
@@ -1,6 +0,0 @@
-%%% Type Definitions
--type resource_type() :: atom().
--type resource() :: term().
--type resource_tuple() :: {resource_type(), resource()}.
-
-
View
@@ -1,140 +0,0 @@
-@title The Resource Discovery Application
-@doc
-
-<img src="http://www.martinjlogan.com/images/erlware-header.gif"/>
-
-<p>
-The Resource Discovery application allows you to set up smart Erlang clusters. Producers and consumers within an Erlang cloud can find eachother with no pre configuration needed. For example lets say we have three services in an Erlang cloud of nodes:
-</p>
-
-<ul>
-<li>Video Display Agent</li>
-<li>Video Producer</li>
-<li>System Logger</li>
-</ul>
-
-<p>
-Each Video Display Agent needs to know about the System Logger. The Video Producer also needs to know about the System Logger and additionally each Video Producer needs to know about each Video Display Agent so that it can broadcast to each of them. Before understanding how all that is expressed in Resource Discovery we need to get some definitions out of the way.
-</p>
-
-<h2>Definitions</h2>
-
-<p>
-A "Resource Type" is the name of a particular type of resource. For example all instances of Video Producer could each have the type "video_producer". Each Video Producer has the same type name but each instance of that resource is different and so has it's own "Resource Instance" identifier. The "Resource Instance" of a "Resource Type" could be any Erlang term(), but is often times a node(), pid(), or registered name. In the case of our Video producer let's say it is an Erlang node name. Finally we have the "Resource" itself. A "Resource" is a type containing both a "Resource Type" and a "Resource Instance", for example a Video Producer resource, of which there could be many, could look like {video_producer, vid@mynet.com}.
-</p>
-
-<h2>Expressing Relationships</h2>
-
-<p>
-Using these definitions we can describe the relationships that we have between our different types, the Video Display Agent, the Video Producer, and the System Logger. The above, Resources and Resource Types are grouped into three categories for describing resource relationships.
-</p>
-
-<ul>
- <li>Local Resources</li>
- <li>Target Types</li>
- <li>Cached Resources</li>
-</ul>
-
-<p>
-Local Resources are those resources that a running Erlang node has to share with the network. A Video Display Agent node could make a call like what is below to express what it has to share with the network.
-</p>
-
-```
-resource_discovery:add_local_resources({video_producer, vid@mynet.com}).
-'''
-
-<p>
-A Video Producer node needs to know about the System Logger instance and about all instances of Video Display Agent nodes. To express this it could make a call like what is below to express this.
-</p>
-
-```
-resource_discovery:add_target_types([video_producer, system_logger]).
-'''
-
-<h2>Finding and Using Resources</h2>
-
-<p>
-Now we are set up for our systems to obtain "Cached Resources". Cached Resources are those that have been discovered and are ready to be used. When each of the nodes comes up onto the network they will make the following call:
-</p>
-
-```
-resource_discovery:inform_network().
-'''
-
-<p>
-This will communicate with all other nodes in the current network. When this function returns all Resources on the network that match the local nodes Target Types will be cached locally. Furthermore the local nodes Local Resources will be presented to all other nodes on the network to give them an opportunity to cache them if they match their respective Target Types. This call will timeout in approximately 10 seconds by default. If you desire a non blocking async call to inform the network use ``async_inform_network'' instead.
-</p>
-
-<p>
-The Cached Resources are now ready to be used. There is one question that this may raise though, which is when other nodes come online and present resources how will we know it locally. Well, if you want immediate notification of new Cached Resources you can subscribe to notifications by using:
-</p>
-
-```
-resource_discovery:add_callback_modules([video_send, log_send]).
-'''
-
-<p>
-The above call will ensure that the exported function "resource_up/1" will be called upon the caching of a new resource within the modules "video_send" and "log_send". Those functions will be called each time this happens regardless of the resource and so the resource up function should use pattern matching like that pictured below to only concern itself with the resources it needs to act upon.
-</p>
-
-```
-resource_up({system_logger, Instance}) ->
- ... do stuff ...
-resource_up(_DontCare) ->
- ok.
-'''
-
-<p>
-Finally to use a resource from the resource cache Resource Discovery provides a number of useful functions. The most common of these is ``get_resource/1''. This will loop through resources in round robin fashion supplying a different resource each time it is called. There are other functions available for more control over the specific resources of a particular type you get. There are also functions provided for removing resources that have been found to be malfunctioning or simply not around anymore. This is up to the user of resource discovery to do at the application level.
-</p>
-
-<h2>Getting into an Erlang Cloud</h2>
-
-<p>
-Getting into an Erlang node cloud is required as a minimal bootstrap for Resource Discovery. To accomplish initial contact by pinging remote nodes already in the desired cloud something similar to the following entries should be in your Erlang config file. If you already have a resource discovery entry in your config file there is no need to add a new one, you should in that case just add the contact_nodes entry into the already existant resource_discovery section of the config.
-</p>
-
-```
-{resource_discovery,
- [
- {contact_nodes, [node1@mynet.com, node2@mynet.com]}
- ]
-}
-'''
-
-<p>
-These entries instruct resource discovery to ping node1 and node2 in order to join an Erlang cloud. At least one of the pings must succeed in order for startup to succeed. Optionally all this can be overridden at the command line with the -contact_node flag:
-</p>
-
-```
--contact_node node3@mynet.com
-'''
-
-<p>
-The above flag set at startup would instruct Resource Discovery to ping node3 instead of those configured in the config file. In the future a plugin scheme will be added so that other methods of bootstrapping into a cloud may be added.
-</p>
-
-<h2>Overcomming network and resource failures with heartbeating</h2>
-
-<p>
-At times resources fail and are perhaps taken out of the store of Cached Resources. At other times networks may fail and clouds become separated. One way of overcomming all of this is to setup heartbeats from Resource Discovery. Resource discovery can be configured to heartbeat at a specified interval. This means that it will both re-ping the configured contact nodes and will run an async_inform_network at the specified interval. To enable this place configuration similar to what is below in you Erlang config file. If you already have a resource discovery entry in your config file there is no need to add a new one, you should in that case just add the heartbeat_frequency entry into the already existant resource_discovery section of the config.
-</p>
-
-```
-{resource_discovery,
- [
- {heartbeat_frequency, 60000}
- ]
-}
-'''
-
-<p>
-An entry like that above tells Resource Discovery to ping every 60000 milliseconds, or one minute. An entry of 0 disables heartbeating all together and is the default if not configured.
-</p>
-
-<p>
-Enjoy! Send questions of comments to erlware-questions@erlware.org or erlware-dev@erlware.org.
-</p>
-
-@author Martin Logan <martinjlogan@erlware.org>
-@copyright 2008 Erlware
View
@@ -1,5 +1,5 @@
project : {
name : resource_discovery
- vsn : "0.2.0.0"
+ vsn : "0.1.0.0"
},
Oops, something went wrong.

0 comments on commit 1a1e236

Please sign in to comment.