Showing posts from November, 2012

POJOs with Packages Example Problem - Apache Axis2 Web Services 2nd Ed.

POJO style web service development is a variation of  bottom-up web service development allowed by Axis2. Compiling a single java file then put .class file under " \webapps\axis2\WEB-INF\pojo" to use it as a web service is simple and straightforward. However, it is so weak because of its limitation of usages. When more complex requirements occurs it is time to gather all required classes under a .jar file and mark exposed web service implementation classes with appropriate annotations then deploy it. I followed the directions from Apache Axis2 Web Services 2nd Ed(page 106). But my project's jar file failed to deploy without warnings and run without errors. Because, Apache axis2 1.6.x and below distributions do not support JSR 181 annotated POJO as it' s declared below issue.

Using Custom Execution Chain Handlers in Apache Axis2

Execution chain concept is behaving like interceptors in EJB but its structure is a little bit more complex than EJB interceptors. Definition of PhaseRule/Phase/Handler in axis flows(inFlow, outFLow, inFaultFlow, outFaultFlow) enables to execute irrelevant tasks to service business logic such as Security, Transport, WS-* Specifications. Axis2 comes with default handlers and phases. Instead of implementing a new custom phase, users of axis2 overrides AbstractHandler class and alter axis2.xml appropriately (global static configuration) to satisfy the requirements.    Simplified UML Class Diagram for Axis2 Execution Chain Concept Phases has handlers and phases' invoke method is called with MessageContext object as parameter by AxisEngine. The above class diagram shows a clear picture of how the handlers and phases related each other. Handlers are not holding state information whilst manipulating Soap Envelope inside MessageContext . Handlers are easy to develop and integrate Underlying stream encoding problem

While examining apache axiom to basically create an XML document, a weird exception is raised from serialize method. Serializing to System.out streams is problem-free; on the other hand, serializing to xml file is not. Since, the project's "text file encoding" is Cp1254 and it conflicts with the defined character encoding defined in OMDocument . Change it as i did it in screenshot at bottom of this post. Let me explain what below code is about. It creates and an instance of OMFactory to create other OM supported XML parts: elements, attributes, namespaces and document to build an XML file programmatically with AXIOM . Then, set some xml metadata attributes and serialize it to System.out and output.xml file. Underlying stream encoding 'Cp1254' and input paramter for writeStartDocument() method 'UTF-8' do not match. at Source) at o

Working with Apache Axis2 and SoapUI

Axis2 is easy to use and simple to develop java web services; however it requires deep undestanding to enhance java web services to support WS-* specifications with its plugin module approach. It has two kind of distributions that varies from each other with their running style: WAR distribution to deploy in any servlet container Standard Standalone distribution  (Note: Source and Documentation distribution does not indicate any significant qualification to mention, here) In order to make everything faster, I start with standalone distribution of Axis2 to test any web service with SoapUI 4.X. There is a default web service included in Axis2 that has a single method that retrieves the version information with listening both Soap 1.1 and Soap 1.2 endpoints. Start axis2 server as follows, then create a "New SoapUI Project". SoapUI will generate appropriate request skeletons to call web services on Axis2, then invoke one of them as in the screen shot below. H:\Axis2\axis