-Djavax.xml.transform.TransformerFactory=com.icl.saxon.TransformerFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl-Dorg.xml.parsers.sax.parser=org.apache.xerces.parsers.SAXParser 

Siehe dazu auch nur Xerces als Default-Parser setzen. 

-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

Axis 2 – Anforderungen geändert, nicht mit Axis 1 erreichbar; WS-Security; Performance; 3rd Generation WS Framwework; andere XFire, MS Indigo;

Axis 2 mit asynchronem Modell; MEP – Message Exchange Pattern; Pull-Parser / StAX; Unterschiedliche Data Bindingmöglichkeiten; MTOM/SwA Attachments; WSDL 2.0;
Handlerketten dynamisch; Hot Deployment/Hot Update f. Services; Modularisierungsfähigkeit;

Erläuterung Streaming-Parser vers. DOM-Parser; Push (z.B. SAX) vers. Pull Parser; StAX – Streaming API for XML

Axiom
eingeständiges Projekt, wrappt StAX;
Simuliertes baumbasiertes Parsing; "deferred building"; in Wirklichkeit Stream-Parser im Hintergrund;

Spez. SOAP-API;

Service Archive
*.aar; neues Deploymentmodell; Ant-, Eclipse-Unterstützung; META-INF muss zumindest services.xml enthalten, normalerweise auch die WSDL-Dateien.

Repository
Ein R. für jede Axis-Installation; Standalone-Services möglich; HTTP;TCP;SMTP/JMS-Listener; zwei Ordner: services (…) und modules (Erweiterungen);

Automatischer REST-Support (muss gesondert disabled werden).

Änderungen in Axis-Konsole nicht persistent, also nicht für Produktivbetrieb geeignet! Änderungen müssen in Service-Archiven vorgenommen werden, um persistent zu sein;

XML Data Binding

• ADB (Axis D.B.); Default;
• XMLBeans;
• JiBX;
• JaxME;
• JAXB-Reference Implementation;

Entscheidender Einfluss auf Gesamtperformance; ggf. auf DB-Framework verzichten;

Axis2-Engine

SOAP-Request (HTTP)
=>AxisServlet~MessageContext-MC_req~
=>AxisEngine~H1…n (Message Handler, weitergeben, transformieren, filtermäßig)~[end in-flow]
=>MessageReceiver (ruft WS auf, dieser kann alles durch Java Aufrufbare sein; leicht selbst zu implemetieren)
=>WS-Aufruf
=>MessageReceiver (weiß um Synchronitätsinformationen)~MC_resp~
=>[falls Antwort]: neue AxisEngine-Instanz[start out-flow]~H1..n~neu
=>Transport Sender->MC_resp
=>AxisServlet
=>SOAP response

Frage: Muss Factory für Identifzierung des Clients erstellt werden (im Message Receiver)? Antwort: Letztlich über Message Context

Axis auf Clientseite
OutInAxisOperation: Verwaltet MC_req und _resp; Vier Flows für Frage/Antwort; Komplementäre Handler; Konfigurierbar, nicht programmatisch, Beispiel: Verschlüsselung.

Phasen

• Eine Phase ist

 • Handler sind mit Regeln verknüpft

• In welche Phase soll der Handler kommen?
• Soll er erster Handler einer Phase sein oder letzter?
• „Handler A immer vor/nach Handler B ausführen“

• Standard-Phasen:

Transport, Security, Pre-Dispatch, Dispatch, Policy Determination

• Konzept erlaubt dynamische Anordnung von Handlern

Module

• Gruppieren Menge von Handler;
• Separat deployed (*.mar);
• Beispiele für Module; Z.B. Transformation älterer Nachrichtenstrukturversionen. SOAP-Monitor.
• Engaging-Konzept – Modul wird für bestimmte Services/Service Gruppen aktiviert;

Client-API
AXIOM-basiert; RPC-Kommunikation unterstützt; Dual protocol transport in request + response; WS-Addressing support; echte Asynchronizität;

Code-Generierung
Derzeit: Java, C#, C++. XML-Darstellung von Konfiguration und WSDL. Ant-Unterstützung. Java2WSDL (…). Maven2 bald. WS-Policy basierte Erweiterungen. Lifecycle-Management (f. Inbetriebnahme etc.).

JAX-WS + Annotations. JSON.

Entwicklungsbeispiel
Code-first (Implementierung zuerst) / Contract first (WSDL/Schema zuerst). Problematisierung des Code-first-Ansatzes. Arbeit von WS-I unterstützt Interoperabilität besser, deshalb geringeres Risiko. Hinweis: Generierte WSDL-Datei mit WS-I-Tools prüfen!

POJO-Beispiel

1. POJO programmieren.
2. Service-Konfigurationsdatei schreiben (services.xml).
3. Service-Archiv erstellen.
4. Deployment.

RPC-Message-Receiver f. POJOS. Bestimmte Methoden können ausgeschlossen werden (in services.xml, excludeOperations-Tag). Dateiname d. Service-Archivs bestimmt den Namen.

Einfaches Beispiel. Besondere Lektion: Überschreiben der Methoden nicht möglich, keine Polymorhpie.

Document-Style sollte vorgezogen werden. RPC über Reflection. Document-Attribut allgemeiner, deshalb nur scheinbarer Widerspruch, das Struktur RPC entspricht.

Target-Namespace kann festgelegt werden.

invokeBlocking (RPCClient): synchroner Aufruf. RPCInOnlyMessageReceiver.

Services und Service-Gruppen

Gruppen – einfacher zu deployen. Kommunikation unter Services möglich. Dateiname des Servicearchivs: Jeder Service hat ein Name-Attribut. Dateiname = Name der Service-Gruppe.

Code-Generierung

WSDL2Code-Optionen (Übersicht); Eclipse-Plugin lässt nicht alle Kommandozeilenoptionen zu.

Session-Verwaltung

Handler/Phasen/Module

Restaurantservice

Trennung Schemata. WSDL beim PortType beginnen. Data-Binfinh, Service-Klassen,Client Classen; ExtensionMapper – Hilfsklasse, ignorieren. Generierte Klassen serializeable machen.

Von SkeletonImpl-Datei ableiten und implementieren. Dann Referenz auf überschreibende Datei, nicht mehr auf Skeleton.

axis2.xml – zentrale Konfigurationsdatei;

<xsl:if test="contains($myExpr, "'")">

etc. Bei den meisten XPath-Tools darauf achten, dass nicht die XML-Entität, sondern das Zeichen verwendet wird.

Leider funktioniert das nicht mit concat() oder generell nicht immer. Bombensicher ist daher nur Michael Kays Vorschlag.

Also

<xsl:variable name="apos">'</x:variable>

und dann verwenden:

<xsl:value-of select="concat('//', '*[@type=', $apos, 'sthg2concat:', @name, $apos, ']')" />