Panimula sa Java EE

Ngayon ay pag-uusapan natin kung ano ito - Java EE: kung ano ang binubuo nito, ano ang mga tampok ng arkitektura ng mga aplikasyon ng Java EE, at magbibigay kami ng mga paglalarawan ng iba't ibang mga teknolohiya ng platform na ito. Ang paksa mismo ay malawak, ngunit hindi kami titigil sa mga pangunahing kaalaman. Sa dulo, gagawa kami ng isang maliit na paghahambing ng Java EE sa Spring Framework at sasagutin ang tanong: "ano ang mas mahusay na matutunan" (spoiler: siyempre, kailangan mong matutunan ang lahat =) ) Magsimula tayo sa mga pangunahing kaalaman.

Java EE - ano ito?

Ang Java EE ay isang platform na binuo sa ibabaw ng Java SE na nagbibigay ng isang API at runtime na kapaligiran para sa pagbuo at pagpapatakbo ng malakihan, multi-tier, scalable, maaasahan, at secure na mga application ng network. Ang ganitong mga aplikasyon ay tinatawag na mga aplikasyon ng negosyo dahil nalulutas nila ang mga problemang kinakaharap ng malalaking negosyo. Gayunpaman, ang malalaking korporasyon at ahensya ng gobyerno ay hindi lamang ang maaaring makinabang mula sa mga naturang aplikasyon at ang mga benepisyong ibinibigay ng Java EE. Ang mga solusyon na inaalok ng platform ng Java EE ay kapaki-pakinabang, at kung minsan ay kailangan lang, para sa mga indibidwal na developer at maliliit na organisasyon.

Pag-unlad ng Java EE

Ang Java EE ay binuo sa pamamagitan ng Java Community Process (JCP), na nabuo noong 1998. Nagbibigay-daan ito sa mga interesadong partido na lumahok sa paghubog ng mga hinaharap na bersyon ng mga detalye ng platform ng wikang Java. Ang batayan ng prosesong ito ay ang JSR (Java Specification Request), mga pormal na dokumento na naglalarawan sa mga detalye at teknolohiya na iminungkahing idagdag sa Java platform. Ang mga naturang kahilingan ay ginawa ng mga miyembro ng komunidad - mga ordinaryong developer at kumpanya. Kasama sa huli ang Oracle, Red Hat, IBM, Apache at marami pang iba. Yung. ang mga lalaki ay nagmumungkahi ng mga bagong feature at goodies para sa pagsasaalang-alang na gusto nilang isama sa Java. At pagkatapos ay humawak sila ng isang boto, sa batayan kung saan ang isang desisyon ay ginawa sa kung ano ang isasama sa susunod na bersyon. Ang kasaysayan ng bersyon ng Java EE ay ganito:

• J2EE 1.2 (Disyembre 1999)
• J2EE 1.3 (Setyembre 2001)
• J2EE 1.4 (Nobyembre 2003)
• Java EE 5 (Mayo 2006)
• Java EE 6 (Disyembre 2009)
• Java EE 7 (Mayo)
• Java EE 8 (Agosto 2017)
• Jakarta EE 8 (Setyembre 2019)

Noong 2017, isang bagong milestone sa pagbuo ng platform ang naganap: Inilipat ng Oracle ang kontrol sa pagbuo ng Java EE sa Eclipse Foundation. At noong Abril 2018, pinalitan ng pangalan ang Java EE na Jakarta EE, na ganap na tugma sa Java EE 8.

Arkitektura ng Application ng Java EE

Isang maikling pagpapakilala. Upang gawing mas madaling maunawaan, pag-usapan natin ang tungkol sa istruktura ng mga aplikasyon ng Java EE at ilan sa mga terminong gagamitin pa natin. Ang mga application ng Java EE ay may istraktura na may dalawang pangunahing katangian:

• Una, multi-level. Ang mga aplikasyon ng Java EE ay multi-tiered, at pag-uusapan natin ito nang mas detalyado sa ibang pagkakataon;
• pangalawa, pugad. Mayroong Java EE server (o application server), na may mga bahaging lalagyan na matatagpuan sa loob nito. Ang mga lalagyang ito ay naglalaman ng (bingo!) na mga bahagi.

Upang ipaliwanag ang arkitektura ng mga aplikasyon ng Java EE, pag-usapan muna natin ang tungkol sa mga layer. Ano ang mga antas? Anong mga teknolohiya ng Java EE ang ginagamit sa iba't ibang antas? Susunod, tatalakayin natin kung paano magkakaugnay ang mga server ng application, mga lalagyan ng bahagi, at ang mga mismong bahagi. Ngunit tandaan na ang lahat ng ito ay mga pananaw mula sa iba't ibang mga anggulo sa parehong bagay, at ang pagkakasunud-sunod ay hindi napakahalaga dito.

