Boblog

How do you tell a good code?

noreply@blogger.com (RobertT) — Mon, 16 Jan 2012 13:06:00 +0000

Agreed with Ayende:
"... most good code bases are actually fairly boring. That is pretty much the definition of a good codebase..."

Source.

Good luck!

Speed up rails3 rspec2

noreply@blogger.com (RobertT) — Sun, 15 Jan 2012 20:30:00 +0000

If you've eventually fell asleep while waiting for your test suits to run, here's a good description on how to speed it up.

PS One little nitpick: all of the spork commands should be executed in bundle exec context as long we use bundler insted of rubygems.

Good luck!

Calculate LOC with one line of code

noreply@blogger.com (RobertT) — Tue, 13 Sep 2011 07:32:00 +0000

Found a very useful tip on how to quickly estimate the size of a project with only one line of powershell script.
Navigate to the root directory of your project and in powershell type the following:
(dir -include *.cs,*.xaml -recurse | select-string .).Count

Thats it.
Good luck!

Execute Caliburn coroutine in action pipeline without UI trigger

noreply@blogger.com (RobertT) — Thu, 11 Aug 2011 18:12:00 +0000

Seems rather easy, isn't it?

Just put it into Presenter's Execute method and the did is done. Well, should it be like that I wouldn't wake up in the night and write this stuff!
Let's see what's there in Execute:

So, it just packs every single coroutine it has in SequentialResult and execute 'em. No filters pipeline used, no routedMessage. None of your neat filters applied to these coroutines.

You might ask what is the difference with executing coroutines as a result of some UI action, be it a routed event or a command. The answer is in the Caliburn.PresentationFramework.Actions namespace.
To be prrecise it is an Action Execute overloaded method that in simple case of SynchronousAction does the following:

namely calls preprocessor filters, delegates a call to method that might be returning coroutine, handles errors with rescue filters, calls postprocessor filters. That is a filter pipeline I am talking about.
Well, seems that Caliburn has everything I need. And all I have to do is just use it.

As header states there is no UI trigger, i.e. I want to execute a coroutine when nobody clicked a button, but rather on some external trigger. As an example, consider model update with call to any data storage during Presenter initialization stage.

Enter DegenerateMessage. This intellectual piece of code is a data container that is being handed to participants on courutine call pipeline in order to hint what was the original method name called.

Another intellectual piece of code is DegenerateMessageTrigger. It is so damn smart that it knows that in order to trigger an action it has to pass a message to message handler!

And yet another piece is a DegenerateMessageHandler. It really shouldn't be called that way as it performs really complicated things. Namely, it creates an ActionHost and when Process is called converts DegenerateMessage to an ActionMessage and put it into the standard Caliburn action pipeline.

If it seems like dancing on your head, then know that you are not alone. But wait, there is another part I forgot to mention. It is a simple interface IResultExecutor aimed to hide all that smart code under two methods accepting Expressions with lambdas calling methods that return coroutines.

Oh, and there is yet another thing. With Caliburn Micro you can accomplish the same with only one line of code.

Cheers!

The best explanation to ESB ever.

noreply@blogger.com (RobertT) — Thu, 04 Aug 2011 06:56:00 +0000

I've finally managed to reread some of old Udi's articles and suddenly realized that following few lines are the best explanation of what ESB is all about, ever.

I never want to miss it again that is why I repost it right here in my blog.

"it’s all in the message. Forget about remote method invocations and pub-subbing events—down on the wire it’s all just messages. The trick is to think of your system as passing messages at the application level as well.

Asynchronous message passing over queues. It’s really quite simple.
Once you’ve packaged everything into the message, that message can be dynamically routed anywhere, and so can its responses. The application doesn’t need to bind against any specific endpoint—it just drops a message addressed to some logical location. Infrastructure can make sure that messages get to the logical recipient, even if they change physical locations.

That infrastructure is what brings about the “Bus” architectural style between your distributed components."

As Udi says, you have to reread it several dozens of times, until it strikes to you.

Good luck!

Git ftp deploy

noreply@blogger.com (RobertT) — Tue, 19 Jul 2011 20:50:00 +0000

With tools like git, NServiceBus, RoR and the rest, life seams to be better then ever.

With git I've managed to setup deployment with a matter of minutes. Just like this: http://blog.wekeroad.com/2009/11/23/deploying-a-web-application-with-git-and-ftp

There are other ways, probably even simplier: http://ayende.com/blog/4836/primitive-git-auto-deploy

Good luck!

Django newby frustrations.

noreply@blogger.com (RobertT) — Sun, 05 Jun 2011 19:12:00 +0000

As you might already guessed, I am currently in a process of discovering two technologies I had no experience with before.

This time I met a strange error running a Django tutorial web application: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0...

The simplest solution to this can be found here: http://victor-k-development.blogspot.com/2010/07/unicodedecodeerror-django.html

But the roots of the problem and an ultimate solution are to be found here: http://stackoverflow.com/questions/4237898/unicodedecodeerror-ascii-codec-cant-decode-byte-0xe0-in-position-0-ordinal

Good luck!

RoR newby frustrations

noreply@blogger.com (RobertT) — Sun, 05 Jun 2011 12:51:00 +0000

As usual, trying to adopt something new is really is a frustration. And though Rails is about to be "a breakthrough in lowering the barriers of entry to programming" you will defenitely meet some errors that might stop you on your way.

First thing I met was: "[rake --tasks] rake aborted! no such file to load -- sqlite3/sqlite3_native".

The solution is really simple. Rake is telling you that it can't find a native library for sqlite. Well, just do what you've been told. Give it a sqlite.dll/.so (depends on OS you are). Put it in $ruby_home\bin.

Next thing to immedeately pop up, after I gave it what it wanted was: "[rake --tasks] WARNING: Global access to Rake DSL methods is deprecated." This one is not as obvious as former. Solution to this one is desribed here: http://benwoodall.com/2011/06/rails-global-access-to-rake-dsl-methods-is-deprecated/

That's it for now.

Good luck!

Installing rails on windows

noreply@blogger.com (RobertT) — Wed, 01 Jun 2011 16:23:00 +0000

If you tried to install rails with gems and failed with message "...No such file or directory" - dont woly be hapy. Just folllow these instructions: http://stackoverflow.com/questions/849660/how-to-stop-the-gem-utility-from-accessing-my-home-directory

Good luck!

JetBrains dotPeek to rescue.

noreply@blogger.com (RobertT) — Tue, 24 May 2011 13:31:00 +0000

I don't know how you faced the fact that Reflector is no longer free, but I for one was very-very dissapointed. Now, our favorite JetBrains team comes to rescue with their brand new tool called dotPeek.

Go and get it here.

PS. Five minutes later I found another tool that will compete to take Reflector's place - JustDecompile from Telerik. It is here.

