You probably already have something along these lines–

• MyApp::Schema—a collection of DBIC classes which are not directly tied to the web application and can be used anywhere without running Catalyst.
• MyApp::Model::DBIC—a Catalyst model instantiated from MyApp::Schema + MyApp’s configuration information.

It’s a good pattern because it gives you DB code that is not tied to your web app but is easily usable from your web app with very little code and extremely flexible configuration. So, repeating this for other data-oriented parts of the application is usually the way to go. Something like–

• MyApp::ForeignSource::SOAP—standalone code, not tied to the web app, that
• MyApp::Model::FSS—a Catalyst model that consumes MyApp::ForeignSource::SOAP providing the application context ($c) easy access to it.

Your setup would look approximately like–

package MyApp::ForeignSource::SOAP;
# Some object system… Moose/Mouse/Class::Accessor
use SOAP::Lite;
# Collection of methods and attributes for running SOAP requests
# and returning the data in nice perl structures or with iterators
# and helpers like Data::Page.
1;
[download]

package MyApp::FSS;
use parent "Catalyst::Model::Adaptor";
__PACKAGE__->config( class => "MyApp::ForeignSource::SOAP" );
# If the arguments to MyApp::ForeignSource::SOAP
# are a hash ref, you’re probably done.
1;
[download]

---
# myapp.yml
Model::FSS:
   args:
     service: http://soap.example.org/srvc.wsdl
     et: cetera
[download]

Contrived controller example with made up methods/data/flow.

package MyApp::Controller::SomeClass;
use Moose;
use namespace::autoclean;
BEGIN { extends "Catalyst::Controller" }

sub index :Path :Args(0) {
    my ( $self, $c ) = @_;
    my $pref = $c->user->search_related("prefs", {type => "soap"});
    my $fss = $c->model("FSS");
    my $stuff = $fss->call("fooBar", $fss->data->name("key")->value($p
+ref->value));
    die $stuff->faultstring if $stuff->fault;
    $c->stash( result => $stuff->result );
}

__PACKAGE__->meta->make_immutable;

1;
[download]

The arguments, methods, object design (Moose is very good at delegation so I’d recommend it for your MyApp::ForeignSource::SOAP class) and such will be details of your particular implementation but that skeleton is The Right Way® in Catalyst. Don’t forget to write tests! If you can write them against your current Flex code, so much the better.

Reading list

• Moose::Manual::Delegation.
• Catalyst::Model::Adaptor, see mangle_arguments et cetera if necessary.
• Data::Page.
• Test::WWW::Selenium for writing tests against your Flex stuff, maybe, which would be easily adjusted to the run against the new code as well.
• catalyst+model+tutorial and Definitive Guide to Catalyst.

Sidenote: some Catalyst devs advocate putting the MVC components in a Web subdir: e.g., MyApp::Web::Controller::Root. I don’t and haven’t had a problem keeping disparate parts in parallel but it’s certainly a sane and clear division.