• Save
Experiences with Oracle WebCenter 11g: Implementing SOA with a User Interface
Upcoming SlideShare
Loading in...5

Experiences with Oracle WebCenter 11g: Implementing SOA with a User Interface



One of the sessions I am (co-)presenting at Oracle Open World 2009 is on 'applying the concepts of SOA to and achieving the SOA objectives with User Interfaces'. What goes for SOA and typical ...

One of the sessions I am (co-)presenting at Oracle Open World 2009 is on 'applying the concepts of SOA to and achieving the SOA objectives with User Interfaces'. What goes for SOA and typical programmatic (web)services can be applied to User Interface components to a large extent. Decoupling - cross location, cross technology, cross development team and deployment unit - and reusing based on clear interface definitions and encapsulation of implementation is also available for user interface development.

Our presentation - I am copresenting with my colleague Peter Ebell - introduced the SOA concepts and objectives and demonstrates the application of SOA to the UI, using first Portlets and then ADF Task Flows. Subsequently we introduce WebCenter - as the portlet-infrastructure for ADF and also as the real life example of the notion of reusable, independently developed user interface components. We will discuss the nature of the contract you define for such reusable UI services (parameters, events - inbound and outbound) and demonstrate the steps you have to go through to make it work. Finally we will go into 'how to add a user interface to a SOA implementation'- or: when does a SOA artefact need a user interface.



Total Views
Views on SlideShare
Embed Views



17 Embeds 1,338

http://technology.amis.nl 1097
http://knoworacle.wordpress.com 105
http://www.slideshare.net 55
http://learnfromadeel.blogspot.com 48
http://www.learnfromadeel.blogspot.com 15
http://webcache.googleusercontent.com 5
http://feeds.feedburner.com 2
http://learnfromadeel.blogspot.fr 2
http://learnfromadeel.blogspot.in 1
http://learnfromadeel.blogspot.co.at 1
http://learnfromadeel.blogspot.com.es 1
http://boorow.com 1
http://www.lmodules.com 1
http://www.javaoracleblog.com 1
http://translate.googleusercontent.com 1
http://www.health.medicbd.com 1
http://learnfromadeel.blogspot.ae 1



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
  • Taakverderling:SOA - what and why - PeterWebServices with a face – Portlets – Peter intro, Lucas demo & conclusionsUI Services with ADF Task Flows - Peter intro, Lucas demo & conclusionsIntroducing WebCenter – LucasPortlet infrastructurePre-packaged task flow servicesPutting a User Interface on the SOA Suite - PeterSummary - Lucas
  • No asynchronous portlets…

