1. Oracle megvette a Sun-t, így a Java-t is
2. James Gosling a Java szülőatyja otthagyta Sun-t (vagyis már az Oracle-t)
3. Oracle perli a Google-t az Android-os Java miatt (hogy pontosan miért, az számomra elég zavaros)
4. Apple bejelentette, hogy a Mac-es Java-t nem fejlesztik tovább
5. És egyáltalán kevesebbet hallani a Java-ról

Ezt a témát jártam körbe kicsit részletesebben.

1. Ezzel talán az a gond, hogy az Oracle miután megvette a Bea-t, már akkor is gondban volt, hogy mit csináljon azokkal a termékeivel, amikből kettő lett neki, és ez helyzet csak romlott a Sun megvételével, ahol megint csak hasonló termékek voltak. Mintha maga az Oracle sem tudná, hogy például, akkor most Weblogic, vagy Glassfish, vagy IAS. (Na jó, az IAS, csak vicc volt )

• Tavaly az Oracle fejlesztői konferencián az előadónak csak záporoztak a kérdések, hogy akkor most IAS-t kell-e használni, vagy Weblogic-ot. A vicc az egészben az volt, hogy pont azokban a napokban látott napvilágot az Sun felvásárlásának a híre, és valaki még a GlassFish-re is rákérdezett, persze az előadó csak az IAS és Weblogic témára tudott mit mondani, mégpedig, hogy Weblogic-ot érdemes használni, az IAS már csak egy ideig lesz támogatva.
• A nagy cégekre általában azt mondják, hogy maga az ördög. Ez most sincs másként, mivel az Oracle, így már egy nagyon-nagyon nagy cég lett.
• Az ilyen cégek lépéseit mindenki nagyon kritikusan figyeli. Legyen szó akár a Google-ről, az Apple-ről, vagy éppen az Oracle-ről.
• Az Oracle adatbázis licenszekről tudjuk, hogy elég drágák, és nem lapul mindenkinek a fiókjában pár darab, így ha lehet, minden informatikai vezető kétszer is meggondolja, hogy kell-e neki Oracle, vagy használjon valami mást, mondjuk MySQL-t.
• Mivel még korábban a Sun megvette a MySQL-t, ami így megint csak az Oracle kezében landolt, a lehetőségek tovább szűkültek, mivel  az Oracle ebből is jó kis pénzt szeretne behúzni.
• Elég csak megnézni a jelenlegi MySQL árakat: http://mysql.com/products/
• Egy Clusteres MySQL kb. évi 2 millió forint.
• Hogy az emberek mennyire ugranak mindenre amit az Oracle változtat, mutatja a napokban felkapott hír, miszerint a MySQL Classic Edition már nem tartalmazza az InnoDB storage engine-t: http://www.infoq.com/news/2010/11/MySQL-Classic-InnoDB
• Már több helyen olvastam, hogy ha új projektet indítasz, akkor inkább PostgreSQL-t használj, vagy valamilyen NoSQL terméket.

