[Java/XML] Welke technieken te gebruiken?

[Banaan]

Over een twee- drietal weken zal ik voor mn werk een java-applicatie moeten gaan aanpassen om XML-berichten te kunnen ontvangen en versturen. Ik heb het echter nu al erg druk en heb te weinig tijd om zelf een eerste oriëntatie te maken om te kunnen beslissen met welke technieken dit te gaan doen.

Ik hoopte daarom dat jullie mij zouden kunnen helpen door het geven van tips welke technieken hierbij goed te gebruiken zijn, en welke juist niet. Ik hoop hierdoor de tijd die ik kan besteden aan het voorbereiden niet verloren gaat aan technieken die later niet toepasbaar blijken te zijn voor mijn situatie.

Het gaat om het volgende:
De java-applicatie bestaat uit dit moment uit een rekenmodule met bijbehorende webbased GUI, waarin oa klantgegevens, bepaalde verbruiksgegevens en offertegegevens kunnen worden beheerd. De rekenmodule berekent de prijzen voor de offertes. In verband met integratie met het CRM-systeem dat hier gebruikt wordt (Siebel voor de geïnteresseerden onder ons) zal in fase 1 voortaan de klant- en verbruiksgegevens worden ingevoerd in Siebel.

De java-applicatie heeft echter deze gegevens wel nodig om een offerte te kunnen maken, dus zullen deze gegevens met XML worden doorgegeven. Via de GUI van de java-applicatie kunnen medewerkers dan een offerte aanmaken, en oa de status hiervan bijhouden. Iedere offerte die wordt aangemaakt of gewijzigd moet ook in Siebel (read-only) te zien zijn, dus de java-applicatie zal voor iedere nieuwe/gewijzigde offerte een XML-bericht naar Siebel sturen.

Aangezien de java-applicatie niet altijd vanuit Siebel wordt aangeroepen is er dus geen sprake van een request-response scenario. In fase 1 is er dus nog sprake van 1 type (layout) bericht naar Siebel, en 1 type bericht van Siebel, maar zoals het er nu naar uit ziet zullen in volgende fases er ook andere types berichten ontvangen en verwerkt moeten gaan worden.

Welke technieken raden jullie me aan om me in te gaan verdiepen en welke niet? Ik heb al aardig wat termen (SAX, DOM, JDOM, SOAP, SAAJ, Xerces, Xalan etc) voorbij zien komen, maar heb gewoon de tijd niet om me te verdiepen in allen, dus hoop dat jullie me op weg kunnen helpen..

Alvast bedankt!

[Verwijderd]

misschien een hele stomme vraag maar waarom heb je deze job dan geaccepteerd als je er geen tijd voor hebt!
misschien een goed idee om het uit te besteden! aangezien je geen tijd en kennis hebt om dit te kunnen doen... zeker bij een bedrijfs kritisch process wil je hoge kwaliteit kunnen leveren! met deze voor waarden is dat onmogelijk

[mbravenboer]

Je moet het probleem een beetje onder verdelen.

Eerst moet je bekijken hoe de XML die uitgewisseld wordt tussen de applicaties eruit ziet of moet gezien. Is dit pure data zonder frutsels? Is het SOAP? Is het XML-RPC? Liefst moet je dit niet verwarren met de manier waarop je 1 van de applicaties gaat programmeren. Als deze het XML formaat te sterk gaat beinvloeden zou het voordeel van XML weleens verloren kunnen gaan. De structuur van dit formaat moet bij voorkeur vastgelegd worden in een schema. Dit kan je bijvoorbeeld in W3C XML Schema of RELAX NG doen.

Daarna ga je bekijken hoe je die XML gaat verwerken in je applicatie. Hiervoor kan je kiezen uit een hoop verschillende mogelijken. Hierover heb ik in dit topic al eens wat geschreven: [rml][ Java] starten met XML[/rml] . Kort samengevat moet je kiezen welke interface met de XML parser je kiest. Zowel SAX, DOM als Pull parsing zijn interfaces tot de XML parser. In principe is het niet echt een fundamentele beslissing voor welke van deze drie kiest. XML Data Binding is soms een aantrekkelijk alternatief.

Je zult ook een XML parser moeten kiezen. De meeste parsers ondersteunen verschillende interfaces. Xerces is een parser die ook W3C XML Schema validatie ondersteunt. De keuze voor je interface kan grotendeels los staan van de parser die je gebruikt. De meeste representaties worden namelijk geproduceerd via SAX. JDOM is een prettige DOM achtige implementatie voor Java en deze ondersteunt constructie van een JDOM via SAX.

Als je XML moet transformeren kan XSLT handig zijn, maar dat is niet direct een tool die je design keuze beinvloed. Je pakt het gewoon wanneer je het nodig hebt.

[Banaan]

Verwijderd schreef op 29 October 2003 @ 11:26:
misschien een hele stomme vraag maar waarom heb je deze job dan geaccepteerd als je er geen tijd voor hebt!
misschien een goed idee om het uit te besteden! aangezien je geen tijd en kennis hebt om dit te kunnen doen... zeker bij een bedrijfs kritisch process wil je hoge kwaliteit kunnen leveren! met deze voor waarden is dat onmogelijk

