Java >> Java tutorial >  >> Java

Platformstrategi:Fra Portlets til OpenSocial Gadgets til Progressive Web Apps:State of the Art

Java

Introduktion

Da verden stadig var ved Javas hånd, definerer vi ofte det såkaldte komponentbaseret platform . Jeg havde denne oplevelse i år 2000 med OpenUSS (Open University Support System). På det tidspunkt havde jeg en idé om at udvikle en platform, der kan udvides ved hjælp af komponentarkitektur og J2EE-teknologi ( OpenUSS Component Architecture). Efter et stykke tid så vi fødslen af portal og portlet teknologi. Alle forsøgte at bygge portlets, som nemt kan installeres på en portalserver, alle baseret på Java. Kan du huske alle disse portaler som Apache Jetspeed, Liferay, JBoss Portal, IBM Webshepe Portal osv.?

Efter portalbølgen var der OpenSocial-gadget som ikke kun er specificeret til Java, men generelt tilgængelig for forskellige teknologiimplementeringer. Den bruger HTML , JavaScript og HVILE fuldstændig uafhængig af Java. Apache Shindig var en Open Source-implementering til OpenSocial-gadget-beholder. OpenSocial gadget var også hovedteknologien til iGoogle, Orkut, MySpace, XING og StudiVZ. Med OpenSocial kan du integrere webapps på to forskellige måder.

I dag har du stadig disse teknologier som Portal, Portlet og OpenSocial gadgets, men de er ikke særlig overbevisende længere. iGoogle er dødt, og ingen ønsker at bruge portal- og portletteknologi i deres nye webapps. Alle vigtige webapps i dag bruger ikke længere disse portaler, portlets og gadgets. Væksten i disse teknologier er helt sikkert ved at falde til nul.

Platform

Generelt en platform består i dag af to elementer:

  • Web-app til webbrowsere:dette er i dag stadig det mest brugte program. Brugere af bærbare, stationære, tablets og smartphones bruger denne type applikationer.
  • Native app til tablets, smartphones og wearables:Kun i nogle få tilfælde har du stadig brug for native apps til stationære og bærbare computere, da webapps bliver bedre hver dag til denne brugssag. De mest målrettede platforme til smartphones, tablets og wearables i dag er Android og iOS .

Lad os se nærmere på begge elementer.

Web Apps

Som nævnt ovenfor har vi ikke længere brug for disse portaler, portlets og gadgets. Leder vi stadig efter en komponentbaseret platform? Har vi stadig brug for følgende krav, som for det meste blev besvaret ved at bruge portaler, portlets og gadgets?

  • Samlet indhold og applikationer
  • Integrer på tværs af applikationer
  • Lav en samlet brugergrænseflade
  • Støt en samlet webapplikationsudviklingsplatform
  • Tilpas indhold og tjenester
  • Implementer en ramme til udgivelse af dynamiske sider

Svaret er ja, men hovedvægten flyttes til forskellige områder . Den nye trend inden for udvikling af webapps er de såkaldte Progressive Web Apps (PWA). I dag er det vigtigere at koncentrere sig om brugeroplevelsen i stedet for selve webappen . Følgende er definitionen af ​​progressive webapps (taget fra Google Developers Code Lab):

  • Progressiv – Virker for alle brugere, uanset browservalg.
  • Responsiv – Passer til enhver formfaktor:desktop, mobil og tablet.
  • Forbindelsesuafhængig – Forbedret med servicemedarbejdere til at arbejde offline eller på netværk af lav kvalitet.
  • Native app-lignende – Føles som en app for brugeren med app-lignende interaktioner og navigation.
  • Frisk – Altid opdateret takket være servicearbejderens opdateringsproces.
  • Sikker – Leveres via HTTPS for at forhindre snooping og for at sikre, at indholdet ikke er blevet manipuleret.
  • Opdagelig – Kan identificeres som en "applikation" takket være W3C-manifestet og registreringsomfanget for servicearbejdere, hvilket gør det muligt for søgemaskiner at finde det.
  • Re-engageable – Gør gen-engagement let gennem funktioner som push-beskeder.
  • Installerbar – Giver brugere mulighed for at "beholde" apps, de finder mest nyttige, på deres startskærm uden besværet med en app-butik.
  • Kan tilknyttes – Del nemt via URL, kræver ikke kompleks installation.

