Here are some notes that I made from a conversation with a good friend Robert Hogg an MVP for BizTalk who has the talent of being able to explain a complex thing simply. In this case it was on getting a better understanding on what is SOA. Here is my understanding of the conversation…
The key thing about Service Orientated Architecture is the term Architecture. This implies that the use of services should be the foundation of the architecture. Services can be functional or data services. Leaving SOA to one side for a moment most applications made can be broken down to 3 tiers; UI, Business Logic and Database. The Business logic can be built on a number of patterns MVC, VMMV etc. SOA is orientated in the business logic tier. In fact SOA could be made even with old technology like MTS.
The thing that differentiates SOA in this case is both Business and IT understand the same thing when it comes down to the word “Service”. A business man would like robust reliable software that is also completely dynamic so as to be able to adapt to changing business needs. Dynamic and robust are like 2 opposing forces which implies a compromise is needed.
Whatever architecture is chosen software must be well written or in other words analyzable, testable, maintainable and re-compassable. SOA does that but where the individual components are arranged as services. New technology such as WCF, BizTalk, ESB, WF make it easier to implement an architecture based on services. These technologies makes Services a natural point for an interface because for example WCF the interface can be easily configured to run with things like reliable messaging, msmq etc. just by modification of a configuration file. Tasks that take several days to completed can be processed via tools like BizTalk can that can reliably processed long running tasks even if the server where to be rebuilt in the mean time. Dynamic tasks such as rearranging business processes can be make over ESB with a small coding overhead. Another aspect of the BizTalk server is that it provides a Hub-Spoke connectivity with out of the box connectors to systems like SAP, PeopleSoft etc. The idea that you make just one interface to the hub as opposed to one per system that you need to connect to.
After some time of programming with SOA you may find that certain services may need to be broken down into smaller ones. When doing this just remember to keep a façade to the old implementation, in this way you will not break any code that is using the old implementation.
I found this a good introduction to SOA from a more down to earth perspective. The subject is quite extensive as there are a lot of example of companies that have tried and failed to implement SOA.
