ntl-orchestra 0.9.2 → 0.9.3

checksums.yaml

@@ -1,7 +1,7 @@
 --- 
 SHA1: 
-  metadata.gz: 7a3c2a8f906bac033bc49fd31c5c785d61fcc665
-  data.tar.gz: b7909a5e4a439b36f0e133a98356a176fe31f31d
+  metadata.gz: 04d7c524d1821f1d2dcaec41a3a567c906b69830
+  data.tar.gz: 7be0bf35060a1714d0edb8d6489d49f46011ac13
 SHA512: 
-  metadata.gz: b29d023f1ec08bd492365f926d328aa2bc8568d92e67bfb030dbe9807935a465efbc15eb4a95da256aac47590ab0a23c103e07196a4d2a2526e832b46db15ea0
-  data.tar.gz: 191c785e486a990ea5a30284f14098174de61f0f55dfb416b5ca5fdee5d4ad95a7dfff89225ff4b95fdd8ca13bffacef488253e162deb37fdfc4f6a46f3afcd4
+  metadata.gz: 82a9d1d61b21cbd09464027b6a72c43fc433979ec851be8906b3f7eb590c7baad62ef200cae5cb21a86ab4a20551c34c744aa801d30601d9d7e2b147fb9a0d89
+  data.tar.gz: b8101d3196af1ffbb1f7faa578c3f665d76d102395331fcda4242b6b9e0e48cfa5d71976c91cc24f00ecdd3d0a91508733eb4be58b89e587b32df799d5f2f70a

data/.travis.yml

@@ -0,0 +1,3 @@
+language: ruby
+rvm:
+  - 2.1.5

data/Gemfile

@@ -5,7 +5,7 @@ gemspec
 
 group :test do
   gem "minitest"
-  gem "minitest-red_green"
+  gem "minitest-red_green", ">= 0.9.3"
   gem "sqlite3"
   gem "webmock"
 end

data/README.md

@@ -1,41 +1,25 @@
-# Orchestra
+# Orchestra ![Build Status](https://travis-ci.org/ntl/orchestra.svg?branch=master)
 
 Seamlessly chain multiple command or query objects together with a simple, lightweight framework.
 
-## Installation
-
-Add this line to your application's Gemfile:
-
-```ruby
-gem 'ntl-orchestra'
-```
-
-And then execute:
-
-    $ bundle
-
-Or install it yourself as:
-
-    $ gem install ntl-orchestra
-
 ## Usage
 
 Here's a simple example without a lot of context:
 
 ```ruby
 operation = Orchestra::Operation.new do
-  node :make_array do
+  step :make_array do
     depends_on :up_to
     provides :array
-    perform do
+    execute do
       limit.times.to_a
     end
   end
 
-  node :apply_fizzbuzz do
+  step :apply_fizzbuzz do
     iterates_over :array
     provides :fizzbuzz
-    perform do |num|
+    execute do |num|
       next if num == 0 # filter 0 from the output
       str = ''
       str << "Fizz" if num.mod 3 == 0
@@ -47,13 +31,13 @@ operation = Orchestra::Operation.new do
 
   finally do
     iterates_over :fizzbuzz
-    perform do |str|
+    execute do |str|
       puts str
     end
   end
 end
 
-Orchestra.perform operation, :up_to => 31
+Orchestra.execute operation, :up_to => 31
 ```
 
 There is an easy way to take this gem for a test drive. Clone the repo, and at the project root:
