This blog has moved to
http://blog.matthias-reining.com

Die bestehenden Artikel bleiben vorerst alle bei blogspot. Neue Artikel veröffentliche ich allerdings nur noch auf http://blog.matthias-reining.com

Donnerstag, 25. Oktober 2012

Software Architektur - Designentscheidung: Modelgetriebene Entwicklung


Als Software Architekt steht man zu Projektbeginn vor vielen Entscheidungen.
Eine Entscheidung ist unter anderem ob man Modelgetrieben, inkl. Casetool-Unterstützung, vorgehen will oder eben nicht.

Im folgenden einige Punkte wieso ich mich bisher gegen den MDA / MDSD Ansatz (Model Driven Architecture, Model Driven Software Development) entschieden habe:

  • MDA ist cool wenn es ein großes unternehmensweites Datenmodell gibt.
    Unternehmensweite Datenmodelle sind aufgrund der Service Orientierung etwas aus der Mode gekommen (der erste google Treffer zu „Unternehmensweite Datenmodelle“ ist ein Artikel aus der Computerwoche von 1989 (http://www.computerwoche.de/heftarchiv/1989/37/1151959/).

    In größeren Unternehmen existieren viele spezialisierte Applikationen die nur über definierte Schnittstellen kommunizieren müssen (beispielsweise über BUS- oder Workflowsysteme). Eine SOA passt hier oft besser als eine große Anwendung, die mit einem unternehmensweiten Datenmodell umgehen kann.

    Kleine modulare Applikationen à Sind die einzelnen Applikationen klein bzw. auch deren Datenmodell, stellt sich die Frage ob der Einsatz eines Case-Tools mit Klassengeneratoren eher die Produktionsgeschwindikgeit ausbremst.
  • Beim Einsatz eines OR-Mappers bspw. basierend auf JPA wie Hibernate oder EclipseLink ist schon seit langen kein aufwändiges XML mehr notwendig. Mit Hilfe von Annotations lassen sich die Datenbank-Entitäten definieren.

    Bei der Verwendung eines MDA-Ansatzes können XML Beschreibungen zu den Java-Entitäts-Klassen automatisch generiert werden. Hier ist ein MDA Ansatz durchaus sinnvoll.

    Bei der Verwendung von Annotations wie bspw. in der JEE (@Entity) lässt sich sehr schlank ein Datenmodell definieren. Der Einsatz von Case-Tools mit Klassengeneratoren verringern hier eher die Produktionsgeschwindigkeit.

  • Werden UML Diagramme primär zur Dokumentation benötigt, lassen diese sich bequem aus den bestehen Klassen generieren. Diese können bei der JEE direkt ins JavaDoc integriert werden (UMLGraph).


  • MDA / MDSD wird im Moment in meiner Wahrnehmung aktuell weniger gepusht als JEE6.
    Verhältnis der JPA Vorträgen zu Modelling- Vorträgen auf aktuellen Java Konferenzen. Ggf. ist dies ein Grund wieso MDA Know How weniger verfügbar ist als JPA Know How.

    Als technisch Verantwortlicher für eine Software ist dies ein nicht unwesentlicher Punkt (gibt es Rotationsmöglichkeiten für Entwickler, welches Know How wird zur Softwarewartung benötigt).



Aus diesen Gründen habe ich mich meist gegen MDSD entschieden… ich geh allerdings davon aus, dass es noch weit mehr Gründe gibt ;-)


Dienstag, 16. Oktober 2012

JBoss AS Security - @RolesAllowed

Mit der Annotation @RolesAllowed (javax.annotation.security.RolesAllowed) kann der Zugriff auf Klassen oder einzelne Methoden von einem AppServer kontrolliert werden.

Leider haben diese Annotation im JBoss AS 7 keine Auswirkungen!

Um EJBs abzusichern wird die Datei jboss-ejb3.xml benötigt (Maven Projekt: src/main/webapp/WEB-INF/jboss-ejb3.xml).

<?xml version="1.0"?> 
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
               xmlns="http://java.sun.com/xml/ns/javaee"
               xmlns:s="urn:security"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
                     http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
               version="3.1"
               impl-version="2.0">
  <assembly-descriptor>
    <s:security>
      <ejb-name>*</ejb-name>
      <s:security-domain>other</s:security-domain>
    </s:security>
  </assembly-descriptor>

</jboss:ejb-jar>

Die Security Domain “other” ist die Default-Security-Domain auf einem JBoss AS 7. Hier muss bei Bedarf die entsprechende Domain gesetzt warden.

Finde ich irgendwie merkwürdig, dass Teile der JEE Spec erst explizit aktiviert werden müssen.
Beim Deployen einer Anwendung wäre IMHO ein kleiner Hinweis angebracht, der darauf aufmerksam macht, dass  @RolesAllowed verwendet wird aber nicht greift…


Donnerstag, 11. Oktober 2012

Start Tweeting

ich habe jetzt schon seit "Ewigkeiten" einen Twitter-Account / aber noch nie was gezwitschert.

Hat sich mittlerweile geändert! Ich twittere jetzt auch und freu mich über Follower :-)

http://twitter.com/MatthiasReining