“Event processing has been going on for more than fifty years.”

However, in On Event Processing as a Discipline and Some Subsets another colleague mistakenly blogs,

“… people who dealt in this area [network management and event correlation] have never investigated event processing in the larger sense (e.g. looking at additional patterns), and this area has also not spawned the event processing discipline.”

If you examine just one page from the CEP history at Stanford, researchers there outlined their view of the future applications for CEP, as follows:

• Instant Insight  - hierarchical event viewing applied to the Enterprise IT layer.
  • Analysing business processes
• Network Level Monitoring and Management
• Cyber Security: Network Intrusion Detection
• Enterprise Monitoring and Management
• Modeling and Simulation of Collaborative Business Processes
• Business Policy Monitoring
• Analysis and Debugging of Distributed Systems

These applications areas mentioned by Stanford researchers, including Professor Luckham, support and validate our recent discussion Magic Quadrant for IT Event Correlation and Analysis, 2007 where we concluded that “event correlation and event analysis is Gartner’s closest magic quadrant (MQ)  [...] relates directly to complex event processing (and event processing in general).”  

If you take a detailed look at the 1999 CEP presentation, Defeating Large Scale Attacks: Technology and Strategies for Global Network Monitoring you will readily see that our colleagues are incorrect when they says that event correlational and network management folks have never investigated event processing in the “larger sense”.  For example, the 1999 slides above, Stanford, slide 6, is titled “Complex Event Processing,” defining CEP from the application perspective of event correlation;

Complex Event Processing

• Accept network ‘events’ from any source
  • CISCO NetFlow FlowCollector, tcpdump
• Correlates events based on content and temporal relationship between events
• Event Processing Agents (EPAs) connected in an Event Processing Network (EPNs)
• Both post-mortem and real-time processing

This single event correlational project example from David’s team at Stanford examined the challenging event correlation problems in the context of hierarchical events, maps, patterns, visualization tools, event processing models, patterns languages, network management abstraction layers, and more.  Those core event processing problems from this 1999 example, very large and complex then, still exist today and are much more large and complex - precisely why it is called “complex event processing.”

It is quite obvious, in just this one example, that many folks have been looking at event correlation as a motivating application for event processing, in a larger context, for a long time, contrary to what our colleagues write in their “history of event processing” posts.  

In a future post I will completely debuke these event processing “history revisionists.”   I will illustrate very clearly how the history of event processing goes back at least a decade, and perhaps two (twenty years) before the history outlined in posts like On Research and Practice in Event Processing and The History of Complex Event Processing. 

David Luckam stated that the art-and-science of event processing goes back around 50 years. 

I am not sure I will go all the way back to 1960 in my next post on the history of event processing.  However,  I will go back at least to the early days of Internet Protocol (IP) networking and illustrate why distributed IP networking, network management and network security, is one of the key  motivating factors for what we now call “event processing” and “complex event processing.”

We represent situations in the domain of event processing by building and refining models of situations. This means that one way to develop CEP applications or designing CEP architectures is to define situations of interest and build models that define the situation.

After we have a working model of the situation we will generally have a hierarchical model of the situation composed of various components of the situation. For purposes of discussion I refer to this as situation modelling.

If a situation is modelled with 15 components then we need to detect these components of the situation. In addition, it is generally not good enough to simply detect each one of these components of the situation. We also have to hold the state of each one of the situational components.

However, it is not good enough to simply observe the state of 15 components of a situation in the detection process; we also need to observe the relationship between the components.

So, let’s say the situation we are looking for is “commercial air plane collision” and we are building a model of this situation. To keep the model simple we will limit the model to airplanes and omit objects like birds, buildings; but we will include wind, air speed, and direction.

Our situational model consists of primary objects, in this case an airplane. Now we need a simple model of an airplane, which is modelled, in this overly simple example, as span, velocity, acceleration, altitude, orientation and relative wind speed and direction. Generally, an object-oriented approach to model building is preferred so we can reuse the model and overload, morph, inherit and encapsulate as necessary.

One example would be when our boss comes to us and says, great job on the airplane collision model, but I also want to know how much jet fuel is on the planes at the moment of our projected situation, so we can estimate the intensity of the explosion. So we need another model and our earlier very simple airplane model would inherit the jet fuel tank model our boss requires.

