Popular Posts

Monday, June 30, 2008

How to deploy Apache Axis2 on Resin and JBoss application servers

Axis2 can be deployed very easily on most of the application servers. Lets see how we can deploy axis2 on JBoss and Resin application servers.

Deploying Axis2 on Resin application server

1. Download and install Resin from here

2. Download Axi2.war

3. Copy axis2.war to RESIN_HOME/webapps (i.e:- D:\resin-3.1.6\webapps)

4. Start Resin server
Go to RESIN_HOME/lib and enter the following command to start the server
java -jar resin.jar start

5. Open a browser and issue http://localhost:8080/axis2
Axis2 welcome page will be displayed.

6. Verify the status of installation. Click on 'Validate' link. You should see the following 'Axis2 Happiness' page.



Deploying Axis2 on JBoss

1. Download JBoss
(I used JBoss 4.2.2 GA but the same procedure can be applied for any version)

2. Download Axi2.war

3. Copy axis2.war to JBOSS_HOME/server/default/deploy

4. Start JBoss (Just execute JBOSS_HOME/bin/run.bat or run.sh)

5. Jboss will explode and deploy Axis2 when starting the server. Exploded directory can be found at JBOSS_HOME/server/default/tmp/deploy/tmpXXXXaxis2-exp.war (i.e:- D:\jboss-4.2.2.GA\server\default\tmp\deploy\tmp46684axis2-exp.war)

6. Open a browser and access http://localhost:8080/axis2
Axis2 welcome page will be displayed.

6. Check whether the installation is successful. Click on 'Validate' link. You should see the following 'Axis2 Happiness' page.

How to avoid "Unable to generate EPR for transport" error in Axis2

"Unable to generate EPR for transport: http" is a FAQ in Axis2 mailing list. You may have experienced this when invoking a service using generated stubs.

Solution:

It's really simple. When creating the instance of stub, pass the actual service end point (epr) to the constructor as follows.

YourserviceStub stub = new YourserviceStub("http://<IP>:<PORT>/axis2/services/YourService")


Ideally when u generate a stub for a service it will pick up the Endpoint reference from the WSDL. So just instantiating stub with YourserviceStub stub = new YourserviceStub() could send the request to the address defined in the WSDL. In case you get the "Unable to generate EPR for transport: http" error, give a try with the above as well.

Wednesday, June 25, 2008

WS-Reliable Messaging with WSO2 WSAS - II

This is the part two of my previous post on WS-Reliable messaging with WSO2 WSAS - 1
I'd suggest you to follow the steps given in there before proceeding with this.

We looked at how WSO2 WSAS and WSO2 Mercury module are used in one-way (IN-ONLY) message interaction in reliable manner. In this post I'll explain the procedure to do the same with Request Reply(IN-OUT) messaging system using single transport channel.

Step 1

Follow the step 1 - Service Configuration and step 2 - Generate stubs of part one of this post with the service implementation class given below.

package org.wso2.wsas.service;
public class MercuryService{

//Twoway messaging
public int Add(int a, int b){

try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return a+b;
}
}

Note that I inserted a Thread.sleep() in service to wait ~3 seconds before returning results so that we may have enough time to block the transport channel when testing reliable message transmission.

Step 2

If you have followed the step 1 and step 2 exactly as given in part 1 of this post by just replacing service impl. class with the above, you should be able to continue with the client as given below.

Open your IDE and write the following client to invoke service with RM.
Make sure to add jars in WSAS_HOME/lib and the generated client stub jar to your class path in order to compile the client.