@@ -81,8 +65,8 @@ Finished in 0.379958s, 126.3298 runs/s, 1526.4845 assertions/s.
 Also, you can access the examples:
 
 ```ruby
-[1] pry(Orchestra)> Orchestra.perform FizzBuzz, :up_to => 31
-[1] pry(Orchestra)> Orchestra.perform InvitationService, :account_name => 'realntl`
+[1] pry(Orchestra)> Orchestra.execute FizzBuzz, :up_to => 31
+[1] pry(Orchestra)> Orchestra.execute InvitationService, :account_name => 'realntl`
 ```
 
 ## Why?
@@ -155,25 +139,25 @@ InvitationService = Orchestra::Operation.new do
   DEFAULT_MESSAGE = "I would really love for you to try out MyApp."
   ROBOT_FOLLOWER_THRESHHOLD = 500
 
-  node :fetch_followers do
+  step :fetch_followers do
     depends_on :account_name
     provides :followers
-    perform do
+    execute do
       FlutterAPI.get_account account_name
     end
   end
 
-  node :fetch_blacklist do
+  step :fetch_blacklist do
     provides :blacklist
-    perform do
+    execute do
       Blacklist.pluck :flutter_account_name
     end
   end
 
-  node :remove_blacklisted_followers do
+  step :remove_blacklisted_followers do
     depends_on :blacklist
     modifies :followers
-    perform do
+    execute do
       followers.reject! do |follower|
         account_name = follower.fetch 'username'
         blacklist.include? account_name
@@ -181,9 +165,9 @@ InvitationService = Orchestra::Operation.new do
     end
   end
 
-  node :filter_robots do
+  step :filter_robots do
     modifies :followers, :collection => true
-    perform do |follower|
+    execute do |follower|
       account_name = follower.fetch 'username'
       account = FlutterAPI.get_account account_name
       next unless account['following'] > ROBOT_FOLLOWER_THRESHHOLD
@@ -195,63 +179,63 @@ InvitationService = Orchestra::Operation.new do
   finally :deliver_emails do
     depends_on :message => DEFAULT_MESSAGE
     iterates_over :followers
-    perform do |follower|
+    execute do |follower|
       EmailDelivery.send message, :to => follower
     end
   end
 end
 ```
 
-At first sight, that very likely appears to be a giant pile of ruby DSL goop. And you would be correct. I'll show you how to plug in POROs in a bit, and there are some further improvements that will make the indirection worth while. For now, here is how you would perform this command:
+At first sight, that very likely appears to be a giant pile of ruby DSL goop. And you would be correct. I'll show you how to plug in POROs in a bit, and there are some further improvements that will make the indirection worth while. For now, here is how you would execute this command:
 
 ```ruby
 # Use the default message
-Orchestra.perform InvitationService, :account_name => 'realntl'
+Orchestra.execute InvitationService, :account_name => 'realntl'
 
 # Override the default message
-Orchestra.perform InvitationService, :account_name => 'realntl', :message => 'Say cheese!'
+Orchestra.execute InvitationService, :account_name => 'realntl', :message => 'Say cheese!'
 ```
 
 There's a lot more to learn, but let's start by building an understanding of the DSL.
 
-## Breaking down the DSL: Nodes
+## Breaking down the DSL: Steps
 
-An *operation* is a collection of nodes that each individually take part in producing some larger behavior. Each node represents one step, or stage, in the whole process. A node, essentially, accepts input, processes, and provides output. Let's look at the first node, called `:fetch_followers`.
+An *operation* is a collection of steps that each individually take part in producing some larger behavior. A step, essentially, accepts input, processes, and provides output. Let's look at the first one, called `:fetch_followers`.
 
 ```ruby
-node :fetch_followers do
+step :fetch_followers do
   depends_on :account_name
   provides :followers
-  perform do
+  execute do
     FlutterAPI.get_account account_name
   end
 end
 ```
 
-This node depends on something called an `account_name`. This means you must supply `:account_name` when you perform the operation, otherwise, `:fetch_followers` won't work. `orchestra` ensures that your performance can't commence without the required input:
+This node depends on something called an `account_name`. This means you must supply `:account_name` when you execute the operation, otherwise, `:fetch_followers` won't work. `orchestra` ensures that your invokation can't commence without the required input:
 
 ```ruby
- # Raises Orchestra::MissingInputError: Missing input :account_name
-operation.perform
+# Raises Orchestra::MissingInputError: Missing input :account_name
+operation.execute
 # Works correctly
-operation.perform :account_name => 'realntl'
+operation.execute :account_name => 'realntl'
 ```
 
 Dependencies can be optional. In the above example, `deliver_emails` defaults the `:message` input to `DEFAULT_MESSAGE`.
 
