Jaka jest alternatywa dla strategii portalu korporacyjnego w przestrzeni Java?

Rozczarowanie przestrzenią portalu

Widzę niepokojącą liczbę dużych klientów korporacyjnych, którzy rozczarowali się swoim doświadczeniem z portalem korporacyjnym, szczególnie tymi w przestrzeni serwera WebSphere Portal Server (WPS). Zainwestowano miliony, ale obietnica spersonalizowanych treści z agregacją i zintegrowanymi narzędziami do współpracy nigdy się nie spełniła. Przejście na WPS 7.x jest dużym krokiem do zgrania i zastąpienia, a klienci zastanawiają się, czy powinni przenieść się całkowicie gdzie indziej.

Oprogramowanie portalu: okropna opcja, ale jaka jest alternatywa

Istnieje mnóstwo hejterów portalu, a czasem rozwiązanie portalu jest w rzeczywistości przesadą, ale jeśli mówisz o dużych, międzynarodowych korporacjach, jak poleciłbyś zaprojektować globalne rozwiązanie bez serwera portalu?

Portale nie zawsze są tak przyjemne w pracy jak Tomcat czy JBoss AS, ale jeśli chodzi o integrację wielu aplikacji, zarządzanie treścią, aktualizowanie pojedynczych aplikacji, które są wdrażane jako osobne pliki wojenne, zarządzanie bezpieczeństwem aż do poziomu portletu, potwierdzając pewne ilość personalizacji dla użytkowników i pomoc w przytłaczającym zadaniu zarządzania tysiącami stron, które duże przedsiębiorstwa mają w ramach swoich wewnętrznych i zewnętrznych stron internetowych, czy jest tam lepsza technologia?

Zdobywanie wiedzy i opinii społeczności

Próbowałem zdobyć jak najwięcej wglądu. Napisałem mały artykuł na temat TSS na ten temat:

Jakie inne alternatywy dla portalu istnieją na rynku?

Wskrzeszam też wątek w CodeRanch, aby zobaczyć, czy uda mi się uzyskać wgląd w tę przystojną załogę.

Zaktualizowano wątek z prośbą o alternatywę dla oprogramowania portalu. Około 2012 r

Szukam również wglądu z twitterati (@potemcam).

To nie tyle cross-post, ile próba naprawdę zebrania głębokiego wglądu ze strony społeczności. Jeśli mogę uzyskać solidne odpowiedzi i doświadczenia, chciałbym je zebrać w artykuł z poradami w TSS.

Jaka jest odpowiednia alternatywa dla korporacyjnego portalu w przestrzeni Java?

Nawiasem mówiąc, odsyłam do tego pytania również z innych stron, aby osoby z tymi samymi pytaniami mogły się podskakiwać tam iz powrotem i sprawdzać, co mówi społeczność na ten temat.

Najpierw musisz rozważyć, jakie problemy Portal został rozwiązany. Czy to, jak sugeruje Wikipedia, zebranie informacji z różnych źródeł w jednolity sposób? Jeśli tak, to jakie jeszcze sposoby musimy to zrobić?

Po pierwsze, jak zebrać informacje z różnych źródeł? Oczywistą odpowiedzią jest wywołanie różnych usług (internetowych). Wprowadza to problemy związane z umowami i opóźnieniami w sieci, bla bla bla, ale są to rzeczy źle rozwiązane przez portal, więc to twoja rozmowa. Załóżmy, że usługi są RESTful? Czy to ułatwia zarządzanie umowami? Możliwie.

Jak zatem ujednolicić informacje? Jednym z problemów, które rozwiązał portal, było umieszczenie tych różnych elementów na jednej stronie i ich niezależne ładowanie. Od tego czasu AJAX wyrósł i ten sam efekt można potencjalnie obsłużyć za pomocą wywołań XMLHttpRequest do różnych usług (RESTful?) W celu uzyskania danych, a następnie przy użyciu wspólnego zestawu arkuszy stylów.

Czy to zadziała? Może i robi. Czy jest łatwiejszy w zarządzaniu niż serwery portalu JSR286? Prawdopodobnie. Czy jest jeszcze mnóstwo problemów do rozwiązania? Zdecydowanie. Ale to realna alternatywa.

