India vs Pakistan is big when it comes to anything. Cricket is no different to that and India vs Pakistan is one of the most hard fought contest you could ever find. India and Pakistan clashed in a crucial Asia Cup 2008 match yesterday. What a clinical chase it was by Pakistan who hunted down the mammoth 308 scored by India. Pakistan was under pressure as they had already lost to Sri Lanka and they needed a victory to keep there hopes alive of getting into the finals. Sri Lanka had already booked their place in the final.
On a placid batsman friendly wicket India posted 308. Chasing down anything over 300 is not easy and to do it under so much pressure takes a lot of courage. Whats more Pakistan were without their regular captain Shoaib Malik and it was Misbah-ul-Haq who had to fill his shoes. Misbah is new to the scene having played just 39 matches and he showed tremendous maturity in yesterday's Match.
What I want to highlight here is that Tough Competition Brings Out The Best. It can bring out the best of a person, company or even a Product. Thats exactly what happened in yesterday's match. Pakistan was under so much pressure and that brought the best out of Misbah-ul-Haq and Younis Khan.
The same can be said about software. Lets take the Enterprise Service Bus (ESB) for example. We did some performance testing on comparing the WSO2 Enterprise Service Bus (ESB) with some other Open Source and proprietary ESBs. If you take a look at Round 1 and Round 2 you would see that the WSO2 Enterprise Service Bus (ESB) was the fastest. Now take a look at the latest (Round 3) results too. The proprietary ESB which was slower in the previous rounds showed better performance. Competition brought the best out of it. I'm pretty sure that this result will encourage our ESB team to perform better next time. Tough competition is always good and it helps us improve our selves.
The same can be said about the WSO2 Registry. This has stiff competition from Mule Galaxy another open source registry. You can see a comparison of the WSO2 Registry and Mule Galaxy here which was done by Deepal.
Thursday, July 3, 2008
Using TCP Monitor to Debug Web Service Calls
TCP Monitor is a great tool when it comes to debugging Web Service calls. It acts as a proxy between your client and the actual service, hence it helps you to have a look at the wire message and figure out whats going on. It comes as an IDEA and Eclipse plugin as well.
Here is how you configure the TCP/IP Monitor Plugin in IDEA.
1. Goto File->Settings->Plugins
2. Search for TCP and you will find Axis TCP Monitor Plugin
3. Right click->Download and Install
4. Restart IDEA
5. You will see TCPMON appear on the right panel. You could also access it at Window->Tool Windows->TCPMON
6. Set Listen port # to 8080, Target HostName (The place where the service is at, if its running locally localhost), Target Port # (the port which the service is running on)
7. Click add
8. Configure your client to send the request to the TCP monitor instead of the actual service (for e.g localhost:8080) and the TCP monitor will forward it to the actual service. You will see the message on the TCP monitor.
Here is how you configure the TCP/IP Monitor Plugin in Eclipse.
1. Goto window->show view->other
2. Search for TCP and you will find TCP/IP Monitor
3. Right click->properties
4. click add
5. Set local monitoring port to 8080, host name (The place where the service is at, if its running locally localhost), port (the port which the service is running on)
6. Configure your client to send the request to the TCP monitor instead of the actual service (for e.g localhost:8080) and the TCP monitor will forward it to the actual service. You will see the message on the TCP monitor.
Here is how you configure the TCP/IP Monitor Plugin in IDEA.
1. Goto File->Settings->Plugins
2. Search for TCP and you will find Axis TCP Monitor Plugin
3. Right click->Download and Install
4. Restart IDEA
5. You will see TCPMON appear on the right panel. You could also access it at Window->Tool Windows->TCPMON
6. Set Listen port # to 8080, Target HostName (The place where the service is at, if its running locally localhost), Target Port # (the port which the service is running on)
7. Click add
8. Configure your client to send the request to the TCP monitor instead of the actual service (for e.g localhost:8080) and the TCP monitor will forward it to the actual service. You will see the message on the TCP monitor.
Here is how you configure the TCP/IP Monitor Plugin in Eclipse.
1. Goto window->show view->other
2. Search for TCP and you will find TCP/IP Monitor
3. Right click->properties
4. click add
5. Set local monitoring port to 8080, host name (The place where the service is at, if its running locally localhost), port (the port which the service is running on)
6. Configure your client to send the request to the TCP monitor instead of the actual service (for e.g localhost:8080) and the TCP monitor will forward it to the actual service. You will see the message on the TCP monitor.
Tuesday, July 1, 2008
Web Services Cannot Get Any Simpler
If someone was to ask "what is the easiest method to write a Web Service?" my definite answer would be the WSO2 Mashup Server. The WSO2 Mashup Server helps you write services (or Mashups which ever you want to call it) using JavaScript with the E4X extension. Will blog more about E4X and its ease of use in the coming days (Stay tuned for that). Writing Services using the Mashup Server can be done in a matter of minutes. Here is the simplest Web Service you could write,
function sayHello() {
return "Hello";
}
Just drop this bit of script as a file into a magic folder (Into your mashups folder found in the scripts directory. Each user is given his own mashups folder depicted by his username) with the .js extension (example hello.js) and your service will get deployed. Lets assume that hello.js was dropped into scripts/keith. This would make the service available at http://localhost:7762/services/keith/hello. Browse to the above location and see what happens. The Mashup Server will show you a tryit page. This is a page thats generated by the Mashup Server on the fly so that you can test your web service out.
You can even access the sayHello service by pointing your browser to http://localhost:7762/services/keith/hello/sayHello. This would invoke the sayHello function in a RESTfull manner.
One can also use the Mashup Server without downloading it. Check out mooshup.com which is a Mashup Server that we've hosted for you. Try creating your own mashups there (You will have to use the UI to create services there cause you do not have direct access to the file system). You can even create a mashup on your local distribution and share it to mooshup. You can have a look at this simple hello service at https://mooshup.com/mashup.jsp?path=/mashups/keith/hello. BTW the Mashup Server is released under the Apache License. So you can download and give it a try your self too. There are no restrictions.
This is the simplest Web Service one could write. The Mashup Server has capabilities to do much more for you. Please refer the Mashup Server project page for more details.
Stay tuned for more tips and tricks about the WSO2 Mashup Server and also Apache Axis2 (The engine behind the Mashup Server)
function sayHello() {
return "Hello";
}
Just drop this bit of script as a file into a magic folder (Into your mashups folder found in the scripts directory. Each user is given his own mashups folder depicted by his username) with the .js extension (example hello.js) and your service will get deployed. Lets assume that hello.js was dropped into scripts/keith. This would make the service available at http://localhost:7762/services/keith/hello. Browse to the above location and see what happens. The Mashup Server will show you a tryit page. This is a page thats generated by the Mashup Server on the fly so that you can test your web service out.
You can even access the sayHello service by pointing your browser to http://localhost:7762/services/keith/hello/sayHello. This would invoke the sayHello function in a RESTfull manner.
One can also use the Mashup Server without downloading it. Check out mooshup.com which is a Mashup Server that we've hosted for you. Try creating your own mashups there (You will have to use the UI to create services there cause you do not have direct access to the file system). You can even create a mashup on your local distribution and share it to mooshup. You can have a look at this simple hello service at https://mooshup.com/mashup.jsp?path=/mashups/keith/hello. BTW the Mashup Server is released under the Apache License. So you can download and give it a try your self too. There are no restrictions.
This is the simplest Web Service one could write. The Mashup Server has capabilities to do much more for you. Please refer the Mashup Server project page for more details.
Stay tuned for more tips and tricks about the WSO2 Mashup Server and also Apache Axis2 (The engine behind the Mashup Server)
Saturday, June 28, 2008
Learn About The Fastest Enterprise Service Bus (ESB) Around
You may have already seen how fast the WSO2 Enterprise service Bus (ESB) is. Want to learn how to use this ultra fast, light-weight and versatile Enterprise Service Bus (ESB) powered by the Apache Synapse ESB?
Well we got an answer for you. Join our free webinar series this July. There will be four webinars in total ranging from an "Introduction to the WSO2 ESB" to more advanced scenarios such as "Using the WSO2 ESB and FIX - supporting Financial messaging".
FIX support is the latest addition to the WSO2 ESB which is available in the recently released 1.7 version. This series of webinars will be presented by Paul Fremantle, CTO at WSO2 together with Asankha Perera ( ESB Architect), Asanka Abeysinghe (Architect) and Ruwan Linton (Senior Software Engineer).
Well we got an answer for you. Join our free webinar series this July. There will be four webinars in total ranging from an "Introduction to the WSO2 ESB" to more advanced scenarios such as "Using the WSO2 ESB and FIX - supporting Financial messaging".
FIX support is the latest addition to the WSO2 ESB which is available in the recently released 1.7 version. This series of webinars will be presented by Paul Fremantle, CTO at WSO2 together with Asankha Perera ( ESB Architect), Asanka Abeysinghe (Architect) and Ruwan Linton (Senior Software Engineer).
Friday, June 27, 2008
Increasing memory of JUnit TestCases in Maven2
The WSO2 Mashup Server uses Maven2 as its build system. Since of late we were facing an issue where our integration tests were failing regularly with the exception "Caused by: java.lang.OutOfMemoryError: Java heap space". This is the JIRA that tracked this issue . During the integration test phase we start up an instance of the mashup server and deploy some test scripts. We them bombard the server with around 110 request (within a second or two) hence it ran out of memory before the tests completed.
Increasing memory given to maven using MAVEN_OPTS did not solve the problem. As this setting just increases the memory given to the build process and not the individual test cases. The solution was to use the following configuration in the surefire plugin.
The pom for the integration test can be found here. This fixed the heap space issue and now we have our test cases running on the nightly build. You can see the status of our nightly builds at http://builder.wso2.org/browse/MASHUP-NIGHTLY
Increasing memory given to maven using MAVEN_OPTS did not solve the problem. As this setting just increases the memory given to the build process and not the individual test cases. The solution was to use the following configuration in the surefire plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>pertest</forkMode>
<argLine>-Xms256m -Xmx512m</argLine> <testFailureIgnore>false</testFailureIgnore>
<skip>false</skip>
<includes>
<include>**/*IntegrationTestSuite.java</include>
</includes>
</configuration>
</plugin>
The pom for the integration test can be found here. This fixed the heap space issue and now we have our test cases running on the nightly build. You can see the status of our nightly builds at http://builder.wso2.org/browse/MASHUP-NIGHTLY
Is Mule Really Open Source?
Most Open Source Projects (Not the namesake open source projects) are released under an OSI approved license. The open source definition of OSI states that "Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:". It goes on to describe 10 items under this. Item #6 states that "The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."
The Mule Enterprise Edition (Mule EE) violates item #6 which is described above. The License of Mule EE states that you cannot publicly publish performance results against it. Whats more if you go to the mule site you won't find the source code of Mule EE, rather it asks you weather you are "Looking for the open source Mule Community Edition?".
What baffles me is that Dave Rosenberg the CEO Mule states that "The Enterprise version of Mule is open source". Take a look at Dave's comment on Sanjiva's blog. What a joke.
Now Mule CE is an open source ESB. But would anybody care to use it in production? Look what we found out about Mule CE during some performance testing. 1% of all requests sent to Mule CE 2.0.1 fails. Now thats how you sell Mule EE keeping Mule CE Open Source.
The Mule Enterprise Edition (Mule EE) violates item #6 which is described above. The License of Mule EE states that you cannot publicly publish performance results against it. Whats more if you go to the mule site you won't find the source code of Mule EE, rather it asks you weather you are "Looking for the open source Mule Community Edition?".
What baffles me is that Dave Rosenberg the CEO Mule states that "The Enterprise version of Mule is open source". Take a look at Dave's comment on Sanjiva's blog. What a joke.
Now Mule CE is an open source ESB. But would anybody care to use it in production? Look what we found out about Mule CE during some performance testing. 1% of all requests sent to Mule CE 2.0.1 fails. Now thats how you sell Mule EE keeping Mule CE Open Source.
Training session on Apache Axis2
A couple of weeks ago we were fortunate to attend a training on Axis2 which was conducted by Deepal. There is no better person to teach Axis2 than Deepal himself cause he has been involved with this project since its inception. Deepal is one of the six core Axis2 authors. The others are Srinath, Eran Chinthaka, Ajith, Chathura and Jaliya. There have been many others who've help Axis2 once the project started going, but these were the guys involved in building the core of it. Not to forget Dr. Sanjiva for all the advice and guidance provided.
The guys who knew Axis2 to some extent were able to make to most of this training, as we were able to question certain decisions made at that time.
Its also nice to note that except for Deepal. the rest are already reading for there PhDs. Deepal will be joining that list next month when he will head off for higher studies. Its also a interesting that the core Axis2 team has been associated with WSO2.
Deepal has also published his first book on Axis2 "Quickstart Apache Axis2" which is now available in the stores.
The Axis2 training was a great success so now its time to learn some policy. Again there will be no better person than Sanka himself, the person behind Apache Neethi (The policy engine used for Apache Axis2 as well as CXF). Once next week is done all of WSO2 will be policy experts too.
All of these are a part on continuous improvement to us.
The guys who knew Axis2 to some extent were able to make to most of this training, as we were able to question certain decisions made at that time.
Its also nice to note that except for Deepal. the rest are already reading for there PhDs. Deepal will be joining that list next month when he will head off for higher studies. Its also a interesting that the core Axis2 team has been associated with WSO2.
Deepal has also published his first book on Axis2 "Quickstart Apache Axis2" which is now available in the stores.
The Axis2 training was a great success so now its time to learn some policy. Again there will be no better person than Sanka himself, the person behind Apache Neethi (The policy engine used for Apache Axis2 as well as CXF). Once next week is done all of WSO2 will be policy experts too.
All of these are a part on continuous improvement to us.
Subscribe to:
Posts (Atom)
Posts
