Если вкратце, то суть ее в том, что клиент открывает долгоживущее HTTP-соединение, которое хранится на сервере до того момента, пока сервер не будет готов отослать ответ обратно. Посылка ответа инициируется сервером (поэтому это и называется AJAX наоборот). Такой подход позволяет избавиться от многократного опроса сервера множеством клиентов с целью получить как можно более свежую информацию. Например, такой сценарий имеет место в онлайн аукционах, разного рода службах информирования об изменении курса акций, чатах и т.д. Суть в том, что момент обновления информации неизвестен, но все хотят получить ее как можно быстрее после опубликования, поэтому начинают бомбить сервер запросами с большой частотой в надежде не пропустить обновление информации на сервисе. Как это влияет на производительность, думаю рассказывать не надо – имеем вполне себе DoS-атаку. Reverse AJAX избавляет нас от необходимости все время опрашивать сервер – соединение открывается один раз, и потом сервер сам отошлет ответ, когда будет что отсылать. Естесственно, когда с сервера придет ответ, нужно установить соединение заново.

Обзоры этого уже есть в интернете, их можно почитать тут, тут и тут. Теории хватает, но я так и не смог найти ни одного работаюшего примера. Куски кода конечно встречались, но увы, я так и не нашел, где можно скачать и посмотреть работающий пример. Итак, исправляем ситуацию и пишем простейший онлайн-чат с использованием Asynchronous Servlets.

Класс сообщения:

public class Message {

	public final String message;
	public final String username;

	public Message(final String message, final String username) {
		this.message = message;
		this.username = username;
	}
}

Сам сервлет:

@WebServlet(name = "chatServlet", urlPatterns = { "/chat" }, asyncSupported = true)
public class ChatServlet extends HttpServlet {

	@Override
	protected void doGet(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException {
		AsyncContext aCtx = req.startAsync(req, resp);
		aCtx.setTimeout(1000*60*5L); //5 min timeout
		ServletContext servletContext = req.getServletContext();
		((Queue<AsyncContext>)servletContext.getAttribute("chatUsers")).add(aCtx);
	}

	@Override
	protected void doPost(final HttpServletRequest req, final HttpServletResponse resp) throws ServletException, IOException {
		AsyncContext aCtx = req.startAsync(req, resp);
		ServletContext servletContext = req.getServletContext();
		String message = req.getParameter("message");
		String username = req.getParameter("username");
		Queue<Message> msgQueue = (Queue<Message>) servletContext.getAttribute("messages");
		msgQueue.add(new Message(message, username));
		aCtx.complete();
	}

}

Hаша служба асинхронных сообщений, которая будет проверять, не пришло ли чего нового и отсылать пришедшее сообщение зарегистрированным адресатам:

@WebListener
public class ChatService implements ServletContextListener {

	@Override
	public void contextDestroyed(final ServletContextEvent sce) {

	}

