Если производительность не является проблемой, и если есть вероятность того, что другие приложения столкнутся с вашим «нативным» сервисом, я бы выбрал RESTful или какой-то другой вид, ориентированный на веб-сервис. Что касается повторного появления сбоев, как уже упоминалось, просто порождайте процесс как службу, и вы должны быть в порядке.
Если ваше приложение является единственной сущностью, которая будет работать с этой нативной службой, то я бы предпочел пойти по пути RMI, а не по чисто сокетному пути. IMO, RMI является естественным подходом для межпроцессного взаимодействия (где процессы являются процессами Java). RMI имеет концепцию «активируемого» удаленного объекта, который будет естественным образом соответствовать вашим требованиям (автоматическое появление при сбое). Кроме того, если вы используете RMI, ваше приложение будет взаимодействовать с собственным процессом через четко определенные интерфейсы Java, а не с контрактами на специальные протоколы (что может быть достигнуто с помощью других высокоуровневых решений, таких как веб-сервисы, но реальная боль, когда дело касается необработанных сокетов) .
Кстати, JFTR, мы используем эту стратегию с нашим производственным приложением, и она работает довольно хорошо, YMMV. : -)