SecConcept - SOA Patterns Service-Oriented Systems

[toc]

---

SOA Patterns

SOA, Service-Oriented Systems

1. Business Services: core buniess operation
   • Coarse-grained services that define core business operations.
   • Represented through XML, Business Process Execution Language (BPEL), and others.
2. Enterprise Services:
   • Implement the functionality defined by business services.
   • Mainly rely on application services and infrastructure services to fulfill business requests.
3. Application Services: core application function for the server
   • Fine-grained services that are confined to a specific application context.
   • A dedicated user interface can directly invoke the services.
4. Infrastructure Services:
   • Implement non-functional tasks such as authentication, auditing, security, and logging.
   • Can be invoked from either application services or enterprise services.

---

Microservices

Microservices have limited service taxonomy.

They consist of two service types, as depicted below.

Functional Services:

• Support specific business operations.
• Accessing of services is done externally and these services are not shared with other services.

infrastructure services:

• implement tasks such as auditing, security, and logging.
• In this, the services are not unveiled to the outside world.

---

Microservices vs SOA

• monolith:
  • similar to a big container wherein all the software components of an application are assembled together and tightly packaged.
  • single point of failure, no scalability,
  • slow development
• SOA Service-oriented architecture: a collection of services.
  • coarse-grained
  • These services communicate with each other.
  • The communication can involve either simple data passing or two or more services coordinating some activity.
  • Some means of connecting services to each other is needed.
  • 4 feature 4 servers.
• Microservices: task level
  • fine-grained
  • an architectural style that structures an application as a collection of small autonomous services modeled around a business domain.

SOA	MSA
Follows “share-as-much-as-possible” architecture approach	Follows “share-as-little-as-possible” architecture approach
Importance is on business functionality reuse	Importance is on the concept of “bounded context”
They have common governance and standards	They focus on people, collaboration and freedom of other options
Uses Enterprise Service bus (ESB) for communication	Simple messaging system
They support multiple message protocols	They use lightweight protocols such as HTTP/REST etc.
Multi-threaded with more overheads to handle I/O	Single-threaded usually with the use of Event Loop features for non-locking I/O handling
Maximizes application service reusability	Focuses on decoupling
Traditional Relational Databases are more often used	Modern Relational Databases are more often used
A systematic change requires modifying the monolith	A systematic change is to create a new service
DevOps / Continuous Delivery is becoming popular, but not yet mainstream	Strong focus on DevOps / Continuous Delivery

---

Major Differences Between Microservices and SOA

1. Service Granularity 间隔尺寸 :
   • microservices: Service components are generally single-purpose services that do one thing really, really well.
   • SOA, service components can range in size anywhere from small application services to very large enterprise services.
   • In fact, it is common to have a service component within SOA represented by a large product or even a subsystem.

1. Component Sharing:
   • SOA
     • Component sharing is one of the core tenets of SOA.
     • component sharing is what enterprise services are all about.
     • SOA enhances component sharing,
   • MSA tries to minimize on sharing through “bounded context”
     • A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies.
   • As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than MSA.

1. Middleware vs API layer:
   • microservices architecture pattern has API layer,
     • API layer between services and service consumers.
   • SOA has a messaging middleware component.
     • The messaging middleware in SOA offers a host of additional capabilities not found in MSA,
     • including mediation and routing, message enhancement, message, and protocol transformation.

1. Remote services:
   • SOA architectures rely on messaging (AMQP, MSMQ) and SOAP as primary remote access protocols.
   • Most MSAs rely on two protocols – REST and simple messaging (JMS, MSMQ),
     • the protocol found in MSA is usually homogeneous.
2. Heterogeneous interoperability:
   • SOA promotes the propagation of multiple heterogeneous protocols through its messaging middleware component.
   • MSA attempts to simplify the architecture pattern by reducing the number of choices for integration.
   • to integrate several systems using different protocols in a heterogeneous environment, consider SOA.
   • If services could be exposed and accessed through the same remote access protocol, MSA is a better option.
   • 

depends on the purpose of the application you are building.

• SOA
  • better suited for large and complex business application environments that require integration with many heterogeneous applications;
  • smaller applications are not a good fit for SOA as they don’t need a messaging middleware component.
• Microservices
  • better suited for smaller and well-partitioned, web-based systems
  • microservices give greater control as a developer.
  • break server/feature in to task level services

example: shopping cart

Microservices:

• DISPLAY THE PIC > for many application (size, license…)

---

ESB Enterprise Service Bus

---

SOA Registry

.