Eclip­se Mi­cro­pro­fi­le

SCREENGUIDE - - Inneres - TEXT: Wer­ner Keil

Ja­va-EE-Tech­no­lo­gi­en im Mi­cro­ser­vice-Um­feld

Mi­cro­Pro­fi­le star­te­te Mit­te 2016 als ge­mein­sa­me In­itia­ti­ve von Soft­ware­her­stel­lern, Ja­va User Groups und Ein­zel­per­so­nen. Ziel ist es, Ja­va-EE-Tech­no­lo­gi­en im Mi­cro­ser­vice-Um­feld bes­ser nutz­bar zu ma­chen und die Bin­dung an ein­zel­ne An­bie­ter zu ver­rin­gern – durch größt­mög­li­che Aus­tausch­bar­keit von Run­ti­mes im Sin­ne des „Wri­te on­ce, run anyw­he­re”-Ver­spre­chens von Ja­va. Als das „Web Pro­fi­le”, ei­ne ver­ein­fach­te Ja­va-EE-Va­ri­an­te zur Webentwicklung mit Ja­va EE 6, erst­mals ein­ge­führt wur­de, spra­chen sich et­li­che Mit­glie­der der „Ja­va En­ter­pri­se Edi­ti­on Platt­form”-Ex­per­ten­grup­pe für wei­te­re, klei­ne­re Pro­fi­le aus. Ver­tre­ter gro­ßer An­bie­ter und Un­ter­neh­men wie Ora­cle, Sun oder auch IBM be­fürch­te­ten da­durch je­doch ei­ne hö­he­re Kom­ple­xi­tät für ih­re Pro­duk­te. Es blieb al­so beim Web Pro­fi­le, das aber noch nicht so leicht­ge­wich­tig war wie Mi­cro­f­rame­works [goo.gl/rKKhoY]. Un­ter Mi­cro­f­rame­work ver­steht man ei­ne Art „ab­ge­speck­tes” Web­frame­work, das sich auf API-Auf­ru­fe be­schränkt, oh­ne et­wa kom­ple­xe­re Ge­schäfts­lo­gik zu un­ter­stüt­zen. Mi­cro­f­rame­works exis­tie­ren für die un­ter­schied­lichs­ten Pro­gram­mier­spra­chen, et­wa PHP, Ru­by, Py­thon oder Ja­vaS­cript/Node.js. Ei­ni­ge Mi­cro­f­rame­works wur­den auch für Ja­va ent­wi­ckelt, ba­sie­ren aber nur teil­wei­se oder gar nicht auf Ja­va-Stan­dards, was die ge­mein­sa­me Nut­zung mit En­ter­pri­se-Sys­te­men er­schwert und den Lern­auf­wand für Ent­wick­ler er­höht – ein Grund, wes­halb vie­le Ein­zel­per­so­nen und auch Her­stel­ler im JCP (Ja­va Com­mu­ni­ty Pro­cess, jcp.org) neue We­ge be­schrei­ten woll­ten, um den Zug in Rich­tung Mi­cro­ser­vices nicht zu ver­pas­sen oder dar­in nur noch zwei­ter Klas­se zu fah­ren. Mi­cro­ser­vices [goo.gl/san­jzA] sind ein Ar­chi­tek­tur­mus­ter, bei dem kom­ple­xe An­wen­dun­gen aus klei­nen un­ab­hän­gi­gen Di­ens­ten kom­po­niert wer­den. Ein wich­ti­ger Aspekt ist, ein­zel­ne Ser­vices ak­tua­li­sie­ren zu kön­nen, oh­ne dass an­de­re ge­än­dert und neu aus­ge­lie­fert wer­den müs­sen, wie es bei tra­di­tio­nel­len „mo­no­li­thi­schen” Sys­te­men der Fall ist. Da­mit ist es deut­lich leich­ter, agil und ite­ra­tiv auch grö­ße­re Sys­te­me zu ent­wi­ckeln und schritt­wei­se aus­zu­lie­fern so­wie den Be­nut­zern schon Teil­be­rei­che zu Test und Nut­zung an­zu­bie­ten. Vie­le Mit­glie­der der Ge­mein­schaft ver­miss­ten ei­ne ge­wis­se Agi­li­tät bei der Ent­wick­lung von Ja­va EE. Ora­cle gab schon Mit­te 2015 ähn­lich wie für JDK 9 ei­ne Ver­schie­bung von Ja­va EE 8 ins Jahr

