Eduard’s Weblog

Dominik Meyer hat im XING Form „WebSphere Process Server“ auf zwei interessante Artikel von IBM zur Performance Tuning von IBM WebSphere Process Server hingewiesen:

• Tuning Human Workflows with Materilized Views
• Tuning of Automatic Processes

Wirklich lesenswert für alle die mit dem IBM WebSphere Process Server arbeiten müssen.

General

• Use the latest service pack level. Fixes can be found on IBM WPS support site: http://www-306.ibm.com/software/integration/wps/support/
• Do not use default path to install. Choose the shortest possible path, avoid blanks (i.e. C:\IBM\WPS).
• Design your service interfaces first. Adding additional fields after deployment may cause issues.
• Reuse existing applications and do not try to split them up if not necessary.

Business Processes

• Prefer BPEL constructs in processes over Java inline code.
• Avoid potential deadlock situations: do not access same variables from two parallel paths and use escalation or timeout mechanism for any asynchronous blocking activity.
• Use dynamic modeling options for decision based on runtime data.
• Use BPEL Fault Handlers when you think that this fault is a part of your business process logic.
• Use “continue on error” option if faults are rarely expected and require human intervention.
• External large data should be referenced.
• Regularly cleanup process choreographer database to speed up query performance.
• Use WPS Business Rules, if the process needs to be changed frequently.

Human Task Manager

Inline task:
An inline task is defined within an implementation of a business process.
Model as an inline task if:

• you need information from the process context
• you want to execute administrative tasks
• you want to define authorization rights on specific activities

Stand-alone task:
A stand-alone task exists independently of a business process.
Model as stand-alone task if:

• you do not need any information from the process context
• your implementation need to be BPEL compliant
• the task should be reused

Business State Machine

• Do not put any logic in generated BPEL.
• It will be overridden when changing state machine.
• Use a composite state to reduce number of transitions needed.
• Avoid long-running service calls in business state machine models.
• Not sure: use BPEL process

Business Rule Manager

• Know the difference between rule set (can be executed with multiple results) and decision table (only first positive condition will fire the action).
• Trying to write a rule set which will have one outcome may become very complex and difficult to maintain.
• Do not forget about security. BRM is tied to J2EE and EJB role settings and without global security anyone can modify/delete business rules!

Development and customer integration

• Use windows platform for development. Unix based systems are difficult to configure and need more time to setup system.
• Setup repositories to avoid concurrent modification of files.
• Use configuration scripts shipped with product or create your own for automating administrative tasks.
• Make a backup regularly.
• Make a deep testing of your system before deploying to production. Try to get service definitions and original data to be integrated. Use WSP testing mechanism.
• Enable WebSphere Security from the first day.

Um meinen Leserkreis zu erweitern und gleichzeitig meine Englischkenntnisse etwas zu trainieren, habe ich beschlossen einige ausgewählte Beträge in Zukunft in Englisch zu verfassen.

Feedback und Korrekturen sind sehr willkommen!

Blogger können jetzt richtig viele Amazon Gutscheine kassieren: Your Privacy vergibt z.B. ein 10 Euro Amazon Gutschein für ein Testbericht über ihren Anonymisierungsdienst. Coupondeal vergibt ebenfalls einen 10 Euro Amazon Gutschein für einen kurzen Bericht über den Gutschein Blog . Der Gutschein Blog von Preistip vergibt abhängig von der Länge des Beitrag einen Gutschein über 5 Euro oder mehr. Pringles schenkt jedem Amazon Kunden einen weiteren 5 Euro Gutschein und Kunden, die eine Amazone-Kreditkarte bestellen erhalten zusätzlich einen 20 Euro Gutschein.

Wer nun alle diese Gutscheine zusammen hat, kann sich etwas schönes bei Amazon kaufen. Viel Spaß beim Bloggen und einkaufen!

Auf der diesjährigen Silverparty war Abendbekleidung und eine ausgefallene Kopfbedeckung angesagt. Ich habe mich für eine original usbekische “Tübetejka” entschieden…

Wünsche allen einen erfolgreiches neues Jahr!

