Java 공간에서 엔터프라이즈 포털 전략의 대안은 무엇입니까?

포털 공간으로 환멸

엔터프라이즈 포털 경험, 특히 WPS (WebSphere Portal Server) 공간의 고객 경험에 환멸을 느끼는 많은 수의 대규모 엔터프라이즈 클라이언트를보고 있습니다. 수백만 달러가 투자되었지만 집계 및 통합 협업 도구를 통한 개인화 된 컨텐츠의 약속은 실현되지 않았습니다. WPS 7.x 로의 전환은 큰 변화와 교체 이동이며 고객은 다른 곳으로 완전히 이동할 것인지 궁금합니다.

포털 소프트웨어 : 끔찍한 옵션이지만 대안은 무엇입니까

많은 포털 증오가 있으며 때로는 포털 솔루션이 과도하게 사용되기도하지만 대규모 다국적 기업에 대해 이야기 할 때 포털 서버가없는 글로벌 솔루션을 설계하는 방법을 어떻게 권장합니까?

포털은 Tomcat 또는 JBoss AS와 함께 작업하는 것이 항상 재미 있지는 않지만 여러 애플리케이션 통합, 컨텐츠 관리, 개별 war 파일로 배치 된 개별 애플리케이션 업데이트, 포틀릿 레벨까지 보안 관리, 특정 기능 입증과 관련하여 대기업이 내부 및 외부 웹 사이트의 일부로 보유하고있는 수천 페이지를 관리하는 압도적 인 작업에 도움이되는 더 나은 기술이 있습니까?

지역 사회 통찰력 및 피드백

가능한 한 많은 통찰력을 얻으려고 노력했습니다. 이 문제에 대해 TSS에 관한 작은 기사를 썼습니다.

포털에 대한 다른 대안은 무엇입니까?

또한 CodeRanch에서 스레드를 부활시켜 잘 생긴 승무원으로부터 통찰력을 얻을 수 있는지 확인하고 있습니다.

Portal Software Stragety에 대한 대안을 요청하는 스레드 업데이트. 2012 년경

또한 twitterati (@potemcam)에서 통찰력을 찾고 있습니다.

그것은 실제로 커뮤니티로부터 예리한 통찰력을 모으려는 시도만큼 교차 게시가 아닙니다. 탄탄한 응답과 경험을 얻을 수 있다면 TSS의 조언 기사로 집계하고 싶습니다.

Java 공간에서 엔터프라이즈 포털에 대한 올바른 대안은 무엇입니까?

그건 그렇고, 다른 사이트 에서도이 질문에 대한 교차 연결을 할 것이므로 동일한 질문을하는 사람들은 앞뒤로 튀어 나와서이 주제에 대한 커뮤니티의 의견을 볼 수 있습니다.

먼저 Portal이 해결하도록 설계된 문제를 고려해야합니다. Wikipedia에서 제안한 것처럼 다양한 소스의 정보를 통합 된 방식으로 통합합니까? 그렇다면 이제 다른 방법으로해야합니까?

우선, 다양한 출처의 정보를 어떻게 모으십니까? 확실한 대답은 다양한 (웹) 서비스를 호출하는 것입니다. 이것은 계약 및 네트워크 대기 시간, blah blah blah의 문제를 소개하지만 포털에 의해 제대로 해결되지 않은 것이기 때문에 귀하의 전화입니다. 서비스가 RESTful이라고 가정합니까? 계약 관리가 더 쉬워 집니까? 혹시.

그런 다음 정보를 어떻게 통합합니까? Portal이 해결 한 문제 중 하나는 이러한 개별 항목을 한 페이지로 가져 와서 독립적으로로드하는 방법이었습니다. AJAX는 그 이후로 성장했으며, 다양한 (RESTful?) 서비스에 대한 XMLHttpRequest 호출을 사용하여 데이터를 가져오고 공유 스타일 시트 세트를 사용하여 동일한 효과를 처리 할 수 ​​있습니다.

이것이 효과가 있습니까? 할 수 있습니다. JSR286 포털 서버보다 관리가 용이합니까? 아마. 여전히 극복해야 할 수많은 문제가 있습니까? 명확히. 그러나 가능한 대안입니다.