PPS. Also, there is a work being done for Silverlight by Denis Vuyka and there is another OSS tool to compete for our souls - ILSpy.

PPPS. Life is good again.

Good luck.

NServiceBus Saga Idempotency

noreply@blogger.com (RobertT) — Mon, 16 May 2011 08:15:00 +0000

Should your business entities had a natural identifier (I think even a surrogate one would do in this case), it would be trivial to ensure idempotency of sagas, that drive their processing.

Just store that Id in a temporal saga storage and enqueue a handler that will guard your sagas as the first handler in NServiceBus endpoint pipe. Something like this one:

And don't forget to specify message handling order:

Good luck!

Applying monadic combinators to build simple parser

noreply@blogger.com (RobertT) — Mon, 11 Oct 2010 07:58:00 +0000

After reading this article, it dawned on me, how easy it might be to write parsers using internal dsl syntax. Looks a bit clumsy in C#, yet rather expressive.

I've used wonderful Magnum library built by Dru Sellers and Chris (creators of open source service bus MassTransit project) as a foundation, since it already contains a base for monadic parsers.

As an example, look how easy it is to write a parser for following simple grammar, describing file version structure:

<version> ::= <part>{<delim><part>|<part>}
<part> ::= <positive integer>+ | <letter>+
<delim> ::= “.” | “,” | “(” | “)” | “ “

And parser in mere 10 lines of code:

Good luck!

Dependency injection Presentation

noreply@blogger.com (RobertT) — Wed, 29 Sep 2010 07:20:00 +0000

На слайдах ниже вы найдете презентацию, которую недавно я провел для своих коллег. Цель ее - завлечь в свою религию, шутка, продемонстрировать наглядно преимущества применения DI вживую. Для оживления презентации, используйте код, выложенный здесь.

Dependency injection

P.S. В английской версии блога, я немного порассуждал на тему того, какие "умницы" и как я рад видеть их новые инструменты, но повторяться мне лень . =)

Удачи!

My two cents in OSS. Free VOIP .Net library!

noreply@blogger.com (RobertT) — Sun, 29 Aug 2010 16:52:00 +0000

Мои поздравления всем! Только что в сфере .Net стало одной бесплатной VoIP библиотекой больше. Эта библиотека - моя обертка над C-библиотекой pjsip, точнее над ее высокоуровнем API pjsua (user agent).

Работа над ней еще продолжается, но код используется в проектах компании DoxWox, которой выражается отдельное спасибо за возможность опубликовать его. В частности, эта библиотека используется для реализации голосовых конференций в приложении для online общения.

Прошу любить и жаловать: http://code.google.com/p/pjsip4net/

Введение можно почитать здесь:
http://bobbbloggg.blogspot.com/2009/04/designing-managed-api-over-flat-native.html

Частично я уже описывал решения, которыми я руководствовался при создании этой библиотеки, но я планирую более подробно описать здесь внутренности библиотеки, одновременно проводя ее рефакторинг (я, кажется уже упоминал, что работа над ней продолжается ;). Ниже можно почитать о некоторых решениях, примененных в коде:
http://bobbbloggg.blogspot.com/2009/10/detached-template-method-pattern.html
http://bobbbloggg.blogspot.com/2009/09/fluent-builder.html
http://bobbbloggg.blogspot.com/2009/03/initializable-pattern.html

Удачи!

Windsor Castle BuildUp

noreply@blogger.com (RobertT) — Mon, 09 Aug 2010 09:59:00 +0000

Некоторое время назад я обнаружил, что в лучшем DI-контейнере в .Net сфере Windsor Castle (это мое мнение не подтвержденное никакими фактами, кроме моих высказываний) нет такой простой функциональности как BuildUp. Некоторые из существующих DI-контейнеров, имеют такой метод, а Castle нет. Это неспроста. Я считаю, что BuildUp - это костыль для ситуаций, имеющих более элегантное решение, но бывают случаи, когда он оправдывает себя. Например, когда скорость решения проблемы важна. Под более элегантным решением я понимаю интеграцию с DI-framework, как, например, Castle WCF facility, но понимаете сами, сколько времени и ресурсов нужно для создания полноценного решения.

Должен признаться, что решение оказалось настолько простым, что я в недоумении, почему раньше этого никто не сделал. Хотя чего там, уже написано выше - костыль. Никто не признается просто.

Итак, прежде всего нужно ознакомиться с возможностями расширения Castle. Лазейка для BuildUp - это ComponentActivator. Активаторы вызываются при необходимости создать объект LifetimeManager'ами. Отсюда ограничение решения - с SingletonLifetimeManager оно работать не будет, но и не должно, если подумать. Устанавливая время жизни Singleton вы таким образом явно декларируете, что объектом (коего будет только один экземпляр) владеет контейнер, и создает его он же. А потому BuildUp для такого объекта - вещь бессмысленная.

BuildUpComponentActivator наследуется от DefaultComponentActivator и переопределяет только один метод - Instantiate. В этом методе мы извлекаем уже существующий и созданный вне контейнера экземпляр из контекста. Если в контексте его нет, то мы делегируем работу по созданию объекта базовому классу.

В контекст он помещается в методе расширении контейнера BuildUp как дополнительный параметр в IDictionary:

Для того, чтобы объект мог быть пропущен через BuildUp, в компонентной модели для него следует установить ComponentActivator. CanBeBuiltUp оборачивает такой вызов для castle Fluent registration API.

Я говорил, что решение удивительно простое? Это результат работы коллектива очень талантливых людей, к коим я не принадлежу, если чо. =)

Удачи!

Trigger Caliburn action status update through Prism's IEventAggregator

noreply@blogger.com (RobertT) — Thu, 24 Jun 2010 07:00:00 +0000

И Caliburn и Prism, в принципе решают одни и те же задачи - создание композитных приложений на WPF. Но, вот Роб Эйзенберг (создатель Caliburn) не считает, что они друг друга взаимоисключают, а я и подавно с ним согласен.
Я использую следующие "фичи" Prism'a:

modularity;
region manager;
event aggregator;

, а из Caliburn следующие:

actions engine;
application & model framework, даже не смотря на то, что с первого взгляда model framework кажется "overarchitected";
convention over configuration;

Вот сейчас я вам расскажу как расширить actions в Caliburn, при помощи Event Aggregator из Prism.
Главный способ расширения - это написание фильтров, которые вставляются в последовательность выполнения action. С их помощью можно проверять предусловия или состояние данных (к примеру можно проверить обладает ли Principal достаточными правами для выполнения действия), дабы определить статус action и обновить эффекты, применяющиеся к UI элементам. Примером такого фильтра является поставляющийся с framework фильтр Dependencies, который вызывает исполнение всей последовательности фильтров, на основании изменения какого-либо свойства, имя которого передается в качестве параметра ему. Но что, если вам нужно просто обновлять статус action, не связанный ни с каким полем в объекте, на основании какого-либо события/условия. Вы можете завести специальное поле и передергивать его значение или даже еще лучше - не заводите никакого поля, а просто кидайте нотификацию с именем несуществующего поля, переданного фильтру. Не знаю как вам, а у меня от таких решений зудит в одном месте.

Так вот зуд мой унялся только когда я написал фильтр, запускающий всю цепочку обработки статуса события по получению уведомления от EventAggregator сервиса Prism.

DependsOnEvent

Фильтр применяется как атрибут, которому передается тип события. Тут есть одно ограничение - событие должно быть унаследовано от generic типа CompositePresentationEvent закрытого типом object, т.е. CompositePresentationEvent_Of_Object. В методе Initialize происходит магия с помощью reflection. Дело в том, что IEventAggregator Prism имеет исключительно generic интерфейс, за что можно разработчиков его только поругать. Мы получаем событие переданного типа и подписываемся на него. Вот именно для этого и приходится колдовать с волшебным зеркальцем, т.к. заранее тип события не известен. Часть, относящуюся к запуску обработки action, я содрал из кода упомянутого выше Dependencies фильтра.

Здесь мы создаем Observer, который будет следить за изменениями зависимых свойств. Т.к. реально никакие свойства не меняются я просто использую трюк с несуществующим свойством - в Initialize при подписке на событие я передаю делегат, который кидает событие обновления свойства Update, которого-то как раз и нет. Observer, поймав это событие запускает всю цепочку обновления статуса action.

PublishEventAfter
Ну и напоследок, фильтр, выполняющий все ровно наоборот, после выполнения action он кидает событие, которое обрабатывает EventAggregator.

Удачи!

Plant your Redis into Windows.

noreply@blogger.com (RobertT) — Fri, 07 May 2010 07:57:00 +0000

Redis - это OSC проект, представляющий собой высокопроизводительное key-value хранилище данных. Это вполне зрелый проект, используемый в реальных проектах в production. Написан он на Си, и основные целевые платформы - Linux, *BSD, Mac OS X, Solaris. Казалось бы такой хороший и такой недоступный (для Windows)? Ан нет, мало того что ServiceStack собрали и распространяют дистрибутив под Windows (работает через cygwin), так они еще и клиентскую .Net библиотеку написали! Но опять есть одно но - сервер работает в виде консольного приложения, что не очень-то подходит для сервера баз данных. Нужно захостить его в Win32 сервисе, но как?

Очень просто:

Берем OSC проект TopShelf - легкий framework для создания Win32 сервисов, берущий все сложности на себя, и пишем хост-сервис, который будет запускать и останавливать наш сервер.

Посмотрите, win32 сервис буквально в 10 строк кода.

Но, а как же насчет консольного окна? А просто - обратите внимание на аргумент передаваемый процессу сервера Redis (redis.conf). Это имя конфигурационного файла. В нем можно изменять любые настройки сервера. В частности там есть пункт daemonize, который на Linux запускает сервер в виде демона, на Windows же запуск с этим параметром приводит к созданию процесса без окна. И еще одно - x.RunAsLocalSystem();

Вот и все. Теперь запускаем собранный проект из командной строки с аргументами: {project.exe} service install, - и смотрим как все по волшебству происходит само. Теперь это полноценный Win32 сервис, можно запускать.

Удачи!

ORM-style IdentityGenerator or impossible is nothing

noreply@blogger.com (RobertT) — Fri, 25 Dec 2009 10:07:00 +0000

То, что я сейчас собираюсь описать, иначе как грязный хак назвать нельзя. Но жизнь сложная штука, и иногда приходится изворачиваться как уж, чтобы добиться своего. А добиться я пытаюсь вот чего: чтобы NHibernate не ломал семантику Unit of Work при работе с классами, Id которых генерится Identity счетчиком в SQL Server.

Прежде всего, советую ознакомиться с историей вопроса: о вреде Identity генераторов, еще о вреде и мнение в законе. Проблема Identyity генератора в том, что он не может получить Id, не вставив запись в таблицу, а без Id сущность нельза ассоциировать с NHibernate сессией, поэтому как только мы пытаемся связать объект с сессией, он тут же попадает в базу. Отсюда вырастают огромные проблемы в длинных бизнес транзакциях, когда все действия с БД атомарны и выполняются в отдельных БД транзакциях, а сама бизнес операция растянута по времени. Так вот откат бизнес транзакции будет невозможен в случае использования Identity генератора. А это как раз мой случай. Но, как я уже написал выше решение есть, но это грязный хак.

Итак. Прекратив ныть, про хак, перехожу к сути. Мне надо:

вставлять свои значения в поля Identity;
получать адекватные значения для Identity поля;

В SQL Server можно отключить автоинкрементацию Identity поля и вставить свое значение, например, пропущенное в последовательности (при удалении). А получить его можно, вставив в таблицу запись и удалив ее. Это возможно, потому что при откате транзакции значение счетчика Identity назад не откатывается, таким образом, изменив таблицу, мы перекидываем счетчик, а затем откатив транзакцию, убираем изменения.

Вооружившись этим знанием я нарисовал следующую схему:

Решение, как следует из картинки состоит из 3х частей:

Custom Id generator, который я назвал ORMIdentityGenerator;
PreInsert listener, для отключения автоинкрементного поля;
PostInsert listener, для его включения назад;

ORMIdentityGenerator

Следуя agile принципу KISS - keep it simple, stupid! я всего лишь конфигурирую его минимальным INSERT выражением, которое можно исполнить, не повредив базу и не вызвав нарушений целостности.

PreInsert

PostInsert

Вот и все. Теперь я могу спокойно редактировать объект в длинной сессии и откатывать изменения, когда потребуется. PS Простите ребята, гаджетом для вставки кода пока не обзавелся. Удачи!

Detached Template Method pattern

noreply@blogger.com (RobertT) — Fri, 02 Oct 2009 16:47:00 +0000

Идея не нова, ее я встретил впервые в Spring framework, в части интеграции с ORM framework’ами. Так для упрощения написания своих Repository или DAO (Как назвать дело вкуса. Я предпочитаю термин Repository, т.к. с точки зрения DDD он более точно описывает свое назначение.) Spring предлагает 2 опции:

передать своему DAO XXXTemplate и пользоваться предоставляемыми им методами, инкапсулирующими последовательность работы с конкретным ORM;
Унаследоваться от XXXDaoSupport, в котором XXXTemplate будет подставлен без вашего участия IoC контейнером;

Так что же это такое? Давайте обратимся к классикам [GoF]:

«Template Method – паттерн поведения [классов]. Template Method определяет основу алгоритма и позволяет подклассам переопределить некоторые шаги алгоритма, не изменяя его структуру в целом.»