Så hovedvægten var at flytte fra :

  • Portaler, portlets og gadgets som blev defineret til at gøre livet til virksomheder (som leverede portaler, portlets, gadgets) og udviklere (som skriver portaler, portlets, gadgets) lettere til
  • Progressive webapps som gør brugere glade.

Det betyder ikke, at vi med en progressiv web-app ikke kan levere ovenstående krav. Lad os se nærmere på alle kravpunkterne.
 

(1) Saml indhold og applikationer og integrer på tværs af applikationer

Med Progressive Web Apps ser dette anderledes ud. Du vil ikke have en sådan integration ved hjælp af portlets. I stedet vil det være en integration af mange webapps ved hjælp af den samme værktøjslinje og hver webapp fungerer ligesom en standalone applikation . Her er en sammenligning.

Portal og Portlets Integration:Netvibes med Portal og Portlets

I en portal- og portlet-integration kan hver portlet maksimeres som en separat webapp.

Progressiv Web Apps-integration med Google Web Apps:Google+, Indbakke, Søg osv.

Jeg var en glad bruger af iGoogle (OpenSocial Gadgets-løsning fra Google), før Google slog det fra. I begyndelsen tænkte jeg, at jeg skulle søge efter et alternativ ligesom netvibes. Til sidst savner jeg det slet ikke. Hvis jeg har brug for at få oplysningerne, har jeg for det meste brug for dem i fuldskærmstilstand . Så i sidste ende har jeg altid brug for webappen i en helhed og ikke kun i en lille portlet .I en Progressive Web Apps-integration definerer hvert ikon en webapp, og den åbnes separat som en selvstændig webapp for at følge reglen om Native App-lignende .

(2) Giv en samlet brugergrænseflade

Begge typer kan understøtte en samlet brugergrænseflade. Progressive webapps bruger almindelig UI-model som Google Material Design eller Bootstrap. Portal, portlets og gadgets har for det meste en mekanisme til at bruge skins i portalcontaineren.

(3) Understøtte en samlet webapplikationsudviklingsplatform

Det er her Progressive Web Apps spiller deres styrke. Så længe webappen bruger HTML , JavaScript, CSS og HVILE det kan implementeres i forskellige teknologistakke som Java, PHP, JavaScript og mange flere. Da du ikke har nogen "Portal Container" i sådan en Progressive Web App, kan du lodret bruge din valgte teknologistack . Hvorimod portal- og portlet-implementering er baseret på en portalcontainer . Så hvis du bruger Tomcat som en container, bliver du nødt til at implementere din portlet i den container. Du kan helt sikkert foretage et fjernserviceopkald, men det er ikke standardtilfældet.

(4) Tilpas indhold og tjenester

Det er her, Portlet viser sin stærke karakter. Du kan slå portlets til og fra efter dine behov. Hvis du ser Google-værktøjslinjen ovenfor, kan du også tilpasse indholdet. Så i dette tilfælde kan den progressive webapp gøre det samme med individuelt design af sin webapp.
 

(5) Implementer en ramme til udgivelse af dynamiske sider

Dette er også muligt med begge typer, og tendensen går til Microservice.

Som en oversigt kan du stadig opfylde ovenstående krav ved hjælp af progressive webapps. Derudover kan du bygge komponentbaserede webapps ved at bruge standardwebkomponenterne. Nogle eksempler på brug af den virkelige verden til progressive webapps kan ses her:

  • Flipkart:Progressive Web Apps hos Flipkart
  • Air Berlin:Progressive Web Apps hos Air Berlin

Native apps