Mga antas ng aplikasyon

Ang mga multi-tier na application ay mga application na hinati ayon sa mga functional na prinsipyo sa mga nakahiwalay na module (mga antas, mga layer). Karaniwan (kabilang sa konteksto ng Java EE development), nahahati ang mga enterprise application sa tatlong antas:

• kliyente;
• average na antas;
• antas ng pag-access ng data.

1. Ang client layer ay isang application na humihiling ng data mula sa Java EE server (gitnang layer). Ang server, sa turn, ay nagpoproseso ng kahilingan ng kliyente at nagbabalik ng tugon dito. Ang application ng kliyente ay maaaring isang browser, isang standalone na application (mobile o desktop), o iba pang mga application ng server na walang graphical na interface.

2. Ang gitnang antas ay nahahati, sa turn, sa antas ng web at antas ng lohika ng negosyo.

   1. Ang web layer ay binubuo ng ilang bahagi na nagbibigay ng pakikipag-ugnayan sa pagitan ng mga kliyente at ng business logic layer.

      Ang mga sumusunod na teknolohiya ng Java EE ay ginagamit sa antas ng web:

      • teknolohiya ng JavaServer Faces (JSF);
      • Mga Pahina ng Java Server (JSP);
      • Expression Language (EL);
      • Mga Servlet;
      • Mga Konteksto at Dependency Injection para sa Java EE (CDI).

   2. Ang business logic layer ay binubuo ng mga bahagi na nagpapatupad ng lahat ng business logic ng application. Ang logic ng negosyo ay code na nagbibigay ng functionality na sumasaklaw sa mga pangangailangan ng ilang partikular na lugar ng negosyo (industriya ng pananalapi, pagbabangko, e-commerce). Ang antas na ito ay maaaring ituring na core ng buong sistema.

      Mga teknolohiyang kasangkot sa antas na ito:

      • Enterprise JavaBeans (EJB);
      • JAX-RS RESTful web services;
      • Mga entity ng Java Persistence API;
      • Java Message Service.

3. Antas ng pag-access ng data. Ang antas na ito ay kung minsan ay tinatawag na antas ng enterprise information system (EIS). Ang EIS ay binubuo ng iba't ibang database server, ERP (Enterprise Resource Planning) enterprise resource planning system at iba pang data source. Ina-access ng business logic layer ang layer na ito para sa data.

   Sa antas na ito makakahanap ka ng mga teknolohiya tulad ng:

   • Java Database Connectivity API (JDBC);
   • Java Persistence API;
   • Arkitektura ng Java EE Connector;
   • Java Transaction API (JTA).

Mga server ng application, mga lalagyan, mga bahagi

Tingnan natin ang kahulugan ng Java EE mula sa Wikipedia. Ang Java EE ay isang hanay ng mga detalye at kaugnay na dokumentasyon para sa wikang Java, na naglalarawan sa arkitektura ng platform ng server para sa mga gawain ng katamtaman at malalaking negosyo. Upang mas maunawaan kung ano ang ibig sabihin ng "set ng mga detalye" sa kontekstong ito, gumuhit tayo ng pagkakatulad sa isang Java interface. Ang Java interface mismo ay walang functionality. Tinutukoy lamang nito ang ilang kontrata ayon sa kung saan ipinatupad ang ilang functionality. Ngunit ang ibang mga klase ay nagpapatupad ng interface. Bukod dito, ang isang interface ay maaaring magkaroon ng ilang mga pagpapatupad, ang bawat isa ay maaaring magkaiba sa bawat isa sa ilang mga detalye. Sa pagtutukoy ang lahat ay eksaktong pareho. Ang Naked Java EE ay isang hanay lamang ng mga detalye. Ang mga pagtutukoy na ito ay ipinatupad ng iba't ibang mga server ng Java EE. Ang Java EE server ay isang server application na nagpapatupad ng mga Java EE platform API at nagbibigay ng mga karaniwang serbisyo ng Java EE. Ang mga server ng Java EE ay tinatawag na mga server ng aplikasyon. Maaaring maglaman ang data ng server ng mga bahagi ng application, na ang bawat isa ay tumutugma sa sarili nitong antas sa isang multi-level na hierarchy. Ang Java EE server ay nagbibigay ng iba't ibang serbisyo sa mga bahaging ito sa anyo ng isang lalagyan. Ang mga container ay ang interface sa pagitan ng mga bahagi na kanilang hino-host at ang mababang antas na paggana ng platform-independent na sumusuporta sa bahagi. Ang mga container ay nagbibigay ng mga partikular na serbisyo sa mga sangkap na kanilang na-host. Halimbawa, ang pamamahala sa lifecycle ng development, dependency injection, concurrency, atbp. Itinatago ng mga container ang teknikal na kumplikado at pinapataas ang portability. Mayroong apat na iba't ibang uri ng mga lalagyan sa Java EE :