2017 be­kannt [goo.gl/b7OVc8]. Als im Lau­fe von 2016 in vie­len „Ja­va EE 8”-Be­stand­tei­len kei­ne er­kenn­ba­re Ak­ti­vi­tät durch Ora­cle vor­lag und die Re­fe­renz­im­ple­men­ta­ti­on „Glass­fish” prak­tisch zum Er­lie­gen ge­kom­men war, ver­ließ Ja­va EE Evan­ge­list Re­za Rah­man das Un­ter­neh­men und grün­de­te ei­ne Com­mu­ni­ty-Be­we­gung na­mens „Ja­va EE Guar­di­ans” zur un­ab­hän­gi­gen För­de­rung von Ja­va im En­ter­pri­se-Be­reich [goo.gl/5ohnSm]. Die Lis­te der Ja­va EE Guar­di­ans ist in­zwi­schen sehr lang und wird an­ge­führt von Ja­mes Gos­ling, dem Be­grün­der von Ja­va. Et­wa um die­sel­be Zeit star­te­ten groß­teils im JCP ver­tre­te­ne Soft­wareher­stel­ler, Ja­va User Groups und Ein­zel­per­so­nen, fast al­le da­von auch Ja­va EE Guar­di­ans, die Mi­cro­Pro­fi­le-In­itia­ti­ve [mi­cro­pro­fi­le.io], um ein stan­dard­kon­for­mes Mi­cro­f­rame­work für die Ja­va-Platt­form zu schaf­fen. Bald wur­de klar, dass man als Teil ei­ner eta­blier­ten Open-Sour­ce-Ge­mein­schaft ef­fek­ti­ver sein wür­de, als selbst ei­ne „Mi­cro­Pro­fi­le Foun­da­ti­on” zu grün­den. Und es wur­de Kon­takt mit Ge­mein­schaf­ten wie Apa­che, Li­nux oder Eclip­se Foun­da­ti­on für ei­ne mög­li­che Teil­nah­me auf­ge­nom­men. Kurz vor Weih­nach­ten 2016 wur­de Eclip­se Mi­cro­Pro­fi­le von der Eclip­se Foun­da­ti­on als Pro­jekt an­er­kannt [goo.gl/EGAh­qF]. Wäh­rend Mi­cro­Pro­fi­le 1.0 be­reits im Sep­tem­ber an­ge­kün­digt war, lau­fen seit An­fang 2017 die Vor­be­rei­tun­gen für ein of­fi­zi­el­les 1.0-Re­lease. Auch wenn ei­ni­ge Her­stel­ler be­reits Vor­ab­ver­sio­nen in ih­re Pro­duk­te ein­bau­ten, ist dies wie et­wa beim all­jähr­li­chen Eclip­se „Re­lease Train” ein Re­lease Can­di­da­te bzw. ei­ne Vor­ab­ver­si­on. Die of­fi­zi­el­le Ver­si­on steht für das ers­te Quar­tal 2017 an. Die Eclip­se Foun­da­ti­on hat sich seit ih­ren An­fän­gen im Tool- und IDE-Be­reich stark ver­brei­tert und konn­te sich als her­stel­ler­neu­tra­le Platt­form von Ent­wick­lungs­tools über Tech­no­lo­gi­en für das IoT (In­ter­net of Things) bis zu bran­chen­spe­zi­fi­schen Pro­jek­ten für die Au­to­mo­bil­in­dus­trie oder Wis­sen­schaft und das Ge­sund­heits­we­sen eta­blie­ren. In­so­fern wirkt die Eclip­se Foun­da­ti­on wie ein gu­ter Part­ner auf dem Weg zu ei­ner her­stel­ler­un­ab­hän­gi­gen Lö­sung für Mi­cro­ser­vices. Sind dar­in doch so un­ter­schied­li­che Mit­glie­der und Her­stel­ler­fir­men ge­mein­sam an Pro­jek­ten tä­tig, wie Mi­cro­soft, IBM, Ora­cle, Red Hat, SAP oder auch Pi­vo­tal, des­sen Spring Cloud als Mit­tel­ding aus In­spi­ra­ti­on und we­sent­li­cher Kon­kur­renz für Mi­cro­Pro­fi­le und die in­vol­vier­ten Com­mit­ter gel­ten mag. Mit Pro­jek­ten wie Eclip­se Ge­mi­ni [goo.gl/kpucmL] ver­such­te das Un­ter­neh­men – da­mals noch un­ter dem Na­men Sprin­gSour­ce –, sei­ne „Spring Dy­na­mic Mo­du­les” ge­nann­ten OSGi-Kom­po­nen­ten für den En­ter­pri­se-Be­reich als Pro­jekt meh­re­rer An­bie­ter zu eta­blie­ren. Was be­dingt auch ge­lang. So ge­hö­ren et­wa Ora­cle-Ver­tre­ter wie Mi­ke Keith aus dem „Ja­va Per­sis­tence/ JPA”-Um­feld zu den Ge­mi­ni-Ent­wick­lern, al­ler­dings war Ge­mi­ni in den letz­ten Jah­ren nicht mehr wirk­lich ak­tiv. Der „Ja­va Per­sis­tence API (JPA)”-Stan­dard ist im Üb­ri­gen auch pro­mi­nen­tes Bei­spiel für Ja­va-Stan­dards, die ih­re Re­fe­renz­im­ple­men­ta­ti­on (RI) als Eclip­se-Pro­jekt füh­ren. Et­was, das man bei Mi­cro­Pro­fi­le in ge­wis­sen Be­rei­chen auch für denk­bar hält, aber nicht vor­ran­gig jetzt schon an­strebt. So mein­te et­wa auch Anil Gaur, Ora­cle Vice Pre­si­dent En­gi­nee­ring für den „En­ter­pri­se und Cloud”-Be­reich, im Rah­men der Ja­vaO­ne: „Die Mi­cro­Pro­fi­le-Be­mü­hun­gen sind kom­ple­men­tär zu dem, was der Ja­va Com­mu­ni­ty Pro­cess mit Ja­va EE macht, und wir freu­en uns dar­auf, dass sie da­zu bei­tra­gen, die­sen Pro­zess vor­an­zu­trei­ben.”

