note: this is mainly a comment to the thread starter, I posted this under the wrong comment.

or ... vs

there is nothing prohibiting the combination of SOAP/Your-Favorite-RPC *and* POE as one is an event framework and the other is a RPC mechanism (and not a framework). These aren't even apples and oranges, they are apples and screwdrivers.

For RPC, I think XML over a secure channel is the way to go. It doesn't have to be SOAP, as SOAP is a designed-by-commitee protocol that tries to do much, so maybe XML::RPC will be easier. I know I prefer it if I can avoid management requirements. SOAP also is too HTTP centric, and you might not need or want the 'envelope' behavior. Those following SOAP are doing so based on the Evil Commitees That Design Things, and these folks are often not programmers who have to use the things they invent. They are often (as in my organization) overpaid meeting attenders and professional teleconference guys. Sad, but true. These are invented often for the wrong reason.

YAML

As for YAML, yes, it's nice as a config file language or for storing info... but YAML parsers are harder to come by in less cool languages (non-Perl, non-Ruby, non-Python), and it's really meant to be human editable, that's the strength -- and we don't even want human editable here. XML's strength is in extensibility, not in editablity -- and YAML is less extensible unless you confine yourself to hashes of named values. XML is supposed to be fairly tolerant of changes in information, layout, etc. That's what it does.

perl2exe

Sidenote: consider PAR as well as perl2exe. PAR is nifty.

(jeffa) You just have to do serialization yourself

Well, not exactly "yourself" and maybe not at all...XML::Simple or something could still be used, and there is this POE inter-kernel IPC I have not experimented with. But you might want to look into it. I am not sure of security implications (can you use SSL?), but essentially it passes events between POE kernels.