in reply to SOAP Modules (OO or not?)

It's called the "Simple Object Access Protocol", and it's basically exposing method calls, but it's typically implemented over stateless protocols (eg, HTTP). Therefore, if you're going to be creating new objects, you'll need to deal with maintaining state and ensuring that the objects are available from call to call. (because in the case of mod_perl, you're running under Apache, a forking server, so you'd want the same object available to each webserver child).

If I needed to do something like this, I'd probably have to go with a lightweight object, registered in a database. If they're small objects, you might be able to have the client pass them with each method call. (see Objects Access in the SOAP::Lite guide)

As for what you need in the code for the service -- 'use SOAP::Lite' is for the SOAP client. You'll want to use the appropriate SOAP::Transport class for your implementation.

Replies are listed 'Best First'.
Re^2: SOAP Modules (OO or not?)
by Cagao (Monk) on Jun 30, 2007 at 13:06 UTC
    Maybe I didn't explain too well, consider this plain module I use for handling SOAP requests...
    package SOAPServer; use strict; use warnings; sub myfunction { my $class = shift; my $self = {}; bless ($self, $class); my $one = shift; my $two = shift; $self->{one} = $one; $self->{two} = $two; return $self; } 1;
    Is that okay on it's own, or should I create a new() sub to do the bless'ing? I'm sure it's more a question of "best practice" than anything else.

    I'm just thinking that I'll soon have lots of sub's in the one module, so it'd obviously make sense to move the bless'ing stuff into a seperate private sub.

    In the future one sub may indeed call other local subs, so if nothing else, blessing it to the class would make my code nicer to read with $self->fun2(), and let me structure the object nicely, and pass the whole thing back to the calling SOAP client.


      So, if someone wanted to call the same method twice on the same object, you've managed to completely remove that ability.

      I guess you could do something like:

      sub myfunction { my $self = get_object( shift ); ... # whatever's function specific, and not related to # creation of the object } sub get_object { my $self = shift; if ( !ref $self ) { return $self->new() } # a string? if ( UNIVERSAL::isa( $self, __PACKAGE__ ) { return $self } return __PACKAGE__->new(); } sub new { ... }

      But, it doesn't seem like a very clean interface to me ... I mean, how can we tell what arguments should've been part of the object initialization, and what were arguments to the method call?

      Personally, I'm a user of SOAP::Lite, but I have a feeling that its history, having been created when SOAP was basically just a thin wrapper around XML RPC, was a problem, as almost all of the examples you find are these sorts of calls. I don't know that there is a good 'best practice' in how to deal with passing objects using SOAP::Lite. (if there is, I'd love to know about it myself)

        yes, you couldn't call that same method twice, but in this situation I wouldn't, the method is the entrance into doing all the processing.

        Think of the first method as being a new() sub which does the blessing then passes straight on to another method where the actual processing occurs.

      Since nobody else is saying anything, I'll just give my thoughts, which are as follows: WTF?!? You're instantiating an object of this class when calling some random method, like a method of the SOAP-exposed API? No, that's not good at all.

      BTW, if you're looking for a role model distribution on how to do your classes, SOAP::Lite is not it at all. Wondered why its development ground to a halt, I don't think it's coincidental.

        Okay, a bit of background, I need a web service that 'internal' people will use, but could be developing their own front-ends.

        So I thought, use SOAP, send me some valid XML and I'll do what you want, the Object will deal, for arguments sake, with customers details.

        So someone can call the Customer service and send me new details to store in a DB, or alter an existing one, etc.

        Hopefully I'll keep it as a nice object internally to make calling further subs nice and easy, and also call more external modules.

        Any suggestions in this situation? I'll have around 10 such modules dealing with different things, and several methods for each one.