Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Mohamed Ismail Mostafa, profile picture
Uploaded byMohamed Ismail Mostafa
PDF, PPTX604 views

SOA and DevOps v0.1

This document provides an overview of Service-Oriented Architecture (SOA) and introduces how DevOps relates to architecture. It begins with defining the strategic goals and benefits of SOA, including reducing IT burden, increasing agility and ROI. Key SOA concepts are explained such as architectural characteristics, basic building components like services, fundamental service patterns, and orientation principles. Examples of building mediums for SOA like components, web services and REST services are also outlined. The document then begins to discuss microservices architecture and how DevOps practices can complement and support SOA.

Engineering◦
Download as PDF, PPTX
SOA and DevOps Contradictory or Complementary Mohamed Ismail Mostafa SOA Certified Architect & Trainer DevOps Transformation Lead mmostafa@devopsi.io Devopsi.io V 0.1
Disclaimer What we will discuss today is being taught in 2 courses, each is 5 days So bear with me J Service-Oriented Solution Logic
Agenda 1. Service Oriented Architecture (SOA) 2. Intro to Microservices Architecture 3. DevOps and Architecture Service-Oriented Solution Logic
Section 1/3 Service Oriented Architecture (SOA)
Service Oriented Architecture Agenda • SOA Strategic Goals and Benefits • Service-Oriented Architectural Characteristics • SOA basic building component: Service • Fundamental Service Patterns • Service Orientation Principles • Building Mediums of SOA • Service Design Patterns • Enterprise Service Bus Patterns • Orchestration Patterns
SOA Strategic Goals and Benefits
SOA Strategic Goals and Benefits • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Strategic Goals and Benefits… • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Strategic Goals and Benefits… • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Strategic Goals and Benefits… • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Strategic Goals and Benefits… • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Strategic Goals and Benefits… • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Strategic Goals and Benefits… • Reduce IT burden • Increase organizational agility • Increase ROI • Increase vendor diversification options • Increase federation • Increase intrinsic interoperability. • Increase business and technology alignment
SOA Architecture Characteristics
SOA Architecture Characteristics • Business Driven • Vendor-neutral • Enterprise-centric • Composition-centric
SOA Architecture Characteristics… • Business Driven • Vendor-neutral • Enterprise-centric • Composition-centric
SOA Architecture Characteristics… • Business Driven • Vendor-neutral • Enterprise-centric • Composition-centric
SOA Architecture Characteristics… • Business Driven • Vendor-neutral • Enterprise-centric • Composition-centric
SOA basic building component: Service
SOA basic building component: Service Three individuals, each capable of providing a distinct service
SOA basic building component: Service Services are Collections of Capabilities
SOA basic building component: Service Service contractService logic Encapsulated resources
Fundamental Service Patterns
Fundamental Service Patterns • Service • Service composition • Functional Context [Context Boundary] • Agnostic/Non-Agnostic • Service Layers Modeling
Fundamental Service Patterns • Service • Service composition • Functional Context [Context Boundary] • Agnostic/Non-Agnostic • Service Layers Modeling
Fundamental Service Patterns • Service • Service composition • Functional Context [Context Boundary] • Agnostic/Non-Agnostic • Service Layers Modeling
Fundamental Service Patterns • Service • Service composition • Functional Context • Agnostic/Non-Agnostic • Service Layers Modeling
Fundamental Service Patterns • Service • Service composition • Functional Context • Agnostic/Non-Agnostic • Service Layers Modeling
Service Orientation Principles
Service Orientation Principles • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Services within the same service inventory are in compliance with the same contract design standards.
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Service contracts only contain essential information and information about services is limited to what is published in service contracts. Service Abstraction also plays a significant role in the positioning and design of service compositions.
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Services contain and express agnostic logic (agnostic functional Context) and can be positioned as reusable enterprise resources/assets.
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Services exercise a high level of control over their underlying runtime execution environment fostering design characteristics that increase a service’s reliability and behavioral predictability. Does that remind you of something!!
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Services minimize resource consumption by deferring the management of state information when necessary. Surrounding technology architecture to provide state management delegation and state deferral options
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted.
Service Oriented Principles… • Standardized service contract • Service loose coupling • Service abstraction • Service reusability • Service autonomy • Service statelessness • Service discoverability • Service composability Services are effective composition participants, regardless of the size and complexity of the composition.
Building Mediums of SOA
Building Mediums of SOA • Components • Web Services • REST services
Building Mediums of SOA • Components • Web Services • REST services
Web Services • Architecture: • Service Contract • WSDL definition • XML definition • WS-Policy definition • Message Processing Logic • Core service logic • Discovery • Design-time discovery • Run-time discovery • Industry Standards: • SOAP • WSDL • UDDI • XML Schema • WS-* • Coordination • WS-Coordination • Transaction • WS-AtomicTransaction • WS-BusinessActivity • Orchestration • WS-BPEL • Addressing • WS-Addressing • Reliable Messaging • WS-ReliableMessaging • Policies • WS-Policy • Security • WS-Security
Building Mediums of SOA • Components • Web Services • REST services
Rest Services
Rest Services • Service Contract • Uniform contract • HTTP Methods • Architecture • Resources • HTTP Headers • Caching • Redirect • Industry Standards • XML • JSON • YAML • …
Rest Services… • RESTful Web Services Maturity Model: • Richardson Maturity Model https://martinfowler.com/articles/richardsonMaturityModel.htmlhttps://restfulapi.net/richardson-maturity-model/
REST Maturity Level 0 • RPC over HTTP https://martinfowler.com/articles/richardsonMaturityModel.html
REST Maturity Level 0… • RPC over HTTP https://martinfowler.com/articles/richardsonMaturityModel.html POST /appointmentService HTTP/1.1 [various other headers] <openSlotRequest date = "2010-01-04" doctor = "mjones"/> HTTP/1.1 200 OK [various headers] <openSlotList> <slot start = "1400" end = "1450"> <doctor id = "mjones"/> </slot> <slot start = "1600" end = "1650"> <doctor id = "mjones"/> </slot> </openSlotList>
REST Maturity Level 0… • RPC over HTTP https://martinfowler.com/articles/richardsonMaturityModel.html POST /appointmentService HTTP/1.1 [various other headers] <appointmentRequest> <slot doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> </appointmentRequest> HTTP/1.1 200 OK [various headers] <appointment> <slot doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> </appointment>
REST Maturity Level 0… • RPC over HTTP https://martinfowler.com/articles/richardsonMaturityModel.html POST /appointmentService HTTP/1.1 [various other headers] <appointmentRequest> <slot doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> </appointmentRequest> HTTP/1.1 200 OK [various headers] <appointmentRequestFailure> <slot doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> <reason>Slot not available</reason> </appointmentRequestFailure>
REST Maturity Level 1 • Resources https://martinfowler.com/articles/richardsonMaturityModel.html
REST Maturity Level 1.. • Resources https://martinfowler.com/articles/richardsonMaturityModel.html POST /doctors/mjones HTTP/1.1 [various other headers] <openSlotRequest date = "2010-01-04"/> HTTP/1.1 200 OK [various headers] <openSlotList> <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/> <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/> </openSlotList>
REST Maturity Level 1.. • Resources https://martinfowler.com/articles/richardsonMaturityModel.html POST /slots/1234 HTTP/1.1 [various other headers] <appointmentRequest> <patient id = "jsmith"/> </appointmentRequest> HTTP/1.1 200 OK [various headers] <appointment> <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> </appointment> http://royalhope.nhs.uk/slots/1234/appointment
REST Maturity Level 2 • HTTP Verbs https://martinfowler.com/articles/richardsonMaturityModel.html Use HTTP verbs as closely as possible to how they are used in HTTP itself
HTTP Verbs How Many HTTP verbs you know?
HTTP Verbs / Request Methods https://martinfowler.com/articles/richardsonMaturityModel.html 1. GET • The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect 2. HEAD • The HEAD method asks for a response identical to that of a GET request, but without the response body 3. POST • The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI 4. PUT • The PUT method requests that the enclosed entity be stored under the supplied URI 5. DELETE • The DELETE method deletes the specified resource 6. TRACE • The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers. 7. OPTIONS • The OPTIONS method returns the HTTP methods that the server supports for the specified URL 8. CONNECT • The CONNECT method converts the request connection to a transparent TCP/IP tunnel 9. PATCH • The PATCH method applies partial modifications to a resource
HTTP Verbs/ Request Methods Post • The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI • The PUT method requests that the enclosed entity be stored under the supplied URI • Create • Create Or Update Put
REST Maturity Level 2… • HTTP Verbs and Codes https://martinfowler.com/articles/richardsonMaturityModel.html GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1 Host: royalhope.nhs.uk HTTP/1.1 200 OK [various headers] <openSlotList> <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/> <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/> </openSlotList>
REST Maturity Level 2… • HTTP Verbs and Codes https://martinfowler.com/articles/richardsonMaturityModel.html POST /slots/1234 HTTP/1.1 [various other headers] <appointmentRequest> <patient id = "jsmith"/> </appointmentRequest> HTTP/1.1 201 Created Location: slots/1234/appointment [various headers] <appointment> <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> </appointment>
REST Maturity Level 2… • HTTP Verbs and Codes https://martinfowler.com/articles/richardsonMaturityModel.html POST /slots/1234 HTTP/1.1 [various other headers] <appointmentRequest> <patient id = "jsmith"/> </appointmentRequest> HTTP/1.1 409 Conflict [various headers] <openSlotList> <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/> </openSlotList>
REST Maturity Level 3 • Hypermedia Controls https://martinfowler.com/articles/richardsonMaturityModel.html • Referred to under the ugly acronym of HATEOAS (Hypertext As The Engine Of Application State) • It addresses the question of how to get from a list open slots to knowing what to do to book an appointment
REST Maturity Level 3 • Hypermedia Controls https://martinfowler.com/articles/richardsonMaturityModel.html GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1 Host: royalhope.nhs.uk HTTP/1.1 200 OK [various headers] <openSlotList> <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"> <link rel = "/linkrels/slot/book" uri = "/slots/1234"/> </slot> <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"> <link rel = "/linkrels/slot/book" uri = "/slots/5678"/> </slot> </openSlotList>
REST Maturity Level 3 • Hypermedia Controls https://martinfowler.com/articles/richardsonMaturityModel.html POST /slots/1234 HTTP/1.1 [various other headers] <appointmentRequest> <patient id = "jsmith"/> </appointmentRequest> HTTP/1.1 201 Created Location: http://royalhope.nhs.uk/slots/1234/appointment [various headers] <appointment> <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/> <patient id = "jsmith"/> <link rel = "/linkrels/appointment/cancel" uri = "/slots/1234/appointment"/> <link rel = "/linkrels/appointment/addTest" uri = "/slots/1234/appointment/tests"/> <link rel = "self" uri = "/slots/1234/appointment"/> <link rel = "/linkrels/appointment/changeTime" uri = "/doctors/mjones/slots?date=20100104&status=open"/> <link rel = "/linkrels/appointment/updateContactInfo" uri = "/patients/jsmith/contactInfo"/> <link rel = "/linkrels/help" uri = "/help/appointment"/> </appointment>
Richardson MM relationship to common design techniques Level 1 Tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources Level 2 Introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation Level 3 Introduces discoverability, providing a way of making a protocol more self-documenting
SOA Design & Architecture
Agenda • Service Design Patterns • Enterprise Service Bus Patterns • Orchestration Patterns
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper How can a service express its capabilities independently of its implementation? The service contract is physically decoupled from its implementation https://patterns.arcitura.com/soa-patterns/design_patterns/decoupled_contract
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper How can direct consumer-to-implementation coupling be avoided? Access to service logic is limited to the service contract, forcing consumers to avoid implementation coupling https://patterns.arcitura.com/soa-patterns/design_patterns/contract_centralization
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper https://patterns.arcitura.com/soa-patterns/design_patterns/logic_centralization How can the misuse of redundant service logic be avoided? Access to reusable functionality is limited to official agnostic services.
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper https://patterns.arcitura.com/soa-patterns/design_patterns/service_facade How can a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently? A service façade component is used to abstract a part of the service architecture with negative coupling potential.
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper https://patterns.arcitura.com/soa-patterns/design_patterns/concurrent_contracts How can a service facilitate multi-consumer coupling requirements and abstraction concerns at the same time? Multiple contracts can be created for a single service, each targeted at a specific type of consumer
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper https://patterns.arcitura.com/soa-patterns/design_patterns/redundant_implementation How can the reliability and availability of a service be increased? Reusable services can be deployed via redundant implementations or with failover support.
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper https://patterns.arcitura.com/soa-patterns/design_patterns/service_data_replication How can service autonomy be preserved when services require access to shared data sources? Services can have their own dedicated databases with replication to shared data sources
Service Design Patterns • Decoupled Contract • Contract Centralization • Official Endpoint • Service Facade • Concurrent Contracts • Redundant Implementation • Service Data Replication • Legacy Wrapper How can wrapper services with non-standard contracts be prevented from spreading indirect consumer-to-implementation coupling? The non-standard wrapper service can be replaced by or further wrapped with a standardized service contract that extracts, encapsulates, and possibly eliminates legacy technical details from the contract StranglerFigApplication : https://martinfowler.com/bliki/StranglerFigApplication.html https://patterns.arcitura.com/soa-patterns/design_patterns/legacy_wrapper
Enterprise Service Bus Patterns
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/compound_patterns/enterprise_service_bus An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging How can services interact with programs that communicate with different data formats? Intermediary data format transformation logic needs to be introduced in order to dynamically translate one data format into another. https://patterns.arcitura.com/soa-patterns/design_patterns/data_format_transformation
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/data_model_transformation How can services interact with programs that communicate with different data Models? A data transformation technology can be incorporated to convert data between disparate schema structures.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/protocol_bridging How can a service exchange data with consumers that use different communication protocols? Bridging logic is introduced to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/intermediate_routing How can dynamic runtime factors affect the path of a message? Message paths can be dynamically determined through the use of intermediary routing logic.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/asynchronous_queuing How can a service and its consumers accommodate isolated failures and avoid unnecessarily locking resources? A service can exchange messages with its consumers via an intermediary buffer, allowing service and consumers to process messages independently by remaining temporally decoupled.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/reliable_messaging How can services communicate reliably when implemented in an unreliable environment? An intermediate reliability mechanism is introduced into the inventory architecture, ensuring that message delivery is guaranteed.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/policy_centralization How can policies be normalized and consistently enforced across multiple services? Global or domain-specific policies can be isolated and applied to multiple services
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/rules_centralization How can business rules be abstracted and centrally governed? The storage and management of business rules are positioned within a dedicated architectural extension from where they can be centrally accessed and maintained.
Enterprise Service Bus Patterns • Base Patterns • Service Broker • Data Format Transformation • Data Model Transformation • Protocol Bridging • Intermediate Routing • Asynchronous Queuing • Extended Patterns • Reliable Messaging • Policy Centralization • Rules Centralization • Event-Driven Messaging https://patterns.arcitura.com/soa-patterns/design_patterns/event_driven_messaging How can service consumers be automatically notified of runtime service events? The consumer establishes itself as a subscriber of the service. The service, in turn, automatically issues notifications of relevant events to this and any of its subscribers.
Orchestration Patterns
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation An orchestration platform is dedicated to the effective maintenance and execution of parent business process logic. Modern-day orchestration environments are especially expected to support sophisticated and complex service composition logic that can result in long-running runtime activities
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation https://patterns.arcitura.com/soa-patterns/design_patterns/process_abstraction How can non-agnostic process logic be separated and governed independently? A dedicated parent business process service layer is established to support governance independence and the positioning of task services as potential enterprise resources.
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation https://patterns.arcitura.com/soa-patterns/design_patterns/process_centralization How can abstracted business process logic be centrally governed? Logic representing numerous business processes can be deployed and governed from a central location.
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation https://patterns.arcitura.com/soa-patterns/design_patterns/state_repository How can service state data be persisted for extended periods without consuming service runtime resources? State data can be temporarily written to and then later retrieved from a dedicated state repository.
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation https://patterns.arcitura.com/soa-patterns/design_patterns/compensating_service_transaction How can composition runtime exceptions be consistently accommodated without requiring services to lock resources? Compensating routines are introduced, allowing runtime exceptions to be resolved with the opportunity for reduced resource locking and memory consumption
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation https://patterns.arcitura.com/soa-patterns/design_patterns/atomic_service_transaction How can a transaction with rollback capability be propagated across messaging-based services? Runtime service activities can be wrapped in a transaction with rollback feature that resets all actions and changes if the parent business task cannot be successfully completed.
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation https://patterns.arcitura.com/soa-patterns/design_patterns/rules_centralization How can business rules be abstracted and centrally governed? he storage and management of business rules are positioned within a dedicated architectural extension from where they can be centrally accessed and maintained.
Orchestration Patterns • Base Patterns • Process Abstraction • Process Centralization • State Repository • Compensating Service Transaction • Extended Patterns • Atomic Service Transaction • Rules Centralization • Data Model Transformation How can services interact with programs that communicate with different data formats A data transformation technology can be incorporated to convert data between disparate schema structures https://patterns.arcitura.com/soa-patterns/design_patterns/data_model_transformation
Section 2/3 Intro to Microservices Architecture
Intro to Microservices Architecture
https://medium.com/@rmzoni/soa-vs-microservices- 349c9f1f5b41 SOA Vs Microservices Architecture Style
SOA Vs Microservices Architecture Style
• Maximizes application reusability • A systematic change requires modifying the monolith (Legacy Systems) • DevOps and Continuous Delivery are not mainstream • Focused on business functionality reuse • For communication it uses Enterprise Service Bus — Monolith Structure • Supports multiple message protocols • Use of a common platform for all services deployed to it • Use of containers (such as Docker) is less popular • SOA services share the data storage • Common governance and standards • Decoupling • A systematic change is to create a new service • DevOps and Continuous Delivery as core value • More importance on the concept of “bounded context” — Products over Projects • For communication uses less elaborate and simple messaging systems • Uses lightweight protocols such as HTTP, REST, and Ligthweight Messaging • Application Servers are not really used, it’s common to use cloud platforms • Containers work very well with microservices • Each microservice can have an independent data storage • Decentralized governance, with greater focus on teams collaboration and freedom of choice • SOA Vs Microservices Architecture Style