Почему Detached? Ну, вот так я придумал. Потому что это не предполагающая наследования реализация идеи Template Method в отдельном классе. Методы класса определяют последовательность действий, которые должны быть выполнены, скрывая детали реализации алгоритма и нижележащих ресурсов. Переопределение же некоторых шагов возможно при помощи callback’ов.

К примеру, под капотом у всех XXXTemplate в Spring происходит следующее (упрощенно):

выделение ресурсов (создание connection и т.д.); (фиксированная часть алгоритма)
начало транзакции; (фиксированная часть алгоритма)
вызов callback executeInTransaction; (изменяемая часть алгоритма)
возврат данных; (изменяемая часть алгоритма)
подтверждение/откат транзакции; (фиксированная часть алгоритма)
освобождение ресурсов; (фиксированная часть алгоритма)

Все эти шаги вам пришлось бы реализовывать самим в каждом месте, где предполагался бы код доступа к данным. Кроме того XXXTemplate скрывают детали реализации и отвязывают от лишних зависимостей. Например, HibernateTemplate конвертирует hibernate-специфичные exception’ы в Spring DataAccessException.

Я использовал этот прием для обхода ограничения языка C# - запрета множественного наследования. Представьте иерархию классов, в которой некоторые классы наследники базового класса должны обладать еще и дополнительными данными/поведением. А чтобы усложнить ситуацию, представьте, что в системе есть еще классы, не принадлежащие этой иерархии, но которые тоже должны обладать теми же данными/поведением. Интерфейс тут единственное возможное решение. Теперь более конкретно, чтобы обосновать применимость.

У меня есть базовый класс Resource, реализующий disposable pattern. Многие из его наследников – объекты системы, хранящие данные о состоянии системы и идентифицирующие конкретные экземпляры по Id.

Идентифицируемость объектов вынесена в интерфейс, т.к. в системе есть классы, которые должны уметь идентифицировать экземпляры и не наследуют Resource. Просто не нужна им такая функциональность, хотя могли бы. Но я предпочитаю, чтобы мои классы говорили сами за себя и не ввожу ненужных допущений, запутывающих модель.

Как видите, IIdentifiable наследует интерфейс IEquatable, т.е. объекты должны сами определять является ли переданным им экземпляр идентичным. И, наконец, тождественность объектов должна определяться не только на основании Id, но и на основании других полей данных. Чувствуете к чему это идет? Мне придется реализовывать логику сравнения по Id и по значимым полям в каждом классе, многократно дублируя код! Я такую личную неприязнь к дублированию чувствую, что аж кушать не могу.

Поэтому давайте разберемся а что же я должен сделать? Я должен реализовать алгоритм установления тождественности, который содержит фиксированную часть (сравнение ссылок

объектов, сравнение Id) и переменную часть (сравнение значимых данных, которые в каждом классе, вообще говоря, свои).

Потому в IIdentifiable я ввел метод DataEquals – это изменяемая часть алгоритма и, как мне кажется наименьшее из зол (но все-таки зло, потому что он публичный и засоряет интерфейс (один из способов уменьшения этого зла - explicit implementation)), а в каждом реализуемом методе Equals интерфейса IEquatable я делегирую выполнение алгоритма моей реализации Detached Template Metod – EqualsTemplate.

Я знаю, знаю, что в .Net есть IEqualityComparer, но мне мое решение нравится больше по 3м причинам:

мне не придется «заставлять» пользователей моих классов использовать IEqualityComparer;
мне кажется, что реализовать один метод проще, чем написать новый класс;
оно мое;

Посмотрите как просто реализуется теперь этот алгоритм:

Удачи!

Select object rather then string in JSF

noreply@blogger.com (RobertT) — Sun, 27 Sep 2009 18:37:00 +0000

Сначала хотел написать, что пост кардинально отличается от предыдущих, потому что про Java и связанные технологии, а потом подумал и понял, что основное-то предназначение блога - делиться опытом применения паттернов и методологий, а не описывать "фичи" языка, который всего лишь инструмент в данном случае. А потому начну так: Этот пост не сильно отличается от предыдущих, но он про Java и связанные технологии.

Все еще здесь? Тогда продолжим! (отлично, спер клише, молодец)

Проект, на котором я работал, своей целью ставил исследование возможностей платформы Java в разработке Web-решений для компании, давно занимающейся разработкой на .Net, следовательно, не имеющей такого опыта и таких специалистов. Так вот, нашей задачей было получение такого опыта и становление такими специалистами за максимально короткий срок – сэкономили, короче.

Проект – небольшой сайт с frontend на JSF 1.2, facelets, RichFaces и инфраструктурой с использованием Spring и Hibernate ORM.

Так вот заметка моя касается представления списков выбора в JSF, которая сделана, на мой взгляд, весьма коряво. Вкратце – сущности, из которых ведется выбор, вы должны представить в виде строк, завернув в класс SelectItem. Назад вместо объекта вы, естественно получите строку, а вовсе не объект, т.к. последний не путешествовал от сервера к клиенту и обратно. Так вот мое решение призвано обойти данную шероховатость JSF. Кстати сказать, я не один такой умный и решений этой задачи есть как минимум несколько: http://jsf-comp.sourceforge.net/components/easysi/index.html, http://balusc.blogspot.com/2007/09/objects-in-hselectonemenu.html, - но… Первое не работает с RichFaces, а второе я нашел уже после того как написал свое.

На решение натолкнула меня тоска. Ага, тоска по счастливым временам когда GUI я «творил» на WPF. Я тогда сильно упростил себе жизнь, написав SelectorCollectionPresenter. И я подумал –почему бы не использовать похожий подход в Java? Сказано – сделано. Я написал класс CollectionPresenter =).

Основная идея – это объект, который хранит карту ассоциаций строковых представлений с объектами и текущую выбранную строку, по которой, собственно, из карты выбирается объект.

Для Generic коллекций в Java я использовал реализацию apache Generic common-collections

Теперь, имея возможность получить ссылку на объект, можно написать facelet,

который получает на вход список SelectItem’ов, которые создал Presenter, и возвращает выбранную строку, по которой Presenter вернет соответствующий объект.
В принципе этот процесс можно отдать на откуп facelet’у целиком:

И вот как выглядит использование первой версии facelet’а в разметке страницы:

Поверх presenter’а я навернул еще generic контроллер, который выбирает список объектов из Repository и подставляет их presenter’у.

Важно заметить, что работать будет с контроллером, с любым временем жизни (стратегией времени жизни в Spring контейнере).

Объекты, для выбора в моем случае – строки справочника, представляемые наследниками класса DictionaryEntry, что в общем случае необязательно, просто тогда надо будет написать соответствующий контроллер.

Вот и все решение, в общих чертах!

