Showing posts with label Axis2. Show all posts
Showing posts with label Axis2. Show all posts

Thursday, July 28, 2011

Sample client for Axis2 XMPP transport

Following is a sample service client that demonstrates the use of Apache Axis2's XMPP transport.

1) Add the following to your axis2.xml

i) Register the tranport listener.
<transportReceiver name="xmpp" class="org.apache.axis2.transport.xmpp.XMPPListener">
<!-- Account details for google talk -->
<parameter name="GoogleServer">
<parameter name="transport.xmpp.ServerUrl">talk.google.com</parameter>
<parameter name="transport.xmpp.ServerAccountUserName">axis2.xmpp.account1</parameter>
<parameter name="transport.xmpp.ServerAccountPassword">apacheaxis2</parameter>
<parameter name="transport.xmpp.ServerType">transport.xmpp.ServerType.GoogleTalk</parameter>
</parameter>
</transportReceiver>

ii) Register the transport sender.
<transportSender name="xmpp" class="org.apache.axis2.transport.xmpp.XMPPSender">
</transportSender>

2) Sample service client.
import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.axis2.transport.xmpp.util.XMPPConstants;
import org.apache.axis2.util.XMLPrettyPrinter;

public class XMPPSampleClient {
public static void main(String[] args) {
invokeTimeService();
}

private static void invokeTimeService() {
String endPointUrl = "xmpp://synapse.demo.0@gmail.com/" + "TimeService";

EndpointReference targetEPR = new EndpointReference(endPointUrl);
try {
ConfigurationContext ctx =
ConfigurationContextFactory.createConfigurationContextFromURIs(
XMPPSampleClient.class.getResource("axis2.xml"), null);

OMElement payload = getPayload();
Options options = new Options();
options.setProperty(XMPPConstants.XMPP_SERVER_TYPE, XMPPConstants.XMPP_SERVER_TYPE_GOOGLETALK);
options.setProperty(XMPPConstants.XMPP_SERVER_URL, XMPPConstants.GOOGLETALK_URL);
options.setProperty(XMPPConstants.XMPP_SERVER_USERNAME, "synapse.demo.0");
options.setProperty(XMPPConstants.XMPP_SERVER_PASSWORD, "mailpassword");

options.setTo(targetEPR);
options.setAction("urn:getServerTime");
ServiceClient sender = new ServiceClient(ctx,null);

sender.setOptions(options);
OMElement result = sender.sendReceive(payload);
XMLPrettyPrinter.prettify(result, System.out);
} catch (Exception e) {
e.printStackTrace();
}
}

private static OMElement getPayload() {
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs = fac.createOMNamespace(
"http://example.xmpp.transports.axis2.org/example1", "example1");
return fac.createOMElement("getServerTime", omNs);
}
}

Wednesday, July 14, 2010

Extend the Axis2 Framework to Support JVM Based Scripting Languages

This article explains how to extend the Axis2 framework to support Java Virtual Machine (JVM) based scripting languages such as Jython, JRuby, etc. It provides a high level overview of the subject, covering some key concepts of Apache Axis2 and how it can be used to come up with an extension to a JVM based scripting language. After going through this article, a developer will be able to extend the Axis2 framework to support the JVM based scripting language of his or her choice.

If you are interested, read the full article on InfoQ.com.

I take this opportunity to thank Nandika for doing the technical review and Charles Humble for doing the editorial review.

Sunday, August 16, 2009

GSoC: Experience

This was my second consecutive year as a Google Summer of Code student. During past 3 months I learned a lot of things. I discussed these in an earlier posts. In a nutshell;

1) I worked with a mentor (Matt Boersma) from a different time zone. This was the first time that I worked with a mentor from a different timezone. Our time difference was nearly 12 hours. We preferred email over chat since it was more conveinent for us.

2) It was a privilege to work as a summer of code student for Python Software Foundation (PSF). All the people who were mentoring me helped me a lot, ranging from shaping up the application (project proposal) to development.

3)It was a greatopportunity for me to work with experienced developers.

I would like to take this opportunity to thank my mentor Matt Boersma and Jython community for helping me to make my project a success. I would also take this opportunity to thank my co-mentors Jim Baker and Frank Wierzbicki.

I would like to state that it was a privilege and a honor to be selected as a GSoC student for a second time and thank Google for organizing a program like this. I am looking forward to participating in next year's GSoC as a mentor. :)

Saturday, August 15, 2009

GSoC: Update

During the development phase, I came across some problems. This is a follow up to my earlier posts. You can have a look at them here.

1) One problem is the way the API is designed to define the XML payload. I designed the WSF/Jython API in such a way that it is comparable with the WSF/Ruby implementation. Therefore WSF/Jython API should adhere to the API specified by WSF/Ruby.