2. Hogy James Gosling (http://en.wikipedia.org/wiki/James_Gosling) otthagyta az Oracle-t, inkább csak szimbolikus jelentőséggel bír, de mindenképpen érdekes dolog. A Java fejlesztők körében (persze csak akik egyáltalán tudtak róla), így nem lett sokkal népszerűbb az Oracle.

3. A Google felhasznált valamilyen kódrészleteket a Java forrásából. Ezért perel az Oracle: http://www.infoq.com/news/2010/08/oracle_sues_google

Az ügy egyébként elég bonyolultnak tűnik, viszont egy érdekes felvetést olvastam valahol: az egész azért van, hogy a Google megvegye a Java-t az Oracle-től, mivel az nem tud vele mit kezdeni, a Google pedig az Android miatt picit felkavarná a Java körüli állóvizet. Nem tudom mennyi igaz belőle, mindenesetre érdekes.

4. Mivel egyre több Java fejlesztő használ Mac-et, így sokaknak fájó az a bejelentés, hogy az új Mac OS X Lion operációs rendszerben, már nem lesz alapból megtalálható a Java. Mivel az Apple fejleszti a Mac-es Java-t, és gondolom az Oracle megint csak kicsit pénzéhesen sokat kért, amire Steve Jobs beintett.

5. Egyre kevesebbet lehet hallani a Java-ról. Régebben, alig bírtam a Google Reader-em Java-s híreivel, manapság jó ha kéthetente van egy-egy érdekes hír. Mintha már mindenki mindent leírt volna amit tudott a Java-ról. Nincs miről írni, mert nem történik semmi Érdemes megnézni, hogy például az O’Reilly kiadónál nincs előkészületben egyetlen Java-s könyv se: http://oreilly.com/java/index.html

Ami még érdekes, hogy maga a Java nyelv és a körülötte lévő technológiák jóval bonyolultabbak, mint kellene.

Ha valaki manapság egy átlag Java-s web-es projektbe belecsöppen, akkor körülbelül a következő dolgokkal találkozhat, amikről tudnia kell:

• Java
• Spring
• Hibernate
• Struts2
• Maven

Az előbb felsorolt technológiák mindegyikéről külön könyvek jelentek meg, mindegyik technológia megtanulása hónapokba telik.

Betanulási idő, és legtöbbször sajnos fejlesztési idő szempontjából a PHP, Python vagy akár a Ruby, még mindig sokkal jobb választásnak tűnik, mint a Java (leszámítva a nagyvállalati környezetet).

Bruce Tate könyve elég érdekesen írja le ezt az egész folyamatot, igaz ő a Ruby szempontjából közelíti meg a dolgot, de próbál objektív maradni: http://pragprog.com/titles/fr_j2r/from-java-to-ruby

Azt mondja, hogy a feladatok nagy részére sokkal ésszerűbb mást használni, esetében Ruby-t, mind Java-t.

Most, hogy ezeket így leírtam, azon gondolkodom, hogy mindezt csak önigazolásként gyűjtöttem-e össze. Azért, mert nem látom a jövőmet a Java-ban.

Nem tudom.

Az Internet tele van a problémával, de teljes egészében leírt megoldást ritkán találni. Általában utalások vannak rá, hogy tároljunk ID-t a Tag mezőben, vagy írjuk át az Adapter-t, de mik is ezek az utalások tulajdonképpen?

A feladat amit kitaláltam egy olyan ListView megjelenítés, ami a SimpleAdaptert-t használja adatforrásnak, így a layout betölthető XML-ből egyszrűen. A layout tartalmaz egy gombot, amit megnyomva az Activity onClick metódusa hívódik meg. A probléma itt következik: az onClick az onItemClick-el ellentétben nem kapja meg melyik soron kattintottunk. Valahonnan pedig illene tudni, hiszen nem minden soron ugyanazt szeretnénk végrehajtani.

Az ötelt a fent amlített netes leírások alapján adja magát, tároljuk le az onClick-et meghívó View Tag-jében (View.setTag(Object o)) a szükséges azonosítót, így az onClick-ben a paraméterként megkapott View-tól le tudjuk kérdezni.

Minden ListView a lista elemeit egy Adapter osztálytól kapja (ListView.setAdapter()) a getView() metóduson keresztül. Az adapter kis átírásával megoldható, hogy a lista elemeibe bekerüljön a az Id a megfelelő Tag property-be, amikor a ListView meghívja a getView()-t. Leszármaztattam hát a SimpleAdaptert-t:

public class ClickableButtonListAdapter extends SimpleAdapter {	

	private static final String HASHMAP_ID = "_id";

	public ClickableButtonListAdapter(Context context,
			List<? extends Map<String, ?>> data, int resource, String[] from,
			int[] to) {
		super(context, data, resource, from, to);

	}

	@SuppressWarnings("unchecked")
	@Override
	public View getView(int position, View convertView, ViewGroup parent) {
		View view = super.getView(position, convertView, parent);
		setViewTag(view, ((HashMap<String,String>) getItem(position)).get(HASHMAP_ID) );
		return view;
	}

	private void setViewTag(View view, Object tag) {
		view.setTag(tag);
		if (view instanceof ViewGroup) {
			for (int i=0; i < ((ViewGroup) view).getChildCount(); i++) {
				setViewTag(((ViewGroup) view).getChildAt(i), tag);
			}
		}
	}
}

A példában a lista elemei HashMap-ek, így ebből szedem ki az Id-t. A HahMap-ben az Id mező az “_id” elemben van, így ezt keresem ki, és rakom a Tag-be. A setViewTag() rekurzív metódus végigmegy az összes megjelenítendő View elemen és beállítja a Tag-et, így bármelyikre definiálhatjuk majd az onClick-et, mindig megkapjuk a Tag-ben a kiválasztott sor Id-ját.

Az Activity-ben az onClick() igen egyszerű:

public void onClick(View v) {
         Toast.makeText(this, "onClick id: " + v.getTag(), Toast.LENGTH_SHORT).show();
}

Nem mondom, hogy szép megoldás, de használható. Jobban tetszene, ha az Android megfelelően támogatná az egyedi ListView létrehozását esetleg azzal, hogy az onItemClick meghívódna, és eldönthetném, hogy mit akarok kezdeni az eseménnyel.

A lista természetesen legyen a tapifonokon már megszokott szépen gördíthető lista, a beviteli képernyő standard beviteli mezőkből álljon össze. Egy ilyen alkalmazás leírását a Developer portál elég jól leírja a Guideokban erre nem térek most ki. Ami szerintem egy kicsit elbonyolított, és nem épp lényegre törő rész ebben az útmutatóban az az adatok tárolása, ezen belül is az Androidba beépített SQLite adatbázis kezelő leírása. Ezt egy külön részben tovább boncolgatja a Notepad tutorial, de itt sajnos már belekeverik a Content Provider-eket is, így nem kapunk kellő instrukciót, hogyan is kellene használni az adatbázist.

A neten található leírások általában azt a módszert erőltetik, hogy a Cursor objektumon végig iterálva, vagy azt felhasználva a ListView objektumhoz a SimpleCursorAdatpter segítségével kezeljük mi az adatbázis kapcsolatot, a kurzort és az ezzel járó minden nyűgös dolgot. Ez nekem nem igazán tetszett, hiszen a Java világában már jópár éve létezik az ORM technika, amit általában egy J2EE alkalmazásban a Hibernate-el szoktunk használni (vagy JPA kinek mi tetszik). Így nincs szükség az adatbázis kapcsolat közvetlen kezelésér, kurzorok bezárogatására, adatbázis kivételek kezelésére. Bánatomra a Hibernate és a JPA nem tűnik jó megoldásnak Android alatt, mert a Hibernate nem kezeli megfelelően az SQLite-ot, és különben is miért lövünk ágyúval verébre?

Így arra gondoltam, ORM technikát nem felejtem el, de az itt felmerülő igényeknek megfelelően alakítom ki. Amit meghatároztam igényként:

• Lightweight megoldás, lehetőleg J2EE technológiák nélkül
• Az alkalmazás felületének és üzelti logikájának elkülönítése az adatbázistól
• Az adatbázis POJO objektumokon keresztül reprezentált

Nem tűnik nagy feladatnak, mégis sokat segít majd később. Elsőként kitaláltam egy alkalmazást. Mindig is szerettem a helyzetmeghatározással foglalkozni, tároljunk hát térkép pontokat adatbázisban.

A tábla szerkezete:

• id
• név
• szélesség
• hosszúság
• magasság

Az adatbázis műveletekhez létrehoztam egy SQLiteOpenHelper osztályt a developer portálon megfogalmazottak szerint:

public class DatabaseHelper extends SQLiteOpenHelper {

private static final String TAG = "DatabaseHelper";
private static final String DATABASE_NAME = "mydatabase.db";
private static final int DATABASE_VERSION = 1;

public DatabaseHelper(Context context) {
super(context, DATABASE_NAME, null, DATABASE_VERSION);
}

@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL("create table " + MapPoint.TABLE_NAME + " (" +
MapPoint._ID + " integer primary key," +
MapPoint.NAME + " text," +
MapPoint.LATITUDE + " real," +
MapPoint.LONGTITUDE + " real," +
MapPoint.ALTITUDE + " integer);");
}

@Override

public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {

Log.w(TAG, "Upgrading database from version " + oldVersion + " to "

+ newVersion + ", which will destroy all old data");

db.execSQL("DROP TABLE IF EXISTS mappoint");

onCreate(db);

}

}

