japhy has asked for the wisdom of the Perl Monks concerning the following question:

At my company, I'm trying to unify a lot of the code we use. To that end, I'm developing a SOAP server that will provide a simple and standard interface to a lot of our database operations (so that things are done properly).

My current situation is this. We have two databases: one stores intel (things like addresses, businesses, persons, phone numbers, email addresses, etc.) and one stores folders. A folder is a collection of intel related to ONE particular piece of intel; we might have a folder on Person intel "Jeff Pinyan", and in this folder would have the IDs of the Alias intel "japhy", the URL intel "japhy.perlmonk.org", the Address intel of "... Plainsboro, NJ, 08536, USA", and so on.

When a folder has an item added or removed from it, its update time needs to be changed. Similarly, when a piece of intel in a folder has a note added to it, ITS update time needs to be changed, as well as the folder's update time. Suffice to say, you have to remember to do specific things all the time. I want to use a SOAP server to make it as simple as:

# gets (or creates) the "Person" intel for "Jeff Pinyan" my $japhy_intel = $intelSOAP->call(new => intel_person => "Jeff Pinyan +")->result; # gets (or creates) the folder for Person "Jeff Pinyan" my $japhy_folder = $folderSOAP->call(new => $japhy_intel)->result; # gets (or creates) the "Alias" intel for "japhy" my $alias_intel = $intelSOAP->call(new => intel_alias => "japhy")->res +ult; # adds Alias "japhy" to Person "Jeff Pinyan"'s folder $folderSOAP->add_to_folder($japhy_folder, $alias_intel);
Now. This is my first time using SOAP. Is this the proper idiom? (I realize autodispatch might make this look a whole lot nicer, and I will probably gravitate towards that.) Should I actually HAVE objects on the application end of the code? Or should the application end merely make SOAP calls that play with objects on their own? Should it be as simple as
$folderSOAP->add_to_folder(intel_person => "Jeff Pinyan", intel_alias +=> "japhy");
I'll admit, that is far simpler and far more appealing now that I've actually written it. I suppose doing it that way means the application never has to worry about objects at all, since the process is contained on the SOAP server itself. That issue won't entirely go away though, because eventually I'll want to do:
my @contents = $folderSOAP->get_contents(intel_person => "Jeff Pinyan" +)->result; for (@contents) { print $intelSOAP->display($_)->result; }
or something. I don't know. Like I said, I'm new to this.

And finally, do I need to have

my $intelSOAP = SOAP::Lite ->ns("/Platform/Intel") ->proxy("http://localhost:9999/Platform/Intel"); my $folderSOAP = SOAP::Lite ->ns("/Platform/Folder") ->proxy("http://localhost:9999/Platform/Folder");
or is there some way for me to get at both services through ONE SOAP::Lite object?

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Replies are listed 'Best First'.
Re: First Forays into SOAP
by samtregar (Abbot) on Jan 20, 2006 at 17:47 UTC
    Should I actually HAVE objects on the application end of the code?

    In my opinion, no. I prefer SOAP interfaces to remain as simple as possible, working on scalar arguements and returning simple structures (single-level arrays or hashes, if possible). If you start passing objects back and forth you'll open yourself up to SOAP's difficulty dealing with large amounts of data, the complexity of SOAP's encode/decode model as well as losing any potential for non-Perl clients to access your service.

    I don't have answers to your other questions. Have you tried the SOAP::Lite list? Back when I was mired deep in SOAP I found it to be helpful.

    -sam

    PS: When you think you've had enough of SOAP, take a look at this: Don't Be Afraid to Drop the SOAP.

Re: First Forays into SOAP
by stvn (Monsignor) on Jan 20, 2006 at 21:07 UTC

    This has absolutly nothing to do with your post, other than it is (partially) about SOAP too.

    We are looking into the "web services" model at $work currently, and so I have been reading a lot about the subject. I recently stumbled upon REST (Representational State Transfer), and this set of slides in particular. It contrasts the REST approach with the SOAP approach and brings up several (possible) weaknessed in SOAP (all of which REST solves of course :).

    Anyway, just thought it might be an interesting read for you.

    -stvn
Re: First Forays into SOAP
by InfiniteSilence (Curate) on Jan 21, 2006 at 01:56 UTC
    Just curious, but why aren't you implementing an LDAP server for this information and using Net::LDAP?

    Celebrate Intellectual Diversity