Upload
gulimran
View
508
Download
0
Embed Size (px)
DESCRIPTION
Service Oriented Architecture The fundamentals of Service Oriented Architecture presented by Gul Imran
Citation preview
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