-Often, you will need the output of one operation to feed into the input of another. The annotations `depends_on`, `iterates_over`, and `modifies` all describe the inputs, and `provides` describes the output. When `provides` is omitted, the name of the output is set to match the name of the node. Orchestra actually uses the annotations to sort the ordering of the nodes at runtime to ensure that all dependencies are satisfied. In the above example, `remove_blacklisted_followers` would not execute before `fetch_blacklist`, no matter where their definitions were placed within the operation. Orchestra detects that `remove_blacklisted_followers` *depends on* `blacklist`, and `fetch_blacklist` actually provides a `blacklist`, so it knows to run `fetch_blacklist` before `remove_blacklisted_followers`. Similarly, if you had your own list of blacklisted account names lying around, you could bypass the `fetch_blacklist` node altogether, since there is no sense fetching a `blacklist` when you've already got one:
+Often, you will need the output of one operation to feed into the input of another. The annotations `depends_on`, `iterates_over`, and `modifies` all describe the inputs, and `provides` describes the output. When `provides` is omitted, the name of the output is set to match the name of the step. Orchestra actually uses the annotations to sort the ordering of the steps at runtime to ensure that all dependencies are satisfied. In the above example, `remove_blacklisted_followers` would not execute before `fetch_blacklist`, no matter where their definitions were placed within the operation. Orchestra detects that `remove_blacklisted_followers` *depends on* `blacklist`, and `fetch_blacklist` actually provides a `blacklist`, so it knows to run `fetch_blacklist` before `remove_blacklisted_followers`. Similarly, if you had your own list of blacklisted account names lying around, you could bypass the `fetch_blacklist` step altogether, since there is no sense fetching a `blacklist` when you've already got one:
 
 ```ruby
 # Never invokes fetch_blacklist
-operation.perform :account_name => 'realntl', :blacklist => %w(dhh unclebobmartin)
+operation.execute :account_name => 'realntl', :blacklist => %w(dhh unclebobmartin)
 ```
 
 This allows your operations to be reused in cases where some of the dependencies can already be satisfied.
 
-Finally, the `modifies` annotiation deserves some explaining. When a node merely mutates an input, you are certainly welcome to declare distinct `depends_on` and `modifies` annotations:
+Finally, the `modifies` annotiation deserves some explaining. When a step merely mutates an input, you are certainly welcome to declare distinct `depends_on` and `modifies` annotations:
 
 ```ruby
-node :remove_blacklisted_followers do
+step :remove_blacklisted_followers do
   depends_on :blacklist, :followers
   provides :followers
 end
@@ -260,7 +244,7 @@ end
 However, `modifies` simply condenses the two into one. The following example is identical to the previous:
 
 ```ruby
-node :remove_blacklisted_followers do
+step :remove_blacklisted_followers do
   depends_on :blacklist
   modifies :followers
 end
@@ -268,16 +252,16 @@ end
 
 ## Breaking down the DSL: the operation itself
 
-Configuring the operation is rather simple. You define the various nodes, and then specify the result. There are three ways to specify the result.
+Configuring the operation is rather simple. You define the various steps, and then specify the result. There are three ways to specify the result.
 
 The first is very straightforward:
 
 ```ruby
 Orchestra::Operation.new do
-  node :foo do
+  step :foo do
     depends_on :bar
-    provides :foo # optional, since the node is called :foo
-    perform do … end
+    provides :foo # optional, since the step is called :foo
+    execute do … end
   end
 
   self.result = :foo
@@ -288,38 +272,38 @@ The second is just a shortened form of the first:
 
 ```ruby
 Orchestra::Operation.new do
-  # Define a node called :foo and make it the result
+  # Define a step called :foo and make it the result
   result :foo do
     depends_on :bar
-    perform do … end
+    execute do … end
   end
 end
 ```
 
-The third is a minor variation of the second. The only difference is that the operation will always return `true`. `finally` makes sense for operations that perform side effects (e.g. Command objects), whereas `result` will make sense for queries.
+The third is a minor variation of the second. The only difference is that the operation will always return `true`. `finally` makes sense for operations that execute side effects (e.g. Command objects), whereas `result` will make sense for queries.
 
 ```ruby
 Orchestra::Operation.new do
   finally :foo do
     depends_on :bar
-    perform do … end
+    execute do … end
   end
 end
 ```
 
 ## Hooking in POROs
 
-You can also hook up POROs to operations as nodes. This is important both to manage complex nodes as well as leveraging existing objects in the system. The `filter_robots` node could be expressed as a PORO rather easily:
+You can also hook up POROs to operations as steps. This is important both to manage complex steps as well as leveraging existing objects in the system. The `filter_robots` step could be expressed as a PORO rather easily:
 
 ```ruby
-node FilterRobots, :iterates_over => :followers, :collection => true
+step FilterRobots, :iterates_over => :followers, :collection => true
 
 class FilterRobots
   def initialize followers
     @followers = followers
   end
 
-  def perform follower
+  def execute follower
     account_name = follower.fetch 'account_name'
     account = FlutterAPI.get_account account_name
     next unless account['following'] > ROBOT_FOLLOWER_THRESHHOLD