Az osztályból látszik, hogy szükséges egy MapPoint nevű osztály. Az ORM-ben ez az osztály lesz a Model osztályom. Így néz ki:

public class MapPoint implements BaseColumns {

 public static String NAME = "name";
 public static String LATITUDE = "latitude";
 public static String LONGTITUDE = "longtitude";
 public static String ALTITUDE = "altitude";

 public static String TABLE_NAME = "mappoint";

 public static final String DEFAULT_SORT_ORDER = "name";

 private Long _id;
 private String name;
 private Double latitude;
 private Double longtitude;
 private Integer altitude;

 public Long get_id() {
 return _id;
 }
 public void set_id(Long _id) {
 this._id = _id;
 }
 public String getName() {
 return name;
 }
 public void setName(String name) {
 this.name = name;
 }
 public Double getLatitude() {
 return latitude;
 }
 public void setLatitude(Double latitude) {
 this.latitude = latitude;
 }
 public Double getLongtitude() {
 return longtitude;
 }
 public void setLongtitude(Double longtitude) {
 this.longtitude = longtitude;
 }
 public Integer getAltitude() {
 return altitude;
 }
 public void setAltitude(Integer altitude) {
 this.altitude = altitude;
 }
}

A Model osztály az Adroidos BaseColumn-ból származik, ami miatt egy _ID nevű mező van definiálva benne. Ez azért jó, mert ilyen mezője minden SQLite adatbázs táblának kell legyen, és így nem kell külön foglalkozni vele.
A Model osztályban nem biztos, hogy jó helyen vannak a statikus tulajdonságok, de egyelőre itt hagyom őket. Ezeket a Notepad tutorial a ContentProvider-be rakja, de nekünk ilyenünk nem lesz.

Végül a legfontosabb elem, a DAO osztály következik. Ez az osztály intézi el végül is az ORM-et, lekéri az adatbázisból a rekordokat, map-eli őket a Model osztályba, jelen esetben a MapPoint-be.

public class MapPointDao {

 private DatabaseHelper databaseHelper;

 public MapPointDao(Context context) {
 this.databaseHelper = new DatabaseHelper(context);
 }

 public int deleteById(long id) {
 return -1;
 }

 public long insert(MapPoint mapPoint) {
 ContentValues values = new ContentValues();
 values.put(MapPoint.NAME, mapPoint.getName());
 values.put(MapPoint.LATITUDE, mapPoint.getLatitude());
 values.put(MapPoint.LONGTITUDE, mapPoint.getLongtitude());
 values.put(MapPoint.ALTITUDE, mapPoint.getAltitude());

 SQLiteDatabase db = databaseHelper.getWritableDatabase();        

 long rowId = db.insertOrThrow(MapPoint.TABLE_NAME, MapPoint.NAME, values);
 db.close();

 if (rowId > 0) {
 return rowId;
 }

 throw new SQLException("Failed to insert row into ");
 }

 public List find(boolean distinct, String[]  columns,
 String  selection, String[]  selectionArgs, String  groupBy, String  having,
 String  orderBy, String  limit) {

 MapPoint mapP = new MapPoint();
 mapP.set_id(new Long(1));
 mapP.setAltitude(new Integer(2));
 mapP.setLongtitude(new Double(200));

 findByExample(mapP);

 if (TextUtils.isEmpty(orderBy)) {
 orderBy = MapPoint.DEFAULT_SORT_ORDER;
 }

 SQLiteDatabase db = databaseHelper.getReadableDatabase();
 Cursor c = db.query(distinct, MapPoint.TABLE_NAME, columns, selection, selectionArgs, groupBy, having,
 orderBy, limit);

 List list = new ArrayList();

 while (c.moveToNext()) {
 MapPoint mapPoint = new MapPoint();

 mapPoint.set_id(c.getLong(c.getColumnIndex(MapPoint._ID)));
 mapPoint.setName(c.getString(c.getColumnIndex(MapPoint.NAME)));
 mapPoint.setAltitude(c.getInt(c.getColumnIndex(MapPoint.ALTITUDE)));
 mapPoint.setLatitude(c.getDouble(c.getColumnIndex(MapPoint.LATITUDE)));
 mapPoint.setLongtitude(c.getDouble(c.getColumnIndex(MapPoint.LONGTITUDE)));

 list.add(mapPoint);
 }
 c.close();
 db.close(); 

 return list;
 }

 public List find(String  selection, String[]  selectionArgs) {
 return find(false,null,selection, selectionArgs, null, null, null, null);
 }

