Service Oriented Architecture (SOA) is a set of engineering principles and methodologies for designing and developing interoperable software services. These services are well-defined in the sense that the service consumers and the services communicate by passing data in a well-defined formats. That lets developers to combine and reuse existing functions and allow certain users to access services over a network.
In some respects, one can regard SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. As of 2008, increasing numbers of third-party software companies offer software services for a fee. In the future, SOA systems may consist of third-party services combined with in-house services. This promotes standardization within and across industries, and spreads the cost of shared resourses over several users. In this respect, SOA revives concepts like modular programming (1970s), event-oriented design (1980s) and interface/component-based design (1990s) and promotes the goal of separating users/consumers from the service implementations. Services can run on multiple distributed platforms and be accessed across networks, which also maximizes the return on the investment.
For SOA to operate, no interactions must exist between the chunks specified or within the chunks themselves. Instead, humans specify the interaction of services (all of them unassociated peers) in a relatively ad hoc way with the intent driven by newly emergent requirements. Thus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. Programmers develop the services themselves using traditional languages like Java, C, C++, C#, Visual Basic, COBOL, or PHP. Services may also be wrappers for existing Legacy systems, allowing re-facing of old systems.
SOA realizes its business and IT benefits by utilizing an analysis and design methodology when creating services. This methodology ensures that services remain consistent with the architectural vision and roadmap and that they adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications.
A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of subordinate services. Services generally adhere to the following principles of service-orientation:
- abstraction
autonomy
composability
discoverability
formal contract
loose coupling
reusability
statelessness
- a mature rollout of SOA effectively defines the API of an organization.
Reasons for treating the implementation of services as separate projects from larger projects include:
Separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates agility. That is to say, it fosters business innovations and speeds up time-to-market.
Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.
An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation.