tags:

views:

115

answers:

2

Hi,

I am using MSMQ as a way to provide asynchronous SOA. Please refer to the code below as it's quite hard to explain. I am trying to figure out the best way to do it.

//another method reads off MSMQ and passes the Message into this method
public void ReadMSMQAndAction(Message m)
{
  var e = m.Entity;

  /* this is really bad, but i some how still need some 
   * kind of traffic cop to direct action */
  switch typeof(m.Entity)
    case Order.GetType()
      switch e.Action
        case "SAVE"
          //todo OrderRepo Save
}

//Message gets searlized and put into MSMQ
public class Message<T>
{
  public T Entity { get;set; }

  /* should this be string?
   * or some kind of rule i.e. "ClassName:MethodName" etc? */
  public string Action { get;set; } 
}

public class OrderRepo
{
  public void Save(Order o) { /* todo */ }
  public void Delete(Order o) { /* todo */ }
  public void Update(Order o) { /* todo */ }
}

As the code gets more complex it'll be really hard to manage. Any suggestions are welcome! Thanks!

+1  A: 

Look into using delegates. They will allow you to pass the actual method call into the MSMQ so that you can then fire the delegate/action when you retrieve it from the queue.

ck
thanks. why didn't i think of delegate.
Jeffrey C
but actually what i was thinking was that i wanted the backend to be transparent to the client, which means the OrderRepo may not be exposed to the client, i want to have some kind of mechanism for the client and back to exchange instructions.
Jeffrey C
If your logic is in a DLL then the front and back can both share it.
ck
A: 

Use WCF. Microsoft has wrapped it up so that the service (in the sense of SOA) presents as a method call, the transport being MSMQ.

The contract is necessarily one way, and the fact that the transport happens to be MSMQ is totally incidental to the service and its client (except insofar as this choice forces a one way contract).


On another note, I feel compelled to comment: until you can clearly and succinctly express the intent and implementation strategy, you do not have a clear and complete idea of what you are creating, and your chances of success are slim at best.

Software development begins with taking the vague maunderings of management and sales people and applying common sense on their behalf, with cycles of feedback, until one side loses interest, the budget runs out, or you produce what the project sponsors regard as a clear and concise rendering of what they imagine they said during that first excited arm waving.

If you cannot explain what you are doing then you don't know what you are doing. Time to stop and think until you do.

Peter Wone