Service-Oriented Architectures aren't new. The underlying ideas of encapsulation, location independence, and programming-by-contract have been in use since it was apparent that dependencies between components (processes, objects, and the like) should be minimized. SOA is the most recent incarnation of these concepts in the current technologies.
Like other attempts to support software intercommunication on a large scale, SOA has its strengths and weaknesses. It must overcome obstacles of different technologies, communication protocols, and Quality-of-Service (QoS). If you're familiar with existing concepts of distributed enterprise computing (such as CORBA or DCOM), the elements composing SOA architecture have clear analogies to the older technologies.
In short, SOA is a means by which a distributed, heterogeneous grouping of hardware and software can exchange information to satisfy a business goal.
The principal motivation for SOA is to improve business agility—allowing organizations to adapt to changes as quickly as possible. To achieve this end, the enterprise must adopt policies that favor agility; for instance:
- Consolidating business logic and data. Components used by different groups for essentially the same purpose should be consolidated. Data should be consistent across groups and used in a consistent way.
- Leveraging existing systems. Systems the organization already uses to support business goals should be leveraged to satisfy the current business need.
To fulfill the business motivations, SOA espouses certain design principles:
- Services based. The fundamental element in SOA architecture is the "service." A service has certain responsibilities that can be used by the rest of the enterprise.
- Loosely coupled. The client (other services, end users, or external programs) leveraging the services need not be aware of how the services fulfill their responsibilities. Internal data structures, calls to other services, transaction management, and storage requirements should be hidden from the client.
- Location independent. The client need not be aware of where a service resides or executes.
- Interoperable. Services should be able to exchange data amongst each other.
- Combinable. Services should be designed and implemented such that they can be combined to create new services.
- Business aligned. Services exposed to end users or external programs should represent business process functionality. The inputs/outputs they expose should be expressible in terms of business-aligned needs.
The strategies used to implement SOA remain topics of discussion and research. However, certain ideas have been demonstrated as being useful across projects. In particular, services should exist on different levels of granularity, ranging from business process services to technical function services.
- Business process services that support end-user business processes or external program requirements.
- Business transaction services that support business process services, addressing the need to maintain transactional integrity.
- Business function services used by multiple business process or transaction services to fulfill a business need. These services encapsulate the smallest business-related functionality that can be used by other services.
- Technical function services that are independent of the business needs, but are necessary to satisfy functional and nonfunctional requirements.
In aligning SOA and Business Process Management (BPM), the capture and correlation of business events becomes an enabler of agility. Bringing trends to the awareness of decision makers or possessing the intelligence to act on a business trend improves the agility of the architecture and the agility of the business. Two business event-handling approaches are at the forefront of discussion:
- Business Event Management (BEM) captures events in real time. On matching a pattern, BEM notifies a decision-maker to act accordingly.
- Complex Event Processing (CEP) correlates events and automatically orchestrates a response. In general, to orchestrate a response that has business meaning without human intervention requires semantic knowledge of the domain.