UM­FANG VON MI­CRO­PRO­FI­LE

Mi­cro­Pro­fi­le Ver­si­on 1.0 um­fasst fol­gen­de Ja­va-Stan­dards: • JAX-RS 2.0: der Ja­va-Stan­dard für REST­ful Web Ser­vices, der seit der Ja­va En­ter­pri­se Edi­ti­on 7 in die­ser Ver­si­on ver­füg­bar ist, un­ter an­de­rem mit REST-Cli­ent-Un­ter­stüt­zung • JSON Pro­ces­sing 1.0: der Ja­va-Stan­dard zur Be­hand­lung von JSON-Do­ku­men­ten, neu seit Ja­va EE 7 • CDI (Con­texts and De­pen­den­cy In­jec­tion) 1.1: Auch die­ses Up­date ist neu in Ja­va EE 7, nach­dem die ers­te Ver­si­on be­reits in Ja­va EE 6 für fri­schen Wind ge­sorgt hat­te.

IN­HALT IM DE­TAIL

JAX-RS: Der Ja­va-Stan­dard für REST (Re­pre­sen­ta­tio­nal Sta­te Trans­fer) Web Ser­vices [goo.gl/MB0NUM]. Der Schwer­punkt liegt ana­log zum Web und zu sei­nem HTTP-Pro­to­koll auf durch URI (z.B. URL) iden­ti­fi­zier­ba­ren Res­sour­cen und per Con­tent-Ty­pe un­ter­scheid­ba­ren Re­prä­sen­ta­tio­nen. REST APIs ha­ben sich in wei­ten Tei­len des In­ter­nets zum De-fac­to-Stan­dard ent­wi­ckelt. Ein Bei­spiel für ei­nen REST-Auf­ruf in ei­ner Web-An­wen­dung wä­re http://ws.mei­ne­do­main.de/pro­ducts für die Lis­te al­ler Pro­duk­te so­wie http://ws.mei­ne­do­main.de/pro­ducts/1234 zur De­tail­an­zei­ge ei­nes be­stimm­ten Pro­duk­tes. Der Auf­ruf http://localhost:8080/REST­fu­lEx­amp­le/rest/hel­lo/ world hät­te „Jer­sey says Hel­lo: world” als Er­geb­nis. JSON Pro­ces­sing: Ja­va-Stan­dard [goo.gl/TU4Bii] für JSON (Ja­vaS­cript Ob­ject No­ta­ti­on). JSON ist ein kom­pak­tes Da­ten­for­mat in ei­ner ein­fach les­ba­ren Text­form zum Zweck des Da­ten­aus­tauschs zwi­schen An­wen­dun­gen. Je­des gül­ti­ge JSON-Do­ku­ment soll auch ein gül­ti­ges Ja­vaS­cript sein.

