Service-Oriented Architecture (SOA): A Deep Dive
Introduction to Service-Oriented Architecture (SOA)
Originally authored by Raghu Kodali (Original Article)
Translated by Mario Alberto La Menza
Summary
Service-Oriented Architecture (SOA) represents the cutting edge of software engineering and is a frequent topic of discussion among development teams. This document introduces SOA, discusses the business needs it addresses, defines what a service-oriented architecture entails, and clarifies common myths and realities surrounding SOA.
What is SOA?
A service-oriented architecture (SOA) is an evolution of distributed computing, based on a request/response model for synchronous and asynchronous applications. Business logic and individual functions are modularized and presented as services for consuming applications/clients. Key to these services is their decoupled nature; the service interface is independent of its implementation. Application developers or system integrators can build applications by composing one or more services without needing to know the implementation details. For example, a service can be implemented in both .NET and J2EE, and the application consuming the service can be on a different platform and use different languages.
Key Features of SOA
- Platform-Independent Interface Description: SOA services have interfaces described in platform-independent XML documents. Web Service Description Language (WSDL) is the standard used.
- Formalized Communication: SOA services communicate with messages formally defined via XML Schema (XSD). Communication typically occurs in a heterogeneous environment with minimal knowledge of the service provider.
- Service Registry: SOA services are maintained in a registry that acts as a directory. Applications can discover and invoke services through this registry. Universal Description, Discovery, and Integration (UDDI) is the standard used.
- Quality of Service (QoS): Each SOA service has an associated QoS. Key QoS elements include security requirements (authentication, authorization), reliable messaging, and policies defining service invocation permissions.
Why SOA?
Enterprise IT infrastructure is often heterogeneous, comprising various operating systems, applications, and system software installed or created at different times under different paradigms. Rebuilding infrastructure from scratch is rarely feasible, as existing applications run key business processes. Businesses must respond quickly to change, leveraging existing investments to meet new requirements, support new interaction channels with customers, partners, and suppliers, and define an architecture that supports organic growth. SOA’s decoupled nature enables connecting new or existing services in a granular way to meet evolving needs, offering the option to deliver services through different channels and expose legacy applications as services, preserving prior investments.
As shown in Figure 1, a company using SOA can create a supply chain application using existing applications that expose their functionality via standard interfaces.
Figure 1. Supply Chain Application.
Figure 2 illustrates an example of a service architecture.
Figure 2. Example Service Architecture.
In Figure 2, service consumers invoke services by sending messages. These messages are typically processed and routed by a service bus to the appropriate service implementation. This architecture can include a business rules engine, enabling business rules to be implemented by one or more services. It also provides a management infrastructure for activities like auditing, billing, and registration. SOA provides agility in business processes, better handling of regulatory requirements (e.g., Sarbanes-Oxley), and isolation of service changes.
SOA Infrastructure
Running and managing SOA applications requires an SOA infrastructure, which is part of the SOA platform. This infrastructure must support relevant standards and runtime containers. A typical SOA infrastructure is shown in Figure 3. The following sections discuss the individual components.
Key Infrastructure Components
SOAP, WSDL, UDDI: These are core parts of the SOA infrastructure. WSDL describes services, UDDI registers and locates services, and SOAP acts as the transport layer. While SOAP is the default for web services, alternative technologies can be used. A consumer can locate a service in UDDI, retrieve its WSDL description, and invoke it using SOAP.
WS-I Basic Profile: Provided by the Web Services Interoperability Organization, this profile is crucial for interoperability testing. Service providers can use the WS-I Testing Tools to ensure interoperability across platforms and technologies.
J2EE and .NET: While J2EE and .NET are dominant platforms for SOA development, SOA is not limited to them. J2EE provides a framework for SOA participation and a mature infrastructure for scalability, reliability, availability, and performance. Specifications like JAXR (for interacting with UDDI registries) and JAX-RPC (for invoking remote services) facilitate portable web service development and interoperability with other platforms like .NET.
Quality of Services (QoS)
Mission-critical enterprise systems require advanced features like security, reliability, and transaction control, which basic web service specifications (WSDL, SOAP, UDDI) don’t address. These requirements are collectively known as Quality of Service (QoS). Organizations like W3C and OASIS are developing several QoS-related specifications.
Security: WS-Security addresses message security, focusing on credential exchange, message integrity, and confidentiality. It leverages existing security standards like SAML.
Reliability: In SOA, numerous documents are exchanged. Reliable messaging features like “once-and-only-once” delivery, guaranteed delivery, duplicate message elimination, and message acknowledgment are crucial. WS-Reliability and WS-ReliableMessaging address these concerns.
Policy: Service providers may require consumers to adhere to specific policies (e.g., Kerberos security clearance). WS-Policy standardizes policy communication.
Orchestration: SOA enables integration of data, applications, and components. WS-BPEL (Web Services Business Process Execution Language) is an OASIS specification for service orchestration, enabling business process creation using discrete services.
Administration: As services and business processes grow, a management infrastructure is essential. WS-Distributed Management (WSDM) specifies how services should be managed.
Other QoS attributes like coordination and transactions are addressed by WS-Coordination and WS-Transaction, respectively.
SOA vs. Web Services
There’s a common misconception that SOA and web services are synonymous. Gartner clarifies that web services refer to technology specifications, while SOA is a design principle. WSDL is a suitable interface standard for SOA, connecting the two concepts. SOA is an architectural pattern, while web services are implemented using a set of standards. Web services are one way to implement SOA, but not the only way. The benefit of using web services for SOA is platform neutrality and improved interoperability.
Benefits of SOA
SOA promotes reusability of existing resources and enables building applications on top of existing ones. It also insulates consumers from changes in service implementations. Services can be modified without affecting other services, and applications can be updated by replacing or supplementing existing services with new ones.
SOA provides flexibility in building applications and business processes within an agile infrastructure that encourages reuse and composition.
Defining SOA
SOA has various interpretations:
- A set of services exposed to customers, partners, or other parts of the organization.
- An architectural style requiring a service provider, a requestor, and a service description.
- A set of architectural principles, standards, and criteria for managing modularity, encapsulation, loose coupling, separation of concerns, reuse, and composition.
- A complete programming model with standards, tools, and technologies like web services.
SOA and Enterprise Architecture
Service-Oriented Architecture (SOA) provides a conceptual, technological, and process framework for efficient and cost-effective development, interconnection, and maintenance of enterprise applications and services. A robust Enterprise Architecture process addresses key questions:
- Does the current architecture support and add value to the organization?
- How should the architecture be modified to enhance organizational value?
- Can the current architecture support future organizational objectives?
Benefits of SOA
- Improved definition of development roles
- Clearer security delineation
- Easier testing
- Support for multiple client types
- Service composition
- Improved maintainability
- Promotes reuse
- Supports parallel development
- Scalability and high availability
- Interoperability