Santhosh Muralidharan

sajid dayer wrote:C:\Users\ac\Desktop\apache-tomcat-6.0.44\webapps\demo\WEB-INF\web.xml.txt
and this folder structure is look like this
and i m accessing like this
http://localhost:8080/demo/helloworld
and also try like this http://localhost:8080/helloworld

Your web.xml looks like a txt file C:\Users\ac\Desktop\apache-tomcat-6.0.44\webapps\demo\WEB-INF\web.xml.txt
Please change to web.xml file and deploy in tomcat.

Please follow this example to deploy your servlet in Tomcat.http://www.mkyong.com/servlet/a-simple-servlet-example-write-deploy-run/

May i know how you are accessing the servlet deployed in Tomcat?. Did you configure the servlet in web.xml?

I presume you deployed the war file in Tomcat. Please ensure to verify the jar files in Tomcat.

We can create single JMS connection and ensure it to call it once. If you want to avoid writing java code for JMS i suggest you to go for Spring Integration http://projects.spring.io/spring-integration/. All the JMS configuration will be in XML. No java code is required.

ActiveMQ would be better option. It uses message compression very well irrespective of the size of data. And also i would recommend RabbitMQ, which is very good for Interoperability.

sowjan kumar wrote:I would like to know which architecture to choose - Apache Camel or Mule soft for a ESB setup.. We have a large transaction based enviornment with large number of user transactions happening.

ESB should well be integrated with other products too such as SAP, Salesforce etc..No cloud based setup or Hadoop/Big data kinda technologies used..

Thanks

I recommend Jboss Fuse ESB. It has Apache Camel and Active MQ embedded in it and other option would be WSO2 ESB. This requires more support from the WS02 technical team to work extensively.

You can try Apache Axis WSDL2Java tool

Please be clear with your question.

Requesting large amount of data for REST service during peak load will always lead to strain on the server.The best option, i think, would be to fetch the data based on managable threshold value to limit the data returned and calling multiple calls would be fine.

Basically REST is stateless means every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request.
Statelessness is easier to distribute across load-balanced servers. Since no two requests depend on each other, they can be handled by two different servers that never coordinate