Удачи!

Fluent Builder

noreply@blogger.com (RobertT) — Thu, 03 Sep 2009 19:26:00 +0000

Fluent Interface и Builder - идеальное сочетание для декларативного создания объектов.
На самом деле примеры такого выгодного симбиоза давно у нас под носом, например: StringBuilder.

Я использовал такой симбиоз для декларативного создания SIP аккаунтов и звонков.

Решение состоит из внутренних Builder-классов, которые предоставляют декларативный интерфейс для создания объектов и скрывают детали типа суффиксов транспорта, схемы и пр., о которых не надо задумываться.

Оба этих класса опираются на вспомогательный Builder – SIPUriBuilder. Этот класс настолько интуитивен, что я удивлен, что я не написал его первым делом.

Результат на лицо:

Было:

string remote = "sip:";

remote += txbURI.Text == "00"

? "127.0.0.1"

: (txbURI.Text + "@" + SIPUserAgent.SIPUserAgent.Instance.AccountManager.DefaultAccount.RegistrarUri.Split(new[]{':'})[1]);

remote += SIPUserAgent.SIPUserAgent.Instance.SIPTransport is TCPTransport

? ":5061;transport=TCP"

: "";

SIPUserAgent.SIPUserAgent.Instance.CallManager.MakeCall(remote);

Стало:

Call c = Call.ConstructCall().SetAccount(acc).SetExtension(txbURI.Text).SetDomain(txbURID.Text).Call();

Было:

var acc = new Account(false);

using (acc.CreateInitializationSession())

{

acc.Credential = new NamePasswordCredential

{

Password = txbPass.Text,

Realm = txbRegistrar.Text,

UserName = txbLogin.Text

};

acc.AccountId = "sip:" + txbLogin.Text + "@" + txbRegistrar.Text;

acc.RegistrarUri = "sip:" + txbRegistrar.Text;

if (ua.SIPTransport is TCPTransport)

{

acc.AccountId += "5061;transport=TCP";

acc.RegistrarUri += "5061;transport=TCP";

}

}

ua.AccountManager.RegisterAccount(acc, true);

Стало:

var acc = Account.ConstructAccount().SetLogin(txbLogin.Text).SetPassword(txbPass.Text)
.SetRegistrarDomain(txbRegistrar.Text).Register();

Комментарии я думаю излишни. Просто сравните число строк.

Удачи!

Designing managed API over "flat" native one or .Net SIP library

noreply@blogger.com (RobertT) — Wed, 15 Apr 2009 07:28:00 +0000

Попробую описать процесс проекции плоского API, написанного в процедурном стиле, в многомерное ООП пространство, на примере работы, которой было занято почти все мое свободное время за последний месяц.

Возможно многим эта заметка покажется интересной не с точки зрения содержания, сколько с точки зрения результата работы, которым я готов поделиться со всеми, а именно - .Net обертка над замечательной SIP библиотекой pjsip, но для меня она ценна именно как описание процесса. Можно сказать мемуар.

Конечно обертка эта не покрывает все то богатство возможностей управления процессом, которое предоставляют различные модули pjsip, но предоставляет высокоуровневый .Net интерфейс к pjsua (user agent) API, необходимый для быстрого создания SIP клиентов.

P/Invoke или как не утонуть в тоннах кода;
Designing API;
Testing API;

1. P/Invoke.

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

реализующая последние RFC в наиболее полном объеме;
с поддержкой различных кодеков, в том числе широкополосных;
портируемая на разные платформы (на будущее);
с возможностью передачи видео-потока (на будущее);
open source с разумной лицензией, которая позволила бы использовать ее в коммерческих приложениях. (UPD3: GPL, под которой распространяется эта библиотека не такая уж и разумная, а, как сказал мой друг: "детище неадекватного проповедника Столмена". Следует заметить, что исходное выражение подверглось жесткой цензуре =). )

pjsip удовлетворяет всем этим условиям, и многим другим, неперечисленным здесь. Замечательная вобщем библиотека.

Итак, прежде всего нам надо скачать исходные коды и собрать dll. Скачать pjsip можно из SVN хранилища, как стабильную версию, так и текущий закоммиченый код.

Далее, забегая вперед, сразу же скажу, что при генерации interop-кода возникла проблема с callback функциями, т.к. C# поддерживает только stdcall callback функции (UPD: врешь ты все =) ), т.е. делегаты будут вызываться как stdcall, тогда как pjsip декларирует свои callback'и как cdecl, это проблема! Путей решения у нее несколько.
Если бы у нас не было доступа к исходному коду pjsip - у нас была бы проблема, которую пришлось бы решать нетривиальным образом, изменяя IL код, сгенерированный для interop кода. Этот хак описан здесь.
UPD: Да, и пока я искал ссылку, нашлось более простое решение, поставляемое самой платформой .Net - UnmanagedFunctionPointer атрибут, с помощью которого можно пометить делегат и обозначить calling convention.
Последнее же решение, к которому прибегнул я, - пометил все нужные мне callback функции в pjsua __stdcall, благо их немного.

Итак, dll, экспортирующую функции высокоуровневого pjsua API я собрал, но даже для этого интерфейса (довольно скромного по сравнению с более низкоуровневыми) я бы писал interop код вручную недели две. Столько времени у меня нет, да это еще к тому же ужасно скучно, поэтому я нашел средство автоматической генерации interop кода - PInvoke Assistant. Достаточно лишь указать этой замечательной утилите всю необходимую информацию, и вуаля - 90% кода сгенерились автоматически. Надо сказать, что 10% недостающего кода эта_замечательная_утилита все-таки не осилила, но винить ее в этом я не намерен, т.к. код был действительно очень сложный для автоматического разбора. Вобщем 10%, написанные вручную, все-таки лучше, чем 100%.

UPD2: нашел еще одну утилиту для генерации interop кода: SWIG. Выглядит она намного мощнее той, которую я использовал, достаточно посмотреть на список поддерживаемых языков.

На этой стадии у меня уже был готов рабочий .Net интерфейс к pjsip, но вот только одна беда - в процедурном стиле, что впрочем не помешало мне написать тестовое консольное приложение, которое регистрировалось на SIP сервере.

2. Designing API.
Дизайн ООП обертки во многом продиктован структурой pjsua API (больше половины работы уже сделано за нас). pjsua логически и очень интуитивно разделяется на следующие группы:

PJSUA-API Basic API Создание/инициализация, конфигурирование, логирование и пр.
PJSUA-API Signaling Transport Управление SIP транспортами;
PJSUA-API Accounts Management Управление аккаунтами;
PJSUA-API Calls Management Управление звонками;
PJSUA-API Buddy, Presence, and Instant Messaging Управление списками контактов, информацией о доступности и IM;
PJSUA-API Media Manipulation Манипуляция медиа-данными;