I hope from this simple example of model building that you will conclude that modelling is one of the most important aspects of CEP. Without good models, situation detection impossible, and CEP engines are useless. Situation modelling is critical to CEP.

So, if a CEP vendor comes to you and says they have a very powerful CEP engine, ask them to show you a complex model of a situation that is important to you and explain to you how they represent the object. If models are not represented using an object-oriented approach, I recommend you send the vendor back to their software development lab, because without an OO approach to modelling, you can only represent very simple situations.

Furthermore, let’s say you are leading a team building a large model. If there are several teams working on various parts of the model, you need a common framework to integrate the work of the various teams. I strongly recommend an OO approach to your model building systems architecture and work breakdown structure.

In a future post, I will write about the companion to modelling – simulation

The same key points of that presentation are still relevant today:

1. Event-Decision Processing is Computationally Intensive

2. CEP requires a Number of Technologies:

• Distributed Computing, Publish/Subscribe and SOA
• Hierarchical, Cooperative Inference Processing
• High Speed, Real Time Processing with State Management
• Event-Decision Architecture for Complex Situations and Events
• There is no single “CEP Solution” or “CEP Product” (in the market place then, and today)

3. CEP needs a Common Vocabulary and Functional Architecture based on Mature, Industry-Standard Inference Models

4. Processing and Integration Patterns for CEP need to be Developed and Formalized

Since March of 2006 a number of other challenges has surfaced.  I will elaborate on this challenges in a future post.

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapide concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.

Applications of Complex Event Processing:

• Instant Insight  - hierarchical event viewing applied to the Enterprise IT layer. (coming soon)
  • Analysing business processes (paper in pdf format)
• Network Level Monitoring and Management (Powerpoint presentation)
• Cyber Security: Network Intrusion Detection
• Enterprise Monitoring and Management (coming soon)
• Modeling and Simulation of Collaborative Business Processes
• Business Policy Monitoring. (coming soon)
• Analysis and Debugging of Distributed Systems (coming soon)

Presentations:

• “Complex Event Processing: An Essential Technology for Instant Insight into the Operation of Enterprise Information Systems,” lecture at the Stanford University Computer Systems Laborary EE380 Colloquium series. Video of the lecture (duration: 60 minutes).

Publications:

• Complex Event Processing in Distributed Systems. David C. Luckham and Brian Frasca, Stanford University Technical Report CSL-TR-98-754, March 1998, 28 pages.Abstract: Complex event processing is a new technology for extracting information from distributed message-based systems. This technology allows users of a system to specify the information that is of interest to them. It can be low level network processing data or high level enterprise management intelligence, depending upon the role and viewpoint of individual users. And it can be changed from moment to moment while the target system is in operation. This paper presents an overview of Complex Event Processing applied to a particular example of a distributed message-based system, a fabrication process management system. The concepts of causal event histories, event patterns, event filtering, and event aggregation are introduced and their application to the process management system is illustrated by simple examples. This paper gives the reader an overview of Complex Event Processing concepts and illustrates how they can be applied using the Rapide toolset to one specific kind of system.
   
• Event Mining with Event Processing Networks. Louis Perrochon and Walter Mann and Stephane Kasriel and David C. Luckham, The Third Pacific-Asia Conference on Knowledge Discovery and Data Mining. April 26-28, 1999. Beijing, China, 5 pages.Abstract: Event Mining discovers and delivers information and knowledge in a real-time stream of data, or events. We show that the process of delivering knowledge by searching patterns in data and subsequent abstraction of found patterns can be applied in real-time to a complex, asynchronous system. Our event processing engine consists of a network of event processing agents (EPAs) running in parallel that interact using a dedicated event processing infrastructure. The agents can be configured at run-time using a formal pattern language. The underlying infrastructure (1) provides an abstract communication mechanism and thus allows dynamic reconfiguration of the communication topology between agents at run-time and (2) provides transparent, location-independent access to all data. These features allow dynamic allocation of EPAs to different threads and processes on different machines at run time.
   