1. Ang mga lalagyan ng Applet ay ipinapatupad ng karamihan sa mga browser. Kapag bumubuo ng mga applet, maaari kang tumutok sa visual na bahagi ng application, habang ang lalagyan ay nagbibigay ng isang secure na kapaligiran.

2. Ang Application Client Container (ACC) ay naglalaman ng isang hanay ng mga Java class, library, at iba pang file na kailangan para ipatupad ang mga feature gaya ng injection, security management, at pagbibigay ng pangalan sa mga application ng Java SE.

3. Ang lalagyan ng web ay nagbibigay ng mga pangunahing serbisyo para sa pamamahala at pagpapatupad ng mga bahagi ng web (mga servlet, mga bahagi ng EJB Lite, mga pahina ng JSP, mga filter, mga tagapakinig, mga pahina ng JSF, at mga serbisyo sa web). Responsable ito sa pag-instantiate, pagsisimula at pag-invoke ng mga servlet, at pagsuporta sa mga protocol ng HTTP at HTTPS. Ang lalagyan na ito ay ginagamit upang maghatid ng mga web page sa mga browser ng kliyente.

4. Ang EJB (Enterprise Java Bean) container ay may pananagutan sa pamamahala at pagpapatupad ng mga bahagi ng modelo ng EJB na naglalaman ng business logic layer ng application. Lumilikha ito ng mga bagong EJB bean entity, pinamamahalaan ang kanilang lifecycle, at nagbibigay ng mga serbisyo tulad ng transaksyon, seguridad, concurrency, pamamahagi, pagbibigay ng pangalan, o mga kakayahan sa asynchronous na invocation.

Gayundin sa Java EE mayroong apat na uri ng mga bahagi na dapat suportahan ng isang pagpapatupad ng pagtutukoy ng Java EE:

1. Ang mga Applet ay mga graphical user interface (GUI) na mga application na tumatakbo sa isang browser. Ginagamit nila ang mayamang Swing API upang makabuo ng mga mahuhusay na interface ng gumagamit.

2. Ang mga application ay mga program na tumatakbo sa panig ng kliyente. Ang mga ito ay karaniwang graphical user interface (GUI) at ginagamit para sa batch processing.

3. Mga web application (binubuo ng mga servlet at mga filter ng mga ito, mga tagapakinig ng kaganapan sa web, mga pahina ng JSP at JSF) - tumatakbo sa isang lalagyan ng web at tumugon sa mga kahilingan ng HTTP mula sa mga web client. Sinusuportahan din ng mga Servlet ang SOAP at RESTful na mga endpoint ng serbisyo sa web.

4. Ang mga enterprise application (built with Enterprise Java Beans, Java Message Service, Java Transaction API, Asynchronous Calls, Time Services) ay tumatakbo sa isang EJB container. Pinangangasiwaan ng mga EJB na pinamamahalaan ng container ang transactional business logic. Maa-access ang mga ito sa lokal man o malayuan sa pamamagitan ng RMI (o HTTP para sa SOAP at RESTful na mga serbisyo sa web).

Ang diagram sa ibaba ay nagpapakita ng tipikal na Java EE application architecture:

Mga teknolohiya

Kaya, inayos namin ang arkitektura. Ang pangkalahatang istraktura ay dapat na malinaw. Sa proseso ng paglalarawan ng mga bahagi ng arkitektura, hinawakan namin ang ilang mga teknolohiya ng Java EE tulad ng EJB, JSP, atbp. Tingnan natin ang mga ito nang mas malapitan. Ipinapakita ng talahanayan sa ibaba ang mga teknolohiyang pangunahing ginagamit sa antas ng kliyente: Ipinapakita ng talahanayan sa ibaba ang mga teknolohiyang ginagamit sa antas ng lohika ng negosyo: Ipinapakita ng talahanayan sa ibaba ang mga teknolohiyang ginagamit sa layer ng pag-access ng data:

Java EE kumpara sa Spring

