2010-01-30 4 views
2

약간의 컨텍스트 : 다소 일반적인 서버 - 클라이언트 모델로 작성한 Java 애플리케이션을 분리하고 싶습니다. 비즈니스 로직과 지속성을 처리하는 "서버"를 제공 하겠지만, 매우 서비스 지향적 인 방식으로 작성합니다. 그런 다음 모든 프런트 엔드 코드 (GUI)는 사용자 친화적 인 방식으로 기능을 제공하기 위해 서버를 호출합니다.Java Spring remoting 옵션

스프링 (및 ORM 프레임 워크)을 사용하여 응용 프로그램을 작성 중이므로 일반적으로 용의자가 RMI, 스프링 HTTP, 헤 시안 (Hessian), 웹 서비스 등으로 서버 기능을 노출하는 일반적인 용의자를 탐색하는 것이 좋습니다. etc (Spring 기본 지원 옵션). 이것들은 참조 문서와 여기에 잘 설명되어 있습니다.

그러나 실제 질문 : 내 서버 서비스를 노출하는 데 사용할 수있는 덜 분명한 이국적인 옵션이 있습니까?

사용 편리 성 (프런트 엔드 POV), 성능 및 확장 성 간의 균형을 맞추는 것이 중요합니다 (항상 그렇듯이). 예를 들어; Flex-AS3 클라이언트의 경우 서버에서 Spring-BlazeDS 통합을 제공 할 생각을했기 때문에 BlazeDS는 AMF 서비스를 호출하기위한 Java 고유 API를 제공합니다.

모든 포인터가 많이 감사하겠습니다.

+0

원격 계층의 선택은 클라이언트와 서버 선택에 따라 결정됩니다. 당신 서버는 분명히 자바이지만 확실히 클라이언트가 플렉스입니까? – skaffman

+0

그게 문제 야, 아마도 내가 충분히 명확하게하지 않았을 수 있습니다.이 단계에서 저를위한 클라이언트는 사소한 것입니다. 이 단계에서 "고객이 어떤 기술을 사용할 것인지 정말로 신경 쓰지 않습니다." Flex 1을 직접 개발할 예정이므로 BlazeDS는 확실하지만 제 3 자 프런트 엔드를 허용하는 데 충분한 서비스를 제공하고자합니다. – tmbrggmn

답변

4

플렉스 프런트 엔드가있는 경우 BlazeDS를, 그렇지 않은 경우 HTTP를 권장합니다. 둘 다 XML을 객체로 변환하고 다시 가져와야한다는 비생산적인 작업을 없애줍니다.

스프링 HTTP는 항상 매력적인 것처럼 POJO 스프링 서비스 인터페이스를 작성할 수 있으므로 끝날 때까지 HTTP 원격을 통해 노출되도록 선택을 연기한다. 그런 식으로 옵션을 열어 두십시오. 나중에 Spring 웹 서비스가 더 잘 작동한다고 결정했다면, 같은 POJO Spring 인터페이스를 계속 재사용 할 수있다.

+0

스프링의 HTTP 익스포터/인보 커를 사용하면 잠재적 인 클라이언트가 스프링을 사용할 수밖에 없다는 것을 말하고 싶습니다 (이 서비스를 요청할 경우)? 나는 진정한 언어/프레임 워크의 유일한 방법은 웹 서비스라고 생각한다. – tmbrggmn

+0

수정. Spring HTTP Remoting을 사용한다면, 클라이언트는 Spring 클라이언트를 사용하여 마샬링/언 마샬링 권한을 가져야한다. 웹 서비스는 불가 지론입니다. SOAP/XML과 동의어 일 필요는 없습니다. 그것들은 당신을 잠글 수도 있습니다. (예 : 축) REST는 완벽하게 좋은 방법입니다. – duffymo

+0

+1 - 클라이언트 - 서버 애플리케이션에서 항상 HTTP 서비스를 사용합니다. Java 클라이언트 만 신경 써야하기 때문입니다. 챔피언처럼 작동합니다! – aperkins