Также логически и интуитивно я выделил следующие сущности:

SIPUserAgent - центральная фигура и главная точка доступа к API, отвечающая за создание/конфигурирование клиента;
Account Manager - интерфейс для управления аккаунтами (аналог - телефонный номер);
Call Manager - интерфейс для управления звонками (прием/создание новых звонков, управление состоянием);
Media Manager - интерфейс для управления медиа-параметрами системы (кодеки, звуковые устройства, конференция);
Conference Bridge - жалкое отражение мощного медиа-микшера pjmedia;

Итак вот он взгляд на систему с высоты:

Поскольку большинство объектов являются обертками над нативными структурами, выделяющимися в неуправляемой памяти, то нам нужен механизм управления освобождением последних. Такой механизм в .Net изобретен давно и называется он Disposable pattern. Очень кстати полезно помнить про этот паттерн, так как он .Net specific, а про такие MS любит спрашивать на собеседовании. Фундамент для Disposable pattern - базовый класс Resource, с одной лишь разницей, что он не реализует IDisposable, т.к. я не хочу отдавать контроль над временем жизни всех объектов, потому что это может нарушить работу системы. Например: нельзя дать пользователю этого API освободить ресурсы VoIPTransport'а во время звонка, или даже пока в системе есть зарегистрированные аккаунты. Следить же за всеми зависимостями просто невозможно, и вообще это есть нарушение всех принципов хорошего дизайна. Поэтому в Resource вместо публичной реализации IDisposable есть internal метод InternalDispose. В случае, когда время жизни объекта может управляться извне, то класс наследник Resource явно реализует интерфейс IDisposable.

Одна из основ дизайна - инициализируемые объекты. В pjsip прежде чем что-то использовать, это что-то сначала надо сконфигурировать и проинициализировать. Причем некоторые объекты поддерживают повторную реинициализацию, а некоторые - нет. О проблемах и решениях инициализации объектов я писал в предыдущей заметке, как раз в то время, когда создавался дизайн всей системы. Каждый инициализируемый класс, проводит валидацию установленных параметров по окончании сессии инициализации.

SIPUserAgent (UA) - центральная точка доступа к API. UA - инициализируемый объект и прежде чем вы получите доступ к различным частям системы, его необходимо... правильно! проинициализировать. По окончании сессии UA проверит все введенные данные на валидность и, если все в порядке, создаст необходимые структуры pjsua. UA поддерживает конфигурирование в config файле, но по умолчанию не использует его, хотя и имеет для этого явный интерфейс - метод ReadConfiguration(), который может быть вызван только во время сессии инициализации. Имеется и зеркальный метод WriteConfiguration(), который следует вызвать до того, как UA будет уничтожен. Кстати, UA это пример объекта, временем жизни которого можно управлять пользователям API, поэтому он реализует интерфейс IDisposable и как дополнение, для большей наглядности метод Destroy(), который по смыслу ничем не отличается от Dispose().
SIPUserAgent, AccountManager, CallManager, MediaManager - singleton'ы и они существуют всегда в единичном экземпляре. Это означает, что в приложении вы не сможете создать больше одного SIPUserAgent'а, да оно и не требуется, т.к. в системе есть понятие аккаунтов.

Transport интерфейс pjsua инкапсулирован в классе VoIPTransport.
Это пожалуй самая маленькая часть системы, предоставляющая интерфейс для создания и конфигурирования конкретного типа SIP транспорта (UDP, TCP или TLS). В UA поумолчанию создается UDPTransport для SIP, который может быть заменен либо при загрузке конфигурации, либо явно одним из наследников VoIPTransport во время сессии инициаллизации. К сожалению в текущем релизе pjsip поддерживает только UDP транспорт для RTP, но в дальнейших планах стоит TCP транспорт для RTP, что авторы сопровождают пометкой "анекдот", им виднее. Поэтому на всякий случай VoIPTransport, а не SIPTransport.

Многие объекты системы имеют различные состояния, которые прекрасно описываются state machine. Состояния эти передаются через callback'и из pjsip и обрабатываются соответствующими менеджерами, так за обработку callback'ов сессии регистрации аккаунта отвечает AccountManager, который затем сообщает state machine, что ее состояние изменилось. Поначалу state machines были частью сущности, состояние которой они описывали, но при более детальном взгляде оказалось, что объект (например звонок [Call] имеет Invite-сессию и медиа-сессию) может иметь несколько никак не связанных состояний, которые лучше даже назвать сессиями. Поэтому для моделирования этих сессий я написал малюсенький набор классов, состоящий из StateMachine - базового класса для сессии; и AbstractState - базового класса для состояния. Классы состояний управляют логикой обработки событий (этакий workflow), а классы сессий просто хранят атрибуты состояния. Я даже рассматривал возможность использования WF движка для моделирования сессий, но понял, что это был бы overkill для задачи такого масштаба.

Accounts

Тут все просто - пользователь создает аккаунт, инициализирует, передает AccountManager'у, который позаботится о его дальнейшей судьбе. В принципе уже здесь можно выкинуть ссылку на аккаунт, т.к. он автоматически попадает в коллекцию аккаунтов AccountManager'ов, из которой будет удален только когда будет вызван метод AccountManager'а UnregisterAccount(account).
AccountManager при старте системы создает внутренний локальный аккаунт, так что система сразу готова к приему и отправке звонков.
У аккаунта есть сессия регистрации, управляющая его состоянием. В принципе число возможных состояний аккаунта равно числу кодов статуса SIP протокола (около 100). Поэтому, чтобы не плодить кучу классов, описывающих состояния, в которые аккаунт неизвестно может ли перейти вообще, я описал лишь те состояния, в которых при тестировании аккаунт побывал однозначно (registering, timedout, registered), а для всех остальных написал общий класс UnknownStatusState, который, получая код статуса, пишет в Trace строку с описанием этого статуса.
Об изменениях в состоянии и Account и AccountManager информируют пользователей генерируя соответствующие события.
В классе Account великое множество свойств, из которых можно почерпнуть информацию о текущем состоянии аккаунта.

Calls

Здесь, конечно, дела обстоят посложнее, но не для пользователя системы, разумеется. С его точки зрения все также просто: чтобы позвонить куда-то нужно лишь вызвать метод MakeCall() CallManager'а, указав последнему куда позвонить и с какого аккаунта, чтобы принять звонок - надо подписаться на событие IncomingCall и вызвать метод Answer() переданного звонка, и все. Звонок также будет помещен в коллекцию звонков, и дальнейшей его судьбой будет управлять CallManager, ну и конечно же пользователь может явно закончить звонок, вызвав Call.Hangup(). Под капотом же все намного сложнее.

Начнем с того, что у звонка две сессии: Invite сессия, управляемая SIP протоколом, и медиа сессия, управляемая RTP протоколом.

