This document discusses implementing a user interface for SOA applications using Oracle WebCenter 11g. It covers exposing user interface components as services using portlets or ADF task flows, which allows for decoupled and reusable UI development. WebCenter provides pre-built task flow services and a framework for consuming portlets. The document demonstrates consuming various task flows and portlets to integrate reusable user interface functionality.

1. Experiences with Oracle WebCenter 11g: Implementing SOA with a User Interface Peter Ebell Lucas Jellema AMIS, The Netherlands

2. 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

3. SOA = BAD

4. Business Agility through Decoupling SOA =

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

6. 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 (!)

7. Traditional SOA: Programmatic Services Typical Components: Application ( = Consumer) Webservices and WSDL ( = Service + Contract) Enterprise Service Bus ( = Service Provider) Queues (= Events and Event Listeners)

8. 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

9. 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!

10. 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

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

12. 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

13. 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

14. 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)

15. 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

16. 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

17. 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

18. 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

20. Consuming Portlets

21. Consuming Portlets (2) todoUpdateEvent

22. 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

23. 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)

24. 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, …

25. Task Flow Contract Like Portlets, ADF Task Flows adhere to a Contract (native ADF). Input:Parameters (initial)EventsNavigation commands Output(Changed) ParametersEventsNavigation events

26. 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…

27. Example: Human Task UI in SOA Suite

28. 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

29. Deploy and Reuse ADF Library

30. Add reusable task flow to page

31. Meanwhile…

33. Task Flow contract elements parameters event Nav command JS custom event Save Task Event NavigationEvent JS custom event

34. (server side) Event handling Todo Task Flow Task Flow Consumer

35. 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

36. 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

37. 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

38. 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

39. Decouple points Portlet Container & Provider Database Portal ESB Database WebService CMS

40. 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?

41. Introduction WebCenter WebCenter == ADF++

42. 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

43. 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

44. 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

45. Demo Leveraging WebCenter Services Reuse RSS Viewer Reuse Document Library Based on WebCenterContent Repository Connection

46. Create Content Repository connection – File System based

47. Consume WC Services in page

48. Consume WC Services (2)

49. RSS Feed Viewer live

50. DocumentLibrary Service Live

51. 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")

52. 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

53. 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