최근에 Java 포털 서버 장면에 깊이 관여했습니다. 비슷한 기능을 제공하는 포털 제공 업체를 찾을 수 있었기 때문에 SharePoint의 저렴한 대안으로 선정되었습니다. 우리는 eXo 플랫폼 과 함께 갔으며 주로 소셜 기능에 대해 광고되었지만 JSR286 포털 서버와 완벽하게 호환됩니다.

Java 포털 은 엄청나게 강력 할 수 있지만, 과도하게 엔지니어링되고 불필요하게 복잡해 보일 수 있습니다. 우리가받은 일반적인 고객 반응은 서버의 기본 구성 및 오버 헤드가 너무 클 수 있다는 것입니다. 장황한 기능 세트를 제공 할 수있는 포털 플랫폼 또는 대안을 아직 찾지 못했지만 일련의 운영 요구 사항을 수용 할 수있을 정도로 슬림합니다. 경쟁 포털 플랫폼간에 수년간의 기능 부풀림이 시장을 심각하게 방해했습니다.

자바 포털 세계의 성장은 엄청나게 느렸다. 당신은 데이트 인터페이스, 구식 UX를 찾을 수 있으며, 모든 행동은 입안에 나쁜 맛을 남길 것입니다. 혁신가는 거의 없으며 eXo 플랫폼은 현대화에 공동 노력을 기울인 것으로 밝혀진 극소수 중 하나입니다.

이 모든 것을 감안할 때 JSR268 세계에서 여전히 성공적인 측정으로 합리적인 제품 을 만들 수 있습니다 . 우리는 각 포틀릿에 대해 JAX-RS 서비스 (기본적으로 체리 따기 포틀릿 기능 및 기능)를 활용하여이를 수행 할 수있었습니다. 모든 데이터베이스 액세스는 최적화 된 CRUD 조작을 위해 웹 서버 별도의 RESTful 서비스에서 실행됩니다. 많은 사람들이 기꺼이 헌신하지 않는 과도한 노력으로 부과하는 부지런함이 필요합니다.

서블릿과 JAX-RS를 사용하여 완전히 기초를 잡고 '포털'을 구축 할 수도 있습니다. 이는 표준 포털 개발보다 훨씬 빠르게 수행 할 수 있습니다. 그러나 표준 웹 포털에있는 전체 구성 기능 세트를 지원할 때는 부족합니다.

간단히 말해서, 곧 변하지 않는 혁신을 방해하는 과도한 기능 세트의 심각한 포착주기가 있습니다. 무거운 타자들은 메타 진화를 보지 못하기 때문에 게임을 바꾸는 획기적인 일이 일어나지 않을 것입니다. 그러나 유일한 대안은 원하는 기능 만 다시 발명하는 것입니다.

Matthew 와는 동의하지 않습니다. 엔터프라이즈 포털과 관련된 문제는 기술로 인해 직접적으로 발생 하지 않습니다 . 문제는 거의 항상 명확한 초점과 방향이 부족합니다.

해결하려는 문제는 무엇입니까? 그것을 몇 가지 세부 사항에 맞게 시도하십시오. 이메일 인 박스에서 정보를 검색 가능한 컨텐츠 솔루션으로 옮기는 것이 상당히 높아질 것입니다. 공유 네트워크 드라이브에있는 정보를 찾으십시오. 그렇다면 워크 플로에 대한 질문이있을 것입니다.

그 외에도 조금 어려워지기 시작하고 솔루션이 실패하는 곳입니다. 관련이없는 팀이 자신의 문제에 대한 정보를 검색하고 다른 팀을 찾은 것을 보여주는 데모가있는 포털을 판매하려는 경우 이미 해당 문제를 해결하여 사람들의 작업 방식을 인식하지 못합니다.

나는 이것을 긴 와플로 바꾸고 싶지 않기 때문에 한 가지 질문을 할 것입니다. 포털 솔루션을 사용하면 이메일 클라이언트처럼 쉽게 동료와 정보를 공유 할 수 있습니까? 특히 응용 프로그램이 중단되어 스크린 샷을 보내려고합니다. 웹 기반 솔루션에서는 작동하지 않는 이메일에 바로 붙여 넣을 수 있습니다. Office와 통합됩니까? 기존의 모든 정보를 포털에 가져 오는 사람은 누구입니까?

사람, 상호 작용 및 요구에 중점을두고 기술을 먼저 잊어 버리십시오. 둘째, 현실의 선량으로 사람들의 기대와 소망을 조절하십시오.