En platformstrategi uden at tage sig af de mest brugte klienter (mobiltelefoner og tablets) er simpelt hen en fiasko. Her er typerne af klientenheder i dag med deres operativsystemer:

  • Skriveborde og bærbare med Windows, Linux og MacOS:I de fleste tilfælde skal du blot bruge en webbrowser (Firefox, Internet Explorer, Edge, Chrome og Safari) med webapps. Der er ingen grund til at bygge native apps til hvert operativsystem, bare gå efter Progressive Web Apps . Her er nogle fakta:
    • Google stopper udviklingen af ​​Picasa-klientappen og flytter alt til internettet med Google Fotos.
    • Integreret udviklingsmiljø (IDE) som Eclipse ville være den ene ting, der burde være indbygget implementeret til at køre på klienter på toppen af ​​operativsystemerne. Men denne model vil også ændre sig i fremtiden, da Eclipse begynder at bruge web-app som sin fremtidige IDE:Eclipse Che – Cloud IDE.
  • Tablets med Android og iOS:I øjeblikket skal du bygge native apps til Android og iOS. Men i mange tilfælde kunne webapps med progressive webapps være løsningen, da webapps kan gøre næsten det samme som de oprindelige apps, især med ankomsten af ​​HTML5.
  • Mobiltelefoner med Android og iOS:Som på tabletområdet i øjeblikket skal du bygge native apps til Android og iOS. På grund af skærmstørrelsen er det sandsynligt, at vi skal udvikle de native apps. Men Progressive Web Apps klarer sig bedre hver dag (se billedet nedenfor og begge eksempler ovenfor med Flipkart og Air Berlin).
  • Wearables, gadgets, biler og TV med Android Wear, Android Auto, Android TV, watchOS, Apple CarPlay og tvOS:Dette er området, hvor du skal skrive indbyggede apps, da de mindre enheder ikke vil kunne køre en webbrowser.

Progressive webapps med materialedesign

Implementeringsteknologi med Java

Det er dyrt at udvikle apps til forskellige målsystemer. Ideen med Progressive Web Apps er fantastisk, da det sparer dig for at skrive native apps til hvert operativsystem. Men stadig i nogle tilfælde – i hvert fald i øjeblikket – skal vi bygge native apps. Til dette formål og for at spare ressourcer er der den såkaldte Hybrid Application Development . Der er en masse Hybrid Application Framework med HTML-brugergrænseflade derude.

Problemet med denne teknik er, at HTML-brugergrænsefladen ikke føles virkelig indfødt. Derfor er der en anden type hybridapplikation det såkaldte Hybrid Application Framework med Native UI . I dette tilfælde bruger du stadig den native UI i hvert operativsystem og bruger f.eks. det samme programmeringssprog til at dække resten. Da Java stadig er det første programmeringssprog, er det klogt at basere din platformstrategi på Java.

Sammenligning Progressive Web Apps – Hybrid Apps med HTML UI – Hybrid Apps med Native UI

Grafikken nedenfor viser en sammenligning mellem Progressive Web Apps , Hybride applikationer med HTML UI og Native UI i runtime.

 Hvilken slags værktøjer og produkter tilbyder Java os til at implementere teknologien ovenfor?

(1) Foundation

  • Spring Boot og Spring Cloud til Microservice Architecture. Disse Open Source-produkter er virkelig modne, produktionsklare og nemme at bruge.