Ostatnio byłem głęboko zaangażowany w scenę serwera portalu Java. Została wybrana jako niedroga alternatywa dla SharePoint, ponieważ udało nam się znaleźć dostawcę portalu oferującego porównywalne funkcje. Korzystaliśmy z platformy eXo i chociaż jest ona głównie reklamowana pod kątem funkcji społecznościowych, jest w pełni zgodna z serwerem portalu JSR286.

Portal Java może być niewiarygodnie potężny, ale naturalnie wiąże się to z kosztem pozorowania nadmiernej inżynierii i niepotrzebnie złożonego. Ogólna odpowiedź klienta, którą otrzymaliśmy, brzmiała, że ​​podstawowa konfiguracja i obciążenie serwera może być zbyt duże. Muszę jeszcze znaleźć platformę portalu lub alternatywę, która może oferować pełny zestaw funkcji, ale pozostać akceptowalnie wąska w stosunku do zestawu wymagań operacyjnych. Lata napięć między konkurującymi platformami portalowymi poważnie zatkały rynek.

Wzrost w świecie portalu Java był agresywnie powolny. Znajdziesz datowane interfejsy, archaiczny UX, a każda czynność pozostawi w ustach zły smak. Jest tu niewielu innowatorów, a platforma eXo jest jedną z niewielu, które, jak się okazało, podejmują wspólny wysiłek na rzecz modernizacji.

Biorąc to wszystko pod uwagę, nadal możesz stworzyć rozsądny produkt w świecie JSR268 z pewnym sukcesem. Byliśmy w stanie to zrobić, wykorzystując usługi JAX-RS dla każdego portletu, w zasadzie funkcje i funkcje portletów wybierających wiśnie. Cały dostęp do bazy danych jest uruchamiany z oddzielnych usług RESTful serwera WWW dla zoptymalizowanych operacji CRUD. Wymaga to ogromnej staranności z nadmiarem wysiłku, którego niewielu jest skłonnych podjąć.

Możesz także przejść całkowicie od podstaw i zbudować sobie „portal” z serwletami i JAX-RS. Można to zrobić znacznie szybciej niż standardowe tworzenie portalu. Jednak nie będziesz w stanie obsłużyć pełnego zestawu funkcji konfiguracyjnych dostępnych w standardowym portalu internetowym.

Po prostu istnieje poważny cykl uwięzienia nadmiernych zestawów funkcji, które tłumią innowacje, które nie wydają się wkrótce zmieniać. Przełomy zmieniające rozgrywkę są mało prawdopodobne, ponieważ ciężcy uderzenia nie widzą ewolucji meta. Ale twoją jedyną alternatywą jest ponowne wynalezienie tylko tych funkcji, które chcesz.

Nie zgadzam się z Matthew , żaden z problemów z portalami korporacyjnymi nie jest spowodowany bezpośrednio przez technologię. Problemem jest prawie zawsze brak wyraźnego skupienia i kierunku.

Jaki problem próbujesz rozwiązać? Spróbuj sprowadzić go do kilku szczegółów. Prawdopodobnie mogę się domyślić, że przenoszenie informacji ze skrzynek odbiorczych wiadomości e-mail do niektórych rozwiązań w zakresie treści do przeszukania będzie dość wysokie. Podobnie jak znalezienie informacji, które znajdują się na współdzielonych dyskach sieciowych. Następnie prawdopodobnie istnieje pytanie dotyczące przepływu pracy.

Poza tym zaczyna się trochę mglisto i właśnie tam zawodzą rozwiązania. Jeśli ktoś próbuje sprzedać Ci portal z wersją demonstracyjną pokazującą niezwiązany zespół poszukujący informacji o swoim problemie i znajdujący inny zespół już rozwiązał ten problem, nie rozpoznaje on sposobu działania ludzi.

Nie chcę, żeby to zmieniło się w długi gofr, więc zadam jedno pytanie. Czy Twoje rozwiązanie portalowe pozwala ci na dzielenie się informacjami z rówieśnikami tak łatwo, jak klient e-mail? W szczególności moja aplikacja uległa awarii i chcę wysłać Ci zrzut ekranu. Mogę wkleić to prosto do mojej wiadomości e-mail, która nie będzie działać z rozwiązaniami internetowymi. Czy integruje się z pakietem Office? Kto dostarczy wszystkie istniejące informacje do portalu?

Skoncentruj się na ludziach, ich interakcjach i ich potrzebach i najpierw zapomnij o kwestiach technicznych. Po drugie, moderuj oczekiwania i życzenia ludzi z odrobiną rzeczywistości.