@@ -329,16 +313,16 @@ class FilterRobots
 end
 ```
 
-Orchestra infers the dependencies from `FilterRobots#initialize`, and automatically instantiates the object for you during the performance. You can alter the name of the method:
+Orchestra infers the dependencies from `FilterRobots#initialize`, and automatically instantiates the object for you during execution. You can alter the name of the method:
 
 ```ruby
-node MyPoro, :method => :call
+step MyPoro, :method => :call
 ```
 
-You can also hook into singletons like `Module` (or a `Class` that implements `self.perform`):
+You can also hook into singletons like `Module` (or a `Class` that implements `self.execute`):
 
 ```ruby
-node MySingleton, :method => :invoke
+step MySingleton, :method => :invoke
 
 module MySingleton
   def self.invoke … end
@@ -349,9 +333,9 @@ By default, the name of the provision will be inferred from the object name.
 
 ## Multithreading
 
-Two of the nodes in the `InvitationService` orchestration -- `filter_robots` and `deliver_emails` -- actually operate on *collections*. `deliver_emails` indicates that `:followers` is a collection by using the `iterates_over` annotation instead of `depends_on`. In fact, the two annotations are identical *except* that `iterates_over` indicates that the dependency is in fact going to be a list. Collections can be defined on a `modifies` annotation, as well, by supplying `:collection => true` as in the case of `filter_robots`.
+Two of the steps in the `InvitationService` orchestration -- `filter_robots` and `deliver_emails` -- actually operate on *collections*. `deliver_emails` indicates that `:followers` is a collection by using the `iterates_over` annotation instead of `depends_on`. In fact, the two annotations are identical *except* that `iterates_over` indicates that the dependency is in fact going to be a list. Collections can be defined on a `modifies` annotation, as well, by supplying `:collection => true` as in the case of `filter_robots`.
 
-When nodes iterate over collections, Orchestra invokes `perform do … end` block once for each item in the collection passed in. It also spreads out each invokation across a thread pool. By default, there is only one thread in the thread pool. You can reconfigure that globally in an initializer of some kind:
+When steps iterate over collections, Orchestra invokes `execute do … end` block once for each item in the collection passed in. It also spreads out each invokation across a thread pool. By default, there is only one thread in the thread pool. You can reconfigure that globally in an initializer of some kind:
 
 ```ruby
 Orchestra.configure do
@@ -360,15 +344,15 @@ Orchestra.configure do
 end
 ```
 
-These collections can operate as filters; the output list is a mapping of the input list *transformed* by the `perform` block. When the `perform` block returns `nil`, the output shrinks by one element. Consider the FizzBuzz example at the top of this document. Notice that `0` doesn't get printed out. This is because the `perform` block in `apply_fizzbuzz` returned nil when the `num` was zero. `nil` values get `compact`'ed.
+These collections can operate as filters; the output list is a mapping of the input list *transformed* by the `execute` block. When the `execute` block returns `nil`, the output shrinks by one element. Consider the FizzBuzz example at the top of this document. Notice that `0` doesn't get printed out. This is because the `execute` block in `apply_fizzbuzz` returned nil when the `num` was zero. `nil` values get `compact`'ed.
 
 ## Invoking an operation through a conductor
 
-Now that you understand how to define operations, we can do some cool things with them. First, though, we need to change the way we invoke operations. Let's instantiate a `Conductor`, and have *that* perform our operations for us:
+Now that you understand how to define operations, we can do some cool things with them. First, though, we need to change the way we invoke operations. Let's instantiate a `Conductor`, and have *that* execute our operations for us:
 
 ```ruby
 conductor = Orchestra::Conductor.new
-conductor.perform InvitationService, :account_name => 'realntl'
+conductor.execute InvitationService, :account_name => 'realntl'
 ```
 
 What did that buy us? First, we can configure the size of the thread pool specifically for this conductor:
@@ -380,20 +364,20 @@ conductor.thread_count = 5
 Second, we can inject *services* into our operation. Our operation needs to be modified such that our database connections and API access are passed in as dependencies:
 
 ```ruby
-node :fetch_followers do
+step :fetch_followers do
   depends_on :account_name, :flutter_api
   provides :followers
-  perform do
+  execute do
     flutter_api.get_account account_name
   end
 end
 
 # and
 