When generating code using Axis2's code generation framework, you should generate it in a such a way that it should support XML object model(preferably in the case of axis2 - apache axiom). Therefore it would be better if the API supported axiom, inorder to use the code generation part. Consider the following example.

from org.wso2.wsf.jython.jythonwsclient import *

req_payload_string = "<deduct><var1>1.8</var1><var2>4.87594</var2></deduct>"
LOG_FILE_NAME = "/home/heshan/IdeaProjects/MRclient/src/python_client.log"
END_POINT = "http://localhost:8070/axis2/services/annotationScript/deduct"

try:
client = WSClient({}, LOG_FILE_NAME)
req_message = WSMessage(req_payload_string, {"to" :END_POINT})
print " Sending OM : " , req_payload_string
res_message = client.request(req_message)
print " Response Message: " , res_message

except WSFault, e:
e.printStackTrace();

In above code snippet, the payload is set as a string. i.e.

req_payload_string = "<deduct><var1>1.8</var1><var2>4.87594</var2></deduct>"

What should be done is to keep the above feature intact with the API and do a feature addition that will support Apache Axiom.

2) Therefore, the existing WSF/Jython codebase should be modified to support axiom for Jython (should look into this further).

3) Modify the existing codebase to include the code generation part. Having said that there should be more work done to seamlessly integrate this(code-generation part) to WSF/Jython code. More coding have to be done on code generation module for Jython.

4) In a earlier post I said of modifying the Python deployer to support Contract First approach. This happens in the server-side code generation. It's a problem that I am still having.

5) In the same post I said that
0nly generate the client code and use the existing WSF/Jython's client API. Then before running the client code you can add the WSF/Jython client-side jar to the class path.
Now it seems like the best option out of the two options mentioned in the above post.

[The above arguments are my opinions and may subject to change.]

Friday, July 10, 2009

GSoC: How to integrate with existing code base

This post will contain my arguments on "How to integrate this project to the existing WSF/Jython code base". This is a followup to my last post.

1. Modify the Python deployer to support Contract First approach.

2. To support Contract First approach you need to be able to generate a skeleton and a message receiver for your service. The generic message receiver that I have already written may not work because it works only on a limited schema structure.

3. Another way to look at the above argument(2) may be; only generate the client code and use the existing WSF/Jython's client API. Then before running the client code you can add the WSF/Jython client-side jar to the class path.

The above arguments are my opinion(for now) on integrating the gsoc code to existing code base. The above arguments may subject to change.

Sunday, July 5, 2009

GSOC: Problems faced during development

Earlier I said that I would be writing a blog post on the problems which I encountered during the development phase of my GSoC project. Here I am compiling them to a list. Some points in the list may not directly be problems but important things which came across during the process.

1. Had a problem with building axis2. This was overcome when I found a workaround for this. (This was a hard issue to regenerate because this will only happen occasionally.)

2. There were lot of dependencies inside axis2's code generation framework. Some dependencies were not set by the build script. Therefore had to manually add the dependencies and run the code. When it gives a compilation error stating a dependency is not there, had to set the dependencies. This took some time :).

3. Had to take some time to understand the existing code base and the architecture of the code generation framework.

4. Learned to work with XSLTs.

5. Another important point to note is that the WSF/Jython distribution, now needs some additional libraries to successfully run. You may have wondered "why is this happening?". As you may already know WSF/Jython is built on top of Apache Axis2. The new releases of Axis2 are having more dependencies towards other liblaries/jars (eg. wsdl4j, etc). Since I no longer work for WSO2, I do not have the access writes to change the build script for WSF/Jython. As soon as I get there, I would remember to revise the build script. Until then you could do a small workaround:)

Download Axis2 standard binary distribution. Then extract it. Add the jars which are residing in the lib folder, to the classpath. Then you could carry on with your work.

6. How to integrate this project to the existing WSF/Jython development. (I will present my arguments on this on a new post)


Saturday, June 27, 2009

Design for Jython Extension for Axis2

In a earlier post I said that I am coming up with a Jython extension for Axis2. This will be a code generation tool for jython. This will use existing infrastructure in Axis2 to support Contract First Web services in Jython. What I am planning to do is to integrate this code generation tool into WSF/Jython. Then WSF/Jython will be able to support both, contract-first and code-first approaches. Thus, making the life easier for the Jython developer :).


The code generation engine calls the extensions one by one and then calls a component what is known as the Emitter. Emitter is the actual component that does the significant bit of work in the code generation process. Emitters are usually language dependent and hence one language has one emitter associated with it. Therefore there should be an emitter to support Jython code generation. This simple yet powerful architecture is shown in the above illustration.

The Emitter processes the WSDL and builds a object model. The object model is simply an XML file which contains the object model of the WSDL with respect to Axis2 information model (ie. axis service, axis operation, axis message, etc). The template is a XSLT file which contains information on how the code should be generated. Then the built object model is parsed against the template to build the jython source code.

