MSMQ and TransactionScope

Thursday, 8 March 2012 07:09 by ebenroux

It turns out that when using TransactionScope you should be creating the MessageQueue instance inside the TransactionScope:

    using(var scope = new TransactionScope())
    using(var queue = new MessageQueue(path, true))
        // timeout should be higher for remote queues
        // transaction type should be None for non-transactional queues
        var message = queue.Receive(TimeSpan.FromMilliseconds(0), MessageQueueTransactionType.Automatic);
        // ...normal processing...

So MSMQ behaves the same way that a database connection does in that one has to create the database connection inside the scope.

Categories:   Software Architecture | c#
Actions:   E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Windows 7 Enterprise 90-day Trial cannot rearm

Friday, 12 August 2011 22:31 by ebenroux

I have been using the Windows 7 Enterprise 90-day Trial edition and as some may know one can 'rearm' the trial something like 3 times after it expires.

In order to do so you simply run the following from a command prompt with administrator rights (right click the cmd link and click on 'Run as administrator'):

slmgr -rearm

Well.  It didn't work.  It wouldn't rearm.  Some folks reckon after the trial expires you are shafted and some reckon you need to reboot a couple of times.  Others go with a crack approach.  Then I came across this:

slmgr -ato

And that did the trick.  So you need to run both.  The first seems to do the 'rearm' bit and the second the activation.

Man am I happy.  I hope this helps someone else out there.


Categories:   Windows
Actions:   E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

SOA is not going away

Sunday, 5 December 2010 13:00 by ebenroux

Sometimes it is difficult to explain things that appear to be extremely simple.  I guess this is where tacit knowledge comes into the picture.  It may very well be that service orientation falls into this category.

Let's say that I wanted to pay a bill 50 years ago by sending my creditor a cheque by mail.  I also expect a letter in reply stating that my cheque has been received.  I firstly place my cheque, along with some relevant information, in an envelope and write the address of the creditor to send the mail to on the front.  I could also write the return address on the back.  I would need to add a stamp to the envelope to demonstrate payment of the requested service.  Next I would place the letter envelope in a post box.  If everything is in order I can reasonably expect the recipient to receive the letter.  I can assume that the post office will provide the expected service.  Of course, this doesn't mean that the service will be provided as expected.  There are a number of things that could go wrong but we'll hope for the best.  So service orientation has been around for a while.

I, as the user of the mail system, see a very coarse-grained service,  Within the post office there are many different services of varying granularity (some quite fine-grained) provided by different departments.

Now, although we expect a response from the creditor I am pretty sure that very few people will run off to their own post box and expect the reply to pop in; nor will they wait for the response.  It is assumed that it will take a couple of days.

Let's jump back to the present and send an e-mail to a creditor.  Once again, we expect a reply but we will not be watching our e-mail client application all day to see when it comes in.  Again we expect some time to pass but hopefully not a couple of days.  So our service will be completed eventually.

On the other hand some services are expected to be completed immediately.  It depends on how consistent our information needs to be at any one time.  For instance,  I have a bank account with no overdraft facility.  I draw my last ZAR100 from an ATM.  Since my wife may draw money using the same account from another ATM I guess that bank would prefer that she not draw "the last ZAR100" also.  So the first transaction would block the second until it has been updated after which the second would fail since there would be insufficient funds.  There may be no place for eventual consistency here.  I say 'may' because the bank could decide to allow such behaviour and simply impose penalties.

Actions:   E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Bite-Size Chunks

Thursday, 4 November 2010 23:03 by ebenroux

I came across this article on ZDNet: "The bigger the system, the greater the chance of failure"

Now, I am all for "bite-size chunks" and Roger Sessions does make a lot of sense.  However, simply breaking a system into smaller parts is only part of the solution.  The greater problem is the degree of coupling within the system.  A monolithic system is inevitably highly coupled.  This makes the system fragile and complex.  The fragility becomes apparent when a "simple" change in one part of the system has high ramifications in another part.  The complexity stems from the number of states within the system that increases exponentially since they are all coupled.

If we simply break the system down into smaller components without removing the high coupling we end up with the exact same problems.  This is typically what happens when folks implement JBOWS.

What is required is to break down the system into components and remove the coupling.  One option is to make use of a service bus to facilitate sending messages between the components asynchronously.  In this way the different components rely only on the message structures in the same way that an interface (as in class interface) abstracts the contract between classes.  So in a way it is a form of dependency inversion since the components no longer depend on the concrete component implementation but rather on the message structures (the data contracts).

Coupling comes in two forms: temporal and behavioural.  Web services are a classic case of high temporal coupling.  Since a service bus is asynchronous it results in low temporal coupling.  Behavioural coupling is tricky either way.

Behavioural Coupling

Friday, 29 October 2010 08:32 by ebenroux

When I left work yesterday I had to work through a turnstile.  One of those big ones that only one person can go throught at any one time, in either direction.  So it turns both ways.  It is secured so I have to swipe my access card to get in or out.

This got me thinking about how that system works.  Let's look at a highly coupled mechanism:

Since the turnstile allows either in or out the service the readers needs to know which reader does what.  When a request arrives to allow someone access into the building our card reader service checks with the autorization system whether the person has access and if so sends a message to the turnstile to allow it to turn in the relevant direction.  So here our card reader service needs to know how the turnstile works and which card reader is attached to which action.  This is rather high behavioural coupling.

Now for something a bit less coupled.  Let's say our turnstile simply 'unlocks' allowing the turnstile to turn once in any direction.  Now the card reader service simply has to ask whether the person has access to unlock the turnstile and send the unlock message.  So our card reader service now does not care how the turnstile works.  This is low behavioural coupling.

Either way can be implemented but I'd say the first is somewhat more complex to get done.

Natural Aggregates vs Synthetic Aggregates

Friday, 20 August 2010 08:47 by ebenroux

In databases we have natural keys such as company code, client number, and order number.  Then we have synthetic keys that are typically globally unique identifiers (GUID) or auto-incrementing numbers (IDENTITY).

It seams to me that we may need to make this same natural and synthetic distinction when it comes to aggregates in domain-driven design (DDD).  The whole Aggregate Root (AR) concept makes it extremely difficult to define certain structures; especially when starting out with DDD.  I find the reason being that some entities don't work well as aggregate roots either:

  1. because the aggregate root seems to change depending on context; or
  2. the entity is not a natural fit for an aggregate root.

An example of a natural aggregate is something like Order and OrderLine.  An order line can never exist without an order.

  • Order has a Total that is calculated by summing the OrderLine Totals.
  • Total on order cannot mean anything other than the total of the order lines.

An example of a synthetic aggregate is something like GrapeBunch containing a GrapeStem and a GrapeBerry collection.

  • GrapeBunch can have a Weight that is calculated by summing the Weight of each GrapeBerry in the collection and adding the Weight of the GrapeStem.
  • The weight of the grape bunch cannot mean anything other than the sum of the grape berry weights and adding the weight of the grape stem.

An example of a problematic aggregate by using an aggregate root is GrapeStem with a GrapeBerry collection.

  • What does the Weight on GrapeStem mean?
  • We could have another mothed called TotalWeight but this is confusing.

So, although an aggregate root can be made to work it just does not feel very comfortable.

Actions:   E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Entity vs. Value Object

Thursday, 19 August 2010 08:54 by ebenroux

This is another question that keeps popping up on the Domain-Driven Design group.  It seems to be a difficult task and some of the answers seem to complicate matters since they come from a technical context.

How do you use your object?

The same concept may very well be implemented as a value object in one context and as an entity in the next and depending on the type of object this distinction would be more, or less, pronounced.  So it is important to understand how you intend using the object.  If you are you interested in a very particular instance it is an entity and that's that.  An object like an Employee or an Invoice can immedsiately be identified as an entity since we are all familiar with these concepts and 'know' that we need to work with specific instances.  So we'll take something a bit more fluid like an Address

Now when would an Address need to be an entity?  Well, do we care about a specific instance?  Is our application (in our Bounded Context) interested in a particular address?

Example 1: Courier - Delivery Bounded Context

Let's imagine that we are couriers and when we receive a parcel we need to deliver it to a recipient at a particular address.  Since we specialise in same-day business delivery we frequently deliver to office blocks that have the same street address but may house many of our clients.  Here we care about a particlar Address and we link recipients to it.  The Address is an Entity.

Example 2: Courier - HR Bounded Context

In our courier company we also have an HR system so we store Employee objects.  Each employee has a home address stored as fields in the employee record in our database.  However, in our object model we have an Address object represented by the Employee.HomeAddress property (this is just for illustration so we won't split hairs as far as software design is concerned).  In this case it seems quite obvious that Address has to be a value object since it is purely a container.

So let's say this same Employee object can have a list of ways to contact the employee and we model a ContactMethod class.  In our data store we will have a one-to-many relationship between our Employee table and the ContactMethod table.  In fact, we go so far as to give ContactMethod an Id so that we can directly update the data in the database (for whatever reason).  ContactMethod would be aggregated with Employee so whenever we save the employee the contact methods are re-populated in the database (deleted and re-inserted).  The ContactMethod is still a value object.  Even though it may have its own life-cycle and identifier we do not care about a specifc instance in our application.  We will never, and can never, say "go and fetch me contact method... {what}".  So there is no way to uniquely identify a Value Object using the Ubiquitous Language for our domain even though it may have an identifier that is universally unique.  It is simply a synthetic key used for technical efficiency.

Immutable Value Objects

Some folks are of the opinion that value objects must be immutable.  This is not necessarily so.  As with our first address example an immutable value object would mean we need to create a new instance to make simple changes such as fixing a spelling mistake.  It is perfectly acceptable to use immutable objects but there is also no reason why we can't change the properties of the same object instance.  The only time that an immutable value object would be required is when the object instance is shared.  But the only time you would share a value object in this way is when you are implementing the flywieght pattern and those cases are pretty rare.



How easy is ORM?

Tuesday, 10 August 2010 09:22 by ebenroux

I subscribe to Code Project newsletters.  So this morning I receive one with the following blog post:

Mixing Table Per Hierarchy and Entity Splitting

And all I can ask myself is how this makes anything easier?

Just do your own mapping and be done with it already.

Actions:   E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Aggregate Roots vs. Single Responsibility (and other issues)

Tuesday, 27 July 2010 10:34 by ebenroux

It is interesting to note how many questions there are around Aggregate Roots.  Every-so-often someone will post a question on the Domain-Driven Design Group regarding how to structure the Aggregate Roots.  Now, I may be no genius but there are too many questions for my liking.  It indicates that something is hard to understand; and when something is hard to understand it probably highlighting a larger problem.

Aggregate vs. Aggregate Root

"Cluster ENTITIES and VALUE OBJECTS into AGGREGATES and define boundaries around each.  Choose one ENTITY to be the root of the AGGREGATE, and control all access to the objects inside the boundary through the root." (Evans, p. 129)

In one of Eric's presentations he touches on this; stating the difference between an Aggregate and an Aggregate Root.  I have mentioned Eric's bunch of grapes example in a previous post so I will not re-hash it here.

The gang of four has two principles of object-oriented design:

  1. "Program to an interface, not an implementation." (Gamma et. al. p. 18)
  2. "Favor object composition over class inheritance." (Gamma et. al. p. 20)

So what's the point?  At first glance it seems that we are working with composition for both the Aggregate and the Aggregate Root.  On page 128 of Eric's blue book there is a class diagram modelling a car.  The car class is adorned with two stereotypes: <<Entity>> and <<Aggregate Root>>.

Single Responsibility?

So is an Aggregate Root called Car sticking to the Single Resonsibility Principle?  It is responsible for Car behaviour; but also for the consistency within the Aggregate since it now represents an Aggregate with the Car entity as the Root.  It seems as though the Car is doing more than it should and I think that this leads to many issues.

Could it be that the Car Aggregate Root concept is a specialisation of the Car entity?  So, following this reasoning it is actually inheritance.  The reason we do not see it is because it is flattened into the Car entity and, therefore, the car no longer adheres to SRP.  My reasoning could be flawed so I am open to persuasion.

Does the Aggregate Root change depending on the use case?

The problem the Aggregate Root concept is trying to solve is consistency.  It groups objects together to ensure that they are used as a unit.  When one looks at the philosophy behind Data-Context-Interaction (DCI) it appears as though the context is pushed into the root entity.  When a different context (use-case) enters the fray that also makes use of the same Aggregate Root it appears as though the Aggregate Root is changing.

There has been some discussion around the issue of the Aggregate Root changing depending on the use case, i.e. a different entity is regarded as the root depending on the use case.  Now some folks state that the Aggregate Root isn't really changing but the fact that it appears to be changing should be an indication that you are working with different Bounded Context.  Now this is probably true; especially since the word context make an appearance.

A quick note on Bounded Contexts:

Let's stay with the Car example.  Let's say we have a car rental company and we have our own workshop.  Now our car could do something along the lines of Car.ScheduleMaintenance(dependencies) and Car.MakeBooking(dependencies).

This is where issues start creeping into the design.  The maintenance management folks don't give two hoots about rentals and, likewise, the rental folks are not too interested in maintenance; they only want to know whether the car is available for rental.  Enter the Bounded Context (BC).  We have a Maintenance Management BC and Rental Administration BC.  Of course we would probably also need a Fleet Management BC with e.g Car.Commission() and Car.Decommission().

The particular Car is the same car in the real world.  Just look at the registration number.  However, the context within which it is used changes.  It is, in OO terms, a specialization of a Car class to incorporate the context.  This inevitably leads to data duplication of sorts since the data for each BC will probably be stored in different databases.

Assuming we view this as a problem, how could we solve this?  As proposed by the GoF we could try composition.  In DCI terms the context can aggregate the different entities.  I previously blogged about an aneamic use-case model and the context looks an awful lot like a use-case.  I have not played around with how to get these concepts into code but we'll get there.

Repositories return Aggregate Roots?

Now this one is rather weird.  I have no idea where this comes from.  For those that have the Domain-Driven Design book by Eric Evans it is a simple case of opening the front cover and having a look at the diagram printed on the inside where it clearly shows two arrows that point to Repositories.  One comes from Entities and the other from Aggregates (note: not Aggregate Root), like so:

  • [Entities] --- access with --> [Repositories]
  • [Aggregates] --- access with --> [Repositories]

The fact is that a repository always returns an entity whether or not that entity is an aggregate. So if folks want to call it an AR when there is no aggregation it probably will not restrict the design.

WCF issues

Friday, 28 May 2010 12:42 by ebenroux

I installed a WCF client on a test machine this morning.  Since it is using message encryption I installed the relevant certificate in the TrustedPeople store.

When the application started I received the following exception:


Turns out that the machines date was incorrect and fell outside of the certificate's valid period.  A quick date change fixed that.

All was still not well as I swiftly moved on to the following exception:


After some investigation and searching the Net it turned out that the time was way off too and that threw something out of joint.  Setting the time to something more relevant sorted that.

So do make sure that you have your servers and workstations more-or-less synchronised.

Categories:   WCF
Actions:   E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed