Eclipse Update irányelv-felügyelet

Az Eclipse Update lehetőséget ad arra, hogy a felhasználók frissítéseket keressenek a jelenleg telepített szolgáltatásokhoz. Az Update minden telepített szolgáltatásnál a beágyazott URL-t használja a távoli kiszolgálóhoz csatlakozásra és az új verziók keresésére. Ha vannak frissítések, az Eclipse lehetővé teszi, hogy a felhasználók megkezdjék a telepítési eljárást. A letöltés, a telepítés és a platform újraindítása után az új szolgáltatásverzió készen áll a használatra.

Azoknál a cégeknél, ahol sok felhasználó dolgozik ugyanazzal az Eclipse-re épülő termékkel (jellemzően egy kereskedelmivel), számos probléma származhat ebből a modellből:

  1. A nagyon nagy termékek (pl. több mint 500 bedolgozó) frissítései is nagyok. Az informatikai támogatási csoportok lehet, hogy nem lelkesednek azért az ötletért, hogy fejlesztők százai egyedileg töltsenek le 500 megabyte-os frissítéseket az egyes gépekre. A sávszélességre mért csapás mellett az ilyen nagy letöltési kérésekben hibák is adódhatnak, ami ismételt kísérleteket eredményez és növeli a fejlesztők állásidejét.
  2. Bizonyos cégek kifejezetten nem akarják, hogy a fejlesztők frissítéseket töltsenek le az internetről. Lehet például, hogy rendelkeznek egy helyi támogatási csoporttal, amely még nem áll készen a szolgáltató webhelyén megtalálható termékverzióval kapcsolatos kérések kezelésére. Lehet, hogy a belsőleg jóváhagyott listára szeretnék korlátozni a frissítéseket és javításokat. Ideális esetben ezt úgy is tehetik, hogy 'proxy' frissítési helyeket állítanak fel a helyi hálózaton (a tűzfal mögött).
  3. Ha a frissítések be vannak állítva a fent említett proxy helyeken, az adminisztrátoroknak valamilyen módon a felhasználók tudomására kell hozniuk, hogy a frissítések elérhetők.

2. Frissítési stratégia, a megmentő

2.1 Támogatás helyi (proxy) frissítési helyek létrehozásához

A termék adminisztrátora számára az első lépés egy helyi Eclipse frissítési hely felállítása lehet egy, a cég helyi hálózatára csatlakozó kiszolgálón (a tűzfal mögött). A frissítési hely a termék internetes frissítési helyének részhalmaza lehet, mivel csak az azokkal a frissítésekkel kapcsolatos szolgáltatásokat és bedolgozókat fogja tartalmazni, amelyeket a cég pillanatnyilag alkalmazni szeretne. Technikailag ez a hely egy szabályos Eclipse frissítési hely lesz site.xml fájllal, szolgáltatásokkal és bedolgozóarchívumokkal.

Az adminisztrátorok kétféle módon hozhatják létre a helyet:

  1. A terméktámogatási csoportok készíthetnek egy tömörített fájlt a frissítési helyről, hogy könnyedén rendelkezésre álljon ebben az adott esetben. Az adminisztrátoroknak csak le kell tölteniük a tömörített fájlt a terméktámogatási weboldalról a választott eszköz használatával, és kicsomagolni azt a helyi kiszolgálón. Ez a megközelítés rendkívül hasznos a nagyon nagy tömörített fájlok esetén, amelyekhez modern, újraindítható letöltéskezelőkre van szükség (ezek ott tudják folytatni a letöltést, ahol kapcsolati problémák esetén leszakadtak).
  2. Az Eclipse Update eszközt kínál távoli frissítési helyek teljes tükrözésére is, vagy lehetőséget ad az adminisztrátoroknak, hogy kiválasszák a letöltendő frissítéseket és javításokat. Ez a tükrözési képesség teljesen automatizálható, és nagymértékben egyszerűsítheti az adminisztrátorok feladatát, de az Update hálózati kapcsolat támogatására támaszkodik.

2.2 Általános frissítési irányelv-felügyelet

Mivel a szolgáltatások a leírófájlba beágyazott frissítési hely URL-címmel rendelkeznek, nem tudhatnak az adminisztrátor által beállított helyi frissítési helyekről. Ezért rendkívül fontos az átirányítási lehetőség biztosítása. Ez, és más frissítési irányelv-beállítások is megadhatók egy Eclipse terméknek egy firssítési irányelv-fájl létrehozásával és az Update beállításával ennek használatára a keresés során.

