Service Oriented Architecture
Upcoming SlideShare
Loading in...5

Service Oriented Architecture



Service Oriented Architecture

Service Oriented Architecture

The fundamentals of Service Oriented Architecture presented by Gul Imran



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Service Oriented Architecture Service Oriented Architecture Presentation Transcript

  • Service Oriented Architecture An Overview
  • 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.
  • 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 Business use cases User Interface Presentation layer Business logic Integration middleware Data access layer Data management Technical layers
  • 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 PIPELINE Enterprise Service Bus Basic Services Legacy Systems Intermediary Services Databases 3rd Party
  • Major Artefacts of a SOA SOA Frontend Service Basic Service Business contract Implementation Business logic Service Repository Technical contract Data Service Bus
  • 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.
  • 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
  • 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 Technology A Tech gateway Technology B Technology B Basic service
  • Service Types Intermediary Services – Facade Application frontend Application frontend Application frontend Facade Basic service Basic service Basic service
  • 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 Application frontend Basic service Basic service Basic service
  • Service Types Process Centric Services Basic service Basic service Basic service
  • 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 Enterprise layer Process layer Intermediary layer Basic layer
  • 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, 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
  • 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 ID Type Name Timestamp Occurrence no. Creator Body 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 – • 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).
  • 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
  • SOA Maturity Model
  • SOA Patterns • Service Inventory Design Patterns – – – – – • Service Design Patterns – – – – – – • Foundational Inventory Patterns Logical Inventory Layer Patterns Inventory Centralization Patterns Inventory Implementation Patterns Inventory Governance 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