Beim JBoss Application Server tritt immer wieder das Problem auf, dass nach mehreren Deployments folgende Exception von der VM geworfen wird:

java.lang.OutOfMemoryError: PermGen space

Verursacht wird dieser Fehler vermutlich durch ein Speicherleck im ClassLoader. In der Produktion stellt dies kein Problem dar, da in einer produktiven Umgebung nicht so oft deployed wird. Für einen Entwickler ist dieses Problem jedoch äußerst lästig. Das Problem kann nicht ohne größeren Eingriff im Sourcecode von JBoss Application Server behoben werden. Man kann das Problem jedoch herauszögern indem man den Speicher entsprechend erhöht:

Dazu muss in der Datei ${JBOSS_HOME }/bin/run.bat zu der der Variable JAVA_OPTS folgende Optionen hinzufügt werden:

-XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=128m

So, dass die Zeile

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

wie folgt aussieht:

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m
-XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=128m
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

Damit wird der PermGenSpace von 64 MB auf 128 MB erhöht. Auf diese Weise kann man sich das lästige Neustarten des Servers nach mehrfachen Deployments sparen.

Open Source Werkzeuge zum Testen und Debugen von Webservice Anwendungen:

• soapUI
• WS-Monitor
• TCP-Mon
• Wireshark

Haben Sie Vorschläge zur Ergänzung der Liste?

Weitere Artikel zum Thema:

• Debugging SOAP requests and responses using Eclipse and Wireshark
• Using java.net’s WSMonitor for debugging

In einem meiner früheren Artikel habe ich beschrieben, wie man mit Apache CXF, Spring Framework sowie Jetty als embedded HTTP Server einen einfachen Webservice implementiert und bereitstellen kann. Dabei wurden JSR-181 und JAXB Annotations verwendet um die Java Klassen mit entsprechenden Metadaten anzureichern. Dies wird auch als „Implementation-First“ oder „Java-First“ Ansatz bezeichnet. In einem weiteren Artikel wurde gezeigt welche Nachteile dieser Ansatz hat und wie man die Generierung der WSDL-Datei mit Annotations beeinflussen und somit den Webservice Contract optimieren kann.

Dieser Artikel beschreibt das Vorgehen nach dem “Contract-First” bzw. „WSDL-First“ Ansatz. Bei diesem Ansatz wird die Schnittstelle vor der Implementierung in Form einer WSDL-Datei definiert. Die entsprechenden Java Klassen werden dann mit einem Codegenerator aus der WSDL-Datei generiert.

Das hier beschriebene Beispiel basiert auf Apache CXF 2.0.3, JSR-181, JAXB 2.1, Spring Framework 2.5, sowie Jetty 6.1.5. Der komplette Source Code inklusive einem Maven Build Script steht zum Download bereit.

Schritt 1: Anforderungen aufnehmen, dokumentieren und Schnittstelle entwerfen

Der Lebenszyklus für jeden Webservice beginnt mit neuen Anforderungen aus dem Fachbereich. Diese Anforderungen müssen wie bei jedem Softwareentwicklungsprojekt aufgenommen und dokumentiert werden. Anhand dieser Anforderungen kann anschließend eine Schnittstelle für den Service entworfen werden. In unserem Beispiel verwenden wir die Schnittstelle aus dem vorherigen Artikel. Das folgende UML-Diagramm zeigt die Schnittstelle des Services sowie die Datenobjekte mit denen der Service arbeitet:

Wie man dem Klassendiagramm entnehmen kann, soll unser Beispiel-Service eine Methode anbieten, die eine Kundenummer als Inputparameter entgegennimmt und einen Kunden als Output zurück gibt. Die Serviceschnittstelle wurde für dieses Beispiel zur besseren Verständlichkeit natürlich stark vereinfacht.

Schritt 2: Datenstrukturen als XML-Schema definieren

Zunächst müssen die Datenstrukturen als XML-Schema definiert werden. Es ist sinnvoll jede Datenstruktur in einer separaten XSD-Datei abzuspeichern. Auf diese Weise können die Datenstrukturen auch in anderen Services wiederverwendet werden. In unserem Beispiel entstehen folgende vier Schema-Definitionen:

