Einige Anfragen bei Google ließen mich checken ob der Pfad zu Ant HOME richtig gesetzt ist(siehe: http://www.herrodius.com/blog/42). Der Pfad war vollkommen korrekt doch meine Main Methode wurde nach wie vor nicht gefunden. Ein anderes Projekt im gleichen Workspace lief und so fing ich an die Projekte zu vergleichen. Mit fiel auf, dass das funktionsfähige Projekt ohne Maven Dependency Management auskamen. Also deaktivierte ich das Dependency Management und probierte einen Start aus. Die Main Methode wurde nun gefunden. Danach aktivierte ich das Dependency Management wieder und welch Überraschung – das Main Methode wurde auch weiterhin gefunden.

Hier möchte ich euch kurz mein heutiges Problemm schildern. Ich habe Eclipse Helios und über den Eclipse Marketplace Sonatype’s m2eclipse und die dazugehörigen Extras installiert. Ich habe in der Vergangenheit schon gute Erfahrungen mit dem Maven 2 Plugin gemacht. Um ein zusätzliches Repository zu dem Standard Nexus hinzufügen musste man die Maven Indexes View hervorholen. Dort konnte man komfortabel ein weiteres Repository anlegen. Heute habe ich aber nur eine View namens "Maven Repositories" gefunden und keinen Button zum hinzufügen eines weiteren Repositories. Also schaute ich bei Sonatype in die Dokumentation und die zeigte weiterhin den mir bisher bekannten Weg. Wenn die Maven Indexes View also nicht existiert, wie soll ich dann ein neues Repository hinzufügen?

Lösung: Die Maven Repository View zeigt das lokale ein globales und alle von Projekte referenzierten Repositories an. Das heißt wenn man in die POM eines Projektes erstmal ein Repository eingetragen hat, sieht man es nach dem Speichern auch in der neuen View. Ich finde den neuen Weg persönlich weniger intuitiv als die vorherige Lösung. Zudem zeigt die Dokumentation von Sonatype noch den alten Weg.

Beispiel: Für mein jBPM 4.3 Projekt müssen folgende Zeilen in die pom.xml eingefügt werden damit das Repository mit aufgenommen wird.

  
     
  	jboss
  	JBoss Repository
  	http://repository.jboss.com/maven2
    
  

Danach kann wieder komfortabel in Maven Manier nach den gewünschten Dependencies gesucht werden. Da ich speziell mit jBPM 4.3 entwickle möchte ich euch die folgende Quelle ans Herz legen, die Dependencies für jBPM 4 auch nett visualisiert: http://community.jboss.org/wiki/jBPM4MavenDependencies.

Das Ergebnis der Analyse war ein Datenbank Dump, der im Commetrix Schema gespeichert wurde. So konnten die Ergebnisse mit Hilfe von Commetrix visualisiert werden. Die Ergebnisse seht Ihr auf den Screenshots weiter unten.

Exemplarisch starke Korrelationen bestanden zum Beispiel zwischen den Worten Gas und Price sowie zwischen President und Election. Unzählige weiter Beispiele könnte ich an dieser Stelle auflisten. Zusammenfassend hat die Lehrveranstaltung sehr viel Spaß gemacht und mich für das Thema semantische Netze begeistert.

Screenshot der Anwendung

Screenshots der visualisierten Topic Map

 

In meinem Java Projekt habe ich eine Datenbank Verbindung in der persistence.xml konfiguriert. So bin ich es aus Eclipse gewohnt und es funktioniert alles bestens. Die Anwendung konnte unter Netbeans jedoch keine Verbindung zu meiner Datenbank herstellen. Und nun haltet euch fest: Wenn man die Datenbank in der IDE gesondert einträgt unter dem Tab "Services" ist Netbeans so schlau und erkennt, dass die Verbindung scheinbar doch richtig konfiguriert wurde und stellt die Verbindung zur Datenbank her. Warum reicht es Netbeans denn nicht wenn die Verbindung in der XML eingetragen ist? Wenn jemand von euch Details dazu hat, lasst es mich doch bitte wissen.

Versionierung

• Subclipse oder Subversive: Subversion Clients

Code Analyse:

• JDepend: Tool zur Analyse von Architektur und Abhängigkeiten
• PMD: Code Analyse, sucht nach potentiellen Bugs und Problemen

Codestyle:

• Checkstyle: Regelsystem zur Einhaltung von Code Konventionen
• JAutodoc: automatische Generierung von Javadoc Kommentaren

Testing / Code Coverage:

• Emma for Eclipse oder Clover (Llizenzpflichtig)

Build

• Maven2 for Eclipse: Integration des Build Tools in die Eclipse IDE

Development

• JBoss Tools: nützlich für die Entwicklung mit dem JBoss Application Server

Seid Ihr mit meiner Plugin Sammlung zufrieden oder gibt es Plugins, die hier unbedingt mit auftauchen sollten? Mir fällt noch eines ein, dass ich schon ewig nicht mehr benutzt habe – der Visual Editor. Da die Entwicklung des Visual Editors nur schleppend voran ging und die Unterstützung in neueren Eclipse Versionen nicht immer gegeben war, habe ich mich regelmäßig mit dem guten Editor von Netbeans beholfen.

Nachdem das Ziel beschrieben ist kann die Arbeit beginnen. Ich habe sehr viele Screenshots verwendet um den Weg möglichst anschaulich zu machen.

Insgesamt werden 4 Projekte angelegt. Beginnen möchte ich mit einem Projekt, dass die einzelnen WebServices (YingService, YangService und MatchService) enthält, die dann im BPEL Prozess verwendet werden.

Dazu legen wir einfach eine neue Web Application an und fügen anschließend die drei WebServices hinzu.

Jeder dieser WebServices hat jeweils eine Methode, die man über Add Operation hinzufügen kann. In dem dazugehörigen Dialog kann man sowohl Parameter als auch Rückgabetyp festlegen. In diesem Beispiel habe ich die Methoden sayYing(), sayYang() und concateStrings(String ying, String yang) genannt. Jede dieser Methoden gibt einen String zurück.

Das wiederholt man einfach noch für die anderen beiden Web Services.

Sind alle Web Services angelegt kann man sich daran machen ein BPEL Modul anzulegen. Dazu legt man ein neues Projekt an wählt im Dialog "SOA" und anschließend "BPEL Module".

In diesem BPEL Module benötigt man nun noch einen BPEL Prozess, den man über "New" ganz einfach anlegen kann. Ich habe diesen Prozess ConcatProcess.bpel genannt.

Um diesem neuen BPEL Prozess die zuvor erstellten Web Services aus dem anderen Projekt bekannt zu machen, nutzt man den komfortablen Befehl „Generate and Copy WDSL“ in dem zuvor erstellten Projekt. Als Ziel wählt man ein Verzeichnis in dem BPEL Module. Ich habe dazu ein Verzeichnis "wsdls" angelegt.

Die Abbildung links zeigt den momentanen Stand in meinem BPEL Module. Wenn die *Wrapper.wsdls und die *.xsds bei euch noch nicht vorhanden sind, liegt es daran, dass ihr die WebServices noch nicht im Prozess verwendet habt. Diese Dateien werden aber automatische erzeugt und sollten euch nicht verwundern.

Bitte überprüft an dieser Stelle den Code der wsdl Dateien. Denn beim Kopieren wurde ein URL zurückgesetzt, die nun angepasst werden muss.

Der folgende Code zeigt das Problem. Die Adress Location soll mit der aktuellen Service URL ersetzt werden.

...


      
    
  
...

...


      
    
  
...

Nun öffnet man den ConcatProcess.bpel und geht in den Designer Modus. Doch bevor der Process mit Hilfe des Designers erstellt wird, legt man am besten noch ein WSDL Dokument an, dass den BPEL Prozess nach außen repräsentiert.

Da der ConcatProcess keinen Eingabe-Parameter hat, kann man den Eintrag getrost entfernen.

In diesem Beispiel werden SOAP und der Binding SubType "RPC literal" verwendet.

In der Abbildung links sieht man erstmalig den Designer auf dem schon der Prozess zu sehen ist. Man kann nun munter die WSDL Datei auf solche Flächen ziehen, wie sie im  roten Kästchen zu sehen sind. Die drei WebServices (YingService, YangService und MatchService) zieht man auf die rechten graue Fläche und das gerade eben erstellte wsdl Dokument auf die linke graue Fläche.

Die linke Abbildung zeigt die Palette mit BPEL Elementen. Uns sollen nur die Element Invoke, Receive, Reply, Assign  und Flow interessieren.

Bitte positioniert die einzelnen Elemente wie links dargestellt in der Oberfläche. Um die Verbindungslinien zwischen den Elementen kümmern wir uns in den nächsten Schritten.

Zuerst macht man einen Doppelklick auf das Receive Element und nimmt die links abgebildeten Einstellungen vor.

Als nächstes macht man ein Doppelklick auf eines der Invoke Element im Flow und erstellt einen Partnerlink zum YingService. Dazu erstellt man sowohl Input als auch Output-Variable. Den Vorgang wiederholt man für den YangService.

Nun klickt man auf das oberste Assign Element und ein Mapper öffnet sich. In solch einem Mapper kann man die Variablen zwischen zwei Elementen zuordnen. Da wir im Receive keine Variable erhalten haben, erstellen wir String Literale, den Variablen SayYingIn und SayYangIn zugeordnet werden.

Bei dem nächsten Assign Element sind bereits Variablen vorhanden, sodass die Mapping Pfeile vom linken zum rechten Baum führen (siehe Abbildung links).

Im letzten Assign ordnet man die Output Variable des MatchService der Gesamt-Prozess-Output Variable zu, die man vorher im Dialog des Reply Elements erstellt.

Als nächstes legen wir ein neues Projekt (Composite Application) an, das später den BPEL Prozess benutzt.

Im nächsten Schritt fügen wir den erstellten Prozess der Composite Application hinzu. 

Nach dem Hinzufügen des Prozesses sollte die Darstellung der Composite Application in etwas so aussehen.

Nun kann es an das Deployment der einzelnen Projekte gehen. Zuerst sollte man den Glassfish Application Server starten. Ich nutze momentan noch den Server in der Version 2. Dieses Tutorial funktioniert aber auch mit der Version 3.

Als erstes wird das Projekt mit den drei einzelnen WebServices auf dem Server deployed. Dazu reicht ein rechtsklick auf das Projekt und Deploy. Das Deployment dauert einen Augenblick.

Das erfolgreiche Deployment überprüft man am besten in der Oberfläche des Glassfish Servers. Die erreicht man im Browser über localhost:4848. Die Anmeldedaten sind standardmäßig admin und adminadmin. Links unter Web Services sollten die Web Services zu sehen sein.

Nun kann man die Composite Application deployen. Diese findet man dann in der Glassfish Oberfläche unter JBI / Dienstgruppen.

Zum Testen der Composite Application erstellt man einfach einen WebService Client. In dem Dialog trägt man als WSDL URL das folgende ein:

http://localhost:9080/ConcatProcessService/ConcatProcessPort?wsdl

Danach sieht man den Client in der Projektstruktur. Wenn man den Baum so weit wie möglich öffnet sieht man die WebService Operation. Zieht man diese Operation mit der Maus in die main Methode sieht man den daraus entstehenden Code. Dieser Code gibt das Ergebnis der WebService Operation per println aus.

Ich hoffe dieses Tutorial hat euch geholfen einen BPEL Prozess zu erstellen und zur Ausführung zu bringen. Viel Spaß beim arbeiten mit BPEL!

Der SOA Zug rollt bzw. ist eigentlich schon lange lange unterwegs und WebServices sind ein Trendthema. Ein Web Service lässt sich mit dem SOAP basierten Ansatz oder mit der REST Idee realisieren. Auf SOAP und Frameworks wie Axis2 werde ich hier nicht eingehen. Nun eine kurze Erklärung zu REST: Der größte Unterschied zu dem SOAP basierten Ansatz ist, dass es die HTTP Methoden wie GET, POST, PUT, DELETE, HEADER benutzt. In dem Glaubenskrieg zwischen den “Seifenliebhabern” und den REST-Anhängern wird das immer als Argument gebracht, dass REST als Web Service viel näher am Internet (HTTP) ist. Denn REST arbeitet wie gesagt mit den HTTP Methoden und die Daten des Service sind per Link erreichbar.

Ich habe mich vor kurzem mit der Materie auseinandergesetzt und versucht eine leichte Erklärung zu finden, die mir zeigt wie ich ein REST Projekt erstelle, es auf dem Tomcat Server zum laufen bringe und anschließend benutze. Weil ich die Ergebnisse bei der Suche nach solchen Tutorials nicht besonders befriedigend fand, dachte ich mir, es wäre an der Zeit so ein einfaches Tutorial zu schreiben.

Projekt Setup:

• Eclipse JavaEE 3.4 (Ganymede)
• Tomcat 6.0.18
• Jersey (REST Referenz Implementierung)

Außerdem verwende ich das Kommandozeilentool Curl zum Testen der Anwendung. Mit dem Tool können einfach Request an eine URL geschickt und die Antwort ausgewertet werden.

Nun kann man direkt in Eclipse loslegen indem man ein neues Dynamisches Web Projekt anlegt.

Nach dem Anlegen des Projektes habe ich lediglich das Paket de.smashit.resources angelegt und die Datei web.xml im Ordner WEB-INF erstellt. Den Inhalt der web.xml findet Ihr weiter unten.

Für das Entwickeln eines RESTful Webservice sind auch einige Bibliotheken von Nöten, die im Ordner WEB-INF/lib liegen müssen. Hier erhaltet ihr die von mir verwendete libs.

Das folgende Listing zeigt eine einfache Ressourcenklasse, die im Paket de.smashit.resources liegt. Diese Ressource ist über die URL http://localhost/RestDemo/helloworld erreichbar. Die Annotation @Path konfiguriert die URL für die Ressource. Die Annotation @GET und @POST zeichnen die einzelnen Java Methoden aus und sorgen für ein Mapping zu den Http Methoden (GET, POST, PUT, DELETE, HEAD). Die @Produces Annotation gibt an welche Output von der Methode zurückgeliefert wird. In diesem einfachen Beispiel ist es nur einfacher Text aber es gibt noch andere Typen wie: application/xml, text/html, application/json.

package de.smashit.resources;

import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;

//The resource (Java class) will be hosted at the URI path "/helloworld"
@Path("/helloworld")
public class HelloRestResource {

// The method will be invoked by HTTP GET requests
// The method will produce content of MIME Media type "text/plain"
@GET
@Produces("text/plain")
public String getClichedMessage() {
return "Hello Rest (GET)";
}

@POST
@Produces("text/plain")
public String setSomething() {
return "Hello Rest (Post)";
}
}

Im Ordner WEB-INF die Datei web.xml anlegen und mit folgendem XML Code füllen. In der web.xml wird ein sogenanntes Servlet gemappt (RestServlet), das von der Wurzel Url aus aufrufbar ist (siehe url-pattern). Die Ressourcenklassen müssen sich in den Paketen de.smashit.resources oder test befinden. Jersey sucht sich die Resourcen aus den Paketen raus.

< ?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">

RestDemo


RestServlet

com.sun.jersey.spi.container.servlet.ServletContainer




com.sun.jersey.config.property.resourceConfigClass


com.sun.jersey.api.core.PackagesResourceConfig





com.sun.jersey.config.property.packages


de.smashit.resources;test



1


RestServlet
/*

Das Projekt wird als WebArchive (.war) auf dem Tomcat deployed. Dazu wählt man die Export Funktion von Eclipse und exportiert die war-Datei in den Ordner Webapps des Tomcats. Falls der Tomcat Server bereits läuft, wird die Anwendung automatisch deployed/gestartet und wenn nicht muss nun noch der Server gestartet werden.

Das Projekt wurde erfolgreich auf dem Tomcat deployed, wenn die Meldung in der Konsole des Tomcat in etwa die Nachricht “Root resource classes found” steht. Dann hat der Server die Resource-Klassen in den einzelnen Paketen gefunden und sie erfolgreich geladen.

Anschließen kann man die Anwendung bequem per Browser oder dem Kommandozeilentool curl testen, indem man eine Anfrage an die Adresse stellt. Sowohl der Browser als auch curl versenden standardmäßig GET-Anfragen. So dass in diesem Fall eine Methode der Ressource ansgesprochen wird, die mit @GET annotiert ist.

Mit Browser:

oder ein GET Request mit curl:

oder ein POST Zugriff mit der Option -F

Hat euch dieses einfache Tutorial gefallen oder geholfen? Ich denke nun sollte jeder die Grundlage von REST verstanden haben und ist in der Lage die vielen Details und Möglichkeiten von REST zu erforschen. In meinen Augen ist der schwierigste Teil der Arbeit im Entwurf eines WebServices mit REST. Den die verwendeten URIs sollten möglichst lange gültig sein und alle gewünschten Anforderungen abdecken. Werden neue Funktionen gewünscht, kommen meist schnell Ressourcen hinzu weil die begrenzte Anzahl der HTTP Methoden nicht viel Spielraum pro Ressource lässt. Also investiert in den Entwurf und Definition der Ressourcen möglichst viel Zeit um eine spätere Änderung wenn möglich zu vermeiden.

Und nun wünsche ich viel Spaß beim Entwickeln von Anwendungen mit REST WebService.

Links:

• http://java.dzone.com/articles/putting-java-rest

Quelle: http://www.peterkroener.de/die-neue-programmiersprache-lernen/

Gemacht wird es, in dem man der Eclipse JVM-Parameter mitgibt. Man startet die IDE mit den folgenden Parametern:

eclipse.exe -vmargs -Xms256m -Xmx256m

-Xms ist die minimal verwendete JVM-Speichergröße
-Xmx ist die maximal verwendete JVM-Speichergröße
In diesem Beispiel habe ich die Speichergröße auf 256 MB fixiert.

Weitere Informationen findet ihr unter Help/ Help Contents/ Workbench User Guide/ Tasks/ Running Eclipse

So lässt sich zum Beispiel auch die JVM einstellen, mit der Eclipse starten soll.