wsdl2java Code Generation

Axis2's wsdl2java code generation tool can be used to auto-generate programming language code for a given WSDL file. It can either generate code to invoke a Web service, or it can auto-generate the skeleton code that will adhere to the specification described within the WSDL file so that the generated code can be deployed as a Web service.

Friday, June 26, 2009

Axis2 Code Generator

This is a follow up to my earlier post. What I am planning to do is to come up with a mechanism to generate jython code for a given WSDL. For this purpose I am planning to use Axis2's Code Generation module.

When you consider a SOAP processing engine, one of the key value additions will be code generation based on WSDL. It is normally considered as a tool and importance of it can be seen as;
  1. User convenience - Code generation tool helps users, to use the framework in easy and efficient way.
  2. Make use of the framework to it's full potential.
Now let's have a look at the architecture of Axis2 Code generator.

The tool's architecture is pretty straight forward. The core processes the WSDL and builds a object model. Then the built object model is parsed against the template to build the source code.

Thursday, June 25, 2009

Building Axis2

This is a bug (I think) which I came across a couple of times, while building Axis2. To overcome this you have to follow 2 simple instructions ;). For the completeness of this blog post, I will direct you through he complete build process.

1. First checkout the source.
svn co http://svn.apache.org/repos/asf/webservices/axis2/trunk/java

2. Build the project from the source. Do not skip the tests, when you do a fresh build.
mvn clean install

NOTE:
Now is the tricky part. If you are not getting build errors, then no problems at all :). If you start getting build errors related to plugins, then do the following to overcome it.

1. First build the axis2-aar-maven-plugin.

2. Then build the axis2-mar-maven-plugin.

3. Afterwards, build axis2. This should pretty much overcome the build error :).

Jython extension for Apache Axis2

In a earlier post I mentioned that my proposal for GSoC 2009 was accepted. There I didn't give much details on what my project is about. Here is a description of my project.

If you have tried out WSO2 WSF/Jython, you will know that it is based on code-first approach. Web services, is a technology to deliver the architectural style defined in SOA. Although there seems to be a general confusion about the relationship between SOA and Web services, it is important to know that Web services are an implementation methodology that adopts standard protocols to execute SOA. There are two widely used techniques in Web service development, ie.
  1. Code First
  2. Contract First
With the contract-first approach, the contract for the Web service is determined first and then the supporting tools are used to generate the implementation code. In contrast, in the code-first approach, first the implementation code is created and then the Web service development framework is used to produce the contract for the Web service.

In simpler terms; in WSF/Jython what I am doing is asking you to write the web service and the client. Then based on the service, a WSDL is generated and exposed as a Web service. Afterwards jython client can be used to invoke the service (ie. code-first).

When it comes to contract-first it is vice versa of the above scenario. First we will have to take the provided WSDL in to consideration. Then based on this WSDL, the code should be generated. Following are the advantages of using contract first approach.
  • Loose coupling between applications
  • Interoperability between multiple services
  • Abstraction hides underlying implementation details
  • Collaboration and agreement between all parties

Monday, October 27, 2008

IITC Poster



This is the poster which was displayed at IITC on behalf of my project. I had this idea about the logo and Harshan & Pandula helped me to make my idea a reality. Mr Dulan Wathugala's constructive criticism helped me to improve the poster's appearance.


Wednesday, September 17, 2008

Deploying a Python Service on Axis2

Apache Axis2/Java, is a popular open source Web service engine. It currently supports exposing services written in Java, Javascript and Ruby as Web services. This article discusses the Python data Binding that enable exposing Web services written in Python.

Axis2/Java is now able to expose a service written Python as a Web service. The underlying deployer will read the annotations and perform data-binding, schema generation. Schema generated will be passed on to the Axis2 engine, which will then perform the WSDL generation. Thereafter, a client is able to invoke the service using the WSDL generated.

Invoking Enterprise Web Services using Jython

This article discusses the usage of WSO2 WSF/Jython API to write Web service clients in Jython. WSF/Jython's Jython-Client API can be used to write a Jython service clients. It supports attachments with MTOM, SOAP, REST and WS-* standards such as WS-Addressing, WS-Security.

Tuesday, September 16, 2008

Jython Web Services with Axis2 - WSO2 WSF/Jython 1.0 alpha release

WSO2 Web Services Framework for Jython (WSO2 WSF/Jython), is an open source framework for exposing and consuming enterprise level Web Services in Jython.

You can download the source and binary distributions from the following URL.
http://wso2.org/projects/wsf/jython

You can read the following articles.
http://wso2.org/library/articles/deploying-python-service-axis2
http://wso2.org/library/invoking-enterprise-web-services-using-jython

Pleas feel free to send any feedback to our forum.
http://wso2.org/forum/797

For further details please visit our project's website at:
http://wso2.org/projects/wsf/jython