Saturday, April 14, 2012

Messaging VS. Notifying

Messaging is the basis of all SOA design, however most people don't know the essense of 'Message' in SOA is actrually 'to convey as little information as possible'. If you can convey less infomation but still get the task done, the design would be better than if you convey more information. Because by doing so, you reduced the inter-system dependency.

The essense of 'Message in SOA' is thus not WCF, not SOAP, not Web Service. It's about how to share information between different entities, while try to keep the dependency between entity as little as possible. Some people use xml as message, while transmit a very complex and big xml. It's not a good practice. Sharing little knowledge. The less the better.

In this sense, Notifying would be a better design than Messaging, because Notify only convey a simple code while Message can be very complex. We learned a lot from project Cloud Samurai(, and thus decided to use Notify rather than Message in the project.

Emerging Order

As we found in several Azure projects, designing complex inter-system interaction is very challenging. Most Azure projects would involve multiple VMs, and multiple components or processes inside each VM, so they are typical inter-system design problems.

SOA (Service Oriented Architecture), although sounds old, is probobaly the most effective way to handle this challenges. However, we need to take a special view through the SOA len. We should emphasis more on Independence. If we can design autonomous and independent components, who can respond to the environment and messages in an intellectural and responsive way, the Order of the inter-system will Emerge as a result.  The complex behavior of the inter-system is hard to be designed, rather it will emerge from the group of independent components.

We learned a lot about the principle of Emerging Order from this project.