Java FTP -asiakaskirjastot tarkistettiin

Kuvitellaan tilanne, jossa haluamme kirjoittaa puhtaan Java-sovelluksen, jonka on ladattava tiedostot FTP-palvelinta käyttävältä etätietokoneelta. Haluamme myös suodattaa lataukset etätiedostotietojen, kuten nimen, päivämäärän tai koon, perusteella.

Vaikka on mahdollista ja ehkä hauskaa kirjoittaa FTP: n protokollankäsittelijä tyhjästä, se on myös vaikeaa, pitkää ja mahdollisesti riskialtista. Koska emme mieluummin viettää aikaa, vaivaa tai rahaa itse käsittelijän kirjoittamiseen, mieluummin käytämme sen sijaan uudelleen olemassa olevaa ohjelmistokomponenttia. Ja runsaasti kirjastoja on saatavilla Internetissä. FTP-asiakaskirjaston avulla tiedoston lataaminen voidaan kirjoittaa Java-muodossa yksinkertaisesti:

FTPClient ftpClient = uusi FTPClient (); ftpClient.connect ("ftp.foo.com", "user01", "pass1234"); ftpClient.download ("C: \ Temp \", "README.txt"); // Lopulta muut toiminnot täällä ... ftpClient.disconnect ();

Tarpeitamme vastaavan laadukkaan Java FTP -asiakirjaston etsiminen ei ole niin yksinkertaista kuin miltä se näyttää; se voi olla melko tuskallista. Java FTP -asiakaskirjaston löytäminen vie jonkin aikaa. Minkä sitten valitsemme, kun olemme löytäneet kaikki olemassa olevat kirjastot? Jokainen kirjasto vastaa erilaisiin tarpeisiin. Kirjastojen laatu on epätasainen ja niiden muotoilu eroaa toisistaan. Jokainen tarjoaa erilaiset ominaisuudet ja käyttää erityyppisiä ammattikielejä niiden kuvaamiseen.

Siksi FTP-asiakaskirjastojen arviointi ja vertailu voi osoittautua vaikeaksi ja hämmentäväksi. Olemassa olevien komponenttien uudelleenkäyttö on kiitettävä prosessi, mutta tässä tapauksessa aloittaminen voi olla masentavaa. Ja tämä on sääli: kun olet valinnut hyvän FTP-kirjaston, loppu on rutiinia.

Tämän artikkelin tarkoituksena on tehdä valintaprosessista lyhyt, helppo ja hyödyllinen. Luettelon ensin kaikki käytettävissä olevat FTP-asiakaskirjastot. Sitten määritän ja kuvaan luettelon asiaankuuluvista kriteereistä, joita kirjastojen tulisi käsitellä jollakin tavalla. Lopuksi esitän yleiskuvan matriisin, joka antaa nopean kuvan siitä, kuinka kirjastot pinoavat toisiaan vastaan. Kaikki nämä tiedot tarjoavat kaiken mitä tarvitsemme nopean, luotettavan ja pitkäaikaisen päätöksen tekemiseksi.

FTP-tuki JDK: ssa

FTP: n viiteeritelmä on Request for Comments: 959 (RFC959). Sun Microsystems tarjoaa RFC959-toteutuksen JDK: ssa, mutta se on sisäinen, dokumentoimaton eikä lähdettä ole. Vaikka RFC959 on varjossa, se on itse asiassa julkisen käyttöliittymän takaosa, joka toteuttaa RFC1738: n, URL-määrityksen, kuten kuvassa 1 on esitetty.

JDK: ssa on vakiona RFC1738: n toteutus. Se tekee kohtuullisen työn perus-FTP-siirtotoiminnoille. Se on julkinen ja dokumentoitu, ja lähdekoodi annetaan. Sen käyttämiseksi kirjoitamme seuraavat:

URL-osoite = uusi URL-osoite ("ftp: // käyttäjä01: [email protected]/README.txt; type = i"); URLConnection urlc = url.openConnection (); InputStream on = urlc.getInputStream (); // OutputStream-lataus os = urlc.getOutputStream (); // Ladata

JDK: n FTP-asiakastuki noudattaa tarkasti vakiosuositusta, mutta sillä on useita haittoja:

Se eroaa periaatteessa kolmannen osapuolen FTP-asiakaskirjastoista; nämä toteuttavat pikemminkin RFC959: n kuin RFC1738: n.
RFC959 on toteutettu useimmissa työpöydän FTP-asiakasohjelmissa. Monet Java-ohjelmoijat käyttävät näitä työkaluja muodostaakseen yhteyden FTP-palvelimiin. Maun mielestä nämä työkalut suosivat todennäköisesti RFC959: n kaltaisia kirjastoja.
URL ja URLConnection luokat avaavat vain virtoja viestintään. Sun-kirjasto ei tarjoa suoraa tukea raakojen FTP-palvelinvastausten jäsentämiseen käyttökelpoisemmiksi Java-objekteiksi, kuten Merkkijono, Tiedosto, RemoteFiletai Kalenteri. Joten meidän on kirjoitettava lisää koodia vain tietojen kirjoittamiseksi tiedostoon tai hakemistoluettelon hyödyntämiseksi.
Kuten RFC1738: n osiossa 3.2.5 "Optimointi" selitetään, FTP-URL-osoitteet edellyttävät, että (ohjaus) yhteys sulkeutuu jokaisen toiminnon jälkeen. Tämä on tuhlaavaa eikä tehokasta monien pienten tiedostojen siirtämiseen. Lisäksi erittäin rajoittavat FTP-palvelimet saattavat pitää tällaista tiedonsiirtoa pahana verkkohyökkäyksenä tai väärinkäytönä ja kieltää lisäpalvelun.
Lopuksi siinä ei ole useita hyödyllisiä ominaisuuksia.

Kaikista tai jostakin näistä syistä on suositeltavaa käyttää kolmannen osapuolen kirjastoa. Seuraavassa osassa luetellaan käytettävissä olevat kolmansien osapuolten vaihtoehdot.

Kirjastojen vertailu

Alla olevassa luettelossa hahmotellaan kirjastot, joita vertailen tässä artikkelissa. Ne kaikki noudattavat viitteellistä FTP-määritystä. Alla mainitsen palveluntarjoajan nimen ja kirjaston nimen (kursivoitu). Resurssit sisältävät linkit kunkin tuotteen verkkosivustolle. Kirjaston käytön aloittamiseksi mainitsen myös tärkeimmät FTP-asiakasluokat.

JScape, iNet-tehdas: com.jscape.inet.ftp.Ftp
/ n ohjelmisto, IP * toimii: ipworks.Ftp
Yritysten hajautetut tekniikat, Java FTP -asiakaskirjasto: com.enterprisedt.net.ftp.FTPClient
IBM alphaWorks, FTP Bean -sviitti: com.ibm.network.ftp.protocol.FTPProtocol
SourceForge, JFtp: net.sf.jftp.net.FtpConnection
Jakarta-projekti, Jakarta Commons / Net: org.apache.commons.net.ftp.FTPClient
JavaShop JNetPavut: jshop.jnet.FTPClient
Aurinko, JDK: sun.net.ftp.FtpClient
Florent Cueto, JavaFTP-sovellusliittymä: com.cqs.ftp.FTP
Bea Petrovicova, jFTP: cz.dhl.ftp.Ftp
Globus-projekti, Java CoG -sarja: org.globus.io.ftp.FTPClient

Huomautuksia:

Tämän kirjoituksen aikana IBM arvioi AlphaWorks FTP Bean Suite -sovelluksen soveltuvuutta verkkosivustolleen. Toistaiseksi lataus on suljettu kaikille käyttäjille.
Jakarta Commons / Net on drop-in korvike Savarese NetComponentsille, jota ei enää kehitetä.
JavaShop JNetBeans näyttää olevan hylätty. Tämän kirjoituksen aikaan sivusto on ollut offline-tilassa yli kuukauden, enkä ole koskaan saanut vastauksia tukipyyntöihini.

Kriteeri

Toistaiseksi olen esittänyt kontekstin ja luetellut käytettävissä olevat kirjastot. Nyt luetellaan asiaankuuluvat kriteerit, joiden perusteella kutakin kirjastoa arvioidaan. Luen kullekin kriteerille mahdolliset arvot sekä lyhenteen (in lihavoitu), jota käytetään lopullisessa vertailumatriisissa.

Tuotetuki

Kirjastot tarjoavat käyttäjille tukea tuotedokumentaation, koottujen Javadocs-tiedostojen, esimerkkikoodin ja esimerkkisovelluksen avulla, joka voi sisältää kommentteja ja selityksiä. Lisätukea voidaan tarjota käyttäjille foorumeiden, postituslistojen, yhteyshenkilön sähköpostiosoitteen tai online-virheenseurantajärjestelmän kautta. / n-ohjelmisto tarjoaa laajan tuen lisämaksusta.

Tukipalvelun ylläpitäjän motivaatio on tärkeä tekijä nopeassa tuessa. Tukipalvelun järjestelmänvalvojat voivat olla:

Vapaaehtoinen henkilö (Minä)
Vapaaehtoinen ryhmä (G)
Ammatillinen yksikkö, joka maksetaan tuen tarjoamisesta (P)

Lisenssi

Kaupallisissa hankkeissa tuotelisenssi on tärkeä asia, joka on otettava huomioon alusta alkaen. Jotkut kirjastot voidaan jakaa vapaasti kaupallisissa tuotteissa ja toiset eivät. Esimerkiksi GPL (GNU General Public License) on vahva, rajoittava lisenssi, kun taas Apache-ohjelmistolisenssi vaatii maininnan vain uudelleen jaelluissa tuotteissa.

Kaupalliset lisenssit rajoittavat kirjastoon ohjelmoitavien kehitystyöasemien määrää, mutta itse kirjaston jakelua ei ole rajoitettu.

Ei-kaupallisissa projekteissa lisenssi on enemmän filosofian asia; ilmainen tuote on tuntuva.

Lisenssit voivat olla:

Kaupallinen (C)
GPL (G)
Vapaa (F); Tarkista kuitenkin ilmainen käyttöoikeus rajoituksista

Jotkut kirjastopalvelujen tarjoajat tarjoavat vaihtoehtoisia, vähemmän rajoittavia lisenssejä pyynnöstä.

Lähdekoodi tarjottu

Suljettu, mustan laatikon ohjelmistokirjasto voi olla ärsyttävää. Lähdekoodin saaminen voi olla mukavampaa seuraavista syistä:

Kun testaat sovelluskoodin suoritusta, kirjastokoodilähteeseen siirtyminen voi auttaa sinua ymmärtämään kirjaston käyttäytymistä
Lähdekoodissa on hyödyllisiä kommentteja
Lähdekoodi voidaan nopeasti muokata vastaamaan erityistarpeita
Esimerkkilähdekoodi voi olla inspiroiva

Ikä

Kirjastoja on testattu, viritetty ja tuettu niiden ensimmäisestä julkisesta julkaisusta lähtien. Koska versionumerointi vaihtelee kirjastojen välillä, perustan tämän kriteerin aikaisimman julkisen julkaisun vuoteen.

Hakemistoluetteloiden tuki

Etätiedostojen tietojen (nimi, koko, päivämäärä) noutaminen palvelimelta on tärkeää useimmissa sovelluksissa. FTP-protokolla tarjoaa NLST komento noutaa vain tiedostonimet; NLST komento on nimenomaisesti suunniteltu hyödyntämään ohjelmia. LISTA komento tarjoaa enemmän tiedostotietoja; kuten RFC959 toteaa, "Koska tiedoston tiedot voivat vaihdella suuresti järjestelmittäin, näitä tietoja voi olla vaikea käyttää automaattisesti ohjelmassa, mutta ne voivat olla melko hyödyllisiä ihmisille." Mikään muu vakiomenetelmä ei nouta tiedostotietoja; siksi asiakaskirjastot yrittävät hyödyntää LISTA vastaus. Mutta tämä ei ole helppo tehtävä: koska ohjelmalle ei ole saatavana arvovaltaista suositusta LISTA vastausmuoto, FTP-palvelimet ovat ottaneet käyttöön erilaisia muotoja:

Unix-tyyli: drwxr-xr-x 1 user01 ftp 512 29. tammikuuta 23:32 prog
Vaihtoehtoinen Unix-tyyli: drwxr-xr-x 1 user01 ftp 512 29. tammikuuta 1997 prog
Vaihtoehtoinen Unix-tyyli: drwxr-xr-x 1 1 1512 29. tammikuuta 23:32 prog
Symbolinen linkki Unix-tyyliin: lrwxr-xr-x 1 user01 ftp 512 29. tammikuuta 23:32 prog -> prog2000
Outo Unix-tyyli (käyttäjän ja ryhmän välillä ei ole tilaa): drwxr-xr-x 1 usernameftp 512 29. tammikuuta 23:32 prog
MS-DOS-tyyli: 1.-29-97 23.32 prog
Macintosh-tyyli: drwxr-xr-x-kansio 0 tammi 29 23:32 prog
OS / 2-tyyli: 0 SUORA 01-29-97 23:32 PROG

Unix-tyyli, sitten MS-DOS-tyyli, ovat yleisimpiä muotoja.

Java FTP -asiakirjastot yrittävät ymmärtää ja tunnistaa automaattisesti mahdollisimman monta muotoa. Lisäksi ne tarjoavat erilaisia vaihtoehtoja odottamattomien muotovastausten käsittelemiseksi:

Lisämenetelmä, joka palauttaa raakan FTP-vastauksen yhtenä merkkijonona (S)
Lisämenetelmä palauttaa kokoelma raakajonoja, yksi merkkijono riviä / tiedostoa kohden (C)
Kehys, joka tukee liitettäviä jäsentimiä (P)

Suurin osa kirjastoista jäsennetään LISTA vastaukset ja jäsennä tiedostotiedot Java-kohteiksi. Esimerkiksi JScape iNet Factoryn kanssa seuraava koodi hakee ja hyödyntää hakemistoluettelossa vastaanotettuja tiedostotietoja:

java.util.Enumeration files = ftpClient.getDirListing (); while (tiedostot.hasMoreElements ()) {FtpFile ftpFile = (FtpFile) tiedostot.nextElement (); System.out.println (ftpFile.getFilename ()); System.out.println (ftpFile.getFilesize ()); // jne. muita hyödyllisiä menetelmiä on kuvattu Javadocissa}

Kohdassa "Ratkaisut jäljellä oleviin ongelmiin" tarkastellaan edelleen hakemistoluetteloita.

Aikaleiman haku

Monissa tapauksissa olemme kiinnostuneita etätiedoston uusimmasta muokkauksen aikaleimasta. Valitettavasti mikään RFC ei esitä vakio-FTP-komentoa näiden tietojen noutamiseksi. Kaksi tosiasiallista menetelmää on olemassa:

Nouda nämä tiedot LISTA vastaus jäsentämällä palvelimen vastausta. Valitettavasti, kuten edellisessä osassa opit, LISTA vastaus vaihtelee FTP-palvelimien välillä, ja aikaleimatiedot ovat joskus puutteellisia. Unix-muodossa epätarkkuus tapahtuu, kun etätiedosto on yli vuoden vanha: vain päivämäärä ja vuosi, mutta ei tunteja tai minuutteja.
Käytä standardista poikkeavaa MDTM -komento, joka hakee nimenomaan etätiedoston viimeisen muokkauksen aikaleiman. Valitettavasti kaikki FTP-palvelimet eivät toteuta tätä komentoa.

Monimutkainen vaihtoehto MDTM komentotuki on lähettää raaka MDTM komento ja jäsennä vastaus. Useimmat kirjastot tarjoavat menetelmän raakan FTP-komennon lähettämiseen, esimerkiksi:

Merkkijono timeStampString = ftpClient.command ("MDTM README.txt");

Toinen mahdollinen huolenaihe on, että FTP-palvelimet palauttavat aikatiedot GMT: nä (Greenwichin aika). Jos palvelimen aikavyöhyke tunnetaan FTP-viestinnän lisäksi, java.util.TimeZone.getOffset () menetelmä voi auttaa säätämään päivämäärää aikavyöhykkeiden välillä. Katso JDK: n dokumentaatiosta lisätietoja tästä menetelmästä.

Luvussa "Ratkaisut jäljellä oleviin ongelmiin" tarkastellaan edelleen tiedoston aikaleiman hakua.

Palomuurit

Palomuuri sijoitetaan yleensä yksityisen yritysverkon ja julkisen verkon, kuten Internetin, väliin. Pääsy hallitaan yksityisestä verkosta julkiseen verkkoon, mutta pääsy kielletään julkisesta verkosta yksityiseen verkkoon.

Sukat on yleisesti saatavilla oleva protokolla, joka on kehitetty käytettäväksi palomuurin yhdyskäytävänä Internetille. JDK tukee Socks 4- ja Socks 5 -välityspalvelimia, joita jotkut kirjastot voivat hallita. Vaihtoehtoisesti JVM-komentorivi voi asettaa Socks-välityspalvelimen parametrit: java -DsocksProxyPort = 1080 -DsocksProxyHost = sukat.foo.com -Djava.net.socks.username = käyttäjä01 -Djava.net.socks.password = pass1234 ...

Toinen yleinen vaihtoehto Socks-välityspalvelintukeen on "socksifioida" asiakkaan koneen alla oleva TCP / IP-kerros. Hummingbirdin kaltainen tuote voi tehdä sen.

JDK tukee myös HTTP-tunneleita. Nämä yleiset välityspalvelimet eivät salli FTP-latauksia. / n -ohjelmiston IP * Works -toiminnon avulla voit asettaa HTTP-tunnelin parametrit.

Suurin osa kirjastoista tukee sekä aktiivisia että passiivisia yhteyksiä: passiivinen yhteys on hyödyllinen, kun asiakas on palomuurin takana, joka estää saapuvia yhteyksiä korkeampiin portteihin. RFC1579 käsittelee tätä palomuuriystävällistä toimintoa tarkemmin. Joidenkin tuotteiden dokumentaatioissa viitataan aktiivisiin ja passiivisiin yhteyksiin PORTTI ja PASV komentoja.

Rinnakkainen siirto

Kun työpöytäsovelluksessa siirto alkaa pääkierteessä, kaikki jäätyy. Jotkut kirjastot palvelevat tapahtumasilmukkaa automaattisesti rinnakkaissiirtoihin erillisissä säikeissä, joten meidän ei tarvitse luoda ja hallita omia ketjuja.

JavaBean-määritysten tuki

Jotkut kirjastot toteuttavat JavaBean-määrityksen. JavaBean-yhteensopivuus sallii visuaalisen ohjelmoinnin, joka on esillä tärkeimmissä Java IDE: issä.