35
SOA in a Nutshell! Abhilash Juluri

Oracle SOA Introduction

Embed Size (px)

Citation preview

Page 1: Oracle SOA Introduction

SOA in a Nutshell!

Abhilash Juluri

Page 2: Oracle SOA Introduction

Introduction SOA Foundation Standards Service Component Architecture (SCA) SOA Infrastructure BPEL BPM Service Bus Phases of a SOA Project

Topics

Page 3: Oracle SOA Introduction

Web discoverable application components Foundation standards:

Web Services

Foundation Standards

Page 4: Oracle SOA Introduction

Find-Bind-Invoke paradigm

Simple WS flow

Page 5: Oracle SOA Introduction

- Business Agility through Decoupling- Adaptability- Business Driven IT enablement- Composition of Services- Architecture style

SERVICE ORIENTED ARCHITECTURE (SOA)

Page 6: Oracle SOA Introduction

Requirements Interpretation

Page 7: Oracle SOA Introduction

Close the gap between business and IT Loose coupling Agility DT @ RT – Design Time at Runtime Natively Interoperable with heterogeneous systems Cross-platform support through open WS standards Reliable Secure Scalable Vendor independent

Why SOA

Page 8: Oracle SOA Introduction

SOA Infrastructure

Page 9: Oracle SOA Introduction

SOA Reference Architecture

Page 10: Oracle SOA Introduction

Business Process Execution Language, BPEL, is an executable modeling language. Through XML it enables code generation.

Comparison

Traditional Approach BPEL ApproachHard-coded decision logic Externalized decision logicDesigned by IT Modeled by business analystsDeveloped by IT Developed by ITMaintained by IT Maintained by policy managersManaged by IT Managed by ITDependent upon custom logs Automatic logs and process

captureHard to modify and reuse Easy to modify and reuse

Page 11: Oracle SOA Introduction

Intrinsic Characteristics of Services• SOA is all about Services• Services are building blocks to SOA solutionServices should be:• Granular – Finding balance between coarse

grained and fine grained service• Atomic – atomic to service-consumer• Idempotent – have no side affects

• raiseSalaryByX Vs. setSalaryAtX()• Stateless – Less footprints to promote repeated

reuse• Event aware• Bound to Service Level Agreement (SLA)

Granular Idempotent

Atomic Stateless

Page 12: Oracle SOA Introduction

Technical/Utility Services◦ Exception Handling, Transformations, Logging, Address

Checker, Emailer, SNMP Traps Elementary Services

◦ For claims – Matching, Pricing, Eligibilities Business Services

◦ Caters the business needs like - Process a claim- Adjust a claim- Retrieve claims history of a subscriber

◦ Composed of one or more Elementary services or Utility services

◦ Business process are exposed as a service◦ Examples: Claim Engine, Billing, Provider, SMS

Service Types

Page 13: Oracle SOA Introduction

SOAP & WSDL◦ SOAP & WSDL interactions are strongly typed◦ Consumer knows what to expect from a service

WS-*

RESTful Services◦ REST seems primarily useful for data integration

between web clients and servers, not so much for enterprise SOA

Standards in SOA

Page 14: Oracle SOA Introduction

WS-Addressing WS-Policy WS-Security WS-SecureConversation WS-Trust WS-ReliableMessaging WS-Coordination WS-AtomicTransaction Etc…

WS Standards

Collectively referred as WS-*

Page 15: Oracle SOA Introduction

Service Component Architecture (SCA) ◦ Set of specifications to model applications using Service-

Oriented Architecture

UDDI Directory, Enterprise Repository, Registry (YellowPages for webservices)◦ Dynamic lookups of services to promote reuse

Specifications per different industry verticals ◦ Healthcare uses HL7 for message formats◦ Financials use XBRL for financial reporting◦ E-commerce (B2B) uses EDI, ebXML, RosettaNet, etc…

Cont…

Page 16: Oracle SOA Introduction

REST SOAP

Makes data available as a resources. E.g. AccountInformation, Invoice

Makes application logic available as a servies. E.g. getAccountInformation, PayInvoice

It’s an architectural style. No strict contract between client and server.

It’s a protocol.

REST Vs. SOAP

REST SOAP

It uses standard HTTP. Easy to implement.

Works on top of any communication protocol.

Returns data in many different formats (JSON, XML, etc.)

It can be fully described using WSDL.

