#Interviews
Axis2 versus XFire – Das Duell
Mit Axis2 von der Apache Software Foundation und XFire von Codehaus liegen zwei moderne SOAP-Frameworks vor, die um die Gunst der Java-Entwickler buhlen. Auch wenn der Name Axis2 andeutet, dass es sich um ein Update des klassischen Apache Axis handeln könnte, so ist es, genauso wie XFire, ein von Grund auf neu programmiertes und völlig anderes Framework als sein Vorgänger. Aber wo liegen die Unterschiede der Frameworks in der Entwicklung von Web Services?
Axis2 versus XFire – Das Duell
Data Bindings Axis 1.x lieferte ein eigenes Type-Mapping-Framework, mit dem die Umwandlung der XML-basierten SOAP-Nachrichten in Java-Typen erfolgte und umgekehrt. Die neue Web-Service-Spezifikation
Axis2 versus XFire – Das Duell
Die Service-Implementierung in der Klasse BookServiceImpl ist relativ einfach und kann in Listing 3 eingesehen werden. Es folgen die Deployment-Descriptoren. Im Verzeichnis Axis2Config ist hierzu die
Axis2 versus XFire – Das Duell
Auch wenn sich die services.xml in der Syntax unterscheiden, so kann man festhalten, dass beide Projekte an dieser Stelle nahezu die gleichen Konfigurationsmöglichkeiten bieten: Definition von Services,
Apache Axis2: AXIOM – das neue Objektmodell für XML-Verarbeitung
Da fast alle Web-Service-Nachrichten in XML oder XML-ähnlichen Formaten vorliegen, ist es eminent wichtig, einen effizienten und leistungsfähigen Mechanismus für die XML-Verarbeitung einzusetzen. Als Web-Service-Engine der nächsten Generation hat Axis2 die Herausforderung angenommen, die Performance von Axis1 noch einmal zu verbessern. Die Antwort auf diese Herausforderung heißt AXIOM – ein Objektmodell, welches Performanz und Benutzerkomfort in sich vereint.
Apache Axis2: AXIOM – das neue Objektmodell für XML-Verarbeitung
AXIOM API Das Programmiermodell von AXIOM wirkt auf den ersten Blick ähnlich wie das von DOM oder JDOM sehr intuitiv. Zuerst wird ein Builder instanziiert, der für den Aufbau des Objektmodells zuständig
Apache Axis2: AXIOM – das neue Objektmodell für XML-Verarbeitung
Web Service mit AXIOM Hat man sich mit AXIOM vertraut gemacht, kann man schon Web Services direkt mit AXIOM entwickeln und aufrufen. In diesem Fall wird kein Data-Binding-Werkzeug für die Konvertierung
Grid Computing – Die helle Seite der Macht
Java EE ist eine schöne Technik. Aus humankapitalistischer Sicht gibt es momentan keinen vergleichbaren Standard, der weltweit mit einer derartig großen Armada an Entwicklern, Architekten und Administratoren aufwartet. Doch Java EE wird auch von der dunklen Seite der Macht angezogen: der hardwarefressenden Seite. Die bisher wenigen bekannte Waffe der hellen Seite der Macht heißt Grid Computing.
Grid Computing – Die helle Seite der Macht
Hardwarereduktion durch Grid Computing im Java EE-UHardwarereduktion durch Grid Computing im Java EE-Umfeld (Stufe 1)mfeld (Stufe 1) Eine typische Java EE-Architektur besteht aus Webservern, Application-Servern
Grid Computing – Die helle Seite der Macht
Symphony definiert sein eigenes Framework, mit dessen Hilfe Code im Grid RPC-basiert oder Message-orientiert verteilt ausgeführt werden kann. Der ausführende Teil wird als Service bezeichnet und
Java-Architektur-Management: vier leistungsfähige Werkzeuge vorgestellt
Kennen Sie eigentlich die inneren Abhängigkeiten ihrer Java-Projekte? Wissen Sie genau, welche Fremdprodukte Ihre Entwickler in Ihr Produkt einbinden? Wie sorgen Sie dafür, dass Ihre aufwendig entworfene Architektur von Version zu Version erhalten bleibt? Wie finden Sie architektonische Schwachstellen? Konkrete Antworten auf diese Fragen und mehr liefern moderne Werkzeuge zur Analyse der Architektur von Java-Programmen.