• eJava - Extending Java with Causality. Alexandre Santoro and Walter Mann and Neel Madhav and David Luckham, Proceedings of the 10th International Conference on Software Engineering and Knowledge Engineering, June 1998, 10 pages.Abstract: Programming languages like Java provide designers with a variety of classes that simplify the process of program development. Some of these classes allow one to easily build multithreaded programs. Though useful, especially in the creation of reactive systems, multithreaded programs present challenging problems such as race conditions and synchronization issues. Validating these programs against a specification is not trivial since Java does not clearly indicate thread interaction. These problems can be solved by modifying Java so that it produces computations, collections of events with both causal and temporal ordering relations defined for them. Specifically, the causal ordering is ideal for identifying thread interaction. This paper presents eJava, an extension to Java that is both event based and causally aware, and shows how it simplifies the process of understanding and debugging multithreaded programs.
   
• Event-Based Execution Architectures for Dynamic Software Systems. James Vera, Louis Perrochon, David C. Luckham.
  Proceedings of the First Working IFIP Conf. on Software Architecture. 1999. San Antonio, Texas.Abstract: Distributed systems’ runtime behavior can be difficult to understand. Concurrent, distributed activity make notions of global state difficult to grasp. We focus on the runtime structure of a system, its execution architecture, and propose representing its evolution as a partially ordered set of predefined architectural event types. This representation allows a system’s topology to be visualized, analyzed and con-strained. The use of a predefined event types allows the execution architectures of different systems to be readily compared.
   
• Using Context-Based Correlation in Network Operations and Management. Louis Perrochon (work in progress, mail author for newest version)Abstract: Network operation consists to a large degree of reaction to activities happening in the network. Better knowledge of the network at any time allows more appropriate reactions. On the example of intrusion detection, we show how context-based correlation of such activities can provide a more detailed view of the network in shorter time. We first present how we model context and then describe the architecture of the Stanford University CEP context-based correlator. Correlation is specified as event patterns in a declarative language that allows us to specify what needs to be detected, instead of specifying how it should be detected. CEP introduces the concept of causal context to intrusion detection. The correlator is able to process events on-line, as they are generated and it can be reconfigured at dynamically. We then show how it increases detection rate, reduce false alarms, and detect large-scale attack patterns at an early stage.

OnStar will soon include the ability for the police to shut off your engine remotely. Buses are getting the same capability, in case terrorists want to re-enact the movie Speed. The Pentagon wants a kill switch installed on airplanes, and is worried about potential enemies installing kill switches on their own equipment.

Microsoft is doing some of the most creative thinking along these lines, with something it's calling "Digital Manners Policies." According to its patent application, DMP-enabled devices would accept broadcast "orders" limiting capabilities. Cellphones could be remotely set to vibrate mode in restaurants and concert halls, and be turned off on airplanes and in hospitals. Cameras could be prohibited from taking pictures in locker rooms and museums, and recording equipment could be disabled in theaters. Professors finally could prevent students from texting one another during class.

The possibilities are endless, and very dangerous. Making this work involves building a nearly flawless hierarchical system of authority. That's a difficult security problem even in its simplest form. Distributing that system among a variety of different devices -- computers, phones, PDAs, cameras, recorders -- with different firmware and manufacturers, is even more difficult. Not to mention delegating different levels of authority to various agencies, enterprises, industries and individuals, and then enforcing the necessary safeguards.

Once we go down this path -- giving one device authority over other devices -- the security problems start piling up. Who has the authority to limit functionality of my devices, and how do they get that authority? What prevents them from abusing that power? Do I get the ability to override their limitations? In what circumstances, and how? Can they override my override?

How do we prevent this from being abused? Can a burglar, for example, enforce a "no photography" rule and prevent security cameras from working? Can the police enforce the same rule to avoid another Rodney King incident? Do the police get "superuser" devices that cannot be limited, and do they get "supercontroller" devices that can limit anything? How do we ensure that only they get them, and what do we do when the devices inevitably fall into the wrong hands?

It's comparatively easy to make this work in closed specialized systems -- OnStar, airplane avionics, military hardware -- but much more difficult in open-ended systems. If you think Microsoft's vision could possibly be securely designed, all you have to do is look at the dismal effectiveness of the various copy-protection and digital-rights-management systems we've seen over the years. That's a similar capabilities-enforcement mechanism, albeit simpler than these more general systems.

