If an organization’s business drivers and technical requirements do not include the integration of components or systems running on different platforms or implemented using different technologies, service orientation may be overkill. There is an overhead for SOA technologies to provide interoperability across platforms. If an organization runs a set of applications built on a homogenous development platform with few interactions with legacy systems running on different platforms and the situation is not likely to change, a move towards service orientation is hard to justify. Likewise, if an organization’s software solutions consist of co-located components or distributed components that interact via e-mail messages, file sharing, or proprietary messaging systems, sophisticated integration mechanisms provided by SOA are an unnecessary burden.
Hard real-time systems are clearly not a good match for service orientation. Strict timeliness requirements conflict with several aspects of common technologies used in service-oriented systems (e.g., Web Services) that may introduce unbounded overhead in processing, such as XML parsing, validation and transformation; network communication; proxies and stubs for technology adaptation; and intermediary components (e.g., service registry, Enterprise Service Bus [ESB]).
Embedded systems are not naturally fit to host service-oriented systems. Embedded platforms have limited computing power, memory, and disk resources. Many SOA technologies are heavyweight in terms of memory and CPU requirements. Thus, designing a SOA solution for the software on a washing machine or a video-game console can bring unneeded complications. On the other hand, mobile communication devices are becoming more powerful and more commonly used as a runtime platform for end-user applications. Many of these applications are service consumers in service-oriented systems.
To reap the benefits and decrease overall costs of SOA adoption, an enterprise-wide, phased strategy is needed, as opposed to isolated modernization of silo legacy systems. If the organization is ill prepared, a decision to move to a SOA environment can cause numerous problems. The Software Engineering Institute has developed and applied the SOA Migration, Adoption and Reuse Technique (SMART) process that helps organizations assess the feasibility of migrating legacy systems to SOA environments [Lewis 2008]. The SMART process includes consideration of business, technical, and organizational aspects and estimation of risks and costs of SOA adoption.
SOA is an architectural pattern that can be combined with other overarching patterns. However, there is a danger in combining SOA with other patterns without understanding the inherent differences and potential incompatibilities between these patterns. Several examples follow:
Multi-Tier: Traditional multi-tier platforms, such as Java EE and Microsoft .NET, are used for the development of enterprise web-based application in several tiers. The typical tiers are (1) a client tier consisting of web clients (browser) or rich clients, (2) a middle tier with components running on an application server and possibly subdivided into web tier and business logic tier, and (3) a back-end tier comprising databases, access to legacy systems, and external services. Multi-tier is an extension of the client-server pattern in which the role a component assumes in an interaction is well defined. The pattern of interaction in multi-tier systems is that the client tier places a request to the middle tier, which in turn makes calls to the back-end tier. Although services can exist in any tier of a multi-tier system, it may not be appropriate to frame an entire service-oriented solution in traditional tiers. In service-oriented systems, services are more independent, and the pattern of interactions among service consumers, service providers, and intermediaries (e.g., ESB) is meant to be more fluid (e.g., composability) than in traditional multi-tier systems. In multi-tier systems these interactions are defined early and the interfaces among tiers are more stable.
Peer-to-Peer: In the peer-to-peer software pattern, components interact directly. However, the asymmetry found in the client-server pattern does not exist in the peer-to-peer pattern; in the latter, any component can initiate the interaction with any other peer component. This peer-to-peer communication between services exists only when callback mechanisms are included for asynchronous operations. Another crucial difference is that in a peer-to-peer solution, all peer components offer the same interface and communicate using the same protocol. For example, the Gnutella peer-to-peer network supports bidirectional file transfers. The peer components running on various machines across the Internet all provide the same interface and services: establish connection with another peer, perform search for file, and perform file transfer.
Model-View-Controller (MVC): In the MVC pattern, the view (user-facing) elements typically subscribe to events emitted by model elements when data changes occur. In the SOA pattern, user-facing components are decoupled from other components that provide services and data access. User-facing components typically fetch the data they display to users or receive the data in response to service requests initiated upon user actions. In the SOA pattern, it is not natural for services that provide core functionality and data (equivalent to model elements in MVC) to notify user-facing components of data changes. Nevertheless, when applying the MVC pattern, services can be used in the implementation of model elements.
SOA is not a one-size-fits-all solution. As an architectural style, SOA is an appropriate solution in some situations; however, there are situations in which it is not appropriate or has to be used in conjunction with other technologies to achieve the desired system qualities. The architects of service-oriented systems play a crucial role in determining what expectations can or cannot be met by SOA adoption, and where tradeoffs can be made for the benefit of the organization and the accomplishment of system quality attributes. The fundamental responsibilities of the architect are to ensure
- Early, contextual technology evaluation—As the use of SOA for external integration and the expectations of SOA adoption increase, many promises will be made about the benefits of SOA that will not be completely validated until implementation. The role of the architect is to perform early, contextual technology evaluation and continuous technology scouting that can lead to more informed decisions on what parts of the system will benefit from SOA technologies [Lewis 2005].
- Architecture tradeoff analysis—It is well known that tradeoffs must be made in systems, because the accomplishment of a certain quality is often at the expense of another quality. Common examples of tradeoffs are performance versus modifiability, availability versus safety, security versus performance, and interoperability versus cost [Bass 2003]. The use of service orientation in systems that have stringent runtime system-quality requirements will require architectural tradeoffs at the expense of loose coupling and flexibility. An architecture analysis and evaluation method that is guided by business drivers and performed via scenarios can help an architect make better, early, and informed decisions about the usage of SOA technologies.
 An overarching pattern is an architectural pattern that applies to an entire system. SOA is often an overarching pattern that can apply to an entire system. In other instances, SOA applies only to part of the system and therefore would not be considered an overarching pattern in that context.
[Bass 2003] Bass, L.; Clement, P.; and Kazman, R. Software Architecture in Practice.
[Lewis 2005] G. Lewis and L. Wrage. A Process for Context-Based Technology Evaluation.
[Lewis 2008] Lewis, G.; Morris, E.; Smith, D.; and Simanta, S. SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment.
– Phil Bianco, Paulo Merson, SEI