개인용으로 만든 작은 Java 응용 프로그램에서 명령 줄 인터페이스를 만들었습니다. 잠시 동안 cli는 원래 응용 프로그램과 동일한 프로젝트에 있지만 현재의 프로젝트로 추출 할 계획입니다. 필요에 따라 cli를 시작하고 실행중인 다른 프로그램을 쿼리 할 수있게 해주는 2 개의 개별 실행 가능 병을 효과적으로 만듭니다. 정보.동일한 컴퓨터에서 실행중인 다른 java 응용 프로그램에서 서비스 호출
동일한 컴퓨터에서 원격 서비스를 호출하는 가장 쉽고 가벼운 솔루션을 찾으려고합니다. 스프링 리모팅을 살펴 보았지만 HttpInvoker, Hessian/Burlap, JAX RPC 웹 서비스는 HTTP 또는 SOAP을 기반으로하므로 제공되는 솔루션 중 상당수가 해당 작업에 적합하지 않습니다. JMS 또한 과도한 것처럼 보입니다.
이렇게하면 RMI가 다소 복잡해 보입니다. 아마도 JMX일까요? 제안 사항?
JMX는 원격 액세스를 위해 RMI를 사용합니다. JMX는 관리자 API (모니터링/관리)를 노출하기위한 것이지 - 범용 원격 API로 의도 된 것은 아닙니다.
스프링 리모팅 지원이있는 RMI는 개발 관점에서 볼 때 매우 가볍습니다. 런타임 일지라도 사용자가 나열한 다른 옵션과 비교할 때 최소한의 오버 헤드를 추가하는 옵션입니다.
스프링 리모팅 지원으로 나중에 필요할 경우 다른 옵션으로 쉽게 전환 할 수 있습니다.
위의 옵션의 성능을 비교/벤치 마크 테스트 한 artcile을 살펴보십시오.
다음은 RMI를 사용합니다. 내가 RMI를 피하고 싶었던 주요 reasosn 중 하나는 몇 년 전에 rmic에서 스텁과 스켈레톤을 사용하여 추가 컴파일 단계가 필요했기 때문에 였지만 J2SE 5.0 릴리스에서는 원격 객체에 대한 스텁 클래스가 없습니다 원격 개체가 5.0 이전 VM에서 실행중인 클라이언트를 지원해야하는 경우가 아니면 rmic 스텁 컴파일러를 사용하여 더 오래 미리 생성해야합니다. 그게 큰 플러스 – nkr1pt
개인용 앱에서는 JMX가 가장 저항력이 적은 경로 여야하기 때문에 JMX와 함께 가고 싶습니다. 나는 과거에 이것에 대한 좋은 경험을했습니다. 몇 분 안에 실행하고 실행할 수 있으며 데이터를 이동할 메시지 형식 (콩이 Serializable 인 경우)에 대해 생각할 필요가 없습니다.
JMX가 부적절한 것으로 판명되면 나중에 다른 구현에서 나중에 삭제할 수 있도록 인터페이스를 원격 호출 앞에 배치하십시오.
프로젝트/기능의 위치에 따라 크게 달라집니다. JMX는 설정하기 쉽고 기존 클라이언트/guis를 사용하여 매개 변수를 쿼리하고 설정할 수 있으므로 많은 작업을 줄일 수 있습니다. 또한 시스템을 모니터링 도구와 통합 할 수도 있습니다.
반면에 기능이 관리/모니터링과 관련이 없으며 데이터를 펌핑하는 라인을 따라 가면 하나의 옵션이 Apache MINA 일 수 있습니다. 나는 과거에 그것을 큰 결과와 함께 사용했습니다. 하지만 자신 만의 프로토콜을 효과적으로 만들 수 있습니다! 나는 MINA가 단순한 RMI보다 "덜 헤비급"이 될 것이라고 의심한다.
내 질문 http://stackoverflow.com/questions/6121990/pass-string-as-params-from-one-java-app-to-another – mKorbel