The Story of How an Oracle Classic Stronghold successfully embraced SOA
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The Story of How an Oracle Classic Stronghold successfully embraced SOA

on

  • 1,377 views

The Story of How an Oracle Classic Stronghold successfully embraced SOA

The Story of How an Oracle Classic Stronghold successfully embraced SOA

Statistics

Views

Total Views
1,377
Views on SlideShare
1,377
Embed Views
0

Actions

Likes
1
Downloads
25
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

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.

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

The Story of How an Oracle Classic Stronghold successfully embraced SOA Presentation Transcript

  • 1. The Story of How an Oracle Classic Stronghold Successfully Embraced SOA AMIS ODTUG Preview 15 th June 2009 Lucas Jellema SOA
  • 2. Overview
    • What is an Oracle stronghold?
    • Triggers to start moving towards Services
    • Levels of embracing Services and SOA
      • Objectives, benefits, costs & challenges
      • Demonstration
    • Pitfalls, Lessons Learned & Best Practices
    • Summary
  • 3. What is an Oracle stronghold?
    • The typical Oracle stronghold
      • Using Oracle RDBMS & Oracle Development tools
        • Lot of SQL and PL/SQL
        • Probably Oracle Forms and maybe APEX as well
        • Possibly Oracle Designer, tools for BI & Reporting
      • Several databases with many years of essential corporate data
      • IT staff has Oracle veterans – 5-15 years or more
      • Internet development may have taken place largely separate from the Oracle technology stack
  • 4. Then wat happened…
    • Job Agency offered Oracle Forms application for entering timesheets
      • Business partners requested a programmatic interface to load multiple timesheets
      • Marketing wants to expose job details from the back office through an internet website
    • Oracle Forms application for assigning homes offered SaaS-style
      • SaaS Customers want the details on houses and their availability published on a website
  • 5. Then wat happened… (2)
    • Car Lease company has various custom applications and databases per department
      • Business requires IT to support processes that go across those applications and databases
        • through a single, unified User Interface
        • involving a legacy database and a 3 rd party ERP system
        • with eventually some self service web modules
    • Insurance company sells policies through agents using a Forms application
      • New direct channel: On-line policy selling
  • 6. Then wat happened… (3)
    • Agricultural company supports ‘cow insemination’ process with Forms application
      • Farmers and inspectors need to be able to record data anytime and anywhere through PDAs (that run a .Net application)
    • Mid-sized chemical pharmaceutical company uses BoB stand-alone systems and databases
      • To allow for faster (near real-time) responses to customer demands and logistical challenges, tighter integration between the systems is needed
  • 7. Common Characteristics
  • 8. Objectives
    • Business Agility
      • (Faster) responses to changing demands
      • Creating new business from existing resources
    • Lower costs
      • Through reuse, better integration, decoupling
    • Higher Quality and Faster Process execution
      • Automated data exchange cross boundaries
      • Workflow and task orientation
      • Business Event driven interaction
  • 9. SOA = BAD
  • 10. SOA = B usiness A gility through D ecoupling
  • 11. Decoupling ≈ Managing Dependencies minimize impact of change while maximizing reusability
  • 12. Types of decoupling
    • Functional
      • Interface - Encapsulation of implementation
        • Design by Contract, Implement by Design
    • Technical
      • No proprietary technology, protocol, message format
      • Standards based (XML, HTTP, RSS, WSDL…)
    • Temporal
      • Asynchronous communication (separate response)
    • Development
      • Separate teams working in parallel based on mutually agreed interface definitions
  • 13. Decoupling Applications & Data Data Application (User Interface) Application (User Interface) Data
  • 14. Decoupling Applications & Data Application (User Interface) Data Application (User Interface)
  • 15. Decoupling Applications & Data (User Interface) Data Application
  • 16. Decoupling Applications & Data (User Interface) Application Workflow Engine Email IM Fax CMS
  • 17. Data Ownership
    • Data no longer exclusively owned by a single application
    • Data (query and manipulation) available via APIs, (web)services and open standards
      • For example based on XML, XSD, WSDL, SOAP, HTTP
    • Data Hubs are formalized, structured approach where data is completely separated from applications
      • All access is through services
      • No data duplication at all in the enterprise
      • Data ownership is separate process
  • 18. Decoupling from Table to ESB+ http WEBDAV FTP http WS/SOAP WS* WS* WS* WSRP
  • 19. Tables in Database
    • SQL for retrieval and manipulation
    • Data Model in plain “view”
    • Decoupling between DML and Retrieval
    • select e.empno, e.ename , d.dname from emp join dept using (deptno)
    • Insert into dept; insert into emp;
  • 20. View in Database
    • Hide (encapsulate) Data Model
      • Manage access privileges
    • SQL for retrieval and manipulation
    • Instead Of trigger decouples DML operations
    • select id, name, department from emp_vw
    • Insert into emp_vw
    • Use case: new UI on top of ‘legacy’ data model
  • 21. Package in Database
    • Hide (encapsulate) SQL
    • Procedure calls for retrieval and manipulation
      • Potentially complex data structures using Object Types and (nested) Cursors
    • HRM_MGR.get_emp( id) return emp_t
    • HRM_MGR.create_emp( emp_t);
    • Use case: tailor made business services to support (Java) client
  • 22. Package in Database (2)
    • Hide (encapsulate) SQL and Oracle and user defined Types
    • Procedure calls for retrieval and manipulation
      • Input and output parameters standard types only (string and number)
      • Complex datastructures: XML passed as string
    • HRM_MGR.get_emp( id) return string
    • HRM_MGR.create_emp( string);
    • Use case: packaged business services to support any client (that can access the DB)
  • 23. Handling XML
    • Structured, multi-level data in a string: XML
    • Oracle Database has XMLType
      • Can be created from a String, will parse XML
        • Can validate against a schema definition (the XML data design)
      • Support XPath operations to retrieve specific bits and pieces from the XML document
      • Can do XSLT transformations of the incoming or outgoing XML
  • 24. AQ for Asynchronous
    • Decouple consumer and provider in time – asynchronuous processing
    • Consumer is registered on the AQ
      • Usually a package that processes User Defined Type that is sent as payload in the AQ message
    • Use case: asynchronously processed one-way (fire-n-forget) requests
      • Potentially lenghty requests
      • High volume of requests
  • 25. Hiding the database http WEBDAV FTP http WS/SOAP WS* WS* WS*
  • 26. Publish package as http-based API using dbms_epg
    • Hide database protocol
      • Not its physical location nor the schema, and user authentication
    • HTTP communication is truly cross technology
      • Browser, Java, .Net, JavaScript & RIA clients, …
      • Approximation of RESTful services (very du jour)
    • Can publish in various formats
      • Text, HTML, CSV, JSON, XML, RSS
    • Use case:cross-technology, internal no WS*/ESB
    http
  • 27. Publish static resources on various protocols with XMLDB
    • Hide database protocol
      • support FTP, WEBDAV, HTTP(S)
    • Run scheduled batch jobs (PL/SQL) to periodically create & expose resources
      • Can also consume and process resources
    • Use case: cross technology need for retrieving slowly changing resources (CSV, XML)
      • Possibly uploading resources for batch processing
    • Use case:
    WEBDAV FTP http
  • 28. SOAP based WebServices http WEBDAV FTP http WS/SOAP WS* WS* WS* WSRP
  • 29. SOAP WebServices
    • All messages (input and output) are XML
    • The message consists of two parts inside an envelope (a SOAP XML wrapper)
      • The header with meta-data
      • The body with the contents to be handled by or returned by the service
    • The WebService Definition Language (WSDL) document describes the service
    • An XML Schema Document (XSD) describes the structure of the XML messages
      • XSD is like an ERD or Table Design
  • 30. Oracle RDBMS 11g - Native Database WebServices
    • Schema can be published through native database web services
      • Each package corresponds with a WSDL
      • Every program unit with an operation
      • WSDL and XSD are dynamically generated
    WS/SOAP
      • http and https is supported
      • Limited control over WSDL & XSD
    • Use case: internal, cross technology, WS enabled client, no ESB or Application Server available
  • 31. WebService in App Server based on PL/SQL package
    • Hide database
      • Protocol, location, authentication: everything handled by the application server
    • Use JPublisher (embedded in JDeveloper) to publish a PL/SQL package as WebService
      • JPublisher creates JAX-WS-annotated class, utility classes and possibly helper types in the database
    • Alternatively: create ADF BC Application Module & publish it as a WebService (Bulldog)
      • With support for SDO (Service Data Objects)
    • Use case: WS (SDO!) enabled client, no ESB
    WS*
  • 32. Enterprise Service Bus Data Service Service Service App 2 Data Service External Partner Service App 1
  • 33. The Enterprise Service Bus
    • Virtualizes services – hides the real service from consumers
      • Deals with the physical location of the services
    • Allows callers to use a generic, canonical message structure that it will transform to the service contract
      • It may even allow callers to use their own “lingo”
    • Adapts synchronous to a-synchronous and vv.
    • Can use multiple real services to offer one virtual (composite) service
  • 34. The Enterprise Service Bus (2)
    • Handles various QoS & SLA aspects
      • sometimes in concert with tools like OWSM
      • Encryption, signing, authentication
      • Retry and fallback
      • “ Throttle” (prevent peak loads)
    • Does monitoring, tracking & auditing, reporting, notification and escalation
    • Works with Adapters to access technologies
      • like RDBMS (SQL, PL/SQL), AQ and JMS, File System, FTP, Java, E-Business Suite
  • 35. Publish PL/SQL Package through ESB
    • Use Database Adapter to create Service, combine with ESB Routing Service
    • Use case:
      • external access to services
      • virtualize location of service –
        • route to service based on content of the request
      • virtualize part of contract of service
        • Package-derived XSD not suitable for consumers
      • handle peak loads
      • monitor service levels and trace service access
    WS*
  • 36. Introducing BPEL for Service
    • BPEL adds to service
      • Long running (stateful) ‘service instances’
      • Composite services that include
        • Multiple service calls (including asynchronous)
        • Exception handling including retry and compensation
        • Human Task for manual steps & Integration Rule Engine
        • Process flow logic
    • Use case:
      • data request must be fulfilled by various services;
      • dml impacts several systems and/or requires human approval
    WS*
  • 37. Publish Business Events
    • Extreme Decoupled Architecture
    • Any system – including database – reports events that may be interesting to other parties
    • The Event backbone (could be the ESB)
      • Defines Event Types (name, structure of payload)
      • Registers Event Listeners (“please call me when the event occurs and send the details”)
      • Receives events – instances of the predefined event type with payload and timestamp
        • Propagate events to all registered listeners
        • Without blocking the event producer
  • 38. Event Driven Architecture (EDA) Data Service Service Service App 2 Data Service External Partner Service App 1
  • 39. Database publishing events
    • Table Trigger intercepts DML
      • Checks for Business Events such as new employee
      • Sends them to package EVENT_PRODUCER
    • Package EVENT_PRODUCER sends events
      • Via UTL_HTTP to a WebService
      • Via AQ to a listener (ESB AQ Adapter)
    Event Producer EMP WS*
  • 40. Publishing Service with UI
    • Instead of only publishing a programmatic service interface
      • A service can be published with a User Interface; the service-with-UI is called: Portlet
    • The standard approach:
      • Portlet Container in Application Server exposes WSRP services for the portlets
      • The Portlet produces (X)HTML and handles HTTP requests
      • A Portal consumes the WSRP Portlets in a web page
    WSRP
  • 41. Decoupling from Table to ESB+ http WEBDAV FTP http WS/SOAP WS* WS* WS* WSRP
  • 42. Increasingly decoupled
    • More hiding of the implementation
    • More Formal Interface Contract
    • Less (proprietary) technology & more standards for interacting
    • Less exposure of (legacy) data model
    • More support for asynchronous interaction
    • More reuse potential
    • Pervasive throughout enterprise
    • More suitable for external consumption
  • 43. Comes at a cost…
    • More run time overhead
      • Additional tiers
      • XML serialization and deserialization
    • More infrastructure
      • Burden of Administration
      • License Costs
      • Hardware
    • Broader skills palette – more stuff to master
    • Harder to get started
  • 44. Pitfalls
    • Inconsistent, illegible, unstructured namespaces and (XML) data model
      • Having the database (table and column names) shine through in the canonical data model
    • Introducing new unmanaged dependencies
      • Hard coded endpoints (service URLs)
      • Calling external services without proper SLA or fallback option
      • Using complex technology without proper skills
  • 45. Pitfalls
    • Lack of Balance between reusability and usefulness (Fine grained vs. coarse grained)
    • The greedy clutches of enterprise architects
      • Think, talk, (high level) design, draw & write, present, think, talk, …. (no real action)
    • Inappropriate use of the SOA infrastructure
      • Web applications retrieving each indivual record (or even field) through a separate service call
        • Running Forms on top of the ESB!
      • Sending debug and trace messages via the ESB
      • Package calls other package via ESB
  • 46. Pay close attention to…
    • Handling errors, exceptions, time out etc.
      • Early detection of service unavailability
    • SOA and Services Governance
      • Involve business in managing services and canonical data model
      • Implement process of life cycle management
      • Ensure services are well known, findable & trusted
    • Involving DBAs/Administrators early on
    • Implementing DTAP process & environment
  • 47. Useful
    • Publish actual XSDs very visibly
    • Use Mock Service implementations during development and test
    • Automated Functional and Performance Test of individual Services
    • Automatic Service ‘ping’ utility
    • Quality of Service – SLAs and Monitoring
    • Canonical Model also includes Domains, Dictionary and “Identity Repository”
  • 48. Summary
    • Objective: agility through decoupling
      • Managing dependencies
      • Crossing boundaries – functional, technology, time
    • Just do it!
      • Get started – at the right level for your situation
        • Do not go off and buy BPEL just like that
      • Even though it won’t be perfect the first time round – you will learn (only) through experience
    • Do it explicitly, visibly and with all involved
    SOA