And that's the key to understanding this system. Don't be fooled by the scare stories of wireless devices on airplanes and in hospitals, or visions of a world where no one is yammering loudly on their cellphones in posh restaurants. This is really about media companies wanting to exert their control further over your electronics. They not only want to prevent you from surreptitiously recording movies and concerts, they want your new television to enforce good "manners" on your computer, and not allow it to record any programs. They want your iPod to politely refuse to copy music a computer other than your own. They want to enforce their legislated definition of manners: to control what you do and when you do it, and to charge you repeatedly for the privilege whenever possible.

"Digital Manners Policies" is a marketing term. Let's call this what it really is: Selective Device Jamming. It's not polite, it's dangerous. It won't make anyone more secure -- or more polite.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Abstract:

Cultural Cognition refers to the disposition to conform one's beliefs about societal risks to one's preferences for how society should be organized. Based on surveys and experiments involving some 5,000 Americans, the Second National Risk and Culture Study presents empirical evidence of the effect of this dynamic in generating conflict about global warming, school shootings, domestic terrorism, nanotechnology, and the mandatory vaccination of school-age girls against HPV, among other issues. The Study also presents evidence of risk-communication strategies that counteract cultural cognition. Because nuclear power affirms rather than threatens the identity of persons who hold individualist values, for example, proposing it as a solution to global warming makes persons who hold such values more willing to consider evidence that climate change is a serious risk. Because people tend to impute credibility to people who share their values, persons who hold hierarchical and egalitarian values are less likely to polarize when they observe people who hold their values advocating unexpected positions on the vaccination of young girls against HPV. Such techniques can help society to create a deliberative climate in which citizens converge on policies that are both instrumentally sound and expressively congenial to persons of diverse values.

And from the conclusion:

Conclusion:

There is a culture war in America, but it is about facts, not values. There is very little evidence that most Americans care nearly as much about issues that symbolize competing cultural values as they do about the economy, national security, and the safety and health of themselves and their loved ones. There is ample evidence, however, that Americans are sharply divided along cultural lines about what sorts of conditions endanger these interests and what sorts of policies effectively counteract such risks.

Findings from the Second National Culture and Risk Study help to show why. Psychologically speaking, it's much easier to believe that conduct one finds dishonorable or offensive is dangerous, and conduct one finds noble or admirable is socially beneficial, than vice versa. People are also much more inclined to accept information about risk and danger when it comes from someone who shares their values than when it comes from someone who holds opposing commitments.

My root script defines a bunch of properties, like where the output directories for the overall build live, where the tools live, and so on. And that works fine when I run the build from the root. The properties get defined, all the child scripts are run with <nant/> tasks, and they see those properties. But if I want to drill down into the tree and run one of the build scripts lower down, suddenly there's problems because it depends on properties that are only defined in the root script. I really like being able to run builds from anywhere in the tree for perf - if I'm trying to fix a particular project, I don't necessarily want to wait for unit tests on the entire tree to run in order to see if mine passed.

Craig made a great suggestion. Put the properties into a separate script (we named it properties.nant) and <include/> that script. Then to enable hierarchical builds, we'd create a properties.nant file for each folder in the tree, which would <include/> its parent. That way I could define properties anywhere in the tree, and they would be "inherited" by anything below it.

I took that idea one step further, because I didn't want to maintain a bunch of property scripts with nothing in them but an <include/> for the parent. I wrote an <includefromparent/> nant task that walks up the directory tree looking for the target file. So now I can do this:

<includefromparent buildfile="properties.nant"/>

This worked great! But now I ran into a problem. Many of my properties are defined like so in the root properties.nant file:

<property name="libraryOutputDir" value="${project::get-base-directory()}\artifacts\libraries"/>

Do you see the issue? If I run the build with the root script, everything works fine, because it's the root nant project I'm building, and get-base-directory() refers to the root of the project, where the artifacts folder lives. But if I run from lower in the tree, it's a different project, and get-base-directory() refers to a subfolder, where the artifacts folder definitely should NOT be.

I needed a way to find the root of the project tree. So I build a second really simple nant task:

<findmarkeddir markerfile="filetolookfor.txt" property="root"/>

