Eduard’s Weblog

openArchitectureWare wurde in der Version 4.2 released:

The openArchitectureWare team is proud to present the long awaited 4.2 release of the well-known MDSD toolkit. The new version comes with several major improvements (see below) and is now also fully compatible with the Eclipse 3.3 Europa release and the corresponding EMF 2.3, UML 2.1 and GMF 2.0!

Major new features include a Debugger for Xpand and Xtend fully integrated Eclipse’s debugging facility. You will love this when writing complex templates or transformations. In addition, openArchitectureWare 4.2 supports Product Line Engineering (PLE) on generator level by integrating with popular variant management tools and the new components XWeave and XVar. The 4.2 release features a revamped Xtext with many more options for customizing the generated textual editors. The team has also worked hard on fixing many annoying quirks, bugs and performance issues.

Siehe auch “New And Noteworthy” für weitere Details.

Mit dem Release von GlassFish 2.0 wurde auch der Webservice Stack “Metro” in der Version 1.0 freigegeben. Kohsuke Kawaguchi und Vivek Pandey geben in ihren Blogs eine Übersicht der neuen Funktionen.

Open Source Java Framework mit Relevanz für eine SOA Plattform:

Service Engines:

• Apache Axis
• Apache CXF

Enterprise Service Bus:

• Apache ServiceMix
• Codehaus Mule
• Sun OpenESB

Messaging:

• Apache ActiveMQ
• OpenJMS

Mediation Frameworks:

• Apache Camel

Service Component Architecture:

• Apache Tuscany

Business Process Management:

• Apache ODE
• JBoss jBPM
• Intalio BPMS

BPEL Designer:

• Eclipse BPEL Projekt
• NetBeans BPEL Designer

Rule Engine:

• JBoss Drools

Service Repository:

• Apache jUDDI

Identity Management:

• Internet 2 Shibboleth

WS-* Frameworks:

• Apache WSS4J (WS-Security)
• Apache Sandesha (WS-ReliableMessaging)
• Apache Kandula (WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity)
• Apache Muse (WS-ResourceFramework, WS-BaseNotification, WS-DistributedManagement)

Artikel:

• “SOA auf die leichte Art” von Wolfgang Pleus im Java Magazin
• “Open-Source als Grundlage für SOA” von Dietmar Müller
• “SOA auf Basis von Open-Source leicht gemacht” von Bernd Seidel
• “Open-Source-SOA - die bessere Alternative?” von Wolfgang Herrmann

Fehlt in der Auflistung ein wichtiges Open Source Projekt?
Ich freue mich immer über Feedback. Schreiben Sie doch einfach ein Kommentar.

Jeder der schon einmal eine J2EE Anwendung entwickelt hat, kennt wahrscheinlich wie frustrierend und fehleranfällig es sein kann Mapping Code zwischen Entity Beans und Data Transver Objects zu schreiben. Das Open Source Framewrok “Dozer” kann hier Abhilfe schaffen. Es handelt sich dabei um ein Java Bean zu Java Bean Mapper welcher rekursiv Daten von einem Objekt auf ein anderes kopieren kann. Dozer unterstützt primitive Datentype, komplexe Datentypen, bidirektionale Beziehungen, Collections sowie Rekursion. Dozer ist eine kleine Open Source Perle, die definitiv einen Blick wert ist.

Ist SOA nur ein Hype? Oder ist dies eine Technologie, die schon Einzug in unseren Alltag gefunden hat? Ich habe das Suchvolumen für die Stichwörter SOA (blau), EJB (orange) und CORBA (rot) mit Google Trends verglichen:

Die Interpretation der Ergebnisse überlasse ich meinen Lesern.

Heute halte ich im Rahmen einer internen Weiterbildung bei LogicaCMG einen Vortrag mit dem Titel “AndroMDA - Einführung in eine Open Source Model Driven Architecture Lösung”.

AndroMDA ist ein freiverfügbarer erweiterbarer Generatorbaukasten in Anlehnung an die Spezifikationen zur Model Driven Architecture (MDA) der Object Management Group (OMG). Aus UML-Modellen wird Code für beliebige Zielplattformen erzeugt. Anders als andere MDA-Toolkits bringt AndroMDA fertige Cartridges für aktuelle Entwicklungsplattformen wie Struts, JSF, Spring, Hibernate, EJB und jBPM mit. Weiterhin besteht zusätzlich die Möglichkeit zur Erstellung eigener Cartridges.

Nach einer kurzen Einführung in MDA gibt der Vortrag einen Überblick über AndroMDA und erläutert die Architektur und Grundprinzipien. Die Möglichkeiten des Toolkits werden anhand einer Web-Anwendung für Pizza-Bestellungen erklärt. Anschließend besteht die Möglichkeit zur Diskussion und zum Erfahrungsaustausch aus Projekten.

Die Powerpoint-Folien und Beispiel-Anwendung stehen hier zum Download bereit.

xsd:choice ist ein verbreitetes XML Konstrukt. Das Mapping von xsd:choice auf eine objektorientierte Programmiersprache ist jedoch nicht ganz einfach. Die JAX-RPC Spezifikation für Webservices definiert z.B. kein Mapping von xsd:choice nach Java.
So mappt ein JAX-RPC Codegenerator eine xsd:choices Typdefinition in der Regel diese auf die Klasse javax.xml.soap.SOAPElement, die Teil der SAAJ API ist. Die SAAJ API ist jedoch nicht besonders benutzerfreundlich.

Hat man die Möglichkeit das XML Schema zu verändern, so besteht die Möglichkeit eine benutzerfreundliche API zu generieren in dem man das xsd:choice Konstrukt mit Polymorphismus ersetzt. Russel Butek hat dazu einen guten Artikel mit dem Titel „Use polymorphism as an alternativ to xsd:choice“ verfasst, welcher dieses Vorgehen sehr gut und detailliert erklärt.

Ich habe die XML Schema Definition für den CustomerService Beispiel aus meinen vorgehenden Beiträgen entsprechend um das Element „Payment“ aus dem Artikel von Russel Butek erweitert und mit Apache CXF auch entsprechenden Java Source Code generiert. Das Beispiel steht zum Download bereit.

Über das WSDL Binding wird ein Webservice an ein bestimmtes Messaging Protokoll gebunden. Wird SOAP als Messaging Protokoll für ein Webservice verwendet so kann der Style entweder „RPC“ oder „Document“ sein. Der SOAP Style kann wiederum entweder „encoded“ oder „literal“ sein. Dies ergibt vier Kombinationsmöglichkeiten:

• RPC/encoded
• RPC/literal
• Document/encoded
• Document/literal

Fügt man zu dieser Liste noch das „Document/literal wrapped“ Pattern hinzu, so hat man zwischen fünf Varianten auszuwählen. Doch welche davon sollte man verwenden?

Russ Butek hat dazu einen sehr guten Artikel mit dem Titel „Which style of WSDL should I use?“ geschrieben, welcher meiner Ansicht nach die Unterschiede der verschiedenen Styles sehr gut erklärt.

Meine Empfehlung:

• Legen Sie keine konzernweite Richtlinie fest, welcher Style zu verwenden ist. Es gibt Gründe für die unterschiedlichen Möglichkeiten und die Wahrscheinlichkeit ist groß, dass man in unterschiedlichen Projekten auf unterschiedliche Probleme stößt.
• Betrachten Sie die Entscheidung über den Style als ein Teil der Implementierung. Ihre System Architektur sollte von dieser Frage unbeeinflusst bleiben.

Die Sevice Component Architecture Implementierung Apache Tuscany SCA wurde in Version 0.99 released:

This 0.99 release of Apache Tuscany SCA is expected to be the last point release before 1.0 final release. It further builds on the stability and modularity established with the previous releases including more complete implementation of SCA specifications, support for distributed SCA domains, SCA policy, OSGi implementation types, and pub/sub support with notification components. Start up time and memory footprint of the runtime has been reduced and there has been numerous bug fixes.

Siehe auch Artikel von Stefan Tilkov bei InfoQ.

Meine beiden Tutorials zu den Themen “SOAP over HTTP Webservice mit Apache CXF (Java First Development)” und “JAXB Webservice in 10 Schritten optimieren” wurden auf der Apache CXF Homepage verlinkt, was für einen kleinen Besucheransturm auf meinem Blog sorgte.

Weitere Artikel zur Apache CXF:

• CXF WS-Security using JSR 181 + Interceptor Annotations
• CXF, Spring and WS-Security putting it all together - Part 1
• Apache CXF: Interview with Dan Diephouse and Paul Brown