JSON wird zur Über­tra­gung und zum Spei­chern von struk­tu­rier­ten Da­ten ge­nutzt. Es hat hier an­de­re, meist schwer­ge­wich­ti­ge­re For­ma­te wie XML weit­ge­hend als Da­ten­for­mat zur Se­ria­li­sie­rung ab­ge­löst – ins­be­son­de­re bei We­b­an­wen­dun­gen und APIs. JSON Pro­ces­sing (manch­mal auch als JSON-P ab­ge­kürzt, je­doch nicht mit „JSON und Pad­ding” zu ver­wech­seln, für das auch meist ei­ne Kurz­form wie „JSON-P” oder JSONP” ge­nutzt wird) für Ja­va exis­tiert in zwei wich­ti­gen Va­ri­an­ten: • JSON Ob­jekt API: et­wa dem XML DOM ver­gleich­bar, mit ei­nem stark ty­pi­sier­ten Ob­jekt­baum, der ein ge­sam­tes JSON-Do­ku­ment re­prä­sen­tiert • JSON Strea­m­ing API: Ähn­lich dem XML StAX Par­ser oder Da­ten­bank-„Cur­sor” wird hier im­mer ein klei­ner Aus­schnitt ei­nes JSON-Do­ku­ments ge­le­sen. Das er­laubt auch, sehr gro­ße oder sich häu­fig än­dern­de JSON-Struk­tu­ren zu le­sen. CDI: Con­texts and De­pen­den­cy In­jec­tion (CDI) [cdi-spec.org] war zu Be­ginn auch als „Web Be­ans” be­kannt, weil man das Kon­zept wie­der­ver­wend­ba­rer „Ja­vaBe­ans” auch auf We­b­an­wen­dun­gen über­tra­gen woll­te. Ja­vaBe­ans kann man am bes­ten mit .NET- oder Ac­tiveX-Kom­po­nen­ten [goo.gl/ey­6ABd] in der Mi­cro­soft-Welt ver­glei­chen. Ei­ni­ge CDI-Im­ple­men­ta­tio­nen, dar­un­ter Apa­che Open We­bBe­ans, tra­gen dem ur­sprüng­li­chen Na­men bis heu­te noch Rech­nung. CDI ist ein Ja­va-Stan­dard, der die Kom­po­si­ti­on und Nut­zung von Mo­du­len durch In­jek­ti­on von Ab­hän­gig­kei­ten er­mög­licht. CDI stan­dar­di­siert das Prin­zip der De­pen­den­cy In­jec­tion für Ja­va, wo­nach die von ei­nem Mo­dul ver­wen­de­ten Ab­hän­gig­kei­ten von au­ßen dem Mo­dul be­kannt ge­ge­ben wer­den und im Mo­dul le­dig­lich als Ab­hän­gig­keit (in der Re­gel ein In­ter­face in Ja­va) statt ei­ner kon­kre­ten Ob­jek­t­in­stanz de­fi­niert sind. Das ist ein ähn­li­ches Prin­zip, wie es et­wa PHP-DI für PHP an­bie­tet [php-di.org] oder wie es das Spring Frame­work un­ter Ja­va ist. Spring teilt seit ei­ni­ger Zeit schon es­sen­zi­el­le API-Kon­struk­te und An­no­ta­tio­nen mit CDI. Da es für CDI meh­re­re Im­ple­men­ta­tio­nen gibt, et­wa die er­wähn­ten Open We­bBe­ans bei Apa­che, setzt Mi­cro­Pro­fi­le auf CDI als her­stel­ler­un­ab­hän­gi­gen Stan­dard – wäh­rend beim Spring Frame­work und bei ähn­li­chen Spring-Lö­sun­gen von Pi­vo­tal, so­fern die­se nicht auch man­che Ja­va-Stan­dards nut­zen, die ein­zi­ge Im­ple­men­ta­ti­on auch Teil des Frame­works ist und man so­mit meist auf de­ren An­bie­ter und sei­ne ge­sam­te Pro­dukt­pa­let­te fest­ge­legt ist.

AUSBLICK