 public List findAll() {
 return find(null,null);
 }

 public int update(MapPoint mapPoint) {
 return -1;
 }

 public List<Map<String, String>> convertForAdapter(List<MapPoint> mapPointList) {
 List<Map<String, String>> list = new ArrayList<Map<String, String>>();
 for (int i=0; i<mapPointList.size(); i++) {
 Map<String, String> map = new HashMap<String, String>();

 map.put(MapPoint._ID, String.valueOf(mapPointList.get(i).get_id()));
 map.put(MapPoint.NAME, mapPointList.get(i).getName());
 map.put(MapPoint.LATITUDE, String.valueOf(mapPointList.get(i).getLatitude()));
 map.put(MapPoint.LONGTITUDE, String.valueOf(mapPointList.get(i).getLongtitude()));
 map.put(MapPoint.ALTITUDE, String.valueOf(mapPointList.get(i).getAltitude()));
  list.add(map);
 }
 return list;
 }
}

A DAO osztály-t nem fejeztem be, csak a find() és insert() metódusokat programoztam le, a delete() és update() mindeninek házi feladat . Az igazság az, hogy már most rájöttem ez nem egészen lesz így jó, mert a DAO osztályt így minden adatbázis táblára létre kell hoznom, minden mezőt egyesével map-elni kell. Nem szeretem az ilyet.

A DAO minden lekérdező metódusa a Model osztályt, vagy az ebből generált lista objektumot adja vissza lekérdezésnél. A módosító metódusok általában azt adják vissza, mennyi rekord módosult, az insert() pedig az új rekord id-t.

Lényeges kiemelni a DAO osztály convertForAdapter() metódusát, ami a SimpleAdatpter számára fog használható objektumstruktúrát előállítani. A find() által visszaadott List objektumból egy más struktúrájú listát állít elő, aminek az elemei már nem Model osztályok.

Végül lássuk, hogyan jelenik meg az Activity-ben a ListView. Az egész Activity-t nem másolom ide be, csak egyes részeit.

 private ListView listMapPoints;

 private List mapPointList;
 private MapPointDao mapPointDao;

 @Override
 protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);

 this.listMapPoints = (ListView) findViewById(R.id.listMapPoints);

 mapPointDao = new MapPointDao(this);                

 refreshList();
 }

 private void refreshList() {
 mapPointList = mapPointDao.findAll();

 int[] i = { R.id.textName, R.id.textDesc };
 String[] s = { "name", "_id" };

 this.listMapPoints.setAdapter(
 new SimpleAdapter(this, mapPointDao.convertForAdapter(mapPointList),
 R.layout.pointlistitem,s,i));
 }

Először az onCreate()-ben kikeressük a ListView objektumot a layout fájlból, majd létrehozzuk a DAO-t. A refreshList() metódusban programoztam le az lista elemek lekérdezését, mert így a refresh esetleg máshonnan is meghívható. Például egy dialógus ablakot definiálhatunk, ami törölni tud lista elemeket, és a törlés után jó ha a lista frissül.

Miért jó?

• Szerintem elég lightweight lett, nem igényel külső lib-et
• Az adatbázis kezelés a program egyetlen pontján van, nem kell az Activity-ben foglalkozni a kurzorral
• POJO osztályok
• Elkülönül az üzleti logika, a megjelenítés és a perzisztencia réteg (MVC)

Problémák

Természetesen ezzel nem állítottam elő egy Hibernate funkcionalitású ORM-et. A fentebbi programban elférnének a következő kiegészítések:

• A DAO egyes metódusainak paraméterezése történhetne Model osztállyal, így szűrőket lehetne megadni. Például findByExample(Model model) vagy deleteByExample(Model model)
• Jó lenne a DAO-t generikusra megírni, hogy ne kelljen mindig a mapeléseket megírni
• A DatabaseHelper az adatbázis szkriptet betölthetné külső fájlból vagy resource-ból
• A DAO-ban az adatbázis kapcsolatokat nem kellene mindig bezárni, egyszer kéne a konstruktorban létrehozni, és a nyitottat használni
• Jó lenne megoldani a foreign key-ek kezelését a Model-ben és a DAO-ban, hogy ne kelljen többször bekérdezni, ha például egy lista több táblából épül fel.
• Hibakezelés és logolás

