Java Web Start - 인기
https://stackoverflow.com/questions/564936
-
05-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
최근에 Java Web Start 애플리케이션을 사용했습니다.내가 보고 있는 페이지에 포함된 jnlp 링크를 사용하여 웹 브라우저에서 이를 시작했습니다.응용 프로그램이 다운로드되고 실행되었으며 제대로 작동했습니다.내 로컬 파일 시스템에 액세스할 수 있었고 다시 시작할 때까지의 기본 설정을 기억했습니다.
내가 알고 싶은 것은 Java Web Start 애플리케이션이 웹의 복잡한 애플리케이션에 대해 더 널리 사용되는 전달 형식이 아닌 이유입니다.Java 및 Java Web Start를 사용하면 데스크탑 애플리케이션의 강력한 기능을 더 쉽게 제공할 수 있는데 개발자가 데스크탑 기능을 html/javascript로 복제하는 데 종종 상당한 시간과 에너지를 소비하는 이유는 무엇입니까?
은행 업무와 같은 일부 기업 환경에서는 클라이언트에게 복잡한 거래 애플리케이션을 제공하는 데 상대적으로 널리 사용되는 방법이라는 것을 알고 있습니다. 그런데 왜 웹 전체에서는 널리 사용되지 않습니까?
(토론을 위해 다음과 같은 세계를 가정해 보겠습니다.다운로드 소스는 "신뢰"되고 애플리케이션은 "서명"됩니다(예:보안 문제 없음), 다운로드 속도가 빠르고(로드 시간이 빠름) 개발자가 Java를 알고 있습니다(html/js/php를 아는 숫자로).
해결책
그 이유는 보안이나 앱의 시작 시간이 아닌 것 같습니다.근본 원인을 찾기 전에 배후에 무엇이 있는지 이해해 봅시다.
Java 제어판에는 사용자가 기본 브라우저의 프록시 설정을 사용하거나 이를 대체할 수 있는 설정이 있습니다.즉, 인프라 팀은 Windows 또는 OS 설치 이미지를 사용자 정의하여 JVM이 엔터프라이즈 프록시 설정과 함께 사전 설치되도록 할 수 있습니다.그래서 저는 이것이 전혀 문제가 되지 않는다고 믿습니다.
Java Web Start는 실제로 Java 제어판의 사용자 정의 가능한 설정으로 모든 앱을 캐시합니다.앱이 캐시되면 해당 앱은 다른 앱과 마찬가지로 "설치"됩니다.첫 번째 실행은 느릴 수 있지만 JVM의 스마트 메모리 할당 기술로 인해 두 번째 실행은 빨라집니다.따라서 시작 시간이 문제가 될 수 있지만 이제 많은 웹 사이트(기업 내부 포함)가 포털로 마이그레이션됩니다.웹 포털에는 일반적으로 포털 자체가 특정 페이지에 어떤 종류의 포틀릿이 구축되고 배포되는지 예측하지 못하기 때문에 개발 목적으로 사용되지 않는 라이브러리가 많이 포함되어 있습니다.따라서 단일 포털 페이지를 다운로드하는 데 최대 MB가 소요될 수 있으며 5초 이상 안에 페이지를 완료할 수 있습니다.이것은 단지 하나의 페이지이고 캐싱은 최대 30%까지 도움이 되지만 매번 다운로드해야 하는 HTML/Javascript/CSS 구성 요소는 여전히 많습니다.이를 통해 저는 Java Web Start가 여기서 장점이 있다고 확신합니다.
Java Web Start는 서버 사본이 업그레이드되지 않는 한 캐시된 경우 다시 다운로드하지 않습니다.따라서 예를 들어MS Project와 같은 프로젝트 관리 소프트웨어는 SmartClient(JWS와 유사)를 사용하여 완료되며, 클라이언트와 서버 간의 정보 교환은 브라우저의 전체 페이지 새로 고침과 같이 표시되지 않는 순수한 데이터일 것입니다.Ajax의 도움을 받아도 전체 페이지 다운로드가 완전히 제거되지는 않습니다.게다가 많은 회사에서는 Ajax가 아직 미성숙하고 안전하지 않다고 생각합니다.이것이 바로 Ajax가 개발자들 사이에서는 뜨거운 주제이지만 아직 엔터프라이즈 소프트웨어에서는 그렇지 않은 이유입니다.이를 염두에 두고 JWS 앱은 JWS 앱이 샌드박스에서 배포 및 실행되고 서명되며 훨씬 더 많은 대화형 GUI를 갖는 것과 같은 더 많은 이점을 가지고 있습니다.
다른 장점으로는 더 빠른 개발(코드 및 성능 디버깅이 더 쉬움), 반응형 사용자 인터페이스(PUSH 기능을 제공하기 위해 Comet 서버가 필요하지 않음), 더 빠른 실행(확실히 클라이언트 컴퓨터가 HTML/Javascript/CSS와 같은 변환 없이 GUI를 렌더링하기 때문에)이 있습니다. 데이터 처리량이 적습니다.)
이 모든 것에도 불구하고 저는 아직 JWS가 왜 그렇게 유명하지 않은지에 대한 질문을 건드리지 않았습니다.
내 의견은 Brian Knoblauch의 의견과 동일하며 인식이 없다는 것입니다.
IT 담당자는 웹 기술, Ajax PUSH, GWT 등의 과장된 광고에 너무 매력을 느끼며, 이러한 모든 유행어는 고객에게 실제로 도움이 되는 것 대신에 다른 기술을 사용하는 즐거움이나 기술적 문제를 해결하는 데 편향되게 만듭니다.
시트릭스를 살펴보세요.Citrix는 실제로 좋은 아이디어라고 생각합니다.Citrix를 사용하면 백그라운드에서 자신만의 앱 팜을 구축할 수 있습니다.고객 경험에 영향을 주지 않고 선택할 수 있는 업그레이드 및 구현 전략이 많이 있습니다.Citrix 배포는 매우 쉽고 안정적이며 안전합니다.기업에서는 여전히 이를 사용하고 있습니다.하지만 JWS가 Citrix보다 훨씬 낫다고 생각합니다.JWS의 아이디어는 클라이언트 컴퓨터가 이러한 앱을 자체적으로 실행할 수 있는 수많은 서버 팜을 호스팅하는 대신 클라이언트 컴퓨터에서 앱을 실행하는 것입니다.이것은 회사에 많은 돈을 절약해줍니다!!!JWS를 사용하면 개발 팀은 여전히 서버 측에서 비즈니스 로직과 데이터를 구축할 수 있습니다.그러나 웹 처리 장치가 없고 클라이언트 컴퓨터가 렌더링 프로세스를 수행하도록 하면 네트워크 소비량과 서버 처리 능력이 크게 줄어듭니다.
JWS가 놀라운 아이디어인 이유를 보여주는 또 다른 예는 Blackberry MDS입니다.Blackberry 앱은 실제로 Javascript를 번역한 Java 앱입니다.BB의 MDS 스튜디오에서는 GUI 도구를 사용하여 BB 앱 GUI를 구축하고 Javascript로 GUI 논리를 코딩합니다.그런 다음 앱이 번역되어 BES 서버에 배포됩니다.그러면 BES 서버는 이러한 앱을 BB에 배포합니다.각 BB에서는 GUI 렌더링 및 네트워킹 기능만 갖춘 씬 Java 앱을 실행합니다.앱에 데이터가 필요할 때마다 웹 서비스를 통해 BES와 통신하여 다른 서버의 서비스를 소비합니다.이거 그냥 JWS BB 버전 아닌가요?매우 성공적이었습니다.
마지막으로 Sun의 광고 방식 때문에 JWS가 인기가 없다고 생각합니다.BB는 BB Java 앱이 얼마나 좋은지 광고하지 않으며 고객은 그것이 무엇인지조차 신경 쓰지 않을 것이라고 믿습니다.BB는 MDS를 사용하여 앱을 개발할 때의 이점을 광고합니다.신속, 비용 절감, 비즈니스 수익.
그냥 내 조금 긴 2 센트 ...:)
다른 팁
Java Webstart의 주요 장애물은 애플리케이션을 다운로드하고 시작하기 전에 JVM을 설치해야 한다는 것입니다.누구나 브라우저를 가지고 있습니다.모든 사람이 JVM을 갖고 있는 것은 아닙니다.
편집하다:그 후 웹스타트에 대한 실무 경험을 쌓았으며 이제 다음 두 가지 사항을 추가할 수 있습니다.
- 그만큼 배포 툴킷 스크립트 Java 1.6u10 부근에 출시된 모듈화된 JVM은 JVM 및 API 코어를 자동으로 다운로드하고 나머지를 다운로드하는 동안 프로그램을 시작할 수 있기 때문에 JVM 요구 사항의 문제를 덜 해결합니다.
- Web Start에는 심각한 버그가 있습니다.Java 1.6 릴리스 중에도 매번 전체 앱을 다운로드하는 릴리스가 있었고, 다운로드한 후 모호한 오류 메시지와 함께 실패하는 릴리스도 있었습니다.대체로 나는 그렇게 취약한 시스템에 의존하는 것을 별로 추천할 수 없습니다.
대부분 인식이 부족해서인 것 같아요.그것은 아주 잘 작동합니다.꽤 매끄 럽습니다.앱은 처음 다운로드하는 경우, 업그레이드가 있는 경우 또는 최종 사용자가 캐시를 지운 경우에만 다운로드됩니다.사용자가 수동으로 업그레이드할 필요가 없는 완전한 데스크톱 앱을 배포할 수 있는 좋은 방법입니다!
Webstart의 문제는 빠른 연결에서도 전혀 빠르지 않은 것을 실제로 '시작'해야 하는 반면, webapp에서는 URL을 입력하면 앱이 거기에 있다는 것입니다.
또한 webstart에서 많은 문제가 발생할 수 있습니다.의도한 사용자에게 필요한 권한이 없거나, webstart의 프록시가 잘못 구성되었거나, jre 종속성에 문제가 있거나, 애초에 Java가 설치되지 않았을 수 있습니다.따라서 인터넷의 평균 John Doe에게는 전혀 만족스럽지 않습니다.
회사와 같이 통제된 환경에서는 많은 경우에 적합하고 쉬운 솔루션입니다.
저는 몇 년 동안 수천 명의 사용자 기반을 대상으로 JWS 배포 애플리케이션을 작업했는데 자동 업그레이드는 실제로 큰 고통이었습니다.
어떤 이유로 업데이트할 때마다 수십 명의 사용자가 "중간에 멈춤" 상태가 됩니다.당신이 얻는 것은 "클래스를 찾을 수 없음" 예외(운이 좋다면)이거나 코드에 도달하기 전에 JWS에서 유익하지 않은 "실행할 수 없음"뿐입니다.업데이트가 절반만 다운로드된 것 같습니다.즉, 업데이트를 원자적으로 다운로드 및 적용하지 않고 캐싱이 좋지 않아 동일한 URL에서 앱을 다시 시작해도 아무 문제가 해결되지 않습니다.
JWS 캐시를 지우거나 다른 URL(예:추가 ?dummyparam=jwssucks 마지막에).개발자인 나조차도 가끔 이런 일이 발생하는데, 방법이 보이지 않습니다.
작동하면 작동합니다.그러나 그렇지 않은 경우가 너무 많아 귀하와 귀하의 헬프 데스크에 큰 고통을 안겨줍니다.기업용이나 업무상 중요한 용도로는 권장하지 않습니다.
즉, "프로그램을 즉시 시작한 다음 백그라운드에서 업데이트를 확인하고 다운로드하는" 배포를 허용하지 않는다는 매우 큰 문제가 있습니다. 이는 애플리케이션의 사실상의 동작이 수렴되는 것입니다.
저는 개인적으로 이것이 너무 큰 성가심이라고 생각하여 이를 제공하는 다른 기술을 적극적으로 찾고 있습니다.
이 게시물을 보면 Web start를 사용할 때 서버를 잘 관리하는 것이 중요하다고 보입니다.시작할 때마다 애플리케이션을 다운로드할 때 발생하는 "큰 고통"은 서버에서 전달된 잘못된 타임스탬프 때문에 발생할 수 있습니다.여기서는 애플리케이션이 아니라 서버를 캐싱을 비활성화하는 것이 아니라 적절하게 사용하도록 구성해야 합니다.버기 스타트에 대해서는 잘 모르겠습니다만, 이 역시 불안정한 연결로 인해 발생하는 것으로 보입니다.
Web start의 중요한 장점은 Linux에서 OpenJDK와 잘 작동한다는 것입니다.일부 행복한 개발자의 클라이언트는 Windows만 사용하지만 내 클라이언트는 Windows를 사용하지 않습니다.
초기 질문에서 언급된 HTML과 JavaScript는 애니메이션 버튼이나 대화형 테이블과 같은 소규모 작업에 잘 작동하는 가벼운 접근 방식입니다.Java 틈새 시장은 훨씬 더 복잡한 작업을 중심으로 보입니다.
Java Web Start는 Java Applet의 일종의 후속 제품이며 애플릿은 새천년 무렵에 불타 버렸습니다.하지만 저는 여전히 Java 애플릿이 GWT나 Javascript 지옥보다 훨씬 낫다고 생각합니다.