This task simply looks up the directory hierarchy until it finds the specified marker file, then puts the name of that directory (the "marked" directory) into a designated property (here I've called it root). With that in place, I rewrote my property definitions in terms of the base directory:

<property name="libraryOutputDir" value="${root}\artifacts\libraries"/>

Voilà! I can now run builds from any of my build scripts. They inherit properties hierarchically like you'd expect, and the system is quite easy to maintain. If you'd like to use these tasks, I've included the code for them below (not much code, really). And if you've never written a nant task yourself before, here's the article I used to figure out how it's done (it's super easy). Here's what you should read to learn about the various options for deploying your custom task assembly so nant recognizes it.

Enjoy!

Here is FindMarkedDirTask.cs

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using System.IO;

namespace PluralsightNantTasks {

[TaskName("findmarkeddir")]
public class FindMarkedDirTask : Task {

  [TaskAttribute("markerfile", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string MarkerFileName { get; set; }

  [TaskAttribute("property", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string PropertyName { get; set; }

  protected override void ExecuteTask() {
    string searchDir = this.Project.BaseDirectory;
    do {
      if (MarkerFileExistsIn(searchDir)) {
        this.Project.Properties[PropertyName] = searchDir;
        return;
      }
      searchDir = ParentOf(searchDir);
    } while (!IsRootDirectory(searchDir));
  }

  private bool IsRootDirectory(string path) {
    return Path.GetPathRoot(path) == Path.GetFullPath(path);
  }

  private string ParentOf(string directory) {
    return Path.GetFullPath(Path.Combine(directory, ".."));
  }

  private bool MarkerFileExistsIn(string directory) {
    return File.Exists(Path.Combine(directory, MarkerFileName));
  }
}
}

And here is IncludeFromParentTask.cs (note I derive from the built-in include task):

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using NAnt.Core.Tasks;
using System.IO;
using System.Globalization;

namespace PluralsightNantTasks {

[TaskName("includefromparent")]
public class IncludeFromParentTask : IncludeTask {

  protected override void Initialize() {
    string fileName = BuildFileName;
    if (fileName.Contains("/") || fileName.Contains(@"\\"))
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "buildfile attribute must only be a filename"));

    string relativePathToFoundFile = SearchParentDirectory(
      Project.BaseDirectory, fileName, 0);
      
    if (null == relativePathToFoundFile)
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "Couldn't find a file named {0}" +
        " in a parent directory of {1}",
        fileName, Project.BaseDirectory));

    // have to use a relative path here
    // because  task uses
    // Path.Combine(projectDir, BuildFileName)
    // to get the full path
    BuildFileName = relativePathToFoundFile;

    base.Initialize();
  }

  private string SearchParentDirectory(string directory,
                        string fileName, int searchDepth) {
    ++searchDepth;
  
    // see if we've traversed all the way to the root
    string currentPath = Path.GetFullPath(directory);
    if (currentPath == Path.GetPathRoot(currentPath))
      return null;

    // recurse until we find the file
    string parentDir = Path.GetFullPath(
      Path.Combine(currentPath, ".."));
    string path = Path.Combine(parentDir, fileName);
    if (File.Exists(path)) {
      StringBuilder sb = new StringBuilder();
      for (int i = 0; i < searchDepth; ++i)
        sb.Append(@"..\");
      return Path.Combine(sb.ToString(), fileName);
    }
    else return SearchParentDirectory(parentDir,
                          fileName, searchDepth);
  }
}
}

My root script defines a bunch of properties, like where the output directories for the overall build live, where the tools live, and so on. And that works fine when I run the build from the root. The properties get defined, all the child scripts are run with <nant/> tasks, and they see those properties. But if I want to drill down into the tree and run one of the build scripts lower down, suddenly there's problems because it depends on properties that are only defined in the root script. I really like being able to run builds from anywhere in the tree for perf - if I'm trying to fix a particular project, I don't necessarily want to wait for unit tests on the entire tree to run in order to see if mine passed.

Craig made a great suggestion. Put the properties into a separate script (we named it properties.nant) and <include/> that script. Then to enable hierarchical builds, we'd create a properties.nant file for each folder in the tree, which would <include/> its parent. That way I could define properties anywhere in the tree, and they would be "inherited" by anything below it.

I took that idea one step further, because I didn't want to maintain a bunch of property scripts with nothing in them but an <include/> for the parent. I wrote an <includefromparent/> nant task that walks up the directory tree looking for the target file. So now I can do this:

<includefromparent buildfile="properties.nant"/>

This worked great! But now I ran into a problem. Many of my properties are defined like so in the root properties.nant file:

<property name="libraryOutputDir" value="${project::get-base-directory()}\artifacts\libraries"/>

Do you see the issue? If I run the build with the root script, everything works fine, because it's the root nant project I'm building, and get-base-directory() refers to the root of the project, where the artifacts folder lives. But if I run from lower in the tree, it's a different project, and get-base-directory() refers to a subfolder, where the artifacts folder definitely should NOT be.

I needed a way to find the root of the project tree. So I build a second really simple nant task:

<findmarkeddir markerfile="filetolookfor.txt" property="root"/>

This task simply looks up the directory hierarchy until it finds the specified marker file, then puts the name of that directory (the "marked" directory) into a designated property (here I've called it root). With that in place, I rewrote my property definitions in terms of the base directory:

<property name="libraryOutputDir" value="${root}\artifacts\libraries"/>

Voilà! I can now run builds from any of my build scripts. They inherit properties hierarchically like you'd expect, and the system is quite easy to maintain. If you'd like to use these tasks, I've included the code for them below (not much code, really). And if you've never written a nant task yourself before, here's the article I used to figure out how it's done (it's super easy). Here's what you should read to learn about the various options for deploying your custom task assembly so nant recognizes it.

Enjoy!

Here is FindMarkedDirTask.cs

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using System.IO;

namespace PluralsightNantTasks {

[TaskName("findmarkeddir")]
public class FindMarkedDirTask : Task {

  [TaskAttribute("markerfile", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string MarkerFileName { get; set; }

  [TaskAttribute("property", Required = true)]
  [StringValidator(AllowEmpty = false)]
  public string PropertyName { get; set; }

  protected override void ExecuteTask() {
    string searchDir = this.Project.BaseDirectory;
    do {
      if (MarkerFileExistsIn(searchDir)) {
        this.Project.Properties[PropertyName] = searchDir;
        return;
      }
      searchDir = ParentOf(searchDir);
    } while (!IsRootDirectory(searchDir));
  }

  private bool IsRootDirectory(string path) {
    return Path.GetPathRoot(path) == Path.GetFullPath(path);
  }

  private string ParentOf(string directory) {
    return Path.GetFullPath(Path.Combine(directory, ".."));
  }

  private bool MarkerFileExistsIn(string directory) {
    return File.Exists(Path.Combine(directory, MarkerFileName));
  }
}
}

And here is IncludeFromParentTask.cs (note I derive from the built-in include task):

using System;
using System.Collections.Generic;
using System.Text;
using NAnt.Core;
using NAnt.Core.Attributes;
using NAnt.Core.Tasks;
using System.IO;
using System.Globalization;

namespace PluralsightNantTasks {

[TaskName("includefromparent")]
public class IncludeFromParentTask : IncludeTask {

  protected override void Initialize() {
    string fileName = BuildFileName;
    if (fileName.Contains("/") || fileName.Contains(@"\\"))
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "buildfile attribute must only be a filename"));

    string relativePathToFoundFile = SearchParentDirectory(
      Project.BaseDirectory, fileName, 0);
      
    if (null == relativePathToFoundFile)
      throw new BuildException(string.Format(
        CultureInfo.CurrentCulture,
        "Couldn't find a file named {0}" +
        " in a parent directory of {1}",
        fileName, Project.BaseDirectory));

    // have to use a relative path here
    // because  task uses
    // Path.Combine(projectDir, BuildFileName)
    // to get the full path
    BuildFileName = relativePathToFoundFile;

    base.Initialize();
  }

  private string SearchParentDirectory(string directory,
                        string fileName, int searchDepth) {
    ++searchDepth;
  
    // see if we've traversed all the way to the root
    string currentPath = Path.GetFullPath(directory);
    if (currentPath == Path.GetPathRoot(currentPath))
      return null;

    // recurse until we find the file
    string parentDir = Path.GetFullPath(
      Path.Combine(currentPath, ".."));
    string path = Path.Combine(parentDir, fileName);
    if (File.Exists(path)) {
      StringBuilder sb = new StringBuilder();
      for (int i = 0; i < searchDepth; ++i)
        sb.Append(@"..\");
      return Path.Combine(sb.ToString(), fileName);
    }
    else return SearchParentDirectory(parentDir,
                          fileName, searchDepth);
  }
}
}