Alt.Net Paris session summary : "Build your own service bus" by Romain Verdier & Julien Lavigne du Cadet

Romain and Julien made a presentation/feedback about their experience in implementing their own Service Bus in ABC Arbitrage (thanks for the commodities). In addition to this summary, I encourage you to have a look at their (impressive Prezi) presentation.

They started with an overview of the context in which service bus notion is considered, reviewing some low-level concepts of MOM (Message Oriented Middleware) and giving a quick view on EAI/ESB concepts. These are the two exterme sides of the subject and set their implementation around two goals:

- add an abstraction layer to the MOM solutions, with lot of wanted conventions that help to simplify configuration, but keeping the power of these tools like interoperability, reliable message infrastructure...

- make far more simpler than EAI/ESB solutions and platform specific

Obviously, this subject is around Message driven architecture.

Next they went deeper in service bus concepts, that some solution they cited also implement. As they said, they did not invent anything.

First subject was about Message dispatching (how):

• send: a message to one conterparty waiting a response
• publish: a message to anyone who wants to pull it without any response

From these two methods, we see that there is two sorts of Message that they implements with two distinct Message concepts:

• Command that are sent -> tell someone to do something (note the imperative tense)
• Event that are published -> tell anyone wants to listen that something happened (note the passive tense)

Next, they talked about Sagas that allow to take care of long-running transactions. Their example of a trading application was judicious to understand it. Basically, it receives a "complex" trading order that will be decomposed in simpler orders (in order to accomplish the requested order without revealing the whole intention to the market...).

• A Saga is initiated by a Command or an Event
• It starts a process that send Command/publish Events
• It goes to sleep until waken by another Command or Event
• ...and it starts over, until the Saga determines it has reached its goal, then it ends.

They also quickly talked about some other (important) details like Pipelines for cross-cutting concerns, Time Service to manage Saga time out typically, Prototype Buffer for interoperable message serialization...

The main thing I would remind about implementation is the convention based aspect. It simplifies configuration (5 lines as they said) and hides some technical details, and then it allows to build the software with a bigger insight in Business value that any software should give to their users. It could be seen as a restrictive framework (just two concepts), but I truely think that it helps abstract from technical topics and focus on business value, and that these concepts are well suited to describe business goals.

Note that we did not talk about lots of related subjects like Event Sourcing, DDD...perhaps the next time :)...but we can say that Message driven architecture does not exclude other paradigms.

error MSB6006: "ResGen.exe" exited with code -532459699

I write my first tip blog post to talk about the following error I got stuck one hour (far too long...) without any search results on Google:

error MSB6006: "ResGen.exe" exited with code -532459699

I got this error when compiling a project targeting 3.5 framework with VS2010, which includes some resource file with CustomAction set to generate associated code.

In fact, I was doing some change to my configuration. Long time ago, I had set up the use of DEVPATH (configure it in the machine.config on dev machine). Due to a problem explained next, I have removed the DEVPATH environement variable, but keeping machine.config as is (to avoid full reconfiguration in case I would need temporarily the DEVPATH...ok I am really lazy :)).

Then, I discover that ResGen.exe fails, I find it when I launched compilation from command line with MSBuild and it was clear in exception trace details...really bad! (note that it works when you do not have RESX files...)

By the way, you should avoid using DEVPATH. It tries to replace GAC, but in fact it fails since it does not take care of DLL versions. But do not through it away to quickly, it could be useful to debug tier DLL for example without modifying all your references...

I found it when I have to install EntLib 5.0 side to side with EntLib 4.1...then only DLL found in first path referenced in DEVPATH was taken in account.

So 2 solutions: you are not lazy and you remove configuration in machine.config OR you are lazy and you set DEVPATH environment variable to something else than empty one (for example "D:").

Team Foundation Server Check In Policy Pack

I search over the web for some Check In Policies for TFS, and some were founds, some really interesting in my case. I think to:

• old reference but interesting http://msmvps.com/blogs/vstsblog/archive/2006/12/08/available-check-in-policies-for-team-foundation-server.aspx
• newer references http://checkinpolicypack.codeplex.com/

But there are several drawbacks:

• TFS Power Tools Check In Policy pack is lacking open source...you cannot contribute, too bad when you miss just an adjustment to an existing policy
• Configurability go from none to too much
• Too much packages with different heterogeneous deliverables (package, docs...)

So why not an open sourced Check In Policy pack, on codeplex for example...I think we can gain from homogenization of development practices for Check-In Policies.

Here are some practices I think to:

• MSI deployment with Wix : one feature by policy for example to allow flexible installation
• Policy configuration management unified
• Encapsulate common functionnalities in shared components (path exclusion...)

I was thinking to this pack to share my first Check In policy around Work Items, when I discovered that TFS bundled one and TFS Power Tools one are really basic and not contributable (do not allow link/hierarchy query) !!

Could be great if several projects could merge in one...

First ALM France UG session

The session

I do not remember how I found this new user group, but I was really happy to assist to this first session.

Contents were "ecumenical", differents points of view and different communities represented (ok a little bit more of .NET one...oddly...). It was a first good point :).

Next, very important, I meet and talk with interesting people, and I hope we will share more in the future through this group.

Quickly about content, what is ALM? François Merand gives 3 major axes : Governance, Dev and Exploitation. Simple, great. So it is not just source control or continuous integration...

Then, Lucian Precup and Arnaud Heritier have made a quick overview of Open Source ALM ecosystem : Maven, IDE, IceScrum, Mantis, Git...and many more.

Daniel Cohen-Zardi followed with a presentation of his company and their product Code Fluent Entities, that proposes a DSL abstracting languages (he does not use the term DSL...but it seems like that to me).

The main points were around 3 concepts : agility, model-driven and executable models. I agree with him on these points. But for the solution, I remain to be convinced for now by this type of product...I prefer coding approach around DDD architecture.

Finally, François Tonic talked about his vision of ALM.

The group

To start, for french people, go to http://blog.alm-france.org/, for others hope it will develop in other countries ! :)

I am looking forward to Google Group discussion list to continue discussions...

Some ideas/reflexions to discuss...

1) We heard a lot the word "industrialization"...opposed to "craftsmanship"...we have to take care of these words use, there are a lot of misconception around industrialization...like over-standardization/normalization (quality ivory tower), over-specialization (like in classic industry)...to be discussed in the group :)

2) I consider ALM practices as central in day to day work, and badly initial formation are lacking in this field (at least mine and some of my colleagues...). There is certainly something to do about that.

3) I would like to share my current experience around ALM, and more importantly to have feedback...my boss and me were thinking about that...perhaps a good chance to try...:)

Thanks again for the creation of this group !