С Invite сессией все более менее понятно - все через нее проходят каждый раз как набирают номер на мобильном и ждут соединения, а вот медиа-сессия более интересная тема. Дело в том, что звонок может иметь более одного слушателя, равно как и вещателя, т.е. быть частью конференции. Но здесь возникает небольшое расхождение с плоской иерархией классов состояний, описывающих эту сессию, т.к. звонок может быть активным и не участвовать в конференции, или участвовать, но не может быть неактивным и участвовать в конференции, т.к. это абсурд. Для описания этой ситуации я применил Decorator - ConferenceMediaStateDecorator, оборачивающий ActiveMediaState.

Между аккаунтом и звонками есть зависимость один-ко-многим, т.е. несколько звонков могут использовать один и тот же аккаунт. Следовательнго система должна каким-то образом следить за этими зависимостями. Можно создать множество и хранить в нем ассоциации, а можно воспользоваться механизмом подсчета ссылок, как это было сделано в COM. Именно этой техникой в сочетании с описанным приемом smart-pointer для .Net я и воспользовался для реализации это й задачи в loosely-coupled манере.

Каждый звонок при создании получает ссылку на аккаунт, с которым он ассоциирован. Он не хранит ее, а блокирует аккаунт (его невозможно будет удалить) вызовом метода Lock(), который возвращает IDisposable (smart-pointer), который при создании увеличивает число ссылок на аккаунт, а при явном уничтожении (Dispose) уменьшает. Этот smart-pointer освобождается при очистке ресурсов звонка.

Media

Медиа менеджер позволяет установить устройства воспроизведения и захвата звука, посмотреть коллекцию кодеков и посмотреть состояние конференц-моста.
Конференц-мост - это часть системы, выполняющая роль микшера медиа потоков. Звонки, подключающиеся к конференции, соединяются со всеми узлами двунаправленного графа, уже участвующих в конференции звонков. В системе может быть только одна активная конференция.
Подключение к конференции может происходить как автоматически - если установлен флаг UA AutoConference (тогда ActiveMediaState будет автоматически оборачиваться ConferenceStateDecorator'ом, который и подключает звонок к конференц мосту), либо явно при помощи метода Call.ConnectToConference() (в этом случае сначала будет произведена проверка активна ли медиа сессия и, если да, то ActiveMedaiState будет обернут ConferenceStateDecorator'ом с тем же результатом). За подключение звонков между собой отвечает ConferenceBridge.

3. Testing API.
Сейчас скажу крамолу - очень важно тестировать код! Поэтому в процессе разработки постоянно писалось тестовое консольное приложение. Оно позволило вычистить API, найти частично ошибки. Далее я решил залезть в чужую шкуру - стать пользователем своей же библиотеки и написать GUI приложение. И в процессе этой работы выловил еще несколько проблем. Например при уничтожении UA возникали racing conditions, связанные с отсутствием синхронизации между процессом уничтожения всех звонков и очисткой аккаунтов, или ошибки связанные с публикацией событий не в UI потоке, т.к. pjsip обрабатывает различные транзакции в различных потоках, то для упрощения клиентского кода, все менеджеры публикуют события через SyncronizationContext, буде таковой существует. Их как правило устанавливают GUI framework'и WinForms или WPF.

Conclusion
Возможно вы заметили, что я покрыл не все части pjsua API и не все возможности уже покрытых групп реализованы - это потому что моя обертка все еще в разработке!
Надеюсь чтение про мои страдания было интересным и поучительным.

PS: Код будет выложен позже.

Всем удачи!

Initializable pattern

noreply@blogger.com (RobertT) — Mon, 16 Mar 2009 08:16:00 +0000

Представьте, что вы разрабатываете API, в котором объекты, являющиеся частью системы, должны быть проинициализированы перед использованием.
Есть несколько способов простимулировать будущих пользователей этого API завершать инициализацию перед использованием:

Ввести метод Initialize в каждом объекте, который нужно проинициаллизировать;
Более "правильный" и следующий дизайну .Net framework - реализовать в классе ISupportInitialize;
Пойти еще дальше и автоматизировать запуск и закрытие сессии инициализации;

Что значит автоматизировать запуск и закрытие сессии инициализации? Скажем, возложить эту обязанность на framerwork. Как это сделать? Об этом и заметка! Вспомните мой пост про удобную обертку над Monitor'ом, с помощью которой можно узнать есть ли в очереди на доступ к ресурсу заблокированные потоки? Так вот для пущего удобства и сохранения стиля выполнения блокировок с поддержкой языковых конструкций (скобочек =) ) там использовался .Net-специфичный паттерн Disposable. Почему бы не воспользоваться тем же приемом для обрамления сессии инициализации? Сказано, сделано. Прошу любить и жаловать - .Net-specific Initializable pattern. Состоит это решение из 2х частей:

собственно объект, который необходимо проинициаллизировать (реализует ISupportInitialize);
обертка, с помощью которой и происходит неявное управление сессией инициаллизации;

Давайте взглянем на эту обертку поближе:

Это маленькая обертка, которая при создании получает ссылку на инициаллизируемый объект и запускает сессию, вызовом метода ISupportInitialize.BeginInit(). И при детерминированном освобождении закрывает сессию вызовом метода ISupportInitialize.EndInit(). Я намеренно не стал реализовывать в этом классе Disposable паттерн целиком с тем, чтобы сессия закрывалась только явно, либо вызовом Dispose() обертки, либо EndInit() самого объекта.

Вот как может выглядеть API:

и использование его в коде:

Easy-peasy!
А вот как выглядел бы код без Initializer:

мое чувство прекрасного плачет =).

Все это конечно не отменяет проверок на наличие сессии в самом объекте, т.к. он должен разрешать редактировать себя только на протяжение последней, а в остальном мне кажется несколько упрощает код, избавляя его от 2х строчек =), зато визуально ограничивает рамки сессии, что на мой взгляд весьма удобно и лаконично.

UPD: поступила вполне обоснованная критика - трудно читаемый код, тяжело разобраться зачем создавать аккаунт и сразу же "диспозить" его. На это могу лишь ответить, что API в данном случае (и вообще, если применяется этот паттерн) должно подсказывать ЧТО оно возвращает, другими словами метод называется не AddAccount, a InitializeAndAddAccount. А еще лучше если бы он назывался CreateAccountInitializer =).

UPD#2:
Придумал как избавиться от неразберихи и нарушения принципов, сохранив красоту идеи.
Не надо делать никаких "conventions" в API. Надо дать возможность желающим писать так как они хотят и привыкли, а извращенцам вроде меня дать возможность "юзать" такие "извраты":

и пример:

как видите API ничуть не пострадало и осталось читабельным и ясным, и ничьи принципы не нарушены.

PS: И еще одно дополнение. Вся эта возня вокруг Disposable паттерна - это ничто иное как smart pointer для .Net! Те из вас, кто писал на С++ поймут о чем я.

Удачи!

Much of muchness. Other readings.

noreply@blogger.com (RobertT) — Mon, 02 Feb 2009 08:11:00 +0000

This is a short note on other possible solutions of forementioned scenarios that these series of articles were devoted to.

Actually there is only one writer that had discovered the same theme. His name is Kent Boogaart. You might know him for his SCSF.WPF Contrib project, that I for one actively use in my projects.

Discovering MAF-enabled solution he breakes it to following pieces:

The most interesting parts here are Event Hub and Service Provider implementations.
Kent's techinque is fully based on MAF advantages (it means he doesn't use any other .Net libraries as I did with WCF in my EventBroker implementation) finishing with the fully independent addins and hosts, that is not true in my case, where host and addin are coupled by service contracts and service provider libraries.

P.S. other articles in this series

P.P.S. Actually there is nothing preventing you from generating proxies to subscription and publication services in addin's and host's projects separately, so there is only one dependency left - my ServiceProvider library. Not a big deal =)

Good luck!

Much of muchness. Part 6. XAppDomain EventBroker.

noreply@blogger.com (RobertT) — Tue, 27 Jan 2009 08:46:00 +0000

Алилуйя! Мы добрались до заключительной (и самой интересной) части.
Здесь я расскажу, свой подход к реализации кросс-доменного EventAgregator'а.

Необходимость создания этого монстра диктует плагинная архитектура - различные изолированные модули, ничего не знающие об остальных плагинах, должны уметь оповещать окружающих о каком-то важном событии, причем получатели сообщения, обязательно будут жить в другом, изолированном домене.
Фундаментом моей платформы является CAB - composite application block, содержащим реализацию EventAggregator'а. Как сделать так, чтобы он не был ограничен одним доменом? Никак. Дело в том, что в CAB композиты публикуют события и подписываются на них при помощи ObjectBuilder pipeline, в котором специальная стратегия EventAggregator'а аккумулирует всю эту информацию. В нашем же случае все объекты плагинов будут создаваться MAF pipeline'ом, и доступа к ним у нас не будет. Так как же быть? Использовать WCF - Windows Communication Foundation.

В WCF из коробки нет реализации механизма Publish-Subscribe, но есть все средства для его реализации. Подходов может быть несколько:

Подписка на основании контракта (contract based);
реализовать стандарт WS-Eventing (topic based);
Pub-Sub framework by Juval Lowy from IDesign (contract based);

За основу решения я взял последний framework от Juval Lowy и расширил его, сделав его contract&topic based, с тем, чтобы интегрировать его с CAB EventAggregator (topic based). Но обо всем по порядку.

Publish-Subscribe framework (С) Juval Lowy IDesign.

Дабы не повторяться, не буду описывать механизмы работы последнего, посему настоятельно рекомендую ознакомиться со статьей, в которой он описан.

Прежде всего небольшим изменениям подвергся контракт сервиса подписки. Теперь ему передается не имя метода, которое надо вызвать у подписчика, а некий объект, выражающий интерес в подписке, который содержит имя метода (contract based) и имя topic (topic based), по которым EventAggregator сможет определить заинтересованность того или иного подписчика в неком событии.

Интерфейс сервиса подписки кросс-доменного EventAggregator'а для моей платформы выглядит следующим образом:

основное его назначение - сообщать WCF инфраструктуре о том, что IEventNotifyCallback - это callback contract для нашего кросс-доменного EventAggregator'а. DomainDTO - это суперкласс для моих DTO.

Сам сервис реализован в классе XAppDomainEventBrokerSubscription.

Он выполняет функции сервиса подписки и связывает инфраструктуру CAB с нашим механизмом. Последнее осуществляется аналогичным CAB'овскому образом - поиск публикаторов событий (по соответствующим аттрибутам) и аккумуляция этих публикаторов в CAB EventAggregator с одной лишь разницой, что вместо подписчика подставляется суррогатный объект, который при получении события опубликует его в нашей кросс-доменной системе (фактически просто пробросит дальше). Интегрируется этот сервис в CAB при помощи специальной стратегии ObjectBuilder'а XAppDomainEventBrokerStrategy.

Публикацией ведает XAppDomainEventBrokerPublication - наследник слегка измененного PublicationService сервиса из framework'а Juval Lowy. Первый реализует callback контракт как контракт сервиса, а последний на основании вызываемого метода и topic находит и вызывает соответствующий метод у соответствующего подписчика.

Но возникает резонный вопрос - а где, собственно, этому сервису передается topic? И куда его вообще воткнуть, если это contract-based framework? Ответ прост. Засунуть в заголовок сообщения и занимаются этим клиенты сервиса. Их только надо унаследовать от PublisherServiceClient - часть моей инфраструктуры WCF (может быть опишу попозже).

Обратите внимание - у базового клиента сервиса подписки есть свойство EventTopic, с помощью которого мы можем передать это значение в WCF pipeline через расширение канала EventTopicChannelExtension, с одним единственным свойством - EventTopic.
Помните суррогатные объекты, добавлявшиеся в EventBroker CAB? Так вот они публикуют события через EventPublisherClient, передавая ему значение EventTopic из аттрибута.
Как EventTopicChannelExtension попал в канал? Все тот же базовый клиент при создании фабрики каналов добавляет EventTopicFlowBehavior, выполняющий всю работу.

Собственно всю работу делает даже не он, а следующие два джентельмена:

Первый, как следует из его названия, инициаллизирует канал, добавляя в него уже упоминавшееся выше расширение EventTopicChannelExtension для передачи EventTopic второму джентельмену, который собственно добавляет этот topic в заголовок передаваемого сообщения.
Из этого самого заголовка, слегка модифицированный мной, PublicationService вычленяет EventTopic и фильтрует по нему подписчиков.

Вот и все! Теперь все, что нужно сделать по шагам:
1. Создать прокси к сервису подписки и подписаться на интересуемое событие, указав при желании метод контракта, который следует вызвать.
2. Создать прокси к сервису публикации и вызвать, мимикрирующий под контракт подписчика сервис публикации, передав при желании topic.

Не очень надеюсь вы не запутались, потому что сам запутывался не раз.

P.S. ссылки на предыдущие посты в этой серии

Part 1. Overview.
Part 2. MAF addin UI - gadget. Object model.
Part 3. WPF-interop and "airspace" notion - hosting gadgets in complex shape windows.
Part 4. Publishing MAF addin settings.
Part 5. Handling unhandled exceptions in isolated addin domains, gadget host.
Part 6. Cross-AppDomain events propagation powered by Juval Lowy's WCF Pub-Sub framework.

Удачи!