I wish my project wasn't on such a tight deadline, because I'd really like to get to know this MooseX::Declare. There's obviously a lot I don't know about it, but it seems like it's a tremendous simplification of the existing Moose object structure which is a tremendous simplification of the existing Perl object structure.

I took your advice and backed off to Moose. What you said about class method vs. instance method is correct. Moving to Moose didn't eliminate that problem and honestly it took me several more hours to figure out that I wasn't going to solve that problem.

I know that SOAP should allow initializing and calling objects as if the SOAP service were on the local machine. That was what I was attempting, however, I couldn't figure it out. So I devised a work around that I'm sure pure SOAP proponents would find appalling. But I reevaluated my requirements and determined that I could get by without this functionality.

My SOAP::Lite server now calls a module that looks like this:

package API;

use API::Translator;
use Moose;

sub normalize {
    my ($class, $address) = @_;
    my $service = API::Translator->new();
    return $service->normalize($address);
}
[download]

This pushes initialization of the API::Translator object behind the SOAP server allowing use to reference methods within that object without issue. It's not a solution I'm completely happy with, but it works.

In retrospect, I'm sure there is a way I can bless the hashref of the object that gets passed through the SOAP server to avoid this middle man class, but like I said above, sometimes the timeline dictates the direction you go.

I appreciate your direction. Thank you.