Experiences with Oracle WebCenter 11g: Implementing SOA with a User Interface Experiences with Oracle WebCenter 11g: Implementing SOA with a User Interface Presentation Transcript

  • Experiences with Oracle WebCenter 11g: Implementing SOA with a User Interface
    Peter Ebell
    Lucas Jellema
    AMIS, The Netherlands
  • Agenda
    SOA - what and why
    WebServices with a face – Portlets
    UI Services with ADF Task Flows
    Introducing WebCenter
    Portlet infrastructure
    Pre-packaged task flow services
    Putting a User Interface on the SOA Suite
  • SOA = BAD
  • Business
    Agility through
    SOA =
  • SOA Concepts
    Services with standardized Contracts
    Producers and Consumers
    Independent development/management of Components
  • Potential SOA Benefits
    Reduce Complexity
    Flexibility – capacity to change and adapt
    Quickly (time to market, prototype)
    With lower impact and risk
    Through (re-)composition and (re-)organization
    Best of breed solutions
    Integration (!)
  • Traditional SOA: Programmatic Services
    Typical Components:
    Application ( = Consumer)
    Webservices and WSDL ( = Service + Contract)
    Enterprise Service Bus ( = Service Provider)
    Queues (= Events and Event Listeners)
  • A2A oriented SOA
    App A
    App B
    Social API
    App D
    App C
    Service API
    Service API
  • SOA and UI – Different Worlds?
    Some services require or interact with a user interface. For instance: BPEL process containing Human Tasks.
    Taking it one step further: some user interfaces can be treated/offered/used like services!
  • UI Application can be a Service too
    Applications can be exposed as a collection of UI services - user interface components based on data and (data)services
    For example in the form of "portlets" that can be consumed by a Portal product in a mash up
  • Remember the SOA Concepts?
    Services with standardized Contracts
    Producers and Consumers
    Independent development/management of components
  • Applying SOA Concepts to UI:WSRP Portlets
    WSRP Standard: WebService for Remote Portlet
    Exposed by Portlet Container (or Provider)
    Portlet renders its own UI/the content (HTML)
    Contract includes (input) parameters (String or String[]) and events (out, simple payload)
    Called by Portal/Portlet consumer
    Portlets can deal with data manipulation, events, navigation, AJAX and partial refresh
  • Portlet and Decoupling
    Just like normal web services
    Portlets can be located anywhere(we only need URL for endpoint)
    Portlets can be implemented in any technology – as long as the standards are followed
    The implementation of Portlets can change
    as long as the contract (parameters/events) is safe
    Ideally the Portlet uses (style) classes and allows the consumer to apply the stylesheet
  • Drawing the Analogy
    Traditional SOA Components:
    Application ( = Consumer)
    Webservices ( = Service + Contract)
    Enterprise Service Bus ( = Service Provider)
    Queues (= Events and Event Listeners)
    WSRP Portlet Components:
    Portal ( = Consumer)
    WRSP Portlets ( = Service + Contract)
    Portlet Providers ( = Service Provider)
    Produces events for Portal (= Events and Event Listeners)
  • SOA and SaaS Providers
    SaaS (Software as a Service) providers are facing a double SOA challenge:
    Provide a (normal SOA) Web Service interfaceallows SaaS customers to integrate their functionality in their local ESB
    Provide a UI Service interface that exposes pluggable application componentsallow SaaS customers to embed UI ‘services’ in their applications/portal
  • SaaS providers need to open up their application – also the UI
    SaaS B
    SaaS A
    Deep link
    Deep link
    Social API
    Portlet API
    Portlet API
    App D
    App C
    Portlet API
    Portlet API
  • Demonstration of Portlets
    show a web application consuming several portlets
    create a new web application that consumes two portlets
    change one of the portlets and redeploy it; refresh the 'portals' - the consuming webapps in the browser
  • Remote
    .NET based
    Local (in container)
    Generic, resuable
    Run Time editing
    Local and Remote
    Remote Service adaptation (WebClipping)
    Run Time editing
    Parameter based synchronization
    Parameter based synchronization
    Publishes Events
  • Consuming Portlets
  • Consuming Portlets (2)
  • Portlet consumer interacting with Portlets and Providers
    Remote .NET based Portlet Provider
    WebCenterPortlet Container & Provider
    Prepackaged Portlets
  • Conclusions Portlets
    What it does
    Interoperability, Cross technology
    Contract (params & events) supports interaction
    Independent development and deployment
    Where it fails/falls short
    Everything stays inside portal region
    No styling/skinning adopted
    No shared transaction context
    Consumer depends on portlet (availability)
    Requires Portlet infrastructure (e.g. Portal)
  • Alternative: ADF Task Flows
    With Oracle ADF (underlying UI technology of WebCenter) comes an alternative way to develop UI Services: ADF Task Flows
    ADF Task flows are Portlet-like in many respects: stand alone, independently developable, reusable UI component
    Task Flow = one or multistep view, internal business logic, navigation flow, beans, …
  • Task Flow Contract
    Like Portlets, ADF Task Flows adhere to a Contract (native ADF).
    Input:Parameters (initial)EventsNavigation commands
    Output(Changed) ParametersEventsNavigation events
  • ADF Task Flow Capabilities
    ADF does not require Portlets in order to work with service-like reusable components
    Task Flows are published via ADF Libraries and can be consumed more natively than Portlets
    Less overhead (saves 300 ms per request)
    Consumer and Task Flow can share Objects and ADF DataBinding
    Supports complex parameters & ADF events
    Can be customized
    No WebCenter license required…
  • Example: Human Task UI in SOA Suite
  • Demo Task Flows
    Show how a existing task flow (TODO) can be published as ADF library and incorporated in other application
    Show how far the integration can go:
    Events (in and out)
    JavaScript sharing
    Client side – detach table uses full screen
  • Deploy and Reuse ADF Library
  • Add reusable task flow to page
  • Meanwhile…
  • Task Flow contract elements
    Nav command
    JS custom event
    Save Task Event
    JS custom event
  • (server side) Event handling
    Todo Task Flow
    Task Flow Consumer
  • Conclusions on ADF Task Flows
    Stand alone, reusable components
    Interface with Parameters and Events
    Though not a very clear contract document
    Complex parameters and event payload
    Fully Integrated in consuming ADF application
    Skin, Data Controls, Transactions, JavaScript scope
    Deployed as part of the consuming application
    Potentially multiple copies of the task flow – for every application using it
    ‘native/standard’ ADF mechanism
  • Comparing UI Service technologies
    Task Flow
    Cross Technology
    Standards based
    Processing overhead
    Slower page rendering
    Design Time and Run Time decoupling
    Remote provider has to be up
    Needs portlet consumption framework, e.g. WebCenter
    And portlet publication
    Local, native, ADF only
    Data Controls
    Transaction context
    Client side JavaScript & UI
    Rich Contract
    Complex parameters
    Events out and in
    With complex payload
    Navigation influence
    Support for customization
  • Development with Portlets & Task Flows
    The use of Portlets and Task Flows allows for a decoupled way of developing applications
    Teams agree on a contract
    And both work their merry way based on the contract – in fairly insulated manner
    Reuse is possible based on that contract
    Maintenance of Portlet and Task Flow can be independent of consuming applications
    Note: task flow is integrated at design time
  • Real life example
    Health Insurance company
    Wants to expose Web Application in its Portal
    For filing expenses and checking on the progress of claim processing
    Portal not yet picked
    WebApp Integration should be decoupled
    Solution: expose parts of the WebApp as Portlet that can be integrated in Portal
    Web app developers are insulated from Portal
    Contract specifies parameters and events
  • Decouple points
    Portlet Container & Provider
  • Some questions
    How does one create and publish a Portlet?
    How does one simply consume a Portlet in her or his application?
    Can an application manager or content editor add/remove portlets/taskflows– at run time?
    Where does one get those pre-built portlets/task flows for generic functionality?
  • Introduction WebCenter
    WebCenter == ADF++
  • WebCenter 11g
    WebCenter Framework
    Publish ADF TaskFlows as Portlet
    Consume any Portlet in ADF pages (drag & drop)
    Content integration
    WebCenter Composer
    Run time applicationediting
    Run time task flow inclusion
    WC Spaces: pre builtapplication for E2.0
  • WebCenter Services100+ pre-packaged task flows
    ADF 11g task flows
    Backed by database & MDS
    Mutually integrated
    Support for Content, Collaboration, Communication
    Web 2.0 style
  • WebCenter Services
    After installing the WebCenter extension in JDeveloper– the catalog of services (task flows) is available
    To use a service:* drag it* drop it * set the values for the params* (optional) customize the task flow
  • Demo
    Leveraging WebCenter Services
    Reuse RSS Viewer
    Reuse Document Library
    Based on WebCenterContent Repository Connection
  • Create Content Repository connection – File System based
  • Consume WC Services in page
  • Consume WC Services (2)
  • RSS Feed Viewer live
  • DocumentLibrary Service Live
  • Other SOA Demands for UI
    Human Workflow
    Actionable email
    Standard Worklist application
    Custom ADF Task Flow (initially generated)
    Web Center Task service
    Web applications may need to communicate with long running SOA processes
    Flow Diagram showing progress
    Relevant state changes (preferably "pushed")
  • Summary
    SOA: integration, decoupling and reuse
    UI components can be decoupled yet integrated – as Portlets or ADF Task Flows
    Portlets: X-technology, remote, standards based, requires portlet infrastructure (two-way)
    Task Flows: native ADF, local, design time decoupling, rich integration, no overhead
    WebCenter: portlet framework and services
    Applying SOA concepts to UI development enables reuse & scalable development teams
  • Resources
    Presentation and demos are on our blog
    Contact us at:
    peter.ebell@amis.nl and lucas.jellema@amis.nl