Better performance and scalability. Reads can be cached.

Provides end-to-end reliability and successful/retry logic is built in.

REST allows better support for browser clients due to its support for JSON.

Security and authorization are part of the protocol.

Advantages

Page 17: Oracle SOA Introduction

REST SOAP

Only works on top of HTTP protocol.Hard to implement and not so popular among web and mobile developers.

No built-in standards for security or reliability. Permits XML data format only.

No constraints on the payload. SOAP defines standards to be strictly followed.

     Requires more bandwidth and resource than REST.

Disadvantages

REST SOAP

When your bandwidth is very limited. When performing transactions that involve multiple calls.

When client and server operates on a web environment.

When you want to enforce a strict contract between client and server

Examples: Social Media Service, Web chat service Examples: Financial services, telecommunication services

When to Use What

Page 18: Oracle SOA Introduction

A programming model Basic building block for SCA is a component Component abstracts business logic

SCA

Page 19: Oracle SOA Introduction

A deployable unit – a business solution Consists of components, services,

references and wires that connect them Composite can be viewed as component

from integration point of view.

SCA Component

Page 20: Oracle SOA Introduction
Page 21: Oracle SOA Introduction
Page 22: Oracle SOA Introduction

Open Standard to orchestrate discrete services into an end-to-end process flow

Specs driven by OASIS (oasis-open.org) Follows SCA programming model Scopes, Fault Handling, Compensation

Handlers, Correlation sets Sync/Async, JCA Adapters, Activities, Events Integrates with Rules, Human Workflows,

SOA Governance

Business Process Execution Language (BPEL)

Page 23: Oracle SOA Introduction
Page 24: Oracle SOA Introduction

Business strategy implementation Graphical representation called as Business

Process Model Business Process Modeling Notation (BPMN) BPM Life Cycle:

Business Process Management (BPM)

Page 25: Oracle SOA Introduction

LOB – Line of Balance

Page 26: Oracle SOA Introduction

A business perspective - Viewing a business as a set of processes that can be explicitly defined, optimized, and managed

A technical (and SOA-oriented) perspective – Development using software designed for implementing, executing, and monitoring process logic

BPM/BPEL Perspectives

Page 27: Oracle SOA Introduction

Endpoint virtualization Content based Routing Transformations Validation Auditing Messaging Synchronous/Asynchronous adaptation Composition

Service Bus

Page 28: Oracle SOA Introduction

Point to Point Integration

Page 29: Oracle SOA Introduction

Point to Point Integration Vs ESB

Page 30: Oracle SOA Introduction
Page 31: Oracle SOA Introduction
Page 32: Oracle SOA Introduction

Centralized library for security policies

Security enforcement, Validation rules are externalized

Improved visibility for the services

Design Time @ Runtime support

Leverages Application Server infrastructure like WebLogic, JBoss

And of course, Decoupling

Complex message flows can be composed using these decoupled services in very short time

REST-ful WS support

SOA Advantages

Page 33: Oracle SOA Introduction

Dynamic nature of markets requires RAD and reduce time-to-market

Identify Business Processes based on business areas

Top-Down approach◦ Business Strategy translated into SOA app(s)

Bottom-Up approach◦ Strategy driven, but existing apps are composed as SOA

apps◦ Keeping Security, Management as centralized as possible

SOA Readiness

Page 34: Oracle SOA Introduction

Select Application

The Path to a Successful SOA Project

BuildServicePortfolio

ServiceBus

BusinessProcess

UserInterface

Dashboard

Security

Scalability

Page 35: Oracle SOA Introduction

ServicePerformance

Response

Under normal conditions - update of an entity in the persistent storage <0.5

Second

Latency

Under normal or stress conditions, critical alert generated by the system will be displayed in less

than 1 seconds (for generation)

Data Loss

under all conditions, a message acknowledged

by the system will not be lost

Availability

Hardware Issues

Under all conditions, when a server crash, the

system will resume operation in less than 30

seconds

Usability

Compliance

The system should comply with maritime data standards (e.g. Mercator projection)

Operability

The system should handle user request without impeding the user's ability to continue

controlling the system (e.g. initiate additional

requests)

Security

Unauthorized users

under normal conditions and connectivity the

system should alert an unauthorized login attempt (intrusion)

within 1 minute

Adaptability

More Users

When additional users need access to the

system, add new /more hardware (to support

load) under 4 man weeks

SLA Attributes