Tovább fogom fejleszteni kis alkalmazásomat, így a fentebbi problémákra megoldást fogok kidolgozni, amit hasonló módon publikálni fogok.

Ma aláírtuk keretszerződésünket az ország legnagyobb, nemzetközi hírnevű  játékszoftver fejlesztő cégével, a Digital Reality-vel. A CodePlay java-s tudását szeretnék kihasználni projektjeikben, amikről egyelőre többet nem mondhatunk. Szigorúan titkos! Írok azonban néhány gondolatot az irodáról, ami azt hiszem elég mély benyomást tett ránk, talán összevethető a hírhedt Google irodákkal.A DR neve valószínűleg mindenki számára ismerősen cseng, aki játszott PC-vel. Azoknak talán még inkább, akik ezt a 90-es években űzték, mint én. Mindig is szívesen emlékszem vissza a PC-s játékok hőskorára, amikor barátaimmal még talán a 386SX előtt ülve játszottuk végig az első magyar fejlesztésű játékokat, a Reuniont és az Imperium Galactica-t. Ma meglepődve tapasztaltam, hogy a cég szépen kinőtte magát, nem egy kis hazai cégről beszélünk.

Ezt tükrözi a Kerepesi út szomszédságában levő iroda is, ahova belépve azonnal észrevehető volt egy olyan “feeling” amit eddig nem tapasztaltunk, csak a neten olvashattunk róla esetleg a Google irodáival kapcsolatban. Megérne egy külön képriportot az rengeteg dolog, amivel az itt dolgozók életét próbálják jobbá tenni. Az első szembeötlő a darts gép volt, ami még nem olyan egetverő újítás, más irodában is láttunk már (nálunk is van a falon, bár nem gép  ), de a ping-pong asztal és a meglehetősen nagy, mint később kiderült 120 fős előadó és vetítő terem mellett már nem lehet elmenni. Itt valamit másképp gondolnak, az biztos. Az iroda kinézete meglehetősen modern, hatalmas üveg falak választják el az irodát a folyosótól, amikre még írni is lehet tábla helyett. Vicces volt látni a felrajzolt kockákat és nyilakat az üveg felületekre, látszik, programozók ülnek az asztaloknál.
A tárgyalóban, ahol a megbeszélés zajlott, hatalmas plazmatévé, 5.1 hangrendszer és legalább három játékgép volt. Ez gondolom természetes lehet egy játékszoftver fejlesztő cégnél, de azért nekünk megakadt a szemünk rajta. Egy xbox még csak-csak elmegy, de ez már sok egy picit. Azt hiszem az i-re a pontot a megbeszélés közben tartott szünet tette fel, amikor is gyanútlanul kinéztünk az ablakon, és előbukkant a műfüves focipálya és kosárpálya, amihez még talán egy kisebb lelátó is volt. Azt hiszem kénytelen leszek a Rákóczi úton az udvart műfűvel borítani, hogy lépést tudjunk tartani.

Szeretem azt hinni, hogy a szoftverfejlesztés egy kicsit “más” munka. Talán a művészethez hasonló, kreatív tevékenység, amihez a szokványos értelemben vett “munkakörülmények” nem megfelelőek. Öröm volt látni, hogy mások is így gondolják. Ha nem is mindenki játszik mindennap az xbox-al, vagy van minden nap focimeccs, de a lehetőség adott, hogy kikapcsoljon az ember, és ezzel növelje teljesítményét és kreativitását a munkában.

Az eIsin rendszer alkalmas az országban forgalomban levő részvények, kötvények, és értékpapírok kibocsátásához szükséges Isin azonosító igénylésére. A rendszerbe bejelentkezett felhasználó az értékpapír adatok valamint a kibocsátó megadásával indíthatja el az igénylési folyamatot, melynek során on-line bankkártyás fizetéssel egyenlítheti ki számláját, majd a folyamat végén azonnal hozzáfér új Isin kódjához. A rendszerhez kapcsolatban van a KELER Zrt. hátér rendszereivel, valamint mindenre kiterjedő naplózó és monitorozó rendszert tartalmaz. A szoftver alapjául szolgáló Internetes keretrendszer képes további KELER-es szolgáltatások egyszerű, gyors Internetes publikálására.