Im An­schluss an den ers­ten Mi­cro­Pro­fi­le Re­lease bei Eclip­se sol­len un­ge­fähr quar­tals­wei­se wei­te­re Ver­sio­nen fol­gen. Hei­ße An­wär­ter zur Auf­nah­me in Mi­cro­Pro­fi­le 1.1 sind: • Ein­heit­li­che Kon­fi­gu­ra­ti­on: Das soll zu­min­dest in der ers­ten Pha­se kei­ne „ei­er­le­gen­de Woll­milch­sau” zur Kon­fi­gu­ra­ti­on wer­den, auch wenn hier die An­sich­ten und Plä­ne ei­ni­ger Ver­tre­ter leicht di­ver­gie­ren mö­gen. Viel­mehr ist ein ver­bes­ser­ter, mög­lichst rei­bungs­lo­ser Aus­tausch von Con­tai­nern ge­plant, die heu­te mit un­zäh­li­gen ver­schie­de­nen Kon­fi­gu­ra­ti­ons­me­cha­nis­men da­her­kom­men. Das meis­te da­von wird in XML-Da­tei­en ge­spei­chert, in ei­ni­gen Fäl­len heu­te durch JSON ergänzt oder ab­ge­löst. Manch an­de­rer An­bie­ter setzt auf YAML, und wie­der an­de­re sind den gu­ten al­ten Ja­va-Pro­per­ties-Da­tei­en treu ge­blie­ben. Ziel des Mi­cro­Pro­fi­le-Con­fi­gu­ra­ti­on-Mo­duls ist es, dies so weit wie mög­lich zu ver­ein­heit­li­chen und da­mit Ser­vices ei­nen ein­heit­li­chen An­sprech­punkt für Kon­fi­gu­ra­ti­on zu bie­ten. Wenn man so will und ganz ver­ein­facht for­mu­liert: wie ei­ne Art Win­dows Re­gis­try, nur eben für den Ser­ver. Egal, ob die­ser nun auf Win­dows, Li­nux, Mac oder ei­nem an­de­ren Be­triebs­sys­tem läuft. • Si­cher­heit: Hier­für ist die Nut­zung so­zia­ler Iden­ti­tä­ten wie Goog­le ID, Face­book etc. zum Sing­le Sign-on im Ge­spräch. • He­alth Mo­ni­to­ring: Ei­ne Art „Puls­mes­ser” für We­b­an­wen­dun­gen und Ser­vices, mit dem Sie die Ver­füg­bar­keit ei­nes Ser­vices über­prü­fen und für den Fall von Pro­ble­men bzw. Aus­fäl­len ent­we­der Ab­hil­fe oder den Wech­sel zu an­de­ren Ser­vices ver­an­las­sen kön­nen. • Cir­cuit Brea­ker: Schutz­schal­ter für Mi­cro­ser­vice-Ar­chi­tek­tu­ren, die aus­ge­hend vom er­wähn­ten He­alth Mo­ni­to­ring die­ses nut­zen und bei ein­ge­schränk­ten oder über­las­te­ten Ser­vices au­to­ma­tisch auf Er­satz­sys­te­me um­schal­ten hel­fen. Im Grun­de ähn­lich wie Clus­te­ring für gan­ze Ser­ver, aber auf ei­ner et­was fein­gra­nu­la­re­ren Ebe­ne. Nicht al­le Fea­tu­res mö­gen zum Re­lease von Mi­cro­Pro­fi­le 1.1 fer­tig sein. Dort, wo noch we­sent­li­che Tei­le fehl­ten, wan­dern be­trof­fe­ne Fea­tu­res in ei­ne Fol­ge­ver­si­on. In man­chen Be­rei­chen könn­te auch ei­ne CDI-In­te­gra­ti­on für weit­ver­brei­te­te Lö­sun­gen wie et­wa Net­flix Hys­trix [goo.gl/pFLCqA] hel­fen, statt das Rad ge­wis­ser­ma­ßen neu zu er­fin­den. Da in die­ser Pha­se Mi­cro­Pro­fi­le nicht den An­spruch ei­nes Stan­dards er­hebt, wä­re das auch par­al­lel zu an­de­ren Ent­wick­lun­gen mög­lich. Eclip­se konn­te schon in der Ver­gan­gen­heit mit manch­mal zwei oder meh­re­ren An­sät­zen für be­stimm­te Pro­ble­me auf­war­ten – et­wa mit zwei Eclip­sePro­jek­ten zur Un­ter­stüt­zung von Build Tools, von de­nen ei­nes das an­de­re letzt­lich über­traf und bis heu­te ge­nutzt wird. Ähn­lich prag­ma­tisch und „dar­wi­nis­tisch” möch­te man das bei Mi­cro­Pro­fi­le eben­falls an­ge­hen.

SELF-CONTAINED SYS­TEMS

