I would suggest you consider something along the lines of a proxy object. You tie yourself to the proxy object and write the appropriate access methods to initiate the SOAP requests.
The fetch and store commands would be the most likely candidiates for the actual SOAP requests. You would then provide additional logic for doing the useful stuff (like each(), keys() etc) which would operate on the data locally once it had been fetched.
Suggest you look at the man page for tie or get the Advanced Perl Programming book. Either way - it should be a straightforward task. I would recommend that you build a comms object to actually initiate the SOAP comms and either inherit from it or use some form of aggregate relationship.
You should have no problem doing either with tie.
Hope that helps | [reply] |
Cool idea! I don't see a reason why it can't be done. I've had some ideas of tying variables to CORBA objects. It would certainly make the CORBA interfaces much simpler, and would really give stuff like EJB a run for it's money.
I think this concept could not only be used for SOAP or CORBA but also for POE. You'd need to do some serious planning and design to get this to work, but I'm sure it's feasible.
-- Brett
Go not to the Elves for counsel, for they will say both no and yes
| [reply] |
Oooo, This does raise some interesting options. Not long ago I was writing a CORBA system with Perl on the server and a Java client. Of course there are hashes all over on the server since the API is in Perl, but hashes aren't a basic type in Java, and they sure aren't in OMG IDL. My simple solution was to map hashes to multidimensional arrays in IDL, but then the client has to do a lot of nitpicking array handling (esp. since it's Java :P )
A better idea might be a general IDL interface defining a set of hash functions. But on the server side it wouldn't work to tie the hash to the 'CORBAHash' b/c the tied hashes are just proxy objects, and the remote reference used by the client will necessarily point to the instance of CORBAHash, not the tied hash. So, on the server side, the CORBAHash would have to be a wrapper class around the hash with the data you want.
What would be nice is to reverse the tie(), so that you could tie an instance of a class to a populated data structure, as in:
tie($corba_hash, %$hash);
return $corba_hash; # return to the client
But then you might as well just pass the hash into the constructor of the remote implementation class. So, I think what you'd want is:
bless($hash, 'CORBAHash');
$ORB->activate($hash); # register object with the ORB
return $hash; # return to the client
If the client were in Perl, you'd want to be able to say:
tie(%hash, 'CORBAHash');
To make this work I think you'd have to write the TIEHASH method to call a remote factory method, since the whole point is to tie the hash to a remote object. The factory method produces a remote object reference with the hash interface, and then it's just a matter of the local Perl interpreter to link the hash reference to the remote reference.
Update: I'm using the COPE language binding for Perl.
| [reply]
[d/l]
[select] |
SOAP is only worthwhile if you're using advanced features of SOAP and require the language-interoperability that comes with using XML. SOAP is necessarily slower than other forms for communication (because XML is a larger data type and because SOAP is so feature-bloated), and it also suffers from the overhead of encoding/decoding XML (if you were to do that, I'd use XML::LibXML, which is clearly the fastest perl XML parser so far).
If you need the language-interoperability of XML but are only doing simple key-value interaction, use XML-RPC. XML-RPC is basically (very basically) cruft-less SOAP. Check CPAN for available modules (RPC::XML and Frontier::RPC come to mind). Even SOAP::Lite, the most feature-laden perl SOAP module comes with an XML-RPC version of its basic use.
If you don't need the XML sort of interoperability (say, both ends of your application are perl-based), roll your own server-client app very simply using sockets and Storable. There are CPAN packages that enable you to setup very simple servers with minimal hassle, and Storable is very speedy for packaging up data and shipping it across networks.
95% of the time, SOAP isn't needed. I used to know of a great article that outlined why XML-RPC should be used over SOAP most of the time, but I can't find it. Your case doesn't even sound like XML-RPC would be necessary. | [reply] |
Another option which is possible (according to a previous poster) is to use CORBA. It also supplies language and architectural interoperability without the overhead of parsing XML.
The speed should be very close to that of raw sockets given a decent IIOP (the CORBA on-the-wire protocol) implementation.
| [reply] |
Don't know if this is practicable, but check out SOAP::Lite. Use it to export your module (GDBM_File or whatever). Then in the client connect with +autodispatch, the class will then be available to your code, and tie should work as well.
One problem. GDBM_File and such are stateful modules, while SOAP servers generally expect to be stateless, although setting up a dedicated server with SOAP::Transport::HTTP might do the trick. | [reply] |