-node :fetch_blacklist do
+step :fetch_blacklist do
   depends_on :blacklist_table
   provides :blacklist
-  perform do
+  execute do
     blacklist_table.pluck :flutter_account_name
   end
 end
@@ -408,21 +392,21 @@ conductor = Orchestra::Conductor.new(
 )
 ```
 
-We can also override the conductor's service registry by supplying them into the performance itself, as we do any other dependency like `account_name`:
+We can also override the conductor's service registry by supplying them into the execution itself, as we do any other dependency like `account_name`:
 
 ```ruby
-conductor.perform InvitationService, :account_name => 'realntl', :blacklist_table => mock
+conductor.execute InvitationService, :account_name => 'realntl', :blacklist_table => mock
 ```
 
-What did this buy us? Two big things. We can now attach *observers* to the performance, and we can actually record all calls in and out of the `flutter_api` and `blacklist_table` services. The former allows us to share the internal operation of the performance with the rest of the system without breaking encapsulation, and the latter allows us to actually replay the operation against recorded snapshots of live performances.
+What did this buy us? Two big things. We can now attach *observers* to the execution, and we can actually record all calls in and out of the `flutter_api` and `blacklist_table` services. The former allows us to share the internal operation of the execution with the rest of the system without breaking encapsulation, and the latter allows us to actually replay the operation against recordings of live performances.
 
-Additionally, you can pass the `conductor` into nodes. In this way you can embed one orchestration into another:
+Additionally, you can pass the `conductor` into steps. In this way you can embed one operation inside another:
 
 ```ruby
 inner_operation = Orchestra::Operation.new do
   result :foo do
     provides :bar
-    perform do
+    execute do
       bar * 2
     end
   end
@@ -432,14 +416,14 @@ outer_operation = Orchestra::Operation.new do
   result :baz do
     depends_on :conductor
     provides :qux
-    perform do
-      conductor.perform inner_operation
+    execute do
+      conductor.execute inner_operation
     end
   end
 end
 
 conductor = Conductor.new
-conductor.perform outer_operation
+conductor.execute outer_operation
 ```
 
 To shorten this, the inner operation can be "mounted" inside the outer operation:
@@ -448,7 +432,7 @@ To shorten this, the inner operation can be "mounted" inside the outer operation
 inner_operation = Orchestra::Operation.new do
   result :foo do
     provides :bar
-    perform do
+    execute do
       bar * 2
     end
   end
@@ -471,9 +455,10 @@ class MyObserver
     case event_name
     when :operation_entered then "Hello"
     when :operation_exited then "World!"
-    when :node_entered then "Hello from within a node"
-    when :node_exited then "Goodbye from within a node"
+    when :step_entered then "Hello from within a step"
+    when :step_exited then "Goodbye from within a step"
     when :error_raised then "Ruh roh!"
+    when :service_accessed then "Yay, service call"
     end
   end
 end
@@ -485,17 +470,18 @@ The arguments passed to `update` will vary based on the event:
 | ------------------------ | ------------------------------------ | --------------------------------- |
 | `:operation_entered`     | The name of the operation starting   | Input going into the operation    |
 | `:operation_exited`      | The name of the operation finishing  | Output of the operation           |
-| `:node_entered`          | The name of the node                 | Input going into the node         |
-| `:node_exited`           | The name of the node                 | Output of the node                |
+| `:step_entered`          | The name of the step                 | Input going into the step         |
+| `:step_exited`           | The name of the step                 | Output of the step                |
 | `:error_raised`          | The error itself                     | `nil`                             |
+| `:service_accessed`      | The name of the service              | Recording of the service call     |
 
-Embedded performances will inherit the observers of the outer operation.
+All observers attached to the execution of the outer operation will also attach to the inner operation.
 
 ## Recording and playing back services
 
-The final main feature of Orchestra is the ability to record the service calls throughout an operation. These recordings can then be used to replay operations. This could be helpful, for instance, to attach to exceptions in your exception logging service so that programmers can replay failed performances on their development environments. In addition, these recordings could be used to drive integration testing. Thus, instead of using separate tools such as ActiveRecord fixtures, FactoryGirl, and VCR for every service dependency, you can test your operations with one single setup artifact.
+The final main feature of Orchestra is the ability to record the service calls throughout an operation. These recordings can then be used to replay operations. This could be helpful, for instance, to attach to exceptions in your exception logging service so that programmers can replay failed executions on their development environments. In addition, these recordings could be used to drive integration testing. Thus, instead of using separate tools such as ActiveRecord fixtures, FactoryGirl, and VCR for every service dependency, you can test your operations with one single setup artifact.
 
-You can record a performance on any `Conductor` by calling `#record` instead of `#perform`:
+You can record a performance put on by any `Conductor` by calling `#record` instead of `#execute`:
 
 ```ruby
 recording = conductor.record InvitationService, :account_name => 'realntl'
@@ -529,6 +515,21 @@ recording = JSON.load json
 Orchestra.replay_recording InvitationService, recording
 ```
 
