Service Oriented Architecture

Service Oriented Architecture

An Overview

What is a Service?

• In economics and marketing, a service is the non-material equivalent of a good.

• Service is said to be a process that creates benefits by facilitating either a change in a client or a change in client’s physical possessions.

Services and Systems

• A service is a program you interact with via message exchanges– Services are build to last– Encompass a business perspective– Stability and robustness are critical

• A system is a set of deployed services cooperating in a given task– Systems are built to change– Adapt to new services after deployment

Vertical Slicing

User Interface

Presentation layer

Business logic

Integration middleware

Data access layer

Data management

Business use cases

Technicallayers

Benefits of SOA

The primary benefits of a SOA include:

• REUSING SERVICES/BEHAVIORS

• AGILITY

• MONITORING

• EXTEND REACH

SOA Reference Architecture

Business Services

Frontend Services Process-centric Services Enterprise Services

Basic Services Intermediary Services

PIP

ELIN

E

Legacy Systems Databases 3rd Party

Enterprise Service Bus

Major Artefacts of a SOA

SOA

Frontend Service

BasicService

ServiceRepository

ServiceBus

ImplementationBusinesscontract

Technicalcontract

Businesslogic

Data

Service Types

Frontend Services

• Initiate all business processes and ultimately receive their results.

• Initiate and control all activity of the enterprise systems.

• A GUI such as Web application or rich client interacting directly with end users.

• A nightly batch program

• Long-living processes that invoke functionality periodically or as result of specific events

• It is possible that a frontend service delegates much of its responsibility for a business process to one or more services.

CustomerService B

Service Types

Basic Services

• Foundation of SOA

• Represent the basic element of the vertical domain

• A SOA strictly defines the ownership of data

• Can be sub-divided into – Data-centric services– Logic-centric services

CustomerService

- Interface A

- Interface BCustomer

DB

CustomerService A

CustomerDB

Service Types

Intermediary Services

• Can be project-specific

• Can be sub-divided into – Technology gateways– Adapters– Facades– Functionality-adding services

Service Types

Intermediary Services – Technology Gateways

Application frontend

Technology A

Tech gateway

Technology A

Technology B

Technology B

Basic service

Service Types

Intermediary Services – Facade

Applicationfrontend

Facade

Basicservice

Applicationfrontend

Applicationfrontend

Basicservice

Basicservice

Service Types

Process Centric Services

• Mostly project-specific

• Can encapsulate the knowledge of

the organisation’s business processes

and their complexity

• Control and maintain their state

• Balance load

• Leverage multi-channel applications

• Separate business and process logic

• An application’s frontend or a frontend service can delegate the entire process control to a process-centric service

Service Types

Process Centric Services

Applicationfrontend

Basicservice

Basicservice

Basicservice

Service Types

Process Centric Services

Basicservice

Basicservice

Basicservice

Service Types

Public Enterprise Services

• Available to customers and partners• Must have interface defined at the business document level• Must be decoupled• Must be secure• Must have accounting/billing• Must have an SLA

Service Granularity

Coarse vs. Fine grained Services

Enterpriselayer

Processlayer

Intermediarylayer

Basiclayer

Core elements of a SOA

• Frontend Services

• Basic Services

• Service Repository

• Service Bus

Service Repository/Registry

• Registry answers– What are the services?– Where are the services?

• Repository answers– How are the services used?– How do the services interact?– Who is using the services?– Why are they used?

• Both are needed to achieve the benefits of SOA

Information in the Service R&R

• Business Service contract• Technical contract• Service owner• Access rights• Intended performance & scalability metrics• Transactional properties of the service

Enterprise Service Bus

• An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code.

• Unlike the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, an enterprise service bus builds on base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

Enterprise Service Bus

Flexible connectivity infrastructure for integrating applications and services to power your SOA

• ROUTING messages between services• QUEUING store and forward messages, reliability• TRANSFORMING message format between requestor

and service• HANDLING business events from disparate sources• MONITORING centralised overview

Enterprise Service Bus

Apache ServiceMix

• Apache ServiceMix is an integration container that unifies the features and functionality of Apache ActiveMQ, Camel, CXF, ODE, Karaf into a runtime platform to build integrations solutions. It provides a complete, enterprise ready ESB exclusively powered by OSGi.– Apache Karaf is the ServiceMix kernel– Apache ActiveMQ as message broker– Apache Camel as message routing, components provider and

EIP framework– Apache CXF as WS-* and RESTful WebService provider– Apache ODE as WS-BPEL embedded engine

Rules Engine

• A rule engine is a piece of software, which having some knowledge is able to perform conclusions.

• Knowledge and inferences are stored in rules, which are called production rules.

• A production rule consists of conditions and actions, which are executed when their conditions are true.

• Rules can get into a conflict. This happens when there are more than one rule which are true, at the same time.

• Conflict resolution is provided by the agenda. It arranges the order of actions, which has been selected to be run.

Rules Engine

ProductionRules

Rule A

Rule B

Rule C

+

+

WorkingMemoryObject X

Object Y

Object Z

Decision

InferenceEngine Pattern

Match

Event Driven Architecture

• Uses unidirectional messaging to communicate among two or more, largely independent peer procedures.

• The communication is initiated by an "event". This event typically corresponds to some business occurrence. A system acting as the event publisher places the event on a queue or publishes it to a topic.

• Any event listeners subscribing to that topic are then notified and thus activated.

• The event publisher and the event subscriber are independent of one another. This allows for completely decoupled operation.

• Events may be further categorized into simple and complex events:

– Simple events are the computerized record of a business event generated by some change in state in the business environment.

– A complex event is a software event that is derived from two or more elementary “member” software events through a process of event aggregation or correlation.

What is an Event?

• An event is a notable thing that happens inside or outside your business. An event (business or system) may signify a problem or impending problem, an opportunity, a threshold, or a deviation.

Event

Header

Body

ID Type

Name Timestamp

Occurrence no. Creator

Data

Event Driven SOA

• A form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings.

• Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process.

• This older approach (sometimes called SOA 1.0) does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both random and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.

Event Driven Architecture

Conceptual Examples• Abandoned iPlayer Programme

– We could construct a VRM event from an "abandoned iPlayer programme" message (parsing the transaction, BBC ID, and time), using other filters to extract the broadcast offset within the programme and tapping the correlation capabilities of the system to add causal indicators such as whether the iPlayer site was suffering performance problems. This VRM event might also include viewer value or rank from the viewer database.

• Engineering Defect

– Based on the types of independent service calls received, the SOA 2.0 platform could identify a product defect by detecting the underlying pattern of the separate complaints, then triggering an alert to engineering or production of the possible defect.

• Real-time Electricity Market

– A virtual electricity market where home clothes dryers can bid on the price of the electricity they use in a real-time market pricing system. The real-time market price and control system could turn home electricity customers into active participants in managing the power grid and their monthly utility bills. Customers can set limits on how much they would pay for electricity to run a clothes dryer, for example, and electricity providers willing to transmit power at that price would be alerted over the grid and could sell the electricity to the dryer. Consumer devices can also bid for power based on how much the owner of the device were willing to pay, set ahead of time by the consumer.

– Homeowners can customize many different types of electricity devices found within their home to a desired level of comfort or economy. For example, to reduce the home owner's electricity usage in peak periods (when electricity is most expensive), the software could automatically lower the target temperature of the thermostat on the central heating system (in winter) or raise the target temperature of the thermostat on the central cooling system (in summer).

SOA and Publishing Services

iPlayer Services

ODM Service

DistributionService

ContentServices

AC

E

Dynamite DB PIPS DB

AOD VOD

Enterprise Service Bus

BroadcastService

ATService

AgendaService

On DemandService

IngestService

HistoryService

RulesService

Database(s)

FavouriteService

RecommendationService

PartnerService

SOA Maturity Model

SOA Patterns

• Service Inventory Design Patterns– Foundational Inventory Patterns– Logical Inventory Layer Patterns– Inventory Centralization Patterns– Inventory Implementation Patterns– Inventory Governance Patterns

• Service Design Patterns– Foundational Service Patterns– Service Implementation Patterns– Service Security Patterns– Service Contract Design Patterns– Legacy Integration Patterns– Service Governance Patterns

• Service Composition Design Patterns– Capability Composition Patterns– Service Messaging Patterns– Composition Implementation Patterns– Service Interaction Security Patterns– Transformation Patterns