Openfire, Smack and Play를 사용하여 채팅 웹 사이트를위한 아키텍처! Framework

Question

Smack API를 사용하는 클라이언트 쪽에서 Openfire XMPP 서버를 사용하는 채팅 웹 사이트를 개발 중입니다. Smack API를 사용하는 웹 프로젝트는 Play! 프레임 워크를 RESTful하게 만듭니다. 나는 Play를 선택했다! 비동기 프로그래밍 제품 (Comet Sockets/WebSockets) 덕분입니다.

기본적으로, 내 아키텍처는 지금까지처럼 다음과 같습니다 :

의 Openfire < -> 웹 서버 < -> 사용자/브라우저.

Android 기기도 지원하고 코드 재사용을 극대화하려면 XMPP 클라이언트 측 코드를 웹 사이트와 Android 클라이언트 모두에 공통적 인 RESTful 웹 서비스로 구현해야합니까?

Openfire < -> Webservice < -> 웹 사이트 < -> 브라우저/사용자.

Openfire < -> 웹 서비스 < -> Android App.

중간 웹 서비스가 도입되어 확장 성 문제가 두려워합니까? 여러 구성 요소를 거쳐야하는 결과로 커뮤니케이션에 지연이 생길 수 있습니까?

위의 정보는 도움이 될 것입니다. 감사.

Answer 1

확장 성의 핵심은 디커플링입니다. 따라서 본질적으로 "구성 요소 중 하나가 실패하면 다른 구성 요소가 정상적으로 작동합니까?"라는 측면에서 문제를 생각할 수 있습니다. 세계 시나리오의 종말을 피하는 것 외에도 각 구성 요소를 독립적으로 수평 확장 할 수 있습니다.

이제 염두에두고 특정 유스 케이스로 이동할 수 있습니다. 레이어를위한 레이어는 여전히 Java EE 아키텍처에 대한 악몽을 보여줍니다. 불필요한 대기 시간을 초래할뿐만 아니라 문제를 정확하게 지적하기가 더 어려워집니다. 서비스가 실패하면 웹 서버, Android 응용 프로그램 또는 웹 서비스로 인해 실패한 것입니까?

코드를 다시 사용하려면 구성 요소를 복제하는 대신 코드를 다시 사용하십시오. 그것은 도서관이 원하는 것입니다. 공통 코드를 가져와 라이브러리로 추출하여 웹 서버와 Android 응용 프로그램에서 모두 사용할 수 있습니다.

Answer 2

일단로드되면 브라우저에서 웹 서비스 (모든 응용 프로그램과 같은)를 직접 소비하는 간단한 웹 페이지를 만드는 것이 가장 좋습니다.

그래서 앱과 웹 페이지의 유일한 차이점은 사용자가 액세스 할 때마다 웹 페이지가 브라우저에 의해로드된다는 것입니다.