(2) Web Apps baseret på Progressive Web Apps

  • For denne type webapps har du ikke mange alternativer i Java-området. Framework som JSF eller Grails er ikke i stand til at implementere denne funktion, da du har brug for JavaScript, som skal køre på browsersiden. Brug af ren Java i stedet for at tilføje kompleksitet i JavaScript med rammer som AngularJS kunne være et plus. Til dette formål kan du vælge følgende produkter:
    • GWT – Dette er stadig den bedste Java til JavaScript Open Source transpiler.
    • jsweet – En transpiler fra Java til TypeScript/JavaScript. jsweet har en anden mekanisme til transformation af Java-koder til JavaScript fra GWT, da jsweet bruger sine egne Java-biblioteker til at styre transformationen.
    • ST-JS (Strongly Typed JavaScript) – En transpiler fra Java til JavaScript, der ligner jsweet.
    • TeaVM:En transpiler fra Java bytecode til JavaScript.
    • DukeScript:En ramme til at skabe JavaScript-applikation baseret på Java. Generelt kan DukeScript tale direkte fra Java til JavaScript-koden.
    • DoppioJVM:En virtuel Java-maskine skrevet i 100 % JavaScript. Ideen er at køre Java-apps i browseren med denne virtuelle maskine.
    • Java2Script Bridge RCP til RIA:En konverter af Eclipse SWT til JavaScript.
  • GWT er det mest modne produkt i denne kategori, og Google bruger GWT i mange af deres produkter. GWT kan integreres med følgende UI-rammer:
    • Bootstrap (GWTBootstrap3),
    • Material Design (GWT Material Design),
    • Materialedesign med polymer.
    • Den fremtidige version af GWT kan også fungere med Angular 2 (Angular2Boot).
  • Der er en samling af bedste praksis, hvordan man bruger GWT til at implementere progressive webapps. Så du kan skrive progressive webapps i dag helt i Java med GWT.

(3) Native apps med HTML UI

  • Brug af mGWT og mGWT PhoneGap med skins af Android og iOS:Med den samme teknologi Java, GWT og PhoneGap / Apache Cordova kan du skrive en indbygget app med HTML UI. I stedet for at bruge denne teknologi bør du måske bruge Progressive Web Apps-teknologi, da HTML-brugergrænsefladen alligevel ikke ser indfødt ud. Progressive Web App er den samme, og du kan skrive den én gang til web og mobil.

(4) Native apps med Native UI

  • I Android kan du implementere den oprindelige brugergrænseflade bare ved hjælp af Java, ingen speciel løsning er nødvendig.
  • I iOS skal du bruge Objective-C til at implementere den oprindelige brugergrænseflade. Brug af Open Source-produkter som J2ObjC (Java to Objective-C transpiler) vil hjælpe meget med at genbruge Java-koderne
  • Produkt som Google Inbox bruger GWT og J2ObjC til at levere de samme funktionaliteter på tværs af operativsystemer (web, Android og iOS) på samme tid.

Platformstrategi

Så hvordan kan vi definere vores platformstrategi i dag? Følgende punkter er min opsummering:

(1) Foundation

  • Hvis du bruger Java som dit programmeringssprog udnytter Spring Boot og Forårsskyer til din Mikrotjeneste implementering af arkitektur. Men i sidste ende kan du bruge forskellige implementeringsteknologier som Java, .NET og andre. Det er bare vigtigt at bruge standarderne i næste punkt.

(2) Server-side og Business Logic

  • Brug RESTful og JSON for kommunikationen mellem mircotjenesterne.
  • Godkendelse og Single Sign On med OpenId Connect og OAuth 2 er et must i denne platformsstrategi, så du er i stand til at integrere alle mikrotjenesterne med alle forskellige implementeringsteknologier.

(3) Brugergrænseflade

  • Portal og portlets er døde . Brug Progressive Web Apps for alle mulige apps. Hvis du har brug for at integrere mange progressive webapps, skal du bare bruge en integrations- eller værktøjslinje, ligesom hvad Google gjorde med sine produkter (se Google+ billedet ovenfor).
  • Hvis du har brug for Native Apps, byg dem med Hybrid Application Framework med Native UI ikke HTML UI.
  • Open Source-produkter for at gøre dit liv lettere for at bygge progressive webapps og indbyggede apps med indbygget brugergrænseflade i Java er følgende:GWT og J2ObjC . Overvej dem for bedre produktivitet og time to market.

En platformstrategi i dag behøver ikke at være baseret på hver enkelt implementering på det samme sprog, stadig hvis du har et lille team, der lægger vægt på det samme sprog, og Java er stadig det bedste tilgængelige programmeringssprog. Det næste billede i slutningen af ​​denne artikel viser state of the art implementeringsteknologier til en teknisk platform baseret på Java.

Implementeringsteknologier til en platform baseret på Java


Java tag