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

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
Summary

SOA = BAD

Business
Agility through
Decoupling
SOA =

SOA Concepts
Services with standardized Contracts
Producers and Consumers
Cross-platform/technology
Independent development/management of Components
Decoupling
Events

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
Reuse
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
CMS
Social API
LDAP
WorkflowEngine
App D
App C
Validation
Service
Service API
Service API
CMS
Email
IM
Fax
8

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
Data

Remember the SOA Concepts?
Services with standardized Contracts
Producers and Consumers
Cross-platform/technology
Independent development/management of components
Decoupling
Events

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
Interface
CMS
Deep link
Interface
Social API
Portlet API
HTMLPages
Portlet API
RSS
RSS
internet
internal
ToDo
News
WorkflowEngine
App D
App C
Portlet API
Portlet API
RSS
CMS
Email
IM
Fax
16

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
Local
Reusable
Parameter based synchronization
Publishes Events

Consuming Portlets

Consuming Portlets (2)
todoUpdateEvent

Portlet consumer interacting with Portlets and Providers
Remote .NET based Portlet Provider
Portal-in-a-Box
WebCenterPortlet Container & Provider
tiger
Med
High
Low
Prepackaged Portlets
Custom
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:
Parameters
Events (in and out)
JavaScript sharing
Skinning
Client side – detach table uses full screen

Deploy and Reuse ADF Library

Add reusable task flow to page

Meanwhile…

Task Flow contract elements
parameters
event
Nav command
JS custom event
Save Task Event
NavigationEvent
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
Portlet
Task Flow
Remote
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
Shared
Data Controls
Transaction context
Skin/Style
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
Database
Portal
ESB
Database
WebService
CMS

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
http://technology.amis.nl/blog
Contact us at:
peter.ebell@amis.nl and lucas.jellema@amis.nl