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


Published on

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.

Published in: Technology, Business
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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

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