Twee wegen naar Enterprise Java

De nieuwste ontwikkelsoftware wil niet meer Integrated Development Environment (IDE) heten, maar Model-Build-Deploy Development Platform. In deze categorie beloven OptimalJ en Together ControlCenter beide dat ze Enterprise Java toepassingen maken aan de hand van een visueel model. In de praktijk blijken deze twee producten enorm te verschillen.

Opmerking: dit artikel bestaat uit meedere pagina’s; klik op de cijfertjes rechtsboven om de verschillende pagina’s op te vragen.

Bij de eerste kennismaking gelijken OptimalJ en Together ControlCenter sterk op elkaar. Beide draaien ze op de Java Developer’s Kit 1.3 (JDK13), met een saai grijze gebruikersinterface. Ze claimen een volledige IDE, ondersteund met UML (Unified Modeling Language) modellen, en bevatten naar Java traditie massa’s instelmogelijkheden. Codebibliotheken en documentatie van derden zijn gemakkelijk toe te voegen, en beide producten steunen op bij voorkeur Open Source utilities, zoals Ant voor makes, versiebeheer met CVS (Concurrent Versions System), en Tomcat als toepassingsserver, om zich tot enterprise ontwikkelgereedschap te completeren.

Compuware OptimalJ

Het meest ambitieus zijn wel de aanspraken van Compuware. Met OptimalJ, hun ‘Model-Build-Deploy Development Platform’ dat nu aan versie 2.0.02 toe is, moet je naar hun zeggen niet langer inzitten met het tekort aan Enterprise Java (J2EE) specialisten. Het laat zowaar beginnende programmeurs toe complexe J2EE te genereren vanuit een diagram in Unified Modelling Language (UML). Gevorderde ontwikkelaars krijgen daar een complete geïntegreerde ontwikkelomgeving (IDE) bovenop, namelijk de open source Netbeans 3.2.

Met OptimalJ volg je een vast ontwikkeltraject. In een domain model stel je het probleemdomein voor als een UML Class Diagram. Daaruit genereer je het toepassingsmodel, met als subcomponenten het databasemodel, het Enterprise Java Bean (EJB) model, en het webmodel. Daar kan ook nog een connectiemodel bijkomen, om koppelingen te leggen met CORBA (Common Object Request Broker Architecture) en met COBOL/CICS (Customer Information Control System) en omgevingen; vanuit een COBOL LINKAGE SECTION maakt OptimalJ in dat geval de juiste interfaces.

Uit het toepassingsmodel tovert OptimalJ werkende Java- en SQL-code en Java Server Pages (JSP). Daaraan kun je nog stukjes toevoegen, om ze ten slotte in dezelfde OptimalJ/Netbeans werkomgeving te compileren, debuggen en uitvoeren. Bij het eindproduct horen ook XML (Extensible Markup Language) deployment descriptors, instructies om de toepassing in productie te geven op de verschillende ondersteunde toepassings- en webservers. Niets is immers vervelender dan die administratie zelf te moeten uitvoeren.

OptimalJ geeft in de broncode aan waar de ontwikkelaar eigen code mag toevoegen, en waar niet. De eigen Java-editor dwingt dat af, en kleurt die blokken ook anders in. Als je een externe codebewerker gebruikt, kan dat natuurlijk niet. Je ziet dan dat beschermde code wordt aangegeven door commentaarlijnen met een sleutel, mogelijk een checksom, maar niemand geeft een kik als je daarin vals speelt. Aangezien de testversie bij hergeneratie alle bronbestanden wist, heb ik niet kunnen nagaan of OptimalJ bij opnieuw genereren alles zomaar overschrijft. In gegenereerde SQL- en JSP-code is de aanduiding van beschermde delen er ook wel, maar bescherming wordt niet afgedwongen, zelfs niet gestimuleerd door inkleuring.

Eenheidsworst

Met dat ontwikkeltraject ligt meteen ook de architectuur vast van alle projecten die je in OptimalJ uitwerkt. EJB’s (Enterprise Java Beans) op de J2EE (Java 2 Platform Enterprise Edition) Application Server halen de gegevens op via JDBC (Java Database Connectivity) en (elementaire) SQL; JSP’s (Java Server Pages) stellen het resultaat voor in HTML- (Web) of WML- (wap) documenten, en servlets smeden dat aaneen. Een vrij complete J2EE implementatie, daar niet van, maar soms mag het wel wat minder zijn. Als voorbeeld testte ik een project met 3 tabellen, van elk 4 kolommen. Daaruit maakt OptimalJ welgeteld 107 Java klassen, en daarbovenop nog 13 JSP- en 43 XML-bestanden. En dan heb je nog geen WAP-interface! Bij Compuware mogen ze daar de trendy woorden ‘patterns’ en ‘best practice’ voor gebruiken, bij ons noemen ze dat de bruutgeweldmethode.

Van mooie woorden kent men wel wat, daar bij Compuware. UML wordt in OptimalJ verengd tot Class diagrammen, enkel voor het domain model, en daar is het niet eens het meest geschikte UML diagram voor. Het domain model blijkt immers niet veel meer dan een gegevensmodel te zijn: langs de ene kant kan je gewoon de gegevensstructuur uit een bestaande database importeren. En langs de andere kant wordt het domain model 1-op-1 vertaald naar een SQL-databaseschema: een tabel per klasse met een kolom per attribuut. Compuware noemt dit fier ‘object-to-relational mapping’.

Wat een OptimalJ-toepassing uiteindelijk naar de browser van de eindgebruiker stuurt, is per tabel een schermpje voor wijzigen en eentje voor raadplegen. Laat dat dan in een gedistribueerde omgeving gebeuren, veel is het niet. Als je extra’s wil, moet je in het webmodel en het EJB-model bijkomende schema’s definiëren, om koppelingen tussen tabellen uit te buiten. In EJB Session componenten distilleer je daaruit een meer gevarieerde kijk op de database. Dit verder ‘modelleren’ gebeurt echter met pop-up wizards en property-lijstjes, volledig zonder grafische ondersteuning. Misschien wel goed, want de diagrambewerker van het domain model liet ik ook al gauw links liggen: slechte navigatie-mogelijkheden, geen hulp om objecten te schikken of uit te lijnen, gebrekkige synchronisatie met propertylijsten, cryptische foutboodschappen, en dikwijls liep zelfs de grafische weergave in de soep.

Langere ontwikkelcyclus

Ook de zogeheten business rules vallen al snel door de mand. Beperkingen of elementaire bewerkingen op gegevensinvoer, en formules om afgeleide gegevens te verkrijgen, kan je in de business expression editor van het EJB model vastleggen. In dat stadium heb je nog geen broncode, maar die business expressions noteer je wel in SQL- of Java-syntax in een klein tekstvenstertje. Alle gebruikelijke codeerhulpjes blijven hier achterwege; je ziet zelfs niet welke veldnamen je kunt gebruiken, zodat je uiteindelijk best eerst op papier codeert, om achteraf over te tikken in die business rule editor. Wil je in de business rules hulpmethodes aanroepen, dan kan je die pas schrijven nadat je uit het EJB model broncode bestanden laat aanmaken. Idem dito voor het gebruik van die business rules; je kunt dat niet afdwingen, dat is niet voorzien in de modellen. Aanroepen daarvan moet je achteraf met de hand in de juiste broncodebestanden aanbrengen. In OptimalJ terminologie heet dat waarschijnlijk “definiëren in het broncodemodel”. Dit maakt dit deel van de ontwikkelcyclus onnodig lang en foutgevoelig: schrijven-compileren-testen wordt hier schrijven-genereren-compileren-verbeteren.

Het allerergste is wel dat OptimalJ je na al dat modelleren nog foute code in de maag splitst. Een geldig domain model, door OptimalJ zelf goedgekeurd, kan toch ongeldige toepassingsmodellen voortbrengen. Dwaasheden, zoals de eigenschap 1-of-meer voor een klasseattribuut, worden zonder meer aanvaard voor het domain model. In het daaruit gegenereerde webmodel geeft dit dan de welluidende foutboodschap: “Error: usedServingAttribute in crm.ejb.CustomerSC.customer of an EJBSessionComponent must refer to a set of EJBServingAttributes of EJBEntityComponents that corresponds to the set of its served EJBDataClasses”, voor een fout die niet in mijn Customer klasse zat, maar in mijn ServiceAgreement klasse.

Ik kan lang blijven kankeren op OptimalJ, maar al die kleine tot hoogst vervelende fouten in dit product, die verdwijnen eigenlijk in het niet vergeleken met de globale onbruikbaarheid. Ik ben er uiteindelijk wel in geslaagd een toepassing te genereren, maar niet degene die ik had willen ontwerpen. Toen die dan strop liep op een duidelijk uit de lucht gegrepen foutmelding van het meegeleverde Solid DBMS (Database Management System), bij het invoeren van het SQL-schema, heb ik niet verder aangedrongen. Ik ben ervan overtuigd dat men bij Compuware dit product getest heeft, en dat hun ervaren specialisten na de nodige opleiding bruikbare toepassingen kunnen ontwikkelen met OptimalJ. Maar ik denk dat uw informatici gemakkelijker op te leiden zijn tot Enterprise Java experts, dan tot OptimalJ liefhebbers.
Je kunt OptimalJ downloaden en met een testlicentie 15 dagen zelf uitproberen. Met een dergelijk enterprise product is dat wel wat kort, zelfs voor een test zoals voor dit artikel. Bovendien krijgt de testlicentie een aantal vervelende beperkingen mee. Specifieke voorzieningen voor grote ondernemingen, zoals de koppeling met CICS/CORBA of de import van modellen uit bestaande databases of UML-bestanden, zijn zelfs uitgeschakeld.

Together ControlCenter

Together ControlCenter is al langer op de markt, en heeft met deze versie 5.5 ook J2EE ondersteuning gekregen. Together heeft, net als OptimalJ, een volledige IDE onder de vleugels. Ditmaal krijgen we echter een rasecht UML modelleer-gereedschap, dat bovendien veel beter geïntegreerd is met de rest van de IDE. Opmerkelijk is ook hoe Together zich voorziet op de verschillende functies binnen een projectgroep. Afhankelijk van je functie start je op met een bepaald zicht op het project, terwijl je andere onderdelen niet of enkel op aanvraag kan gebruiken. Zo zijn er vier voorgedefinieerde rollen, van programmeur tot ‘business modeller’. Deze laatste start bijvoorbeeld steeds met de diagrambewerker op, en kan broncode wel bekijken, maar niet compileren. Het is een fluitje van een cent om voor elke rol in te stellen welke onderdelen van Together hij kan gebruiken. Op deze manier kan Together door projectmedewerkers met een verschillende achtergrond gebruikt worden. Bovendien kan Together meerdere talen aan. De ondersteuning is het meest uitgebreid voor Java en C++, maar ook CORBA/IDL en Visual Basic 6 komen aan bod, met zelfs al een voorproefje van C# en VisualBasic.NET.

Diagrammen

Je begint het modelleren van je toepassing natuurlijk in de diagrambewerker. Die kan al mijn favoriete diagrammen uit de UML standaard aan: Activity, Class, Collaboration, Component, Deployment, Sequence, Statechart en Use Case. Aanvullend heeft Together ook enkele eigen diagrammen. In het Business Process diagram beschrijf je de werking van een systeem na implementatie. Op basis van EJB Assembler, Enterprise Application en WEB Application diagrammen worden XML deployment descriptors voor gedistribueerde toepassingen aangemaakt, en worden componenten verpakt in de juiste Java en Web Application archieven (JAR en WAR). Verder doe je de gegevensanalyse in het Entity Relationship diagram, gebruik je een Robustness diagram om je Use Case diagrammen te inspecteren, definieer je JSP tag bibliotheken in het Taglib diagram, en Document Type Definitions in het XML Structure diagram.
Vanuit de diagrammen wordt, voor zover van toepassing, onmiddellijk code gegenereerd in de gekozen taal. Bovendien wordt bijvoorbeeld ook de toevoeging van een methode in broncode direct weerspiegeld in het diagram. De integratie tussen IDE en diagrammen blijkt ook uit de vlotte navigatie. Die gebeurt door hyperlinks, zelf gedefinieerd of gewoon op naam, of ook vanuit de hiërarchische verkenner of met een zoekfunctie. Verder kan je vlot in- en uitzoomen en je weg zoeken in het diagramoverzicht in een zijvenster. Dit alles maakt van Together een erg interactief ontwikkelgereedschap, daar waar OptimalJ zich meer gedraagt als uit de kluiten gewassen wizard.

Niet slim genoeg

De ‘refactoring’ optie voor broncode is om van te watertanden. Een stuk code dat je wil afzonderen in een aparte methode, selecteer je gewoon, en Together doet al het werk; zelf moet je enkel een treffende naam opgeven. Together kent genoeg van Java om de juiste return-waarde uit te cijferen, of te signaleren dat een routine niet eenvoudig af te zonderen valt.

Toch brengt ook Together me nog niet in verrukking. Te veel features zijn op het randje af onbruikbaar door een gebrekkige implementatie. Code autocompletion is bijvoorbeeld niet slim genoeg om bij niet-elementaire uitdrukkingen het type te bepalen, en kan dus ook de mogelijke operaties daarop niet laten zien. Als je een eigenschap van een attribuut wijzigt in de verkenner of in het property-venster, rolt het codeervenster steeds terug naar de top. Via dat property-venster kun je ook documentatie aanmaken, met een preview van de resulterende Javadoc HTML. Maar het is verwarrend dat het property-venster enkel reageert op je selectie in het diagramvenster, niet op die in het codevenster. Ik weet dat je documentatie beter vooraf, in de diagrammen dus, aanmaakt, maar tijdens het coderen wil je daar toch dikwijls wat in verduidelijken.

Ook een gereedschap zoals de code audit heeft veel potentieel, maar is even oppervlakkig, soms zelfs storend, als de ‘geavanceerde’ spellingchecker van moderne tekstverwerkers. Ik mis daarin vooral de mogelijkheid om zogezegde fouten blijvend als goed aan te duiden, want ik wil niet iedere keer weer het hele lijstje moeten nakijken. Een prachtig hulpmiddel voor de grotere programmeershops zijn de Metrics. Dit is zowat de Grammatik van Java en C++, die je programmeerstijl analyseert. Via export naar diagrammen en tabellen kan dit mooi dienen als meetinstrument voor de complexiteit en verschillende facetten ‘aanbevolen stijl’ van een groep programma’s. Echt prachtig zou het worden moest je met die Metrics overzichten kunnen krijgen per programmeur.

Wil je Together uittesten, dan kan je het pakket downloaden en per e-mail een testlicentie aanvragen. Buiten de alweer korte evaluatieperiode (15 dagen) geeft de testlicentie verder geen beperkingen. Downloaden kan wel ergernis geven: ik heb het twee keer geprobeerd met MS Internet Explorer en nog een keer met Netscape, en juist voor het einde ervan was mijn pc keer op keer zo goed als geblokkeerd. Als enige uitweg zag ik de duw op de reset-knop Blijkt dat beide browsers vroegtijdig de download scan van mijn MacAfee VShield activeerden. En die had een zware klus, ruim een uur, aan de verschillende lagen van compressie in het installatieprogramma. Dat heb ik achterhaald aan de hand van de CD-ROM die ik uiteindelijk aanvroeg.