A kérdésben XML-formátumot használ, és bármilyen neve lehet. A fájlt a Beállítások > Telepítés/frissítés párbeszédablak Frissítési házirend mezejeben lehet beállítani. A szövegmező alapértelmezésben üres: a felhasználók megadhatják a frissítési irányelv fájl URL-címét. A fájlt a helyi adminisztrátor kezeli, és meg van osztva minden terméktelepítés számára. A megosztás kétféle módon érhető el:

Az irányelvfájlnak meg kell felelnie a következő DTD-nek:

<?xml encoding="ISO-8859-2"?>

<!ELEMENT update-policy (url-map)*>
<!ATTLIST update-policy
>

<!ELEMENT url-map EMPTY>
	pattern	CDATA #KÖTELEZŐ
	url	CDATA #KÖTELEZŐ
>

url-map

Ez az elem a szolgáltatásleírásokba beágyazott URL-címek felülírására szolgál. Új frissítések keresésekor az Eclipse keresés funkciója ellenőrzi a frissítési irányelveket (ha vannak ilyenek), és megnézi, hogy a megfelelő szolgáltatás-előtagok url-map beállítása meg van-e adva. Ha egyezést talál, a megadott URL-t fogja használni a beágyazott helyett. Ezen a módon az adminisztrátorok beállíthatják az Eclipse termékeket arra, hogy a helyi kiszolgálón, a tűzfal mögött keressék a frissítéseket. Eközben az Eclipse által telepített harmadik féltől származó szolgáltatások továbbra is az alapértelmezett mechanizmus használatával kerülnek frissítésre, mivel nem találnak egyezést az irányelvekben.

Több url-map elem is lehet a fájlban. A szolgáltatás-előtagokat ki lehet választani úgy, hogy többé-kevésbé jellemzőek legyenek. Minden Eclipse frissítés átirányítására például a minta attribútum "org.eclipse" lehet. Ugyanígy lehetséges az is, hogy egy teljes szolgáltatás-azonosítót használjunk mintaként, ha szolgáltatásonként van szükség átirányításra.

A fájlban található minták fokozatosan is kiválaszthatók, a potenciális egyezések szűkítésére. Ez azt eredményezheti, hogy több egyezés lehet egyetlen szolgáltatáshoz. Ebben az esetben a leghosszabb mintával való egyezés kerül használatra. Például:

<?xml version="1.0" encoding="UTF-8"?>
<update-policy>
	<url-map pattern="org.eclipse" url="URL1"/>
	<url-map pattern="org.eclipse.jdt" url="URL2"/>
</update-policy>

A fenti esetben minden Eclipse szolgáltatás az URL1 forrásból kerül frissítésre, kivéve az org.eclipse.jdt-t, amely az URL2-t fogja használni.

A frissítési irányelv-fájlok nem tartalmaznak lefordítandó karaktersorozatokat, következésképpen nincs szükség speciális NL-kezelésre sem. Általánosságban a fájloknak UTF-8 kódolást kell használniuk.

2.3 Frissítések automatikus felkutatása

Az automatikus frissítések lehetővé teszik, hogy az Eclipse egy megadott ütemterv szerint lefuttasson egy frissítéskeresést: minden indításkor (ez az alapértelmezett), naponta egyszer, hetente egyszer stb.).

3. Összefoglalás

A megoldást alkotó lépések teljes sorozata:

  1. Az adminisztrátor elkülönít egy kiszolgálót a céges helyi hálózaton a helyi termékfrissítések kiszolgálására. Ez kezdetben nem tartalmaz frissítési helyeket. A gépen futnia kell egy HTTP-kiszolgálónak.
  2. Az adminisztrátor beállít egy frissítési irányelv-fájlt a kiszolgálón, és tájékoztatja az összes felhasználót arról, hogyan állíthatják be a frissítési irányelv beállításokat a megadott URL-re.
  3. Amint a termék szolgáltatója frissítéseket és javításokat helyez el a saját frissítési helyein, az adminisztrátor letölti a támogatott frissítéseket a helyi kiszolgálóra.
  4. Az automatikus frissítés végrehajtódik az előirányzott gyakorisággal; ekkor az ügyfelek termékei felveszik a helyi frissítéseket és értesítik a felhasználót.
  5. A felhasználó kiválasztja a felfedezett frissítés telepítését.