Some questions regarding pipe and filter implementation

I am going to develop a component called ExtractInfoFromUrl. This component has a method called addUrl(url) that accepts urls and will open the given url and extract info from the corresponding page, raising an event when done. Internally, the component is composed of pipes and filters.

I have 3 questions:

1. I'd like to know what would be better -- to have each Filter have a Thread(that is, in Java, inherit from Thread) or have the Pipes have Threads?

2. It is obvious that I will have to have my filters or my pipes with threads. But won't I have, too, to use a Thread for my component itself? I need a thread that controls the other ones, and I believe the main program's thread is not suited for the task, but I am not too sure why.

3. Is there any other kind of Java implementation for PipedR开发者_开发百科eaders/Writers that allows me to handle other kinds of data instead of char/int ? That is a bit too low level for me, I'd say. If there were some other that'd allow strings instead, for example, it'd be preferable.

Thanks

1. For one, it's usually preferable to implement Runnable rather than extend Thread, but regardless, I don't think that you'll want to have your Filters or Pipes extend Thread or implement Runnable, but rather have each pipe be used in a new Thread.

2. What do you mean by "component"? Do you mean a visualized GUI component? Or something different?

3. I've wrapped PipedWriters in PrintWriter

Conceptually, filters represent the computations in a filter-and-pipe architecture, so I would think it makes more sense for the threads to be associated with filters (if threads are used at all). Pipes are the "communication" portion of the pattern.

Again, conceptually, if the information extracted from a retrieved page does not depend on any other data, then using threads for them makes sense only in a multiprocessor case. I'm also not sure why there is a need for a master thread - perhaps you can elaborate.

Instead of using low-level Reader/Writers, why not consider message queues?