My question is how do I make the design of this Windows Service clean...

By doing a good job :) That sounds flippant, but "clean" is such an 'airey-fairy' and subjective term that it is impossible to answer. What you, me and 10 others would call 'clean' are probably a dozen different things.

Is there some part of your app, which from the above seems well thought through, that you are having your doubts about your current implementation? Specific questions (with code) are generally easier to attempt good answers to.

... how do I share data between threads and packages?

Assuming you've seen threads::shared, what problems are you having? Again, specific examples and code are good idea.

Generally, share data not code. Objects contain both and do not easily move between threads.

"clean" is such an 'airey-fairy' and subjective term that it is impossible to answer

Entirely true, of course. However, in my short time on PM, I've learned that most monks seem to give petitioners the benefit of the doubt on what "clean" means and infer, instead, that they really mean "recommended best practices". Yes, we can still get 12 opinions from 10 people (I realise this isn't exactly what you said - I can count ;-}), but perhaps that will help narrow down the question. I don't think "best practices" are quite so subjective. Still subjective, but should be much less so.

... most monks seem to give petitioners the benefit of the doubt on what "clean" means and infer, ...

For some, maybe most questions, I agree with you that what would consistitute 'clean' or 'best practice' is fairly obvious and you can infer, and answer on that basis. For this particular question, I think it is much less clear.

If you were to take a survey of the Monks asking them about the four components of the OPs title, I would not be at all surprised if you got a large percentage, maybe even a majority, that would suggest that anything that used threads, or anything that used Win32 for that matter, could never be considered clean.

From my personal bias, I have no problem with those two, but SOAP (and many things that utilise XML) just seems like a cumbersome and clumsy way of doing what could be done more simply and easily without.

From the description given, the OP appears to have already given considerable thought to the overall requirements of his task, and chosen a workable and possibly optimal solution for it's implementation given the environment in which he needs to operate.

Given that level of detail of his design, I could not see a way to make positive suggestions in the absence of either working code that could be made 'more clean', or specific implementation problems to solve.

Without sight of his code to critique, nor problems to address, the only advice I could see as applicable, was "Do a good job".

If you have better insight as to what changes he should make his code, or design alternatives he should consider, without requiring further information, by all means offer them--to him.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

use Thread::Queue;

# in your "job shutdown" dispatcher:
#
#    start the worker threads, passing the $q
#
my @workers = ();
my %queues = ();
my $q;

$q = Thread::Queue->new(),
push(@workers, threads->new(\&run, $q)),
$queues{$workers[-1]->tid()} = $q
    foreach (1..$threadcount);
#
#    wait for them all to tell you they're ready
#
my $resp = $_->dequeue()
    foreach (values %queues);
#
#    now do yer thang...when you get a "shutdown event":
#
$queues{$killtid}->enqueue('Kill job');
[download]

sub run {
    my $q = shift;
    $q->enqueue('ready');
#
#  need to sleep or otherwise wait for the
#  spawner to read the queue
#
    while (1) {
        my $cmd = $q->dequeue();
#
#    process the command; you'll need to 
#    add a timer to come back and check it
#
    }
}
[download]

package WorkerResource;

use Thread::Queue::Queueable;

use base qw(Thread::Queue::Queueable);

sub new {
    my $class = shift;
    
    my %obj : shared = ();
    #
    # ...do some object init..
    #
    return bless \%obj, $class;
}
#
#    overload Thread::Queue::Queueable marshal methods
#
sub curse {
#
#    marshall any complex object members into something
#    that can be passed over a Thread::Queue::Duplex,
#    i.e., either a scalar, or a threads::shared ref
#    note that, if your object is threads::shared,
#    it implies all its members are either scalar or
#    threads::shared, so you can use the default TQQ::curse()
#    
#
}

sub redeem {
    my ($class, $obj) = @_;
#
#    unmarshall any complex object members and rebless the
#    object back into its class.
#    note that, if your object is threads::shared,
#    it implies all its members are either scalar or
#    threads::shared, so you can use the default TQQ::redeem(),
#    which just blesses
#
}

package main;

my $q = Thread::Queue::Duplex->new();
my $thread = threads->new(\&run, $q);
my $resource = WorkerResource->new();

my $msgid = $q->enqueue($resource);

my $result = $q->wait($msgid);
[download]

However, be careful of passing around closures and filehandles. The former just won't work; the latter needs some magic to convert to fileno's in curse() and back to handles in redeem().