	@Override
	public void contextInitialized(final ServletContextEvent sce) {

		Thread t = new Thread(new Runnable() {
			@Override
			public void run() {
				final Queue<AsyncContext> chatUsers = new ConcurrentLinkedQueue<AsyncContext>();
				sce.getServletContext().setAttribute("chatUsers", chatUsers);

				Queue<Message> messages = new ConcurrentLinkedQueue<Message>();

				sce.getServletContext().setAttribute("messages", messages);

				Executor messageExecutor = Executors.newCachedThreadPool();
				final Executor chatExecutor = Executors.newCachedThreadPool();

				while (true) {
					if (!messages.isEmpty()) {
						final Message message = messages.poll();
						messageExecutor.execute(new Runnable() {
							@Override
							public void run() {
								while(!chatUsers.isEmpty()) {
									final AsyncContext aCtx = chatUsers.poll();
									chatExecutor.execute(new Runnable() {
										@Override
										public void run() {
											try {
												ServletResponse response = aCtx.getResponse();
												response.setContentType("text/xml");
												response.getWriter().write(messageAsXml(message));
												aCtx.complete();
											} catch (IOException e) {
												e.printStackTrace();
											}
										}

										private String messageAsXml(final Message message) {
											StringBuffer sb = new StringBuffer();
											sb.append("<message>")
											.append("<username>")
											.append(message.username)
											.append("</username>")
											.append("<text>")
											.append(message.message)
											.append("</text>")
											.append("</message>");
											return sb.toString();
										}
									});
								}
							}
						});
					}
				}
			}
		});

		t.start();
	}
}

Ну и страничка чата собственно. Используется JQuery. Как видно, никакой разницы с точки зрения JQuery между Reverse AJAX и просто АJAX нет:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Servlet 3.0 example</title>
<script src="js/jquery-1.5.1.js"></script>
</head>
<body>
<script>
	$(document).ready(function(){
		function getData() {
			$.ajax({
				  url: "chat",
				  type: "GET",
				  dataType: "xml",
				  context: document.body,
				  success: function(data){
					var username = $(data).find('username').text();
					var text = $(data).find('text').text();
					var history = $('#chat_msgs').text();
				    $('#chat_msgs').html(history + username + ": " + text + "\n");
				    getData();
				  }
			});
		}
		$("#sendMsg").click(function(event){
		     $.post("chat", $("#msgForm").serialize());
		     $('#message').val('');
		});

		getData();
	});
</script>
<h3>Asynchronous Servlet 3.0 Based Reverse Ajax Chat</h3>
<textarea cols="60" rows="5" id="chat_msgs" name="chat_msgs"></textarea>
<br/>
<form id="msgForm" name="msgForm">
	Username: <input type="text" id="username" name="username" value="" />
	Message: <input type="text" id="message" name="message" value="" />
</form>
<br/>
<input type="submit" id="sendMsg" name="sendMsg" value="Send message" />
</body>
</html>

Вот так это выглядит в действии:

Сразу хочу сказать, что это минимально возможный рабочий вариант. Здесь нет много чего важного, например, обработки ответа сервера по истечении таймаута, обработки ошибок и т.д. Но всё это можно прочитать в специфииации Servlets 3.0. Архив с кодом можно скачать здесь. Проект распаковать, импортировать в Eclipse, деплоить на Tomcat 7.0. Проверено в Opera 11, FF4, Chrome 10, работает без нареканий. IE как всегда на высоте – завис намертво. Если после прочтения статей по теории в интернете не совсем понятно, что и зачем тут нужно, пишите в коменты, будем обсуждать.

Effective Testing

In this blog post I’m going to talk about testing, or more precisely, what makes testing effective. Probably every developer nowadays knows that certain test coverage is required, but not everybody has a clear understanding how to make these tests really effective and helpful.
If one is asked what are tests for, the answer usually is: “They verify that my code works”. This is true but is not everything about it. This mentality usually drives people to write their tests after the actual code is complete just to make sure that it can run and does something. This is better than nothing but still not as good as it could be. There’re several reasons for that.
First, if a developer writes the test after writing the code, he/she has never had the chance to see the test fail and then subsequently pass (once the code is written). Never seeing a test fail may mean that it is just working by coincidence. The developer sees the green bar and assumes everything is good, but that green bar is actually masking a bug.
Second, it’s not a rare case that the written code is not testable. That is, it can have lots of dependencies that make it very hard to write a good test case for it, so if somebody wants to test it, he/she will have to spend quite an amount of time breaking these dependencies (but quite often people just give up on that and live with the code being completely untested).
Third, this approach leads to a trouble when a code base grows over a certain size. Developers can easily forget to update some test cases or fix the failing tests in an inappropriate way just to make them pass. This makes a test codebase rot which is a huge problem. After a while the amount of effort that one has to spend to keep a rotten test code base in sync with the actual system will be more then he/she has to spend on the actual code changes and after a while it can slow down the whole process so much that a team will have to abandon their tests completely. This means that they are in big trouble. Now they can’t be sure that their changes do not break anything, so no refactoring can be done and they have to do manual regression testing after each change.
Last but not least – by writing tests after the code you usually test just methods but not behaviour. This is not effective because tests should focus on a valuable behaviour that the class under tests provides. So one needs to test the features of the code to make sure that it works as expected and can be used efficiently in collaboration with its clients instead of just covering all methods with tests one by one – quite often you need to call several methods of your class in a row to collaborate with other objects.
On the other hand, if you write tests first by following the TDD principles you get a whole bunch of benefits: first, you give up on treating your tests just as something that verifies your code. Your tests become a runnable specification that describes what your code does and not how it does it. That is, you start thinking in terms of features and this helps us to maintain a necessary level of abstraction.
Test first also makes the test readable and maintainable – you think about a certain scenario and this allows you to keep your test clean from unnecessary details. Writing tests first also enforces you to think about the dependencies. Because you have to pass all the dependencies to the object under test you will get a clear indicator as you are coding that your design is bad. Another indicator is if your test becomes too large and complicated – this points you to the fact that the class under test is doing too much and has too many responsibilities and you probably need to decompose it.
So what should you do to make your test code base effective and helpful besides writing your tests first? There’re several best practices and pieces of advice that can be used. This is not the complete list of course, but it will show you the way to go.
The key factor that makes your tests effective is their readability. If the test is easy to read it is easy to maintain it. This means that you should apply the same code standards to your test code as you apply for production code. You should not treat the test as something that can be written in a mess. Follow the common clean code rules: no magic numbers, good and explanatory variable naming, no nested if-s, etc. Please refer to [1] as a great guide how to write clean and readable code. If you do not follow these standards, it’s just a matter of time until the test codebase starts to rot.
Test methods should be small, ideally 10-15 lines and contain just a few asserts (ideally one). It should be very clear what the test does and what atomic scenario is being executed. If your test is long and has lots of assertions inside you will have to spend a lot of time just figuring out what it actually does. Also, the test method should have a very clear and descriptive name that states what feature is being tested:
public void testCheckout1() // NO
public void testCheckoutWithOneCartItemAndDiscountAppliedGivesFreeShipping() //YES
Don’t be afraid of long method names – you are not going to call these methods anywhere, but you will be able to understand what kind of scenario is being tested at a glance.
Do not duplicate creation of test objects inside your tests – use test object builders that will help you easily create and maintain families of such object instead [2, 3]. By using the builders you will greatly increase readability and remove duplication from your tests. An example can look like following:

List movies = Arrays.asList(
MovieBuilder.movie().withTitle("Blade Runner")       // <- here's the builder being used
.withAddedActor("Harrison Ford")
.withAddedActor("Rutger Hauer")
.build(),
MovieBuilder.movie().withTitle("Star Wars")          // <- ... and also here
.withAddedActor("Carrie Fisher")
.withAddedActor("Harrison Ford")
.build());

There’s an Eclipse plugin called “Fluent Builders” that allows you to generate these builders automatically from any class you wish and saves your time greatly [4].

All of your test should have the same canonical structure:
1) Setup (prepare context and environment);
2) Execution (trigger the tested behaviour);
3) Verification (check that results are what we expect);
4) Teardown (clean up everything that can influence other tests and release all resources)
This means that all the tests should be completely independent from each other. This is very important, because if you have chained tests and the first test in the chain fails – all other tests will also fail. This is really bad because your test code base becomes very brittle and uninformative – you don’t know if tests are failing because of chaining or because of incorrect behaviour of the code that’s under test. So make your tests completely decoupled and independent.
Do not load data from hardcoded location in the file system, this will ensure that your test suite can be run in different environments under different operation systems and this will increase the maintainability of the test suite.