+## Installation
+
+Add this line to your application's Gemfile:
+
+```ruby
+gem 'ntl-orchestra'
+```
+
+And then execute:
+
+    $ bundle
+
+Or install it yourself as:
+
+    $ gem install ntl-orchestra
 
 ## Contributing
 

data/lib/orchestra/conductor.rb

@@ -9,18 +9,18 @@ module Orchestra
       self.thread_count = Configuration.thread_count
     end
 
-    def perform operation, input = {}
-      operation.perform self, input do |performance|
-        copy_observers performance
-        yield performance if block_given?
+    def execute operation, input = {}
+      operation.execute self, input do |execution|
+        copy_observers execution
+        yield execution if block_given?
       end
     end
 
     def record *args
       recording = Recording.new
       add_observer recording
-      perform *args do |performance|
-        performance.add_observer recording
+      execute *args do |execution|
+        execution.add_observer recording
       end
       recording
     ensure

data/lib/orchestra/dsl/object_adapter.rb

@@ -1,12 +1,12 @@
 module Orchestra
   module DSL
     class ObjectAdapter
-      def self.build_node object, args = {}
-        method_name = args.delete :method do :perform end
+      def self.build_step object, args = {}
+        method_name = args.delete :method do :execute end
         collection = args.delete :iterates_over
         adapter_type = determine_type object, method_name
         adapter = adapter_type.new object, method_name, collection
-        NodeFactory.build adapter, args
+        StepFactory.build adapter, args
       end
 
       def self.determine_type object, method_name
@@ -23,12 +23,12 @@ module Orchestra
 
       def initialize object, method_name, collection
         @collection = collection
-        @method_name = method_name || :perform
+        @method_name = method_name || :execute
         @object = object
       end
 
       def build_context state
-        ExecutionContext.new self, state
+        ObjectContext.new self, state
       end
 
       def collection?
@@ -36,7 +36,7 @@ module Orchestra
       end
 
       def context_class
-        @context_class ||= Node.build_execution_context_class dependencies
+        @context_class ||= Step.build_execution_context_class dependencies
       end
 
       def dependencies
@@ -56,7 +56,7 @@ module Orchestra
         end
       end
 
-      def perform state
+      def execute state
         deps = object_method.dependencies
         input = state.select do |key, _| deps.include? key end
         Invokr.invoke :method => method_name, :on => object, :with => input
@@ -74,7 +74,7 @@ module Orchestra
           "#{object} does not implement instance method `#{method_name}'"
       end
 
-      def perform state, maybe_item = nil
+      def execute state, maybe_item = nil
         instance = Invokr.inject object, :using => state
         args = [method_name]
         args << maybe_item if collection?
@@ -86,10 +86,10 @@ module Orchestra
       end
     end
 
-    class NodeFactory
+    class StepFactory
       def self.build *args
         instance = new *args
-        instance.build_node
+        instance.build_step
       end
 
       attr :adapter, :compact, :provides, :thread_count
@@ -100,12 +100,12 @@ module Orchestra
           :provides => nil, :compact => false, :thread_count => nil
       end
 
-      def build_node
+      def build_step
         adapter.validate!
-        Node::DelegateNode.new adapter, build_node_args
+        Step::ObjectStep.new adapter, build_step_args
       end
 
-      def build_node_args
+      def build_step_args
         hsh = {
           :dependencies => adapter.dependencies,
           :provides     => Array(provides),
@@ -115,7 +115,7 @@ module Orchestra
       end
     end
 
-    class ExecutionContext
+    class ObjectContext
       def initialize adapter, state
         @__adapter__ = adapter
         @__state__ = state
@@ -125,8 +125,8 @@ module Orchestra
         end
       end
 
-      def perform *args
-        @__adapter__.perform @__state__, *args
+      def execute *args
+        @__adapter__.execute @__state__, *args
       end
     end