Customer.xsd
Person.xsd
Gender.xsd
Address.xsd

Schritt 3: Service Interface in einer WSDL-Datei definieren

Im nächsten Schritt muss das Service Interface in einer WSDL-Datei beschrieben werden. Die WSDL-Datei inkludiert die XML-Schema Dateien, die die Datenstrukturen beschreiben und definiert die vorhanden Operationen sowie die Input- und Output-Nachrichten:

CustomerService.wsdl

Schritt 4: Java Source Code aus WSDL-Datei definieren

Aus der WSDL-Datei kann nun mit Hilfe eines Genarators Java Code generiert werden. Apache CXF bittet dazu ein entsprechendes WSDL2Java-Tool an, welches sowohl von der Kommandozeile als auch aus Ant und Maven Skripten aufgerufen werden kann. In unserem Beispiel verwenden wir ein Maven Build-Skript und der Codegenerator wird automatisch vor dem Kompilieren aufgerufen. Die Konfiguration für den Codegenerator kann der pom.xml Datei entnommen werden.

Schritt 5: Service Interface implementieren

Nachdem die entsprechenden Java-Klassen für die Datenstrukturen und den Service generiert wurden, muss das Interface implementiert werden. Die Implementierung der Geschäftslogik befindet sich in der Klasse CustomerServiceImpl.java, welche das generierte Interface ContactService implementiert:

public class CustomerServiceImpl implements CustomerService {
    public Customer getCustomer(String customerNumber)
            throws BusinessLogicException {
        Customer result = null;
        if("12345".equals(customerNumber)) {
            Person maxMueller = new Person();
            maxMueller.setFirstname("Max");
            maxMueller.setLastname("Müller");
            maxMueller.setGender(Gender.MALE);
            Address maxMuellerAddress = new Address();
            maxMuellerAddress.setLine1("Mussterstr. 10");
            maxMuellerAddress.setLine2("");
            maxMuellerAddress.setPostalCode("12345");
            maxMuellerAddress.setCity("Musterhausen");
            Customer maxMuellerCustomer = new Customer();
            maxMuellerCustomer.setPerson(maxMueller);
            maxMuellerCustomer.getAddress().add(maxMuellerAddress);
            result = maxMuellerCustomer;
        }
        throws new BusinessLogicException("No such customer");
    }
}

Wie man dem Source-Code entnehmen kann, gibt diese Implementierung immer den Kunden „Max Müller“ als Output zurück wenn die Kundennummer „12345“ als Inputparameter übergeben wurde und in allen anderen Fällen wird ein BusinessLogicException mit entsprechender Fehlermeldung geworfen.

Schritt 6: Service bereitstellen

In diesem Beispiel wird der Service mit Hilfe von Jetty über HTTP bereitgestellt. Die Konfiguration der Komponenten erfolgt über das Spring Framework. Die Spring Konfiguration ist in diesem Beispiel in der Datei server-applicationContext.xml enthalten.

server-applicationContext.xml

Über die main-Methode in der Klasse ServiceServer wird der Spring Context initialisiert und somit der Jetty Webcontainer gestartet, welcher die Service Implementierung unter http://localhost:9090/customerService verfügbar macht.

ServiceServer.java

Schritt 7: Client für den Service implementieren

Um den Service anzusprechen und testen zu können, empfiehlt es sich ein Client zu implementieren. Die Implementierung von Clients ist mit Apache CXF 2.0 relativ einfach deklarativ mit Hilfe des Spring Frameworks möglich. Die Spring Konfiguration für den Service Client ist in diesem Beispiel in der Datei client-applicationContext.xml enthalten.

client-applicationContext.xml

Die Klasse ServiceClient enthält eine main-Methode in der Spring Context initialisiert wird und auf das entsprechende Client-Bean zugegriffen wird.

ServiceClient.java

Alternativ eignet sich auch soapUI hervorragend zum Testen von Webservices.

Ich wünsche allen ein traumhaftes Weihnachtsfest.