/home/ynovikov/workspace/project/src/test/resources/config.properties //NO. Absolute path is used
../test/resources/config.properties //YES. Relative path is used

Always use explanatory assertion messages, so that you can easily understand the reason of failure.
assertEquals(“Price discount hasn’t been applied”, expectedPrice, actualPrice);
Assertions should be precise – assert only those results that are triggered by test scenario and are not covered by other tests. This will make your test bas more robust.
Try to use mocks only for something that you can’t change, don’t use them as stubs. There’s a good article by M. Fowler about that [5].
Make sure that the code under test satisfies SOLID principles [6]. If you do that together with writing your test first, you are very likely to get the code that is easier to test, change and maintain.
Very important: your tests (not only unit, but acceptance and integration tests as well) should be fully automated so that you can make running your test as a part of continuous integration process. This will ensure that your build is always in a good and working state.
One more thing to remember – effective unit tests should be fast. This will allow you to execute them very often, may be after every single change you make to the code. This will provide you fast feedback if your changes broke something so that you can very quickly locate and fix the newly introduced bug.
If you start developing a user story, write acceptance test(s) first and don’t forget to follow TDD when you start implementing the feature itself. Each acceptance test suite should include a happy path scenario (when everything works as expected) and tests for cases when something goes wrong or for alternative behaviour.
Write integration tests to ensure that your code works correctly with some third-party libraries or services that you can’t change. All integration points with such things like payment gateways, geoip providers, persistent mechanisms etc. should be covered by integration tests.
If you’ve just started a project from scratch, the first thing you should do is to build a “walking skeleton” – the minimal possible configuration of your product that can be built, deployed and tested in a continuous integration environment against all kind of tests (unit, acceptance, integration). For example, if you develop a web application, it can just show you a page that reads a couple of records from database and displays them (and you create all kinds of tests for this functionality). This will ensure that your test environment and test frameworks are up and running, so that you can be sure that they are working correctly and ready for serious work.
I hope this article has been helpful, but don’t forget to check out the books and links in the list below. I have found them extremely useful and I hope you do too.
Bibliography and references:
1. “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin;
2. “Growing Object-Oriented Software, Guided by Tests” by Steve Freeman, Nat Pryce;
3. http://www.betriebsraum.de/blog/2010/02/08/better-tests-with-test-data-builders/;
4. http://code.google.com/p/fluent-builders-generator-eclipse-plugin/;
5. http://martinfowler.com/articles/mocksArentStubs.html;
6. http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

