[ejb] standaard.

[Alarmnummer]

Waarin verschillen de EJB-vendors in hun EJB-implementaties? Ik heb al een paar keer gehoord dat ze zich vaak niet houden aan 'de standaard'. Maar waarin verschillen ze dan? En dan doel ik verder niet op performance ed, maar puur op configuratie en development.

[mbravenboer]

Ik heb de indruk dat dit vooral een historisch probleem is, maar je bent op de hoogte van mijn gebrekkige ervaring met EJB, dus neem die indruk niet te serieus .

Je zag dat er vendor specifieke uitbreidingen en mogelijkheden aangeboden werden, die vaak zo nuttig waren dat ze ook daadwerkelijk gebruikt werden. Hierdoor is de zaak niet meer portable over de verschillende aanbieders, wat uiteraard niet echt het idee is van een J2EE standaard.

Je zag echter steeds opnieuw dat dergelijke uitbreidingen of mogelijkheden opgepikt worden in het JCP en na allerlei voorstellen en overleg tot standaard verheven werden. Ik heb de indruk dat we nu op een punt zitten waarop veel noodzakelijk materiaal op deze manier verwerkt is.

[Alarmnummer]

Ik heb intussen al wel ontdekt dat de entity-mapper wel vendor specifiek is.

HTML:

<jbosscmp-jdbc>
    <enterprise-beans>
        <entity>
            <ejb-name>GangsterEJB</ejb-name>
            <table-name>gangster</table-name>
            <cmp-field>
                <field-name>gangsterId</field-name>
                <column-name>id</column-name>
            </cmp-field>
            <cmp-field>
                <field-name>name</field-name>
                <column-name>name</column-name>
                <not-null/>
            </cmp-field>
            <cmp-field>
                <field-name>nickName</field-name>
                <column-name>nick_name</column-name>
                <jdbc-type>VARCHAR</jdbc-type>
                <sql-type>VARCHAR(64)</sql-type>
            </cmp-field>
            <cmp-field>
                <field-name>badness</field-name>
                <column-name>badness</column-name>
            </cmp-field>
            <!-- Load Groups -->
            <!-- Queries -->
        </entity>
    </enterprise-beans>
</jbosscmp-jdbc>

Maar als dit het enigste is wat verschilt, dan is het nog te overzien.

[ Voor 40% gewijzigd door Alarmnummer op 26-04-2003 17:23 ]

[Verwijderd]

EJBs zijn redelijk standaard. Er zijn een stel specificaties (J2EE 1.3 specs is de meest gebruikte op dit moment). In die specificaties wordt een DTD aangeboden die een xml bestand beschrijft waarin de generieke gegevens staan van je EJBs (de ejb.xml file) (voor web applicaties heb je web.xml en voor ears application.xml).

Nu is niet alles in deze xml bestanden te beschijven en bieden veel J2EE implementors extra mogelijkheden om je beans te optimaliseren (denk hierbij aan read-only beans, specifieke settings, cluster informatie etc.. etc..) hiervoor is echter geen standaard omdat het buiten de ejb specificaties valt.

Het lastige is dat ook al zijn er heel veel overeenkomstige zaken tussen de verschillende implementaties toch iedereen zo zijn eigen opzet heeft. Ook bij CMP , zoals je al opmerkte, heb je dit verschijnsel.

Zoals mbravenboer ook al zegt zijn heel veel van die zaken asl door de JCP gevoerd en tot standaard verheven. Als je je dus aan de standaard houdt en niet van vendorspecifieke zaken gebruik gaat maken (bijv. dynamisch jms topics aanmaken of roles definieren etc), maar alleen de dingen doet die in de specs staan zul je niet tegen veel problemen oplopen.

Het grootste probleem is 'descriptor hell'. Heb je een mooie J2EE applicatie gemaakt , compleet volgens de specs, en hij draait perfect op JBoss dan heb je nog steeds wel werk te doen om hem op een weblogic aan de gang te krijgen. Je moet portable dan ook niet zien als , hup deployen en klaar. Maar meer als ,descriptors voor de nieuwe app server maken, deployen en testen en dan pas klaar.

Maar gelukkig zijn hier ook al steeds meer tools voor. Zoals ik al vaker heb lopen roepen. XDoclet is een perfect tooltje hiervoor. Hiermee houdt je alle bean gerelateerde informatie in de sourcefile (als MetaData in de javadocs) , in je ant build file specificeer je voor welke applicatie servers je je descriptors wil genereren en XDoclet doet de rest voor je. Ik heb zelf een redelijk grote applicatie in een middagje naar 3 verschillende applicatieservers gedployed met XDoclet, werkt echt erg goed.

[Alarmnummer]

Zo lang het alleen de descriptor is, dan vind ik het niet zo`n ramp. Ik genereer dat ding verder (voorlopig) toch niet. En ik denk niet dat het nodig is dat mijn systeem vendor-specifieke descriptor info nodig heeft.

Als de basis structuur in ieder geval maar hetzelfde is, zodat ik tenminste al mijn informatie eruit kan halen. Ik moet genoeg info hebben om de entity-record-types op te bouwen, en ik moet genoeg info hebben om de missende interfaces/classes te genereren. En verder moet ik nog info hebben om queries te wrappen in functies. Ik denk dat dit allemaal wel gaat lukken.