Service Oriented Architecture


I've found that a large number of developers hear the acronym SOA and assume it's speaking of the use of web services as a major architectural driver. Service Oriented Architecture is actually a mindset which seeks to create independent/loosely coupled software services. This mindset allows easy transition to software services available via various network protocols (i.e. web services).

SOA's Role

Keeping sub-systems loosely coupled (preferably independent) is crucial to a foundational framework's flexibility. When you think about SOA in regards to this framework, think building blocks or pipes and fixtures. The only allowable dependencies in a system like this are on the most basic functionality.

Practical Approach

SOA can be realized through several practical considerations. One way is through the use of patterns. While there is a lot of material on patterns, a lot of the design will resemble the following patterns; Abstract Framework, Singleton and Decorator. The reason I single out these three in particular is that all of them are good examples of design methodology which focuses on functionality outside of business objects/entities. This lends itself to an over-all architecture which focuses on individual components (services) which work together against completely independent business objects/entities. These business objects are often referred to as Plain Old CLR Objects (POCOs) as they serve primarily as object oriented data structures with very simple functionality.


Framework Development

The over-all development of Nvigorate itself will benefit from this approach as it should free up development of the different namespaces and classes from one another. Parallel development paths allow more participants and shorter release schedules.

Framework Maintenance

Being able to isolate maintenance and new feature development decreases the potential for cascading bugs and eases regression testing efforts.


Developers using this framework will be able to integrate it with their business objects without having to do a lot of Nvigorate specific modification to their pre-existant source. This makes Nvigorate attractive to developers and project teams which are looking for a robust and flexible framework as it will have very little integration cost for them. It also make Nvigorate a feasible possibility for teams wanting a way to migrate legacy systems to newer technology as it reduces the need to create specialized business objects.

The reduction in development/retrofit time would make this framework very attractive to teams at different stages of development as opposed to a lot of framework which require application design and business objects to cater to that specific framework.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.