Integráció - röviden

Minden integrációs projectnél végül oda jut a párbeszéd, hogy az integráló fél/kliens felteszi a kérdést: Hogyan oldjuk meg azokat a problémákat, amelyek az én rendszeremben jelentkeznek és a te rendszeredből jönnek?
Erre ez az általános válasz a szolgáltatók részéről: Azok a problémák, amik a te rendszeredben jelentkeznek, azok a tieid.

JUM 12

Tvik már beszámolt, de én is beszámolnék, csak hogy szinesítsem a képet és a visszajelzések számát.

Viczián István: JAX-WS

A végén rá is kérdeztem, bár kicsit hülyén, szóval az előadás a JAX-WS és a reference implementációjának problémáit ölelte fel. Azaz nem feltétlenül szívja meg az ember pont így. Igen, elég ijesztő volt. Contract first WS. Nem tudom, én ezekkel nem szivatom magam, felannotálom a web service interfaceket alaposan :-D és ha az interface marad ugyanaz, akkor a kigenerált WSDL is, sőt a SOAP üzenetek tartalma is. Szóval innentől én kevés motivációt érzek a dologra, persze ha bankot vagy atomreaktort kellene ezzel hajtani, akkor biztosan óvatosabb lennék. Még egy saját horror-élményt hozzáfűznék: CXF és jettison, ha ugyanaz a neve egy property-nek és a property property-jének, hát akkor a jettison ott elcsűri a json objektumot. A tréfa az, hogy a többi részét is kiteszi, csak elötte lezárja a tömböt. Atomreaktort már csak az ilyenekért sem hajtanék vele, ez a bug akármilyen egyszerűnek is hangzik, elég rég óta vár javításra.

Csutorás Zoltán: Agile, SCRUM, Lean

Igen, volt szó a SCRUM-ról is, de a végén az a modell, aminél a gyártósor leállások voltak és mindenki le volt rajta döbbenve, na az nem a SCRUM volt már, hanem valami más aminek a nevére nem emlékszem. Update: KANBAN. Az előadó stílusából azt a következtetést vontam le hogy neki alighanem vannak hozzá acéldrótokkal erősített idegei, hogy a felvázolt módszertant keresztülvigye. És akkor gondolom működik is. Annyi biztos, hogy én ehhez gyáva vagyok.

Kis Gergely: Andriod és Hundriod

Az elején kicsit gyanakvóan figyeltem, hogy miért indítja furcsa paraméterekkel parancssorból az openoffice-t, mi az a pythonos trükk, amit még elstartol hozzá... Viszont hamar kiderült, hogy innetől az androidos telefonnal irányíta a prezentációt. Onnantól kezdve nagyon tetszett, bár nem egy felhasználóbarát megoldás per pillanat, de nagyon látványos demó volt. Én továbbra is beérem az kötelező mutatvánnyal amúgy, én a telefonomat tényleg csak telefonként (és fényképezőként és pendrive-ként és walkman-ként) használom.

JAX-RS és JAX-WS

Köszi a hozzászólásaitokat az előző postra, egész sok inspirációt kaptunk ahhoz hogy hogy írjuk át a teszteket!

Igazából most is a véleményetekre lennék kiváncsi.

Szintén munkahelyi projectben azon mesterkedtem, hogy SOAP-os REST-es web service-t is meghagyom egészen addig, amíg teljesen világossá nem válik hogy az adott környezetben melyik a nyerő megoldás. Természetesen spring-gel inicializálom a service bean-eket, CXF-fel exportálom ki, JSR 181 web services és JSR 311 rest annotációkkal látom el a service metódusokat és a beaneket még JAXB annotációval is helyenként. Sikerült is, bár szerintem kicsit szőrös a dolog.

1. Elösször is a JAX-RS a beanjeid Collection (list, map) mezőire megköveteli, hogy legyen mindnek alapértéke és csak gettere. Azaz ne lehessen null soha, legfejebb üres. Viszont a JAX-WS elvárja hogy mindenkinek legyen szép gettere és settere, különben nem számít proprtynek. Ez a kettő nem feltétlenül zárja ki egymást, csak kicsit megcsúfítja a bean-eket.
   
   Például így fog kinézni egy bean:
   
   
   

   
   /**
   * Szerintem gáz, amikor magyar neve van egy osztálynak :)
   * Majdnem mint amikor a javadoc is magyar.
   */
   @XmlRootElement(name="csirke")
   public class Csirke {
   boolean isKopaszNyaku;
   boolean isKendermagos;
   List<Tojas> tojasok = new ArrayList<Tojas>();
   @XmlTransient // Nem ezt a property-t hasznaljuk a rest apival
   public List<Tojas> getTojasok() {return tojasok;}
   public void setTojasok(List<Tojas> tojasok) {this.tojasok = tojasok;}
   @XmlElement(name="tojas")
   @XmlElementWrapper(name="tojasok")
   public List<Tojas> getTojasLista(){ return getTojasok();}
   }

   
   
   Szóval szerintem kicsit összetúrkáltuk az alkalmazás legérzékenyebb részét: az adatmodellt. Ha az adatmodell csúnya, az mindennek rossz alaphangulatot ad.
2. A CXF-nek kicsit nehéz volt megmagyarázni, hogy ha pl a /services/ alá mappeltem a CXFServlet-et, akkor mit kell csinálnia akkor, amikor kap a /services/-re egy kérést. Azt hiszem az lehetett a baj, hogy nem állítottam be at address-t.
   
   
   

   
   <jaxrs:server name="jaxrs-server" bus="rest" address="/rest">
   <jaxrs:servicebeans>
   <ref bean="csirkefarm">
   </jaxrs:serviceBeans>
   </jaxrs:server>
   

   
   
   
   
3. A service interfacekre raktam az annotációkat, hogy ha lecserélem az implementációt, akkor az új service-re már ne kelljen másolgatnom. Hát elég cifrán meg lett annotálva egy-egy ilyen metódus.
   
   
   

   
   @WebService(name = "csirekFarm")
   @Path("/csirkeFarm/")
   public interface CsirkeDAO {
   @WebMethod(operationName = "getCsirke")
   @WebResult(name = "getCsirkeResult")
   @GET
   @Path("/csirke/{csirkeId}")
   public void Csirke getCsirkeById(@Webparam(name="csirkeId") Long id);
   

   
   
   
   

Most, hogy az annotációk legyőzték az XML konfigurációkat, a kódunk tele van konfigurációval :-) A hétvégén összedobok hozzá egy archetype-ot, ha elég időm marad rá.

JUM 2008-01-16

Az idei első Java User Meeting aka Paláver. Bevetettem egy kis gerillamarketinget a JHacks ügyében (köszi a lehetőségért :)), mire haza értem már új snippeket láttam. Köszi köszi :)
Szóval ezek voltak...

1. Kuvera: JasperReports
   IReports tervezővel bemutatva a Jasperreports. Elég jól nézett ki a dolog, nekem viszont a BIRT riporttervezője kicsit tökösebbnek tűnik, főleg hogy abba az IDE-be van építve amit amúgy is használok.
   Igen pontos és részletes bemutató volt, szerintem kicsit túl pontos és részletes, pl a classpath beállítások kevésbé lényeges dolgok...
   
2. Balogh Péter: SCA, SDO
   Az első cégember a JUM történetében, az IBM-től. Hát vannak az IBM szoftverekkel előitéleteim, ezt az előadást is így szemléltem, mindenesetre elég szinvonalas összefoglaló volt. Majd az apache tuscany házatáján jól szét fogok nézni.
   A melóhelyi SOAP gebaszolásokkal pont egy fényévre vagyunk ettől a szinttől, de keményen követjük a trendet gyökkettő sebességgel.
   
3. Java 7 vitafórum TVik vezetésével
   Új műfaj a JUM-on, és elég jó indítással szerintem. Nekem nagy megkönnyebbülés volt hogy nem csak én fújolok a java-xml integrációra, hanem minden jelenlevő. Viszont mi lesz a javával?
   Hát ha szabad tippelni, a java 1.5 a csúcs volt, már ebben is volt pár aknamező feature mint pl autoboxing. Lassan kevésbé lényegessé válik a java nyelv, sokkal inkáb lényeges lesz a java runtime.
   Lassan be kell szerezni a Groovy könyveket (nekem már kipipálva), 1-2 éven belül talán már hazai álláshirdetésekben is megjelennek követelményként alternatív JRE-alapú nyelvek ismerete. Majd nosztalgiázva gondolunk vissza azokra az időkre, amikor még volt normális editor ahhoz a nyelvhez, amit használtunk.
   

WS-Hell

Végignéztem az általam ismert java web service stack-eket (Axis 1-2, CXF, Xfire, JAX-WS) és egyik sem tudja kezelni a soapenc:Array típust. Néhányan azért mégiscsak használják, ezt az adattípust, például a google a SOAP search apiban. Ez kicsit szomorú :-(
Valamit kihagytam esetleg?

SOA, WS, ilyesmi...

Olvastam a múlt héten egy olyan véleményt, hogy a SOA-ban egyszerűen nem kellenek tranzakciók, mert azok amúgy is csak üzlet-specifikus dolgok, úgyhogy legyek szives re-eninerelni a teljes rendszerünket. Ezzel vagyok jól kisegítve, egyrészt a rendszer tervezése még annyira sem az én hatásköröm mint beleszólni a mások rendszereinek implementációs részleteibe, másrészt a tranzakciók annyira természetes kis keretet adtak a programozáshoz, hogy az ember nem szivesen mond le róluk.

Most úgy néz ki, van végre olyan webservices stack, ami ismeri az ide vonatkozó WS-Coordination és WS-AtomicTransaction szabványokat, mégpedig a Sun Metro nevű cucca. Ezzel kapcsolatban megvan minden, amit a Sun cuccaiban nagyon nem szeretek:

• Zavaros névadási konvenció, minden kanyarban másképp hívják a gyereket.
  
• A dokumnetációban mindenhol más Sun termékekre hivatkozik, pl Netbeans és Glasfish. Nekem nem kell a netbeans, én azt szeretném tudni, hogy az XML-be hol kell beletúrni, és arra is fel kell készülni hogy a cuccaink soha nem fognak glasfish-en futni.
  
• A furi licensz miatt nem lehet felpakolni a maven repository-ba.
  

Szóval túlélhető, de kemény menetnek igérkezik a most indított prototype project, most még mindenki optimista. Aztán majd meglátjuk.

WS-Transactions

Második nekifutás WS-Transactions a falnak.
Vagy nagyon advanced dolgot akarok, vagy nagyon nagy hülyeséget, ez remélem hamar kiderül, mindenesetre az élet tranzakciók nélkül piszok nehéz tud lenni, még akkor is ha web servicekről van szó. Persze egyszerű esetekben (örüljön az akinek a munkája egy egyszerű eset) egy tranzakcióban egy WS hívás van, ha sikerül akkor azt lehet mondani hogy oké, ha meg elfekszik akkor rollback és megpróbáljuk később esetleg. Nem ilyen ideális az élete azoknak akik kénytelenek egynél több hívást indítani egy tranzakcióban, főleg ha adat módosításáról van szó.
Kicsit utánnanéztem a WS-AtomicTransaction speckónak, találtam hozzá egy WSDL-t is, szóval akár implementálni is lehetne, csak elöbb gondol, mert annyira azért mégsem sürgős. A saját implementáció azért merül fel lehetőségként, mert még mindig senki sem csinálta meg. Pedig már nem annyira új a dolog, kiváncsi vagyok mi lehet az oka.
Mindenesetre egyelőre egy implementáció lehetőségét keresem, nem túl bonyolult, a kliens oldara kell egy tranzakció interceptor ami a kliens oldalon figyeli hogy létezik-e tranzakció, a hívott WS támogatja-e a tranzakciókat, meghívja a WS-Transactions api megfelelő hívásait, aztán prepare és commit esetén ilyesmi. A szerver oldalon pedig a transaction-managerrel kell összehuzalozni.
Húú, ha csak ilyen igazságosztásból kellene megélnem biztos rohadt könnyű lenne. A gond például a prepare hivásnál van, ahhoz programozói szintről vajon hogy lehet hozzáférni... Sehogy, mi?
Ilyenek lesznek...

Pár link..

• Guy Pardon előadása a Javapolison
• WSDL (Lényeg)
• Speckó, ezt is el lehet olvasni...