2. What is a Service?
• In economics and marketing, a service is the nonmaterial 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.
3. 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
4. Vertical Slicing
Business use cases
User Interface
Presentation layer
Business logic
Integration middleware
Data access layer
Data management
Technical
layers
5. Benefits of SOA
The primary benefits of a SOA include:
• REUSING SERVICES/BEHAVIORS
• AGILITY
• MONITORING
• EXTEND REACH
6. SOA Reference Architecture
Business Services
Frontend Services
Process-centric Services
Enterprise Services
PIPELINE
Enterprise Service Bus
Basic Services
Legacy Systems
Intermediary Services
Databases
3rd Party
7. Major Artefacts of a SOA
SOA
Frontend
Service
Basic
Service
Business
contract
Implementation
Business
logic
Service
Repository
Technical
contract
Data
Service
Bus
8. 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.
9. 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
- Interface A
Customer
Service A
- Interface B
Customer
DB
Customer
Service B
Customer
Service
Customer
DB
11. Service Types
Intermediary Services – Technology Gateways
Application frontend
Technology A
Technology A
Tech gateway
Technology B
Technology B
Basic service
12. Service Types
Intermediary Services – Facade
Application
frontend
Application
frontend
Application
frontend
Facade
Basic
service
Basic
service
Basic
service
13. 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
16. 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
18. Core elements of a SOA
• Frontend Services
• Basic Services
• Service Repository
• Service Bus
19. 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
20. Information in the Service R&R
•
•
•
•
•
•
Business Service contract
Technical contract
Service owner
Access rights
Intended performance & scalability metrics
Transactional properties of the service
21. 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.
22. 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
23. 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
24. Rules Engine
•
•
•
A rule engine is a piece of software, Rules Engine
which having some knowledge is
able to perform conclusions.
Production
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.
Working
Memory
Rules
Rule A
Object X
+
Rule B
Object Y
Object Z
+
Rule C
Inference
Engine
Decision
Pattern
Match
25. 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.
26. 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
ID
Type
Name
Timestamp
Occurrence no.
Creator
Body
Data
27. 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.
28. Event Driven Architecture
Conceptual Examples
•
Abandoned iPlayer Programme
–
•
Engineering Defect
–
•
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.
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).
29. SOA and Publishing Services
AOD
ODM
Service
Distribution
Service
iPlayer Services
Ingest
Service
History
Service
VOD
Favourite
Service
Recommendation
Service
ACE
Enterprise Service Bus
Content
Services
Dynamite DB
Broadcast
Service
AT
Service
On Demand
Service
PIPS DB
Partner
Service
Rules
Service
Database(s)
Agenda
Service