Eduard’s Weblog

Die Versionierung von Anwendungen und Softwaremodulen war schon immer eine Herausforderung für Softwareentwickler. Mit der Einführung von Services und serviceorientierten Architekturen (SOAs) ist diese Problemstellung noch wichtiger und gleichzeitig herausfordernder geworden, da die Komponenten in einer verteilten Umgebung nicht mehr der Kontrolle eines einzelnen Teams unterliegen. Christian Schneider und ich beleuchten in einem Artikel, welcher in der Zeitschrift ObjektSPEKTRUM 02/2009 erscheint, die Aufgaben des Versionsmanagements und mögliche Strategien zur Umsetzung und stellen im Anschluss eine Strategie vor, die sich in der Praxis bei einem Energieversorger bewährt hat.

Many thanks for the participation and active discussion on my session at OOP. As I promised, I’ve just put my presentation slides on Slideshare and it’s available for download as PDF, too.

Slide design inspired by Ethos3 and Presentation Zen.
Any feedback is highly appreciated!

Ziel einer serviceorientierten Architektur ist eine möglichst weitgehende Automatisierung von Geschäftsprozessen. Diese werden durch Dienste, sogenannte Services, abgebildet. Wie jede Software durchläuft auch ein Service einen Lifecycle mit den Phase: Analyse, Design, Entwicklung, Test und Betrieb. Andy Wolf und ich haben einen Artikel in JavaSPEKTRUM 01/2009 geschrieben, welcher auf die Besonderheiten des Service-Lifecycles eingeht. Das Heft ist ab dem 16.01.2009 im Handel erhältlich.

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.

Bewährte Vorgensweise für die Optimierung der Performance bei Webservices:

• Gestallten Sie ihr Webservice Interface mit dem Ziel die Anzahl der Client-Requests zu reduzieren und den Netzwerkverkehr zu minimieren.
• Das Parsen von XML-Nachrichten auf Gateways, Proxies usw. sollten soweit wie möglich reduziert werden.
• Versuchen die Komplexität der XML Nachrichten so einfach wie möglich zu halten.
• Unabhängig von der Verarbeitung muss jede XML Nachricht erst geparst werden. Versuchen Sie daher die Größe der Nachrichten so klein wie möglich zu halten.
• Die Wiederverwendung von bestehenden Verbindungen wirkt sich insbesondere bei vielen kleinen Nachrichten außerordentlich positiv auf die Performance aus. Verwenden Sie daher „keep-alive“ bei HTTP Verbindungen und setzten Sie einen Connection Pool bei JMS- und Datenbank-Verbindungen ein.
• Die Komprimierung der Daten kann sich abhängig von der Nachrichtenart und –größe positiv aber auch negativ auf die Performance auswirken. Führen Sie entsprechende Tests durch und testen Sie verschiedene Komprimierungslevels.
• Setzen Sie moderne XML-Parser Technologien ein. StaX ist besser als SAX und SAX ist besser als DOM Parser.
• Verwenden Sie einen schnellen XML Parser. Eine schnelle Java Implementierung ist z.B. Woodstock.
• Nutzen Sie eine schnelle Databinding Implementierung. In der Regel liefern Frameworks, die optimierten Marshalling- und Unmarshaling-Code für Domain Klassen generieren, die beste Performance. Schnelle Implementierungen für Java Anwendungen sind JiBX, SXC und JAXB-RI.
• Das Einlesen von XML Nachrichten in Objekte ist sehr Ressourcen intensiv. Moderne Databinding Frameworks wie JiBX oder JAXB arbeiten mit XML-Streams. Falls möglich nutzen Sie diese Möglichkeit.
• Bei read-only Operationen bietet sich Caching als Performanceoptimierung an.
• Security kostet Performance. Setzten Sie nur die Security-Mechanismen ein, die von einem Service wirklich benötigt werden.
• End-to-End Security (wie z.B. WS-Security) hat in der Regel höhere Performancekosten als Transport-Schicht Security (wie z.B. SSL).

Haben Sie weitere Vorschläge für Performancetuning bei Webservices?
Ich freue mich auf Ihre Kommentare.