Turning Portlets into Services: The Consumer Profile Oscar Díaz, Salvador Trujillo, Sandy Pérez ONEKIN Research group University of the Basque Country San Sebastián (Spain) May 11th, 2007 The 16th International World Wide Web Conference

O. Díaz, S. Trujillo & S. Pérez 2 Outline  Problem statement: portlet variability  What can vary  When can it vary  How is it supported

O. Díaz, S. Trujillo & S. Pérez 3 Service Oriented Architecture  “SOA can be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services” © Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA.Prentice Hall,2005

O. Díaz, S. Trujillo & S. Pérez 4 Portlet-based SOA  Portlets can be the enablers of SOA at the front end “Front-end” SOA PORTLET REPOSITORY PORTLET BUS SOA PORTLET REPOSITORY PORTLET BUS

O. Díaz, S. Trujillo & S. Pérez 5 From Web Services to Portlets XML Request XML Response Web Services Client Application User Interface WS Proxy 2 nd Hand Car Database Search for Cars Car Search Service request Client application Portlet User Interface Business Logic response SOA PORTLET REPOSITORY PORTLET BUS

O. Díaz, S. Trujillo & S. Pérez 6 Portlet repository  Portlet Swap: jboss.org  Portlet Exchange: portletexchange.com  Open Source Portlet Repository Project (2006): “a library of ready-to-run applications that you can download and deploy directly into your portal with, in most cases, no additional setups or configurations” SOA PORTLET REPOSITORY PORTLET BUS

O. Díaz, S. Trujillo & S. Pérez 7 “Portlet bus” SOA PORTLET REPOSITORY PORTLET BUS  Portlet interoperability based on the WSRP standard  The portal as the most popular portlet consumer WebSphere portlet Plumptree portlet Oracle portlet eXo portal

O. Díaz, S. Trujillo & S. Pérez 8 WSRP protocol (registration) Portlet ConsumerWSRP Producer getServiceDescription As an unregistered consumer Metadata Metadata indicates that registration is required, and certain data is required for registration register With registration data register Registration context Unique to the consumer getServiceDescription As a registered consumer Metadata + Offered portlets SOA PORTLET REPOSITORY PORTLET BUS

O. Díaz, S. Trujillo & S. Pérez 9 Portlets as Web components (reusable) MyBrowser End User 1 MyBrowser End User 2 Portal 1 Consumer 1 Portal 2 Consumer 2 HTTP Producer A Producer B Producer L SOAP SOA PORTLET REPOSITORY PORTLET BUS

O. Díaz, S. Trujillo & S. Pérez 10 But this is not enough …  Portlets are coarse-grained components They realise full-fledged applications (not just functions)  The larger the component, the lower the reuse “front-end” SOA PORTLET REPOSITORY PORTLET BUS VARIABILITY

O. Díaz, S. Trujillo & S. Pérez 11 Portlet ubiquitousness  The capacity of a component for being customized to the idiosyncrasies of distinct consumer applications Portlet Consumer (e.g. a Portal) SOA PORTLET VARIABILITY PORTLET REPOSITORY PORTLET BUS

O. Díaz, S. Trujillo & S. Pérez 12 Outline  Introducting the setting: portlet variability  What can vary  When can it vary  How is it supported

O. Díaz, S. Trujillo & S. Pérez 13 What can vary  Portlet variations can manifest in any of the three layers: the presentation layer –rebranding the rendering with logos and banners, changing the labels and text, changing the entry fields and so on. the functional layer –tuning the process to fit the consumer demands. the data layer –distinct functionalities will probably require distinct data.

O. Díaz, S. Trujillo & S. Pérez 14 e.g. presentation-style variants  A portlet output must be aesthetically harmonised with the presentation guidelines of the hosting Portal  WSRP supported Blue-ish Green-ish Red-ish

O. Díaz, S. Trujillo & S. Pérez 15 e.g. functional variants  Previous variants where domain independent  Most often, variations are domain dependent

O. Díaz, S. Trujillo & S. Pérez 16 flightBooking sample case  Domain: an air carrier selling tickets through distinct travel agencies:  Portlet: flightBooking

O. Díaz, S. Trujillo & S. Pérez 17 What can vary on flightBooking?  payment, indicates how travel agencies (portlet consumers) are compensated  checkin, some travel agencies do not allow for this functionality  flightTypes, indicates the focus on domestic or international flights  portletPref, permits the travel agency to tune which trip parameters end users can set a default for

O. Díaz, S. Trujillo & S. Pérez 18 The consumer model  A feature is any characteristic, placed by the carrier and used by the travel agency to describe how the flight booking process should be tailored to the agency’s idiosyncrasies.  The Consumer Model is a feature model that captures the variation space for consumers of a given portlet

O. Díaz, S. Trujillo & S. Pérez 19 Consumer model for the sample case (*) and alternativeor mandatory optionalrepetitions 1..* * (*) FODA notation

O. Díaz, S. Trujillo & S. Pérez 20 The Consumer Profile  A Consumer Profile instantiates the consumer model for a particular consumer (e.g. Thomas Cook travel agency).

O. Díaz, S. Trujillo & S. Pérez 21 The consumer profile for Thomas Cook travel agency

O. Díaz, S. Trujillo & S. Pérez 22 Outline  Introducting the setting: portlet variability  What can vary  When can it vary  How is it supported

O. Díaz, S. Trujillo & S. Pérez 23 When can it vary  When are blue decorators set?  We need to indicate for each feature when it needs to be committed to a particular variant (binding time)

O. Díaz, S. Trujillo & S. Pérez 24 Binding time: portlet setting  configuration time, the decision is set by the portal administrator any time during the lifetime of a running portlet  runtime, the decision is resolved during the enactment of the portlet (e.g. default departure airport) adaptive: automatically based on the user profile adaptable: user intervention through the edit mode

O. Díaz, S. Trujillo & S. Pérez 25 But …  Handling all variants through parameterization would make the implementation too complex The resulting code could be very cumbersome to develop and maintain  It is a problem of scalability Total number of variants (aprox.) = 3 X 2 X 2 X 2 x 2 x 2 = 96 combinations

O. Díaz, S. Trujillo & S. Pérez 26 Moreover …  Features can impact distinct artifacts

O. Díaz, S. Trujillo & S. Pérez 27 Binding time  Configuration time  Runtime: adaptive adaptable  Development time, the decision is taken when the portlet is being developed

O. Díaz, S. Trujillo & S. Pérez 28 Annotating the consumer model with binding times

O. Díaz, S. Trujillo & S. Pérez 29 Outline  Introducting the setting: portlet variability  What can vary  When can it vary  How is it supported

O. Díaz, S. Trujillo & S. Pérez 30 Software Product Line Approach  Shift of focus from a specific portlet to a portlet domain that sets the variation space (feature model)  Two processes domain engineering is in charge of determining the commonality and the variability among the portlet family: feature model + core assets application engineering is responsible for deriving a specific application portlet  Distinguishing between these processes permits to separate construction of the platform for the portlet family from production of the custom application portlet

O. Díaz, S. Trujillo & S. Pérez 31 Moving Software Product Lines to portlet development What needs to be changed in this diagram? Portlet consumerWSRP Producer getServiceDescription As an unregistered consumer Metadata Metadata indicates that registration is required, and certain data is required for registration register With registration data register Registration context Unique to the consumer getServiceDescription As a registered consumer Metadata + Offered portlets

O. Díaz, S. Trujillo & S. Pérez 32 New description parameters to account for the consumer model  Affects getServiceDescription() parameters  WSRP-compliant extension

O. Díaz, S. Trujillo & S. Pérez 33 New registration parameters to account for the consumer profile  Affects register() parameters  WSRP-compliant extension

O. Díaz, S. Trujillo & S. Pérez 34 A new actor: the domain producer Domain Producer getServiceDescription As an unregistered consumer. Metadata Metadata indicates that registration is required, plus an extension –the consumer model. register With registration data, plus an extension –the consumer profile. Portal regiser (Registers the portal.) Registration Context Unique to the consumer. getServiceDescription As a registered consumer. Metadata + cloned domain portlet

O. Díaz, S. Trujillo & S. Pérez 35 The domain producer  From the portal perspective, it behaves as a conventional portlet provider where the portal assumes portlets to be already deployed at the provider  But, if the binding time of a selected feature is “development time” then the portlet is not yet deployed!!!

O. Díaz, S. Trujillo & S. Pérez 36 Hence, behind the curtains…  The Domain Producer needs to: Generate the application portlet Deploy the application portlet into the so-called Application Producer Consume the application portlet through a locally deployed “domain portlet” that behaves as a proxy to the application portlet Portal Server HTTPWSRP Domain Producer WSRP Domain Portlet PL Factory Application Producer WSRP P1 WSRP P2P3 P4 Domain Portlet consume

O. Díaz, S. Trujillo & S. Pérez 37 Behind the curtains… Domain Producer getServiceDescription As an unregistered consumer. Metadata Metadata indicates that registration is required, plus an extension –the consumer model. register With registration data, plus an extension –the consumer profile. creates the portlet Portlet handle Portal PL Factory API Application Producer java:createPortlet the consumer profile. ant:stop deploys the portlet ant:start clonePortlet (Clones domain portlet, which is a proxy portlet) setPortletProperties (Updates the wsrp_portlet_handle preference with the returned portlet handle.) register (Registers the portal.) Registration Context Unique to the consumer. getServiceDescription As a registered consumer. Metadata + cloned domain portlet Handle cache

O. Díaz, S. Trujillo & S. Pérez 38 To recap …  Setting: portlets as enablers of SOA at the front-end  Problem statement: Portlets are coarse-grained components Reuse requires portlets to be engineered for variability Current parameterization approaches are not enough

O. Díaz, S. Trujillo & S. Pérez 39 Contributions  An SPL approach is presented WSRP extensions required to accommodate the consumer profile A new actor, the Domain Producer is introduced Generative SPL techniques required  A prove-of-concept sample case has been developed with WSRP4J

O. Díaz, S. Trujillo & S. Pérez 40 © Yukon valley by Marc Shandro Oscar Díaz Salvador Trujillo Sandy Pérez © Yukon Valley by Marc Shandro Thanks for your attention!!