DCSIMG
ESB on IServiceOriented - IHateSpaghetti {code}

IHateSpaghetti {code}

VSX, DSL and Beyond by Eyal Lantzman

Syndication

Coding / Architecture

Extensibility /DSL

Projects

Articles

ESB on IServiceOriented

IServiceOriented has posted an implementation for ESB - Publish/Subscribe. I have couple of comments about the implementation.

1. I would split the ServiceBusRuntime into several partial classes each of them will be responsible for a group of logical commands, ie: ServiceBusRuntimeListner, ServiceBusRuntimePublishSubscribe, ServiceBusRuntimeService etc. This way you get maintainability and psychological (and FS) separation of the core system providing better readability and understanding of the code.

If the code file contains a lot of lines high percentage won't read it at all (read it in some article on human reaction to long block of text vs. same amount of text written sparsely.

2. They are using lightweight read/write locking mechanism. In my opinion the code will be a lot more readable if you implement a wrapper class such as:

   1: public class RWLock :IDisposable
   2: {
   3:     private bool _read;
   4:     private ReaderWriterLockSlim _lock;
   5:     
   6:     ///<summary>
   7:     ///private constructor
   8:     ///</sumarry>
   9:     private RWLock (ReaderWriterLockSlim rwLock, bool read)
  10:     {
  11:         _read = read;
  12:         _lock = rwLock;
  13:         
  14:         if (read)
  15:             _lock .EnterReadLock();
  16:         else
  17:             _lock .EnterWriteLock();
  18:     }
  19:     
  20:     ///<summary>
  21:     ///Read lock acquire
  22:     ///</sumarry>
  23:     public static RWLock AcquireReadLock(ReaderWriterLockSlim rwLock)
  24:     {
  25:         return RWLock (rwLock,true);
  26:     }
  27:  
  28:     ///<summary>
  29:     ///Write lock acquire
  30:     ///</sumarry>
  31:     public static RWLock AcquireReadLock(ReaderWriterLockSlim rwLock)
  32:     {
  33:         return RWLock (rwLock,false);
  34:     }
  35:     
  36:  
  37:     ///<summary>
  38:     ///Lock release
  39:     ///</sumarry>
  40:     public void DIspose()
  41:     {
  42:         if (read)
  43:             _lock .ExitReadLock();
  44:         else
  45:             _lock .ExitWriteLock();
  46:     }
  47: }

Basically, its a cool use of IDisposable interface that will enable the following code:

   1: using (var locker = RWLock.AcquireReadLock(_subscriptionsRWLock))
   2: {
   3:     //do some thing
   4: }

Instead of:

   1: _subscriptionsRWLock.EnterWriteLock();
   2: try
   3: {
   4:     //do something
   5: }
   6: finally 
   7: {             
   8:     _subscriptionsRWLock.ExitWriteLock();
   9: }
Published Sunday, July 27, 2008 6:00 AM by Eyal

Comments

# Making the Possible Impossible@ Sunday, July 27, 2008 1:24 PM

Have you ever gone to a restraunt with a menu that was just too big? Every once and a while I wind up

# re: ESB on IServiceOriented@ Monday, July 28, 2008 9:17 AM

I wonder if there's a problem with your solution. Doesn't the private constructor have to be thread safe itself. e.g all operations must be atomic.

Let's say one thread tries to acquire a write lock and then you have a context switch at line 12. Another thread tries to acquire a read lock and then you have a switch back. the first thread won't get the lock it asked for.

by Kim

# re: ESB on IServiceOriented@ Tuesday, August 05, 2008 3:39 AM

Hi Kim,

That's fine by me because the locking mechanisem is preserved - the actual EnterReadLock(...) will block for the other thread. The constructor is not thread safe by the logic within it ensures that it will block for the first thread that will call EnterXXXLock(...). You can put static locking oject but you don't need it for functionality perspective.

by Eyal

Leave a Comment

(required) 
(required) 
(optional)
(required) 

Enter the numbers above: