we use spring-remoting for a Client-Server-Application. Now we are in doubt how to realize a real load test with serialized objects.
The problem is that many load testing toolkits are based on plain text HTTP communication, so it's very easy to parameterize the http-requests. Because spring-remoting is based on serialized objects we can't easily parameterize the http-communication to the server.
My first idea was to encapsulate the endpoint of spring-remoting and to call the service over client-side service classes. But how can I realize calling the remote-service from multiply clients to gain a real load test scenario?
Are there any solution for wrapping the client-side service in an easy manner?
Has anybody some experiences how to realize it?
Thanks for advice.
There is a discussion on the Spring forums about how to use JMeter to do testing. To use JMeter you'll need to write a custom Sampler. They have examples on the JMeter site.
Alternatively, you could try Grinder. Testing scripts are written using jython but it is arguably easier to create tests for non-standard protocols.
There is a commercial JMeter plugin which allows this, see:
http://www.ubik-ingenierie.com/blog/load-testing-java-serialization-applications-with-jmeter/
To make your tests realistic, you will need to variabilize content in the
serialized objects.
This Java Serialization plugin will allow the following:
Easy recording of traffic with JMeter Proxy Server, a Test Plan using
custom Sampler will be created
Easy variabilization of requests (which will appear as XML) through as
easy syntax as for example ${searchedWord} where searchedWord can come from
a CSV or any user defined variable.
Easy extraction of data from responses using JMeter standard Post
Processors
Easy debugging of Request/Responses through standard JMeter View Results
Tree element
Disclaimer : I am member of the company that distributes this solution
Related
What is the advantage of using selenium with Typescript over selenium with Java.
Which type of web applications can be automated with Selenium+Typescript and why these cant be done with selenium+java?
In term of automation -> Type scripts basically used by tools like protractor which actually used javascript itself but provide extension to write scripts in typescript which then converted to javascript and pass further for execution.
The main use of typescript is its oops based so its easy to write maintainable code.
Protractor is a nodejs plug-in which use selenium wedriverjs binding internally
Your second question why typescripts:
Basically Protractor is use on Angular-JS client side websites. still you can automate non-angular websites also using Protractor
Normally selenium do not have the capability to understand if the element is ready due to even after page load completed, JavaScript is still working behind for Anugular/JS based website so Protractor provide wrapper which having additional functionality like waitForAngular
Additionally Protractor provide more locators identify strategy which is not present in normal selenium with java or c#
Refer:
http://www.protractortest.org/#/locators
As Protractor is build on wedriverjs we also need to script for it on JavaScript or typescript. basically even if you code in typescript internally it will convert it into typescript. people prefer typescript as it follows full oops unlike like JavaScript
Source:
http://www.protractortest.org/#/
there are more js based framework is in the market like:
WebdriverIO
Nightwatch
Now java also comes up with many library like JSWaiter etc which claim they can handle js based client side websites with java + selenium as well
No major benefits in my opinion, that's my tl,dr;
I can think of a couple of options you might have though:
You might be able to integrate the test framework with the front-end application repository. This can be useful if you are using a Typescript based framework (like React for example) and you can potentially use that to import the application data (for example stub responses for APIs that the developers are using for their dev work, assuming they are available there... just an example) and use that for testing the front-end code in isolation without the API dependencies.
The other reason I can think of is that if you did the above you can potentially execute your test cases as part of the CI of the front-end code, for example you can run a subset of the test cases with pull requests to make sure all is green before merging in the main branch.
Really you can do all the above with an external repo written in Java (hence, no major benefits)
I am working on an application which is built in .NET and Java. The Java component contains the complete Rule base using Redhat BRMS suite. The .NET client (UI and desktop based applications) will be consulting the Java Rule engine and sending/receiving the JSON data. The decision which has been taken is to expose the Rules engine (Redhat BRMS 6.0.0 using Drools) as a REST based API. I have come-up with the following design approaches:
Write a REST controller in Spring framework and service classes for calling BRMS.
Write a simple REST controller using JBOSS proprietary RESTSY or JAXRS.
Write a Camel adapter and wrap the REST calls behind the Camel and let the Camel talk to Drools.
Wrap REST behind SOAP based webservices.
I want to ask which one would be the better approach for designing such as System.
Any other thoughts are welcome.
As might be obvious from https://github.com/gratiartis/sctrcd-payment-validation-web and https://github.com/gratiartis/qzr my general preference is for exposing my Drools business rules using REST APIs in a Spring application.
The only alternative I consider in the above list is 4, where the API is exposed through a SOAP web service. Albeit definitely not wrapping a JSON REST service! A well-designed Spring application can expose functionality through both REST and SOAP APIs with very little effort.
I have usually exposed via SOAP when working with .NET clients. Firstly, the .NET tooling has excellent support for generating proxies based on WSDL that you have defined. Secondly, the WSDL forms a well-defined contract which both you and the client developers must obey. Having a strict contract can be very useful in preventing arguments. Although if your interface is simple, it may not be so much of a benefit.
The other key reason is that the WSDL does not change unless you change it deliberately. A REST JSON API may seem quick to develop, thanks to Jackson generating everything for you. However, it can expose your internal object model (and dependencies!), meaning that unless you are careful, what seems like a trivial change to an internal model can make private data visible and can break clients.
All that said, if you can keep the API reasonably simple and have a good relationship with the .NET devs (perhaps you're one of them), then going with the Spring REST API would be my recommendation. Feel free to steal code from the github repos if it can help you get started!
btw - If you were to consider Camel, it's worth noting that there is a Drools-Camel component which does quite a bit of the work for you.
In my view,
I would go with the option 1. This is the simplest and easiest approach.
Option 2 may be second choice.
Option 3 - Looks like if there are some routing rules you could choose. Again its could make it complex.
And definitely not option 4 to make it complicated with SOAP.
I'm about to start work on a large project that will involve providing a significant number of web services.
We'll be using the Java platform, so, of course, we'll be making heavy use of JUnit, Hudson, etc. (although I'm not sure that matters at all.)
We're looking for a set of best practices and/or tools for testing the web services. We'll have several goals in mind:
Obviously, we need to prove that the services behave correctly. This means issuing web service calls, receiving the responses (checking them for correctness), and then, probably issuing another web service call to ensure that the system is in the new state that we want it to be in post-original call (and, obviously, checking that response for correctness.)
We'll need to collect response times.
We must be able to execute the test cases automatically (jUnit style, but against a running system, not against individual code units.)
It would be incredibly cool if non-developers (technical business users) could "author" the test cases. They aren't XML experts (and will never be,) so expecting them to create the XML files is not realistic. But they are subject matter experts, so giving them a "form" to fill out that would generate the XML file is realistic. However; there will likely be far too many disparate services for us to custom-build each of these "forms."
Any thoughts, best practices, or lessons learned would be appreciated.
SOAPUI
This is the best open source tool for testing web services. You can create unit tests, it even has a form interface that will read the wsdl and create a form to invoke the services.
Fiddler
You will need to look at the request and responses on the wire. This is crucial since most toolkits don't make it easy to see what exactly is coming back and forth.
XMLSPY
This is a paid program, but it has very very clean interface. IT make it easy to debug the xml files and will let you invoke services. It reformat even malformed XML and is a lifesaver in many situations. If you can afford it GET IT!
We use SOAPUI to do the functional testing initially. However, SOAPUI is not good for regression and load testing.
Next step, we load the XML into JMeter.
It can drive load from multiple machines and we can easily stress our servers to the limits.
We are removing our XSL-> HTML solution annd replacing it with a Flex UI for our userbase. One of the concerns is that the BlazeDS (amf endpoint, so streaming or polling) won't be able to handle the load as well as the EJB -> XML -> XSLT -> HTML stack. My theory is that it should perform better, but I need a way to statistically prove this.
Are there any suggestions for a product and/or method for stress-testing BlazeDS? Adobe has a stress test framework for LCDS, but it says it is not compatible with BlazeDS. I think that it might be simple to test given that I am not planning on using it as a messeging solution right now, and simple want it as an endpoint for RemoteObject connections.
I would look at using JMeter to run some automated tests against the backend:
http://jmeter.apache.org/
You should be able to write a test against the backend which takes some Java objects and uses the API available in Blaze to encode them in AMF and set the result as the body of the HTTP request.
Rob de Boer has a good article on implementing such an approach here http://blog.jteam.nl/2009/07/14/performance-testing-a-flex-blazeds-application/
To expand upon Cliff's answer, there is now a JMeter plugin for handling AMF messages. It will deserialize the message to XML so that it can be edited. You can use variables to generate unique session ids that are inserted into each AMF sample.
http://github.com/steeltomato/jmeter-amf
Full disclosure: I am the project author.
Several frameworks come to mind:
jmeter
perf4j
TPTP.
, but I need a way to statistically prove this.
Hm, if you want really expressive statistics (e.g. besides average, max, min also standard deviation, or even 95% confidence interval or serial correlation), you'll have to take a close look at the tools, since most of them are weak on statistics.
Hopefully this list explaining the strength and weakness of several performance testing tools can help you.
My Company (UBIK-INGENIERIE) distributes a commercial Apache JMeter plugin to load test AMF based applications and by extension BlazeDS ones.
You can easily record, variabilize and replay Flex/AMF based application with standard knowledge of Apache JMeter.
See:
http://www.ubik-ingenierie.com/-Solutions-
http://www.ubik-ingenierie.com/blog/ubik-load-pack/
I'd like to write an applet (or a java Web start application) calling its server (servlet?) to invoke some methods and to send/retrieve data. What would be the best way/technology to send and to retrieve those message ?
Protocol:
If you don't care about interoperability with other languages, I'd go with RMI over HTTP. It has support right from the JRE, quite easy to setup and very easy to use once you have the framework.
For applicative logic, I'd use either:
The command pattern, passing objects that, when invoked, invoke methods on the server. This is good for small projects, but tends to over complicate as time goes by and more commands are added. Also, it require the client to be coupled to server logic.
Request by name + DTO approach. This has the benefit of disassociating server logic from the client all together, leaving the server side free to change as needed. The overhead of building a supporting framework is a bit greater than the first option, but the separation of client from server is, in my opinion, worth the effort.
Implementation:
If you have not yet started, or you have and using Spring, then Spring remoting is a great tool. It works from everywhere (including applets) even if you don't use the IOC container.
If you do not want to use Spring, the basic RMI is quite easy to use as well and has an abundance of examples over the web.
HTTP requests? Parameters in, xml out.
XML is still my preferred choice for data interchange.
Using XML with something like xstream that removes much of the hassle of XML Java libraries. You can serialize and deserialize objects in a very simple way.
A lightweight solution could be Hessian too.
A simple example is here.
If you need an ORM for that case: try Cayenne.