Ang Spring Framework ay itinuturing na isang katunggali sa Java EE. Kung titingnan mo ang pag-unlad ng dalawang platform na ito, isang kawili-wiling larawan ang lalabas. Ang mga unang bersyon ng Java EE ay nilikha kasama ng IBM. Ang mga ito ay naging cool, ngunit clumsy, mabigat, at hindi maginhawang gamitin. Nahirapan ang mga developer dahil sa pangangailangang magpanatili ng malaking bilang ng mga configuration file at iba pang dahilan na nagpapalubha sa pag-unlad. Kasabay nito, ipinanganak ang Spring IoC. Isa itong maliit, maganda at madaling gamitin na library. Gumamit din ito ng configuration file, ngunit hindi tulad ng Java EE, isa lang. Ang pagiging simple ng Spring ay humantong sa katotohanan na halos lahat ay nagsimulang gumamit ng balangkas na ito sa kanilang mga proyekto. At pagkatapos ay nagsimula ang Spring at Java EE sa kanilang landas patungo sa parehong bagay, ngunit mula sa magkaibang dulo. Ang Pivotal Software, ang developer ng Spring, ay nagsimulang maglabas ng bawat proyekto upang masakop ang lahat ng posible at imposibleng pangangailangan ng mga developer ng Java. Unti-unti, ang dating tinatawag na Spring ay unang naging isa sa mga proyekto, at pagkatapos ay ganap na pinagsama sa ilang iba pang mga proyekto sa Spring Core. Ang lahat ng ito ay humantong sa hindi maiiwasang komplikasyon ng Spring kumpara sa kung ano ito ay orihinal. Sa paglipas ng panahon, naging napakahirap na subaybayan ang buong magkabuhul-buhol na mga dependency sa Spring, at ang pangangailangan ay bumangon para sa isang hiwalay na aklatan na maglo-load at magpapatakbo ng lahat ng bagay mismo (ngayon ang minamahal na Spring Boot ay nagsinok sa isang lugar). Sa lahat ng oras na ito, ang JCP ay nagtatrabaho sa isang bagay - upang makamit ang maximum na pagpapasimple ng lahat ng bagay na posible sa loob ng Java EE. Bilang resulta, sa isang modernong EJB, upang ilarawan ang isang bean, sapat na upang tukuyin ang isang anotasyon sa itaas ng klase, na nagbibigay ng access sa developer sa buong kapangyarihan ng teknolohiya ng Enterprise Java Beans. At ang mga katulad na pagpapasimple ay nakaapekto sa bawat detalye sa loob ng Java EE. Bilang resulta, ang Spring at Java EE ay halos magkaparehas sa mga tuntunin ng functionality. Ang ilang mga bagay ay mas mahusay, ang ilang mga bagay ay mas masahol pa, ngunit kung titingnan mo sa buong mundo, walang malaking pagkakaiba. Ganoon din sa pagiging kumplikado ng trabaho. Parehong ang Spring at Java EE ay mahusay na mga tool. Marahil ang pinakamahusay na kasalukuyang umiiral para sa pagbuo ng mga enterprise network application sa Java. Gayunpaman, ang Java EE sa pangkalahatan ay maaaring gumana lamang sa loob ng Enterprise Application Server (Tomcat ay hindi isa), at ang isang application sa Spring stack ay maaaring tumakbo sa anumang bagay (sa parehong Tomcat), at kahit na walang server sa lahat (dahil ito ay tatakbo sa loob nito nang nakapag-iisa). Ginagawa nitong mainam na tool ang Spring para sa pagbuo ng maliliit na front-end na GUI application o mga arkitektura ng microservice. Ngunit ang pag-aalis ng pag-asa sa mga server ng application ay may negatibong epekto sa scalability ng mga application ng Spring. At ang Java EE ay angkop para sa pagpapatupad ng isang scalable monolithic cluster application. Ang mga developer na pamilyar sa Spring Framework ay kasalukuyang higit na hinihiling sa labor market. Ganito ang nangyari sa kasaysayan: sa panahon na ang Java EE ay sobrang kumplikado, ang Spring ay "nakakuha ng isang customer base." Gayunpaman, walang malinaw na sagot sa tanong kung ano ang matututunan sa Spring o Java EE. Ang isang baguhan ay maaaring bigyan ng sumusunod na payo. Kilalanin (kahit mababaw) sa parehong mga platform. Sumulat ng isang maliit na proyekto sa bahay sa parehong Java EE at Spring. At pagkatapos ay bungkalin nang mas malalim ang balangkas na kakailanganin sa trabaho. Bilang resulta, hindi magiging mahirap ang paglipat sa pagitan ng Spring at Java EE.

Mga resulta

Ang isang malakihang paksa, siyempre, ay hindi maaaring saklawin sa isang artikulo! Pagkatapos ng isang toneladang bagong termino, malamang na gusto mong "ilapat" ang kaalamang ito sa isang halimbawa sa totoong buhay. Samakatuwid, magpapatuloy kami sa pag-aaral ng Java EE: makakahanap ka ng mga praktikal na aralin sa pag-set up ng isang lokal na kapaligiran para sa pagbuo ng Java EE sa susunod na artikulo.