Hehe welkom in de wondere wereld van detachering! Ik zit bij deze klant en die wil dit. Ik heb de java-applicatie vanaf de grond af opgebouwd en ken die dus door en door. De klant wil dus dat ik dit ook ga doen, en normaal is dit niet zo'n probleem, want het heeft zeer zeker mijn interesse, alleen is er nu een harde deadline waardoor ik enigszins in de problemen kom. Een extra persoon erbij is voor de klant geen optie, dus ik zal het toch echt moeten oplossen. Nu gaat me dat heus wel lukken, maar hoop gewoon wat tijd te besparen door jullie wat tips en aanbevelingen te vragen..

[ Voor 28% gewijzigd door Banaan op 29-10-2003 11:41 ]

[Robtimus]

JDOM
Die gecombineerd met (de bijgeleverde) xerces library voor het parsen zelf werkt uitstekend en intuitief, omdat de new SAXBuilder().build(FILE).getRootElement() constructie een boomstructuur teruggeeft. Daarmee kun je imho heel goed werken.

Alleen was iemand me voor

[ Voor 6% gewijzigd door Robtimus op 29-10-2003 11:43 ]

[udenjpg]

Ikzelf prefereer DOM4J ipv. JDOM.
Het is (een heel klein beetje) sneller, gebruikt minder geheugen en heeft ingebouwde JAXEN support (X-Path).

Als het een strak gedefinieerde XML betreft kun je beter Zeus of Jax-B gebruiken.

[Alarmnummer]

Ik werk zelf ook met JDom en afgezien dat het lastig is om regel en colom info op te halen bij het parsen (handig voor foutmeldingen), werkt het echt handig.

Je zou trouwens ook kunnen kijken naar een databinding framework generator. Op basis van je schema/dtd bestand worden java bestanden gegenereerd die alles inlezen in plaatsen in java 'dummy' objecten.

Je zou hier ook nog naar kunnen kijken, maar eigelijk vind ik JDom al goed genoeg werken.

Ik maak trouwens 1 class met statische methodes , Persoon readPersoon(Element root) en Element writePersoon(Persoon p) die dus XML naar java objecten omzetten of andersom. Werkt imho heel handig.

[Robtimus]

Alarmnummer schreef op 30 oktober 2003 @ 11:37:
Ik maak trouwens 1 class met statische methodes , Persoon readPersoon(Element root) en Element writePersoon(Persoon p) die dus XML naar java objecten omzetten of andersom. Werkt imho heel handig.

Ikzelf maak als dat nodig is een constructor en een toXML() method, public Persoon(Element root) en public Element toXML(). Vind ik persoonlijk iets netter.

[Alarmnummer]

IceManX schreef op 30 oktober 2003 @ 12:30:
[...]
Ikzelf maak als dat nodig is een constructor en een toXML() method, public Persoon(Element root) en public Element toXML(). Vind ik persoonlijk iets netter.

Ik snap niet helemaal wat je bedoelt.

Ik heb een 'XMLMapper' object die dus 2 publieke methodes heeft,

static void write(XXX item, File file)throws XMLMapperException;

static XXX read(File file)throws XMLMapperException;

En verder maak ik voor iedere object dat gemapped van en naar XML moet worden een read en write methode zoals ik hierboven al had beschreven, deze methodes zijn private.

Ik hoop verder niet dat jij de XML afhandel code in je 'domein' objecten zelf hebt gedaan. Alle aspecten van een systeem probeer ik wel te scheiden en zeker niet te mixen. Hierdoor blijven mijn 'domein' objecten een stuk cleaner (en mijn ontwerp ook)

[ Voor 23% gewijzigd door Alarmnummer op 30-10-2003 12:39 ]

[Robtimus]

Alarmnummer schreef op 30 oktober 2003 @ 12:37:
Ik hoop verder niet dat jij de XML afhandel code in je 'domein' objecten zelf hebt gedaan. Alle aspecten van een systeem probeer ik wel te scheiden en zeker niet te mixen. Hierdoor blijven mijn 'domein' objecten een stuk cleaner (en mijn ontwerp ook)

Die ene keer dat ik het gedaan heb eigenlijk wel, vond ik wat gemakkelijker (ik ben lui ja!).

De allerbeste manier zou zijn om het dmv aspect oriented programming te doen, dus AspectJ gebruiken. Kijk maar eens op http://eclipse.org/aspectj/

[Alarmnummer]

IceManX schreef op 30 oktober 2003 @ 12:54:
[...]
Die ene keer dat ik het gedaan heb eigenlijk wel, vond ik wat gemakkelijker (ik ben lui ja!).

tsss

De allerbeste manier zou zijn om het dmv aspect oriented programming te doen, dus AspectJ gebruiken. Kijk maar eens op http://eclipse.org/aspectj/

Dat zou je kunnen doen, en zie verder mijn sig hoe ik over aop denk