security - Secure Communication in Java - Serialized CipherText-Objects vs. Transport-Layer-Encryption vs. RMI over SSL -

i want implement encrypted communication between 2 java servers, both under control. there 3 architectures have in mind , want input on pros , cons of them.

architecture 1: whenever invoke remote method, not pass parameters plain text serialized ciphertext-object. use esapi-library this, actual implementation not matter. what's important ciphertext-object contains arbitrary data encrypted symmetric key including mac authentication. symmetric key available pre-shared secret on both servers.

architecture 2: don't care encryption on application level delegate transport layer. vpn-tunnel or sort of server-to-server encryption supported. don't have information available on modern application server @ moment. input on welcome well.

architecture 3: using javax.rmi.ssl use rmi on ssl.

it feels architecture 1 complicated , pain implement. architecture 2 leaves encryption application server. application developer have no control on configuration these features. that's bad because want ensure application cannot used without proper encryption. architecture 3 seems best way have no experience technology.

how rate 3 architectures? did miss better way implement this? main goal ensure secure encrypted communication, complexity of resulting source code, performance issues , of course concern well.

first of all, security solutions not one-size-fits-all. must evaluate threats(who interested in snoping/attacking), risks (what lose if attacker succeeded) , cost of implementation , use.

second, security solutions not exclusive. implement 3 solutions @ same time (communication on vpn of rmi-ssl calls encripted parameters). issue cost of implementation , overhead.

now question @ hand:

1) not it, because:

• it allows snopping know metods called, if not know data passed.
• as far know, macs can spoofed
• you have keep control of servers , in future shared secret not discovered. maybe next month 1 of servers taken away location/branch/departament , more people starts having access it. or maybe deploy servers in bussiness without changing secret.

2 , 3) more or less equivalent. 2, though, have sure servers accept connections coming through openvpn, , not other ni. not know rmi on ssl well, if has not hidden vulnerability looks ok.

imho, go 3 (standard, integrated in server , more flexible). 2 option too, easier implement requires have better control of server. 1 reinventing wheel there valid options, discard it.