"Socket" programs are out of style. It's rarely worth the effort to define and debug and secure a new protocol from the ground up and firewalls used these days tend to limit the ports that can be used without getting the network people involved.
Probably the easiest, and best supported "socket" protocol these days is to simply use a web service. And J2EE/JEE have security mechanisms built into their specs, which can be augmented by established (and debugged) add-ons like Spring Security.
Another alternative is to use a messaging service, such as JMS. It's less firewall-friendly, but it allows for store-and-forward operations.
A third option is RMI. RMI is very low overhead, but you have to supply your own security protocols, it requires compatible JVM versions on both client and server sides. and clearance through any intervening firewall(s). A variant of this is remote EJBs. Actually, RMI-IIOP may reduce some of the earlier problems I mentioned with RMI, but it has been a while since I looked. RMI isn't very popular these days and its bare-bones services put more of a documentation and support burden on your local infrastructure.
There was a fourth option - CORBA, which is similar to RMI, except that clients could be in many languages, not just
Java. CORBA was a "must have" skill in the 1990s, but died rather quickly when people started raising firewalls, since CORBA didn't work with fixed ports and was thus inimical to firewalls. It was essentially replaced by
SOAP, which in turn was replaced by web services. CORBA is no longer supported in Jakarta
JEE and vendor support for CORBA is nearly or completely dead at this point.