웹 기반 클라이언트 대 두꺼운/리치 클라이언트?

Question

저희 회사는 주요 통신 회사의 소프트웨어 솔루션 제공 업체입니다. 환경은 현재 IBM WebSphere 기반이며, 프론트 엔드 IBM Portal 서버는 EJB 서비스를 제공하는 백엔드 WebSphere Application Server 클러스터와 통신합니다. 일부 포틀릿은 자체적으로 제작 된 MVC 패턴을 사용하고 일부는 JSF로 작성됩니다.

최근에 우리는 백엔드 서버의 EJB와 직접 통신하는 개념 증명 (rich-thick-client) 애플리케이션을 수행했습니다. NetBeans 플랫폼을 사용하여 작성되었으며 WebSphere Application Client 라이브러리를 사용하여 EJB와의 통신을 설정합니다.

정말 고통 스럽지만 클라이언트가 안전한 JAAS/SSL 통신을 사용하도록하고있었습니다. 그러나 이러한 문제가 해결 된 후에는 풍부한 클라이언트가 익숙해 진 웹 기반 포털 클라이언트 응용 프로그램에 비해 다음과 같은 장점을 가지고 있음을 발견했습니다.

• CORBA vs. HTTP,
• 개발이 간단하고 디버그주기가 테스트 서버
에 클라이언트 응용 프로그램을 배포 할 필요가 없으므로 단축 넷빈즈 '비주얼 디자이너와 스윙의 일반적 강력한 아키텍처
• 의 사용이 빠르게 인해) 포털 서버 중간에 사람을 잘라
• 웹 기반 개발 (Struts, JSF, JQuery, HTML, JSTL 등, e tc)

잠시 동안 웹 기반 개발 (심지어 JSF 포함)의 고통을 견뎌낸 후 다음과 같은 결론을 내 렸습니다. 리치 클라이언트는 모든 상황에 적합하지 않지만, 사내 인트라넷 기반 솔루션을 개발하고 있다면 NetBeans Platform 또는 Eclipse RCP를 고려하지 않는 것이 좋습니다.

풍부한 클라이언트와 웹 클라이언트에 대한 의견/경험이 있으십니까?

Answer 1

배포를 위해 Java Web Start를 사용하는 한 반드시 동의하지는 않습니다. IT 웹 애플리케이션의 요점은 버전 X가 더 이상 지원되지 않을 때 모든 사용자를 버전 Y로 업데이트하려는 원격 배포의 혼란을 피하는 것입니다.

웹 앱으로 무료로 받으실 수 있습니다.

Answer 2

하나의 이점은 많은 계산/검증이 클라이언트 측에서 수행 될 수 있다는 점입니다. 이는 각 클라이언트가 전체 응용 프로그램의 처리 부하를 공유 할 수있게합니다.

두꺼운 클라이언트의 또 다른 이점은 클라이언트에서 상태를 유지한다는 것입니다. 이로써 서버의 상태를 비우고 내결함성을 손쉽게 만들고 확장 할 수 있습니다.

우리의 경우 응용 프로그램의 하드웨어에 대한 인터페이스가 있고 스캐너는 워크 스테이션의 직렬 포트에 있으며 응용 프로그램에서 인쇄 작업을 응용 프로그램 제어 할 수 있도록 JNI 계층을 프린터에 구현했습니다. (인보이스 인쇄)

새 소프트웨어를 시작하고 배포 할 때 우리는 로컬 시스템의 파일을 서버의 배포 된 날짜와 대조하여 로컬 시스템이 최신 버전인지 확인합니다. 시스템이 오래된 경우 우리는 필요한 jar 파일을 다운로드 한 다음 응용 프로그램을 시작합니다. 이렇게하면 사용자가 웹 페이지로 이동할 필요가 없습니다.

새로운 Java EE 관련 서버 측 패턴에 대해서도 this book을 권장합니다.