Be­son­ders im deutsch­spra­chi­gen Raum fin­den sich pro­mi­nen­te Bei­spie­le gro­ßer Un­ter­neh­men, die ei­ne Self-Contained-Sys­tems (SCS) ge­nann­te Va­ria­ti­on gän­gi­ger Mi­cro­ser­vice Patterns be­vor­zu­gen [goo.gl/MpHZN3]. Ein we­sent­li­cher Un­ter­schied ist – ne­ben klei­ne­rem Schnitt ein­zel­ner Ser­vices –, dass ein SCS in vie­len Fäl­len ein ei­ge­nes au­to­no­mes Web-UI be­sitzt, wäh­rend Mi­cro­ser­vices fast im­mer als „He­ad­less”, al­so oh­ne ei­ge­ne Prä­sen­ta­ti­ons­schicht, ge­se­hen wer­den. Auf­grund ver­wen­de­ter Stan­dards und Ba­sis­tech­no­lo­gi­en, ins­be­son­de­re JAX-RS, bie­tet sich für Mi­cro­Pro­fi­le der MVC-Stan­dard für Ja­va an.

MVC 1.0: Der MVC-Stan­dard für Ja­va EE [goo.gl/FCgZNN] wur­de in gro­ben Zü­gen von Spring MVC in­spi­riert, das wie­der­um auf frü­he­re MVC Web Frame­works wie et­wa St­ruts zu­rück­geht. Durch ei­ne Kom­bi­na­ti­on aus der Fest­le­gung auf „Cloud” und tra­di­tio­nel­le­re Mi­cro­ser­vices und der Über­schnei­dung mit an­de­ren be­reits eta­blier­ten Stan­dards wie Ja­va Ser­ver Faces (JSF) ent­schied Ora­cle, den MVC-Stan­dard selbst nicht mehr wei­ter­zu­ver­fol­gen, ob­wohl die­ser be­reits gu­te Fort­schrit­te ge­macht hat­te. Die Auf­ga­be wird auch da­durch er­leich­tert, dass der MVC-Stan­dard ei­ne kon­se­quen­te, re­la­tiv schlan­ke Er­wei­te­rung von JAX-RS ist, un­ter Nut­zung an­de­rer JSRs wie CDI oder Be­an Va­li­da­ti­on. Das macht es als op­tio­na­le Er­wei­te­rung für Self-Contained Sys­tems auf Ba­sis von Mi­cro­Pro­fi­le zu ei­nem sehr gu­ten Kan­di­da­ten für die Prä­sen­ta­ti­ons­schicht, da die meis­ten Vor­aus­set­zun­gen und Ba­sis­ab­hän­gig­kei­ten be­reits in Mi­cro­Pro­fi­le 1.0 ent­hal­ten sind. Aus­ge­hend vom zu­vor er­wähn­ten JAX-RS-Bei­spiel Ser­vice hier ein ver­gleich­ba­res „Hel­lo World”-Bei­spiel auf Ba­sis von MVC 1.0: Zahl­rei­che Ele­men­te wie @Path oder @GET de­cken sich hier­bei mit dem JAX-RS-Bei­spiel. Da­durch kön­nen Sie mit we­nig Auf­wand aus ei­nem Mi­cro­ser­vice nach tra­di­tio­nel­ler Aus­le­gung ei­ne Kom­po­nen­te ab­lei­ten, die als Self-Contained Sys­tem fun­gie­ren kann. In die­sem Fall wä­re auch die URL-Si­gna­tur so gut wie un­ver­än­dert. Er­gän­zend fin­det sich statt ei­nes ein­fa­chen Strings als Na­me ein mit­tels CDI @In­ject in­ji­zier­tes Be­nut­zer-Ob­jekt.

Wer­ner Keil ist Ja­va EE Con­sul­tant, Mi­cro­ser­vice­und Test-Au­to­ma­ti­on-Ex­per­te bei ei­ner Bank, nach ver­gleich­ba­rer Tä­tig­keit für Ver­si­che­run­gen und Un­ter­neh­men im Be­reich Print und Au­to­mo­ti­ve/Em­bed­ded, so­wie Agi­le Coach, Ja­va-Em­bed­ded­und Eclip­se-RCP-Ex­per­te bei ei­nem An­bie­ter von Em­bed­ded-und Re­al­time-Sys­te­men. Twit­ter: @wern­er­keil Kom­men­tie­ren: screen­gui.de/34/mi­cro­pro­fi­le

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.