public class RequestReplyAnnonClient{

public static void main(String args[])throws AxisFault{

ConfigurationContext cc = ConfigurationContextFactory.createConfigurationContextFromFileSystem
("C:\\RM\\client-repo"+"C:\\RM\\client-repo\\conf\\axis2.xml");

MercuryServiceStub stub = new MercuryServiceStub(cc);
MercuryServiceStub.Add request = new MercuryServiceStub.Add();
request.setA(12);
request.setB(8);

stub._getServiceClient().engageModule("Mercury");

for (int i = 0; i < 29; i++) {
try {
//Two-way invocation
MercuryServiceStub.AddResponse response = stub.Add(request); System.out.println(response.get_return());
} catch (RemoteException e) {
e.printStackTrace();
} try
{
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// Setting the last message stub._getServiceClient().getOptions().setProperty("MercuryLastMessage", Constants.VALUE_TRUE);
try {
MercuryServiceStub.AddResponse response = stub.Add(request); System.out.println(response.get_return());
} catch (RemoteException e) {
e.printStackTrace();
} try
{ Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
In order to have the reliable messaging support at the client, we need to engage Mercury module with "stub._getServiceClient().engageModule("Mercury")". We also need to have ConfigurationContext to define the client repository where the Mercury.mar and axis2 configuration file (axis2.xml) is placed. Create a directory, client-repo and copy WSAS_HOME/repository/modules/mercury.mar to client-repo/modules directory. Also, create a sub-directory conf under client-repo and copy an axis2.xml file ( I have used axis2.xml copied from Axis2-1.4) in to that folder. As in one-way scenario, we need to let Mercury know when we are complete. The simplest way to do this is to mark the LastMessage with stub._getServiceClient().getOptions().setProperty("MercuryLastMessage", Constants.VALUE_TRUE)

Step 3

Compile and run the client. You should configure tcpmon in order to monitor request and response messages.

You will notice that the first message travels through tcpmon contains <wsrm:CreateSequence> as the first first child of soap body. If the transport channel does not get blocked, CreateSequenceResponse message will be returned to client immediately.

You will see that <wsrm:MessageNumber>1</wsrm:MessageNumber> soap header element in the next message where the actual request payload is transmitted. The response of this message may include <wsrm:SequenceAcknowledgement> which denotes the ack to the first message. This will be continued until the last message in which the <wsrm:LastMessage /> as a header element could be seen. (In our test, the message number should be 30)
The end of whole sequence will be denoted by TerminateSequance message.

Lets check whether the reliability is actually provided by WSO2 mercury module when the transport channel is interrupted.

When the 3rd message is sent (Message number 3), click on "Stop" button of Tcpmon listen port. You will see the following in tcpmon.



This mimics the behavior of typical network interruption in data communication. Wait a few seconds and restart the listen port.



As you can see, the response of request message number 3 will be returned when the transport channel is restarted and continues with the rest of the messages. No messages are lost though the channel interruptions are occurred. All 30 messages will be delivered reliably even the network communication issues are occurred during message transmission.

We have looked at one of a basic tests which can be done in order to verify how WSO2 WSAS and mercury module provides reliable message delivery in web service communication. There are more. I'll discuss them in a future post.

Tuesday, June 24, 2008

Short notes on SOAP messaging

SOAP is the fundamental messaging framework for web services. It is the first piece of thing you should learn and understand when starting to deal with web services. I think most of the readers of this blog possess a good understanding of the concepts and techniques of SOAP. However, this blog is not restricted to folks who are working with SOA and web services. QA testers and non-web service specific developers are also a part of target audience.
I thought to describe a set of commonly used terms in SOA and web services in fairly simple and non-technical user oriented manner so that most novice users get benefit from it.

SOAP defines a standard message format based on XML. It provides a mechanism to bind messages to different network protocols. It also defines a processing model to serialize/de-serialize messages.

Structure of a soap message

<Envelope>
<Header>
<headerBlock1/>
</Header>
<Body>
<payload/>
</Body>
</Envelope>

SOAP message consists of 3 basic elements.
Soap Envelope

Body

Header

SOAP envelope should have one mandatory body element which contains the message payload.
One soap message can have zero or more header elements. The SOAP header is an extension that provides a way for information to be passed within a SOAP message that is not
part of the business message payload. Soap headers include information that controls QOS (quality of service) such as Security and reliable messaging.

Soap nodes are intended to receive or send soap messages in the message transmission path. If a node transmits a message it is known as a SOAP Sender. If it receives a message, then it is a SOAP Receiver. If a node does both transmitting and receiving of soap messages, then it is called a SOAP Intermediary.

The Soap sender which builds the message initially is said to be initial SOAP sender. The final target of the message is Ultimate Soap receiver. It is expected to process the payload of soap message.

There is an important attribute you may have seen in soap header elements. it is the "mustUnderstand" attribute. If this attribute is set to true, the target node should process the SOAP header block. If this attribute is false or not available, then target SOAP node can ignore processing the block.

SOAP fault is a model to handle exceptions when an error occurs in processing a soap message.
Soap fault is included in the body element of soap message.
Soap fault should have a mandatory fault code element. There are five fault codes defined in SOAP 1.1 specification.

VersionMismatch: message does not comply with the SOAP version
Sender: message was incorrectly generated when receiving node processing it
Receiver: Receiving node cannot process the message
MustUnderstand: The targeted node cannot understand the soap header
DataEncodingUnknown: The target node cannot understand the data encoding mechanism of the message

SOAP bindings allow a SOAP message to be transmitted over different transport protocols such as HTTP and SMTP.
In a web service interaction, the request and response SOAP messages can be sent via two different transports.

If you can understand the commonly used terms I explained above, you should be able to follow and explore more with the detailed reading materials published on various places.

Stay tuned. I will post a set of commonly used terms of WSDL soon.

Monday, June 23, 2008

Retrieving web service metadata using wso2-mex module

I have published a Knowledge base post at Wso2 oxygen tank which describes the procedure to retrieve web service metadata using wso2 WSAS and wso2-mex module .
You will find it useful since there are no much documents available on the web regarding ws-MEX (ws-MetaDataExchange) configuration and usage.

Friday, June 20, 2008

WS-Reliable messaging with WSO2 WSAS -1

Web services are an essential component of distributed computing. Reliable communication between services and service consumers should be taken in to account when designing SOA based systems.
WS-Reliability is a SOAP-based specification that fulfills reliable messaging requirements critical to web service applications.
The objective of this post is not to discuss the features and architectural details of WS-Reliable Messaging (WS-RM). You can find the WS-RM specification from here and a lot of useful materials are available on the web. I'm going to demonstrate the simplest RM scenario, one-way single channel invocation using WSO2 mercury, which is an implementation of WS-RM using Apache Axis2.
WSO2 mercury is shipped as a module with WSO2 web services application server version 2.3 (WSO2 WSAS-2.3) as well as a separate piece of product. I'm going to describe the scenario using WSO2 WSAS, however you may also follow the given steps with Axis2-1.4 .

We are going to send a set of ping messages (one-way messages) to a web service in reliable manner. In other words, we send a set of requests to a service and block the channel at the middle of message transmission. Then we restart the transport channel. If WS-RM is not enabled, the message transmission will be lost when the transport channel goes down. You have to re-send messages. However, if our service and client are configured to use Wso2 mercury (WS-RM implementation), it will take care of guaranteed delivery of the rest of the messages when the transport channel is back again.

Lets see how reliable messaging can be used with WSO2 WSAS and Mercury.

Pre-requisites:
Install WSO2 WSAS-2.3

Step 1 - Service configuration

Create a simple web service implementation class as follows.

package org.wso2.wsas.service;
public class MercuryService{

//Oneway messaging
public void Ping(String s){
System.out.println("*****Received the ping request*****");
}
}

Compile and save the class.

Next, create a service descriptor (services.xml) as given below and save it in a META-INF directory.

<service name="MercuryService">
<Description>
Mercury test service
</Description>
<messageReceivers>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-only"
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
<messageReceiver mep="http://www.w3.org/2006/01/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
</messageReceivers>
<module ref="Mercury" />
<parameter name="ServiceClass" locked="false">
org.wso2.wsas.service.MercuryService
</parameter>
</service>

Note that <module> element is used to engage the Mercury module, which provides reliable messaging at the server side.

Now, create a deployable Axis2 service archive (*.aar) using the above service implementation class and META-INF/services.xml file. (Please have a look at Axis2 user guide if you are not familiar with service archive structure)

Copy the created service archive (Lets say it is "MercuryService.aar") to WSAS_HOME/repository/services directory. It will be deployed on WSAS. Start WSO2 WSAS using wso2wsas.bat{sh} and login in to admin console (https://localhost:9443)

Go to the services and service group management page and you should see the "MercuryService" there. Click on the service name. You will be directed to MercuryService's service management page. Click on "Manage Module Engagements" link. You will notice that the mercury module is listed under "Modules engaged at service level".



That's all for configuring RM at the web service level. Let's take a look at the client side configuration.

Step 2 - Generate stubs

First, we need to generate client side stubs through WSO2 WSAS management console. In the MercuryService's service management page, select "Generate Client". "Stub Generation" page will be displayed. Click on "Generate" with the code gen options as specified in the following image.

Save the generated jar file in your file system.

Step 3 - Write Client

Now write the client to invoke service in reliable manner. Make sure to add jars in WSAS_HOME/lib and the generated client stub jar in the previous step to your class path in order to compile the client.

package org.wso2.wsas.client;

public class OnewayAnnonSOAP11Client{

public static void main(String args[])throws AxisFault{

ConfigurationContext cc = ConfigurationContextFactory.createConfigurationContextFromFileSystem
("C:\\RM\\client-repo",C:\\RM\\client-repo\\conf\\axis2.xml");

MercuryServiceStub stub = new MercuryServiceStub(cc, "http://localhost:9080/services/MercuryService");
MercuryServiceStub.Ping request = new MercuryServiceStub.Ping();
request.setS("ping");

stub._getServiceClient().engageModule("Mercury");

for (int i = 0; i < 100; i++) {
try {
stub.Ping(request);
} catch (RemoteException e) {
e.printStackTrace();
} try
{ Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// Setting the last message stub._getServiceClient().getOptions().setProperty("MercuryLastMessage", Constants.VALUE_TRUE);
try { stub.Ping(request);
} catch (RemoteException e) {
e.printStackTrace(); }
try { Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace(); } } }

In order to get the reliable messaging support at the client, we need to engage Mercury module with "stub._getServiceClient().engageModule("Mercury")". We need to have ConfigurationContext to define the client repository where the Mercury.mar and axis2 configuration file (axis2.xml) is placed. Create a directory, client-repo and copy WSAS_HOME/repository/modules/mercury.mar to client-repo/modules directory. Also, create a sub-directory conf under client-repo and copy an axis2.xml file ( I have used axis2.xml copied from Axis2-1.4) in to that folder. You can call ping method of your webservice inside a loop so that multiple requests will be submitted. stub.Ping(request); In reliable messaging, a Sequence is created using a CreateSequence interaction, and terminated when finished with a TerminateSequence interaction. Therefore, a CreateSequence message is generated by client as the first step. If the CreateSequenceResponse message is received, then the actual application message delivery is started. Each message in a sequence has a message number, which starts at one and increments by one for each message. These message numbers are used to acknowledge the messages. In order to complete the sequence, the last message should be stated explicitly with stub._getServiceClient().getOptions().setProperty("MercuryLastMessage", Constants.VALUE_TRUE); Lets try to understand this scenario by sending messages via tcpmon. Start tcpmon and configure listen port as 9080 and target port as 9762.


Step 4 - Run client and monitor with TCPmon

Now run the client and check the messages delivered through tcpmon. You will notice that the first message is "CreateSequence". You will see that <wsrm:MessageNumber>1</wsrm:MessageNumber> soap header element in the next message where the actual ping request payload is transmitted.

Finally, check whether the messages are delivered reliably when your transport medium is interrupted. While the request soap messages are being sent, stop the incoming transport channel through tcpmon. You may do so by just stopping the port 9080. Wait a few seconds. Restart port 9080. You should see that the message transmission is resumed.

Thats all for now! will post more on WSO2 WSAS/Axis2 and RM soon.

Thursday, June 12, 2008

Isolated test estimations do very little in agile world

The traditional test estimation techniques do not seem to work well in agile systems. In general, most test estimate models are based on development estimates and often you don't get sufficient time for complete test coverage. There will always be a battle between devs. and testers in scheduling and effort estimation.

Think about a simple scenario. Manager of project A asks a developer how many days he needs to implement a particular module. Suppose developer requests 3 weeks. Then
the manager asks how long will it take to do testing of that particular module. Test lead may request 2 weeks based on his estimates.
The immediate answer will be "No, do it in 1 week, you can get help from a few more testers working on project B"

Suppose the test estimate has done using valid estimation mechanism and enough time is allocated for executing all test cases.
Will the testing be completed within 2 weeks (or 1 week with more testers) as scheduled?
According to my experience, It depends.
If your programmers write unit tests and do code reviews, the test schedule will not be deviated much from the original estimates.
However, if the above disciplines are not followed, the estimations will no longer valid. There will be hell a lot of bugs when QA team start testing the code. Blockers may prevent exercising major components and therefore product Schedule slippages are ineviatable.

I think there shouldn't be two different estimates for development and testing. Both should come together in a common project estimate to achieve on time delivery.
The estimates to complete a module should be prepared, which includes both dev and testing effort.
In the above example, developer and tester can work together to come up with a combined estimation which captures code quality and testing implications. Both parties should monitor the progress and adjust the estimates accordingly. If unit tests and code reviews are not happened as scheduled, project leads should agree to allocate more time for testing.

Keep in mind. I'm expressing my views according to the Agile environments. Not the outsourced test models which requires to have separate QA/test estimates to be signed off by clients before start testing cycles.

Tuesday, June 10, 2008

WSO2 WSAS -2.3 is out!

WSO2 Web services application server (WSAS) - 2.3 was released yesterday. It was an extremely tough release. We were given the June 10th deadline less than 2 weeks back (on 27th of May). There were major changes happened in core Axis2. We were supposed to ship with Axis2-1.4 which had not been gone through a rigorous QA/test cycle to verify compatibility with WSO2 WSAS. It was one of the most challenging test/QA cycles I have ever gone through. It is obvious that less than 2 weeks are not enough to do a full scale functional/regression test, no option, we had to mange somehow.

Milestone builds were planned to out for QA testing on every friday though it did not happen. There were a lot of regression issues and most of them were uncovered during the initial QA tests. Fixes were getting delayed and some blockers avoided exercising some major features until last moment. Worked around the clock to complete functional as well as regression testing.
During the last few days 2-3 release candidates were out in a day. :) We had to make sure the regressions are minimum in between RCs. Interoperability with other SOA frameworks such as .NET was one of the major requirements expected from WSAS-2.3 release. Interop test suites were already in place when we started test cycles. However, most of java test suites were out dated, no build scripts or failed in execution. Therefore we had to update some of them/write from scratch.
Automated ant based functional test-framework helped to do quick smoke tests. However, as I expected and believed, good/critical defects were always uncovered during manual tests.

WSAS-2.3 release can be considered as a true TEAM effort. Everyone worked hard to get the things done within the given extremely tough deadline. I'm confident that WSAS-2.3 will also be demonstrated the better product quality as in previous releases though everything done within short time.

Finally our effort and hard work paid off as the interop demo of WSAS was very successful at the Microsofts' TECH ED 2008.

One thing I should mention here is, if the deadline is fixed (if it is not negotiable) and the schedule is very aggressive with limited time allocated for testing, you have to forget some process bullshit and work hard to find more and more BUGS. Yes, Risks are apparent, however you have to set the expectations with your leads making sure everyone understands the constraints/issues clearly.

WSO2 WSAS-2.3 release can be downloaded from http://wso2.org/projects/wsas/java

From the WSO2 WSAS 2.3 - Release Note - 10th June 2008
======================================================

WSO2 WSAS is an enterprise ready Web services engine powered by Apache
Axis2 which offers a complete middleware solution. It is a lightweight,
high performing platform for Service Oriented Architectures, enabling
business logic and applications.
Bringing together a number of Apache Web services projects, WSO2 WSAS
provides a secure, transactional and reliable runtime for deploying and
managing Web services.

Key Features
------------
* Data services support - Expose you enterprise data as a services in a
jiffy
* WSAS IDE - Eclipse IDE integration
* Clustering support for High Availability & High Scalability
* Full support for WS-Security, WS-Trust, WS-Policy and WS-Secure
Conversation and XKMS
* EJB service provider support - Expose your EJBs as services
* Axis1 backward compatibility - Deploy Axis1 services on WSAS & Engage
advanced WS-* protocols in front of legacy services
* JMX & Web interface based monitoring and management
* WS-* & REST support
* GUI, command line & IDE based tools for Web service development


New Features In This Release
----------------------------
* Improved interoperability
* Improved Data Services support
* Various bug fixes to Apache Axis2, Apache Rampart & WSAS
* WSO2 Mercury Integration - A new WS-RM Implementation

Data Services - Bringing Enterprise Data to Web
-----------------------------------------------
* Service enable data locked in relational databases, CSV & Excel files
in no time
* Zero code. Simple descriptor file describes the data to service mapping
* Controlled access to your data
* Customizable XML output
* Benefit from REST & WS-* support
* Built-in Connection pooling support
* Supports exposing Stored procedures & functions
* Built-in caching
* Throttling - to ensure your database is never overloaded.
* Easy configuration via graphical console
* Test your services via Try-it tool

Training
--------

WSO2 Inc. offers a variety of professional Training Programs, including
training on general Web services as well as WSO2 WSAS, Apache Axis2,
Data Services
and a number of other products.

For additional support information please refer to
http://wso2.com/training/course-catalog/


Support
-------

WSO2 Inc. offers a variety of development and production support
programs, ranging from Web-based support up through normal business
hours, to premium 24x7 phone support.

For additional support information please refer to http://wso2.com/support/

For more information on WSO2 WSAS, visit the WSO2 Oxygen Tank
(http://wso2.org)

How to do various things with WSAS - WSAS HOWTO
Series(http://wso2.org/library/2707)

For further information see the full release note
http://wso2.org/project/wsas/java/2.3/docs/release_notes.html

Monday, June 2, 2008

Paul Fremantle (WSO2 co-founder/CTO) is among world's best CTOs

Today Inforworld has published the list of top leaders for technology and management innovation - The best CTOs of 2008

It is with a great pleasure to inform you that Paul Fremantle is being recognized as one of 2008 InfoWorld Top 25 CTOs!

Congratulations Paul!!!!