Кстати, тут можно увидеть и замыкание – функция doCalc обращается к переменной enabled, которая не является ее аргументом, но находится в контексте выполнения. Можно попробовать запустить нашу функцию:

scala> doCalc(5+5)
10

Если установить enabled в false, то ничего на печать не выведется:

scala> enabled = false
enabled: Boolean = false

scala> doCalc(5+5)

Ничего на консоль не выведется, как и было задумано. Вроде бы, наш скрипт делает то, что мы от него хотим – если разрешено, печатает, если запрещено – нет. Однако, это не совсем так, в чем легко убедиться, запустив нашу функцию например так (не забыв при этом проверить, что enabled установлен в false):

scala> doCalc(5/0)
java.lang.ArithmeticException: / by zero
at .(:7)
at .()
at RequestResult$.(:3)
at RequestResult$.()
at RequestResult$result()
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAcce…

Как видим, значение передаваемой функции вычисляется уже при передаче ее как параметра, то есть происходит передача по значению вне зависимости от того, будем ли мы вообще обращаться к этой функции. Это нам не подходит, поскольку мы должны вычислять значение функции только тогда, когда происходит собственно обращение к этому параметру. Тут и поможет передача параметров по имени. Модифицируем нашу функцию следующим образом:

def doCalc2(predicate: => Int) = if (enabled) println(predicate)

и выполним предыдущий вызов:

scala> doCalc2(5/0)

В этот раз значение функции не вычислится, потому что к параметру не обращались. Если установить enabled = true и запустить повторно, увидим знакомую картину – произошло обращение к параметру и вычислилось значение функции:

scala> doCalc2(5/0)
java.lang.ArithmeticException: / by zero
at .(:7)
at .()
at RequestResult$.(:3)
at RequestResult$.()
at RequestResult$result()
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAcce…

Таким образом можно реализовывать отложенные(lazy) вызовы. Подробнее можно почитать тут.

Итак, для начала работы сначала необходимо установить сам пакет. Я использовал версию 6.0. Немного старовата, но для демонстрации работы большего и не нужно. Коннектор J/Link скачиваем с сайта производителя. После этого в любой IDE создаем проект с простейшей структурой. Мой пример был создан в Eclipse, скачать его можно здесь. Далее я буду исходить из того, что проект вы скачали и посмотрели что там за структура, поэтому буду просто называть имена директорий. В classpath проекта входит папка lib, в которой лежит как J/Link коннектор (JLink.jar), так и нативный MathLink адаптер (JLinkNativeLibrary.dll). Его я туда скопировал из системных файлов Mathematica, чтобы лишний раз не указывать его путь – при загрузке по JNI он будет найден автоматически, т.к. находится в classpath.  Сразу отмечу, что эта dll – для 32-bit Windows. Если в вашей операционке эта библиотека откажется подгружаться (например, в 64-bit Windows) – замените соответствующим ей dll из системных файлов Mathematica.  Запускается пример при помощи скрипта startup.bat, в котором указан classpath, заданы параметры загрузки адаптера MathLink (о них подробнее в справочнике Mathematica) и указан путь к ядру (MathKernel.exe). Проверьте, чтобы он был верным для вашей инсталляции пакета. На этом описание структуры проекта закончу и перейду к самому примеру.

package com.ynov.javamath;

import com.wolfram.jlink.KernelLink;
import com.wolfram.jlink.MathLinkException;
import com.wolfram.jlink.MathLinkFactory;

public class JavaMathHelloWorld {
	
	public static void main(String[] args) {
		KernelLink kernelLink = null;
	    
	    try {
			kernelLink = MathLinkFactory.createKernelLink(args);
		} catch (MathLinkException e) {
			System.out.println("Can't create link: " + e.getMessage());
			return;
		}

		try {
			kernelLink.discardAnswer();
			System.out.println(">>>>>>>>");
			double result;
			kernelLink.putFunction("EvaluatePacket", 1);
			kernelLink.putFunction("Times", 2);
			kernelLink.put(3);
			kernelLink.put(3);
			kernelLink.endPacket();
			kernelLink.waitForAnswer();
			result = kernelLink.getInteger();
			System.out.print("1) ");
			System.out.println("3 * 3 = " + result);
			
			kernelLink.newPacket();
			kernelLink.putFunction("EvaluatePacket", 1);
			kernelLink.putFunction("N", 2);
				kernelLink.putFunction("Sqrt", 1);
				kernelLink.put(3);
			kernelLink.put(20);	
			kernelLink.endPacket();
			kernelLink.waitForAnswer();
			result = kernelLink.getDouble();
			System.out.print("2) ");
			System.out.println("Sqrt(3) = " + result);
			System.out.println(">>>>>>>>");
		} catch (MathLinkException e) {
			System.out.println("MathLinkException: " + e.getMessage());
		} finally {
			kernelLink.close();
		}
	
	}

}

В 13 строке создается ссылка на экземпляр ядра Mathematica. Там происходит подгрузка MathLink коннектора (той самой dll, запускается ядро пакета и налаживается с ним взаимодействие). В 20 строке немного танцев с бубном – при старте ядро посылает нам сообщение, которое нам ни к чему, поэтому удаляем его из буфера вывода при помощи вызова соответствующей функции. Далее можно начинать непосредственно работу с ядром – отправлять ему для вычисления нужные нам выражения. Для этого необходимо иметь представление, как эти выражения строить как таковые, так что для тех, кто не в курсе – нужно почитать соответствующий раздел справки. Любое выражение в этом пакете может быть представлено в текстовом виде при помощи Core Language. Мы рассмотрим 2 примера с использованием простейших математических функций – умножение 3*3 (будет записано на языке пакета как Times[3,3]) и вычисление корня квадратного из 3 с требуемой точностью (N[Sqrt[3], 20]). Полное описание этих функций можно найти по ссылкам, приведенным выше в справочной документации. Есть три способа выполнить расчет и получить результат. В первом – ядру передается строка целиком и оно берет на себя ее анализ, построение выражения и результат вычисления отдается как строка. Во втором – результат вычисления отдается в соответствии с типом. А мы рассмотрим третий, наиболее сложный и полезный – построение выражения в виде дерева и возврат значения в соответствии с типом. Итак, в строке 23 мы вызываем функцию создания нового пакета вычислений:

kernelLink.putFunction("EvaluatePacket", 1);

Это выражение Core Language, инструкция ядру, что вложенные функции должны рассматриваться и вычисляться как один пакет. Первый аргумент – имя функции, второй – количество ее аргументов. Далее, как аргумент для EvaluatePacket, в строке 24, передаем собственно функцию, которую нужно вычислить:

kernelLink.putFunction("Times", 2);

А в строках 25 и 26 передаем аргументы этой функции – сомножители 3 и 3. После этого в строке 27 закрываем наш пакет заданий при помощи соответствующей функции. Так как это был первый пакет, создавать его явно не было необходимости, но вообще это делается при помощи соответствующей функции, как показано в строке 33. В строке 28 запускаем вычисление и ждем ответа, а после этого в строке 29 получаем результат вычислений. В следующих строках с 33 по 43 вычисление квадратного корня происходит по тому же принципу, только уровней вложенности выражения будет 2 (функция N принимает как аргумент функцию Sqrt),  а остальные принципы ровно те же самые. Ну и в строке 48 закрываем соединение с ядром. Кстати, ядро можно так же запустить в серверном режиме и обращаться к нему по сети – подробнее в документации. В общем, ничего сложного, но пользы может быть от такого интеграционного решения много. Спасибо за внимание

mvn archetype:generate
-DgroupId=<groupId>
-DartifactId=<artifactId>
-DarchetypeArtifactId=<archetypeId>

Or you can use more  simple wizard-style approach: just type mvn archetype:generate and Maven will ask you to provide all necessary information to create the project structure that will fit your requirements. You will have to make a choice of desired archetype from provided list so there’s no need to know the correct id – Maven will help you. I assume that you have Maven2 installed, it’s bin directory is added to system path. I prefer the second way because it’s much easier for me – there’s no need to remember the archetype ids. A complete list of artifacts can be found here.

[...]
else
«$_RUNJAVA» $JAVA_OPTS «$LOGGING_CONFIG» $CATALINA_OPTS \
-Djava.endorsed.dirs=»$JAVA_ENDORSED_DIRS» -classpath «$CLASSPATH» \
-Dcatalina.base=»$CATALINA_BASE» \
-Dcatalina.home=»$CATALINA_HOME» \
-Djava.io.tmpdir=»$CATALINA_TMPDIR» \
org.apache.catalina.startup.Bootstrap «$@» start \
#>> «$CATALINA_BASE»/logs/catalina.out 2>&1 &
[...]

И комментируем там последнюю строчку,  как показано выше.  После этого сохраняем изменения, запускаем сервер при помощи catalina.sh start – и готово: