Jul
8
WRITTEN BY:
David Cummins
Wednesday, 8 July 2009
SOA stands for service-oriented architecture. The term encompasses many meanings, but the one that I like to use is that it is a systems development and integration methodology where systems group functionality around business processes and package these into interoperable services.
This development methodology and architectural style has become increasingly popular in the last couple of years and opens new development and revenue streams for organisations. The introduction of SOA, and its subsequent maturity, has given rise to concepts such as the enterprise service bus (ESB), software as a service (SaaS) and cloud computing.
When you scan through the current IT headlines these days, you can not help but be introduced to these terms or at least be exposed to web applications that espouse these principles—such as Twitter, Salesforce.com, Netsuite and Facebook.
What makes these applications so useful to systems developers and integrators is that they provide mechanisms that allow us to easily reuse components within an organisation's business processes and systems, no matter where these SOA components may be hosted. These mechanisms follow the guiding principles of SOA around:
- reuse, granularity, modularity, composability, componentisation and interoperability
- standards compliance
- services identification and categorisation, provisioning and delivery, and monitoring and tracking.
SOA allows organisations to create best-of-breed applications that blend components sourced from specialist service providers, as well as legacy systems, quicker and more cost-effectively. This allows businesses to react to changing market conditions and respond to new opportunities faster than they were able to previously using traditional technologies. Additionally, such systems are easier to test as, by definition, service components have to be well-defined, granular and have fully documented interfaces in order to interoperate within the SOA framework.
When embracing SOA, enterprises need to take into consideration:
- the task of building the infrastructure that can manage the potentially millions of metadata messages that SOA systems generate
- investing in automated testing frameworks to identify potential and real errors in composite applications
- the ability to deliver the ‘ilities’ (security, scalability, simplicity, extensibility, visibility, customisability, reliability and reusability) when creating your SOA frameworks especially when you may be sourcing some services from external providers.
In a further article I will explore how some of the ‘ilities’ can be addressed using Cisco's Service Oriented Network Architecture (SONA) to the edge of the network and beyond.
References
http://www.adobe.com/devnet/articles/saas.html
http://www.cisco.com/en/US/solutions/ns340/ns629/networking_solutions_products_genericcontent_sona_overview2.html
http://en.wikipedia.org/wiki/Service-oriented_architecture