service oriented architecture & beyond

Service Oriented Architecture & BeyondImesh GunaratneSenior Technical Lead, WSO2

Agenda

▪ An Introduction to SOA▪ SOA Reference Architecture

▫ Horizontal Layers▫ Vertical Layers

▪ SOA Principles▪ Enterprise Application Integration (EAI)▪ Service Development▪ Microservices

An Introduction to SOAThe concepts and evolution

1

Service Oriented Architecture (SOA)

An architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.

https://en.wikipedia.org/wiki/Service-oriented_architecture

Evolution of SOA

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.html

SOA Reference ArchitectureA reference architecture for designing enterprise solutions

2

SOA Reference Architecture (RA)

https://www.opengroup.org/soa/source-book/soa_refarch/layers.htm

SOA RA Horizontal Layers▪ Consumer Interfaces

▫ End user applications

▪ Business Processes▫ Choreographed services representing business use-

cases

▪ Services▫ Business services

▪ Service Components▫ Components that build services

▪ Operational Systems▫ Data models, enterprise data repository, technological

platformshttps://en.wikipedia.org/wiki/Service-oriented_architecture

SOA RA Vertical Layers▪ Integration

▫ Platform integration, data integration, service integration, application integration

▪ Quality of Service (QoS)▫ Security, availability, performance etc. constitute the

quality of service parameters

▪ Information▫ Provides business information

▪ Governance▫ Governing the entire SOA strategy


SOA PrinciplesBest practices to be followed

3

SOA Principles [1]▪ Standardized service contract

▫ Services adhere to a communications agreement, as defined collectively by one or more service-description documents.

▪ Service loose coupling

▫ Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.

▪ Service abstraction:

▫ Beyond descriptions in the service contract, services hide logic from the outside world.


SOA Principles [2]▪ Service reusability

▫ Logic is divided into services with the intention of promoting reuse.

▪ Service autonomy (govern itself)

▫ Services have control over the logic they encapsulate, from a Design-time and a Run-time perspective.

▪ Service statelessness

▫ Services minimize resource consumption by deferring the management of state information when necessary.


SOA Principles [3]▪ Service discoverability

▫ Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.

▪ Service composability

▫ Services are effective composition participants, regardless of the size and complexity of the composition.

▪ Service granularity

▫ A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.


SOA Principles [4]▪ Service normalization

▫ Services are decomposed or consolidated to a level of normal form to minimize redundancy (performance optimization, access, and aggregation).

▪ Service Location transparency▫ This refers to the ability of a service consumer to

invoke a service regardless of its actual location in the network.


Enterprise Application Integration (EAI)Integration patterns

4

Point to Point IntegrationInventory

SCM

Billing

CRM ERP

HR

Using an Enterprise Service Bus

Inventory

SCMBilling

CRM ERP

HR

Enterprise Service Bus (ESB)

▪ Protocol switching▪ Message

transformation▪ Content/header

based routing▪ Failover handling▪ Load balancing▪ Request throttling▪ Response caching▪ Security▪ Logging & monitoring▪ Enterprise

Integration Patterns (EAI)

Integration Pipeline

http://www.enterpriseintegrationpatterns.com/patterns/messaging/

Sample Integrations

http://www.ossmentor.com/2014/11/camel-and-enterprise-integration.html

Enterprise Integration Patterns (EAI)

http://www.enterpriseintegrationpatterns.com/patterns/messaging/

Message Oriented Middleware (MOM)

https://docs.oracle.com/cd/E19316-01/820-6424/aerar/index.html

MOM is software or hardware infrastructure supporting the sending and receiving of messages between distributed systems - Wikipedia

Service DevelopmentService types & frameworks

5

Elements of SOA


Service Types▪ SOAP Web Services

▫ Transport: HTTP/HTTPS▫ Content type: XML▫ Service definition: WSDL▫ Message payload: SOAP

Header + SOAP Body▫ Service method: SOAP

Method▫ Security: WS-Security

(BasicAuth, Signature, IDAssertion, LTPA), SAML

▫ Java spec: JAX-WS

▪ RESTful Web Services▫ Transport: HTTP/HTTPS▫ Content type: Mostly JSON ▫ Service definition: WADL▫ Message payload: JSON

message▫ Service method: URI + HTTP

Method▫ Security: OAuth, BasicAuth▫ Java spec: JAX-RS

Frameworks▪ SOAP Web Services

▫ Apache Axis (Java, C++)▫ Apache Axis2 (Java)▫ Apache CXF (Java)▫ Java EE: GlassFish, JBoss

(Java)▫ .NET Framework (C#, VB.

NET)▫ Spring Web Services (Java)

▪ RESTful Web Services▫ Apache CXF (Java)▫ Jersey (Java)▫ Java EE: GlassFish, JBoss

(Java)▫ .NET Framework (C#, VB.

NET)▫ Restbed (C, C++)

MicroservicesDesigning an application as a collection of micro services

6

Microservices

An approach for developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

http://martinfowler.com/articles/microservices.html

Monoliths Vs Microservices


Deployment Model


Decentralized Data Management


Traditional SOA Vs Microservices [1]


Traditional SOA Microservices

Messaging Type Synchronous: wait to connect

Asynchronous: publish and subscribe

Programming Style Imperative model Reactive programming (event/callback driven)

Lines of Code per Service

Hundreds/Thousands Hundreds or fewer

State Stateful Stateless

Databases Large RDBMS NoSQL + RDBMS

Traditional SOA Vs Microservices [2]

Traditional SOA Microservices

Code Type Procedural Functional

Means of Evolution Each service evolves and becomes larger

Each small service is immutable and can be abandoned or ignored

Means of systemic change

Modify the monolith Create a new service

Means of scaling Optimize the monolith Scale individual services

System-level awareness Less aware and event driven

More aware and event driven


THANKS!

Any questions?

service oriented architecture & beyond

Technology