SOA Patterns

SOA Patterns
• Service-Oriented Architecture (SOA) patterns are
recurring solutions to common architectural problems
encountered when designing and implementing service-
oriented systems.
• These patterns provide guidance on how to structure
services, handle communication between services,
manage data, and ensure scalability, reliability, and
maintainability within a SOA environment.
• Service Decomposition: Breaking down a monolithic application into smaller,
more manageable services based on business functionality.
• Service Abstraction: Hiding the implementation details of a service to provide a
simplified interface for service consumers. This allows for changes to the service
implementation without impacting consumers.
• Service Loose Coupling: Minimizing dependencies between services to allow
for easier maintenance, scalability, and flexibility. This is often achieved through
the use of standards-based interfaces such as REST or SOAP.
• Service Composition: Combining multiple services to fulfill a particular
business requirement. This can be achieved through orchestration (centralized
control) or choreography (distributed control) of service interactions.
• Service Orchestration: Centralized coordination of service
interactions to achieve a specific business process. This involves a
central controller (e.g., a workflow engine) that coordinates the
execution of services.
• Service Choreography: Decentralized coordination of service
interactions where each service is responsible for initiating its own
interactions based on predefined rules or events.
• Service Discovery: Mechanisms for dynamically locating and binding
to services at runtime. This allows services to be added, removed, or
replaced without requiring changes to service consumers.
Service Registry: A centralized repository where services publish their
metadata (e.g., location, interface, version) to enable discovery by other
services and consumers.
Service Gateway: A centralized entry point for accessing multiple
services. The gateway handles tasks such as authentication,
authorization, routing, and protocol translation.
Event-Driven Architecture (EDA): Architectural style where services
communicate and react to events. This pattern enables loose coupling
and scalability by allowing services to asynchronously react to changes
in the system.
Message-Oriented Middleware (MOM): Middleware
infrastructure that facilitates communication between
distributed components using messages. MOM provides
features like message queuing, publish/subscribe, and
guaranteed delivery.
Data Replication and Caching: Techniques for improving
performance and scalability by replicating and caching data
across multiple services or nodes.
Transaction Management: Coordinating distributed
transactions across multiple services to ensure data consistency
and integrity.
Security Patterns: Patterns for implementing security
mechanisms such as authentication, authorization, encryption,
and auditing in a service-oriented environment.
Monitoring and Management: Patterns for monitoring the
health, performance, and usage of services, as well as managing
service deployments, scaling, and configuration.
 Service Layer in Enterprise
Applications
The Service Layer is a design pattern that provides a common
interface for application logic, separating it from user interface
and data access code.
Purpose:
• Organizes business logic into reusable services.
• Decouples business logic from other layers.
• Makes the application easier to maintain, test, and extend.
• Use Case: Instead of writing business logic in controllers or UI code, it’s
placed in the Service Layer, making code cleaner and more modular.
 Enterprise Application
Integration
• EAI Patterns are design solutions used to integrate different enterprise
applications, services, and systems so they can communicate and work
together smoothly. These patterns help handle data transformation,
communication, and process coordination across heterogeneous
systems.
Importance:
• Ensures separation of concerns (e.g., UI, business logic, data).
• Promotes code reuse and modularity.
• Makes systems easier to maintain and upgrade.
• Helps teams follow standard best practices, improving collaboration.
• Supports integration and flexibility in complex enterprise environments.
• Common EAI Patterns:
• Message Translator
• Message Broker
• Message-Oriented Middleware (MOM)
Message Translator
• Purpose: Converts messages from one format to another. Solves the
data format mismatch between systems.
• Ensures smooth communication by translating field names, structures,
or units.
• Example: Translates an XML message into JSON before passing it to a
system that only accepts JSON.
• Example: System A sends a message with customerName, while
System B expects name. A Message Translator modifies the message to
match the expected format before sending it to System B.
Message Broker is a middleware component that receives messages from one
system, processes or transforms them, and then routes them to the appropriate
destination system.
Role:
• Performs message routing, transformation, and validation.
• Enables communication between systems with different data formats or
protocols.
• Supports centralized integration logic.
• Scenario: In a retail company, an order management system sends order data. The Message
Broker transforms it into the required format and sends it to the inventory and shipping
systems—ensuring smooth communication even if each system uses different data structures.
Message-Oriented Middleware (MOM) is a software layer that allows
different systems or applications to communicate by sending and
receiving messages asynchronously. It acts as a message-handling
system between distributed components.
How it facilitates integration:
• Enables loose coupling between systems.
• Allows systems to communicate without being online at the same time.
• Supports reliable message delivery even if the receiving system is temporarily
unavailable.
• Common examples include Apache ActiveMQ, RabbitMQ, and IBM MQ.
 Pattern Notation
• Pattern notation is a standardized way of representing
design patterns to facilitate communication and
understanding among software developers and architects.
• It helps in documenting the structure, behavior, and
interactions of design patterns in a clear and concise
manner.
• There are several notations used for representing design
patterns
[Link] (Unified Modeling Language): UML is a standard notation for
modeling software systems, including design patterns. UML diagrams
such as class diagrams, sequence diagrams, and collaboration
diagrams can be used to represent the structure and behavior of
design patterns.
[Link] Diagrams: Some design patterns have their own specialized
diagrams for representing their structure and relationships. For
example, the Gang of Four (GoF) design patterns are often represented
using class diagrams with specific annotations to highlight the roles,
responsibilities, and collaborations of classes within the pattern.
3. Textual Notation: Design patterns can also be documented using
textual descriptions that outline the problem, solution, consequences,
and implementation considerations of the pattern. This approach is
often used in conjunction with diagrams to provide a comprehensive
understanding of the pattern.
4. Pattern Languages: A pattern language is a structured collection
of design patterns that are related to each other and can be used
together to solve complex problems. Pattern languages often provide
a consistent notation and vocabulary for describing patterns and their
relationships.
5. Architectural Views: Some design patterns are best
represented using architectural views, such as component
diagrams, deployment diagrams, and package diagrams, to
illustrate how the pattern applies at a system-wide level.
6. Formal Specification Languages: In some cases, formal
specification languages such as Z, Alloy, or TLA+ may be used to
provide a rigorous mathematical description of design patterns,
particularly for complex or critical systems.
MODULE 5
 Service Identification Patterns
• Service identification patterns are used in Service-
Oriented Architecture (SOA) to identify and define
services based on various criteria such as business
functionality, data, and process boundaries.
• These patterns help in decomposing a monolithic system
into smaller, more manageable services that can be
independently developed, deployed, and maintained.
 Service Identification Patterns
• Functional Decomposition: Services are identified based on discrete business
functions or capabilities. This pattern involves breaking down a monolithic
system into smaller services, each responsible for a specific business function or
use case.
• Domain-Driven Design (DDD): Services are identified based on domain
concepts and boundaries. DDD emphasizes modeling the domain of the problem
space and defining services aligned with domain entities, aggregates, and
bounded contexts.
• Entity Service: Services are identified based on domain entities. Each service is
responsible for managing the lifecycle and behavior of specific domain entities,
providing CRUD (Create, Read, Update, Delete) operations and related business
logic.
• Utility Service: Services are identified for providing common utility functions or
cross-cutting concerns such as authentication, authorization, logging, caching,
and validation. These services encapsulate reusable functionality used by other
services.
• Process-Driven Design: Services are identified based on business processes or
workflows. This pattern involves defining services to support end-to-end business
processes, with each service representing a step or activity in the process.
• Data-Driven Design: Services are identified based on data boundaries and
access patterns. This pattern involves defining services to manage specific
datasets or data domains, with each service encapsulating data access and
manipulation logic.
• Event-Driven Design: Services are identified based on
event sources and consumers. This pattern involves
defining services to publish and consume events
asynchronously, enabling loosely coupled communication
and reactive processing.
• Policy-Driven Design: Services are identified based on
business policies or rules. This pattern involves defining
services to enforce and execute business policies, such as
pricing rules, eligibility criteria, or compliance
regulations.
• Composite Service: Services are identified based on
composition requirements. This pattern involves defining
composite services that orchestrate interactions with multiple
underlying services to fulfill complex business requirements.
• Legacy Wrapper Service: Services are identified to
encapsulate and expose functionality from existing legacy
systems or applications. This pattern involves creating
services that act as facades or adapters to integrate legacy
functionality into a service-oriented architecture.
 Service definition patterns
• Service definition patterns refer to established
methodologies or approaches for defining the
characteristics, behaviors, and interfaces of services in
service-oriented architecture (SOA) or microservices
architecture. These patterns help in designing services
that are modular, scalable, reusable, and interoperable
[Link] Service: This pattern focuses on managing a specific business
entity (e.g., Customer, Product) and its associated data. It encapsulates
operations related to CRUD (Create, Read, Update, Delete) functionalities
for that entity.
[Link] Service: Utility services provide common functionalities or
operations that can be reused across multiple services. Examples include
logging, authentication, authorization, and error handling services.
[Link] Service: Task services encapsulate a specific business process or
workflow. They define a series of steps or actions that need to be
performed in order to accomplish a certain task or goal.
4. Process Service: Process services coordinate the interaction between
multiple services to execute a complex business process. They typically
orchestrate the invocation of various services in a predefined sequence to
achieve a specific outcome.
5. Proxy Service: Proxy services act as intermediaries between clients and
backend services. They provide a facade to clients, abstracting the complexity
of underlying services and enabling features like load balancing, caching, and
routing.
6. Event-Driven Service: Event-driven services react to events or messages
generated by other services or external systems. They subscribe to specific
event types and trigger appropriate actions in response to those events.
7. Composite Service: Composite services aggregate
functionalities from multiple underlying services to fulfill a
higher-level business requirement. They orchestrate the
invocation of constituent services and potentially perform
additional processing or transformation on their outputs.
8. Gateway Service: Gateway services serve as entry
points into a system or network, providing access control,
security enforcement, and protocol translation
functionalities. They often handle incoming requests from
external clients and route them to appropriate internal
services.
9. Adapter Service: Adapter services facilitate the
integration between services with different interfaces or
protocols. They convert data formats, translate message
payloads, and handle protocol mediation to enable
interoperability between heterogeneous systems.
10. Saga Service: Saga services manage long-running,
distributed transactions across multiple services in a
reliable and fault-tolerant manner. They implement
compensating actions to rollback changes in case of failures
during the execution of distributed transactions.