Web Services for Remote Portlets (WSRP)WSRP Kickoff Meeting March 18-20 2002Dr. Carsten LeueThomas SchckPeter Fischer

SummaryWeb Services for Remote PortletsIdea and GoalsArchitecture and DesignMarkup, Actions and Persistence

ImplementationJ2EE standalone versionIntegration into portal servers

StandardsRelationship to WSIAInteroperability

WSRP MotivationEnable the sharing of portlets (markup fragments) over the internetVisual Component Pool Internet Client Text processorClient BrowserClient Portal

Goals of Web Services for Remote Portlets (WSRP)Allow visual, interactive, user-facing web services to be easily plugged into all standards-compliant portalsLet anybody create and publish their content and applications as user-facing web servicesPortal administrators can browse public or private UDDI directories for user-facing web services to plug into their portals as new portlets, without any programming effort

Let portals interact and publish portlets so that they can be consumed by other portalsMake the internet a pool of visual web services, waiting to be integrated

Remote Portlets vs. data oriented WSWSRP visual & user facing & interactiveData service100101961001001019610010010196100WSPresentationLayerWSRP Service100101961001001019610010010196100WSPresentationLayer

WSRP Sample UsageStocks serviceDocument serviceCartoon serviceInternet or Intranet via SOAP

WSRP AdvertisingUDDIStocks servicePublish?FindBindLive ConnectionSOAPPublish

WSRP EntitiesServiceexposes the WSRP interfaceAggregation (client)consumes multiple WSRP servicesaggregates the services onto pagesDevicedisplays the aggregated markup to the end userhandles user inputService ComponentWSRPAggregation Component (client)Device Componentportletportletportlete.g. HTTP

WSRP InstancesScenarioThe same service may be accessed multiple times with different settingsThe server must manage and identify each of these settings

SolutionService + settings form a remote instanceClients always integrate instances of WSRP servicesThe management of the instances settings can be negotiated between client and serverAggregation Component (client)WSRPIBM stocksHP stocksSUN stocksService Component

What needs to be defined?InterfacesManagement of remote instancesMarkup retrieval and action processing

ProtocolSequence of callsMarkup rulesAction and namespace encoding

UDDI configurationHow to publish?What to publish?fooUDDI

Summary: Traditional Back-End Usage ScenarioLocal PortletsEfficient Local deployment of code Specific UI for each deployed portlet Business layer and presentation layer both located on the portal server Portlets cannot be shared between portals!! AggregationUserPortlet 1Portlet 2Portlet APIPortlet APIDataLayer 1DataLayer 2BE specificAPIBE specificAPIPortal Server

Traditional Web Service Usage ScenarioPortlets using Web ServicesDifferent Web Services expose different interfaces Specialized UI and proxy code required for each WS Local deployment of code is still necessary Data layer separated from presentation layer Portal ServerAggregationUserPortlet 1Portlet 2Portlet APIPortlet APIDataLayer 1Proxy 1Proxy 2WebService 1WS specificinterfaceDataLayer 2WS specificinterfaceWebService 2

Wish listClients viewPlug-and-playConfigurableInteractiveMarkup and user awareServers viewModest implementation overheadScalableClient awareUsers view Does not want to botherStandard?

WebServices for Remote Portlets (WSRP)All remote connections share a unified API No coding required, proxy and stub are coded once or generated automatically Stable and standardized transport mechanism (e.g. SOAP) Visual and user-facing Portal ServerWS specificinterfaceAggregationUserPortlet APIPortlet APIGenericProxyGenericProxyWebApp1WebApp2GenericStubGenericStubSOAPSOAPWSRPAPIWSRPAPIPresentation and Interaction Layer

Requirements for a remote APILocal caseEach Portlet forms a logical instancePortlets generate markup based on user and device profilePortlets can store state data in a database

Portlets can encode actions as URLs

Remote caseThe service must be instance awareUser and device data must be transmitted to the serviceThe service must either be persistent or it must delegate the persistence to the callerActions encoded by the service must be recognized and remoted by the callerTo authorize calls, remote instances are embedded in a binding contextAggregationPortlet APIWSRP API

WSRP ContractWSRP technical contracts defineAction handling and embedding in URLsNamespacing of named entitiesRestrictions on markup producedAllowed order of method invocation

WSRP interfaces defineLifecycle handlingMarkup RetrievalAction handling

Life Cycle ManagementcreatePortletInstanceServiceBindingInstanceSessionPersistentTransientbindClient[createSession]InstanceInstanceSessionSessionBindingAggregation Component (client)Service ComponentInstances are identified by handles

Example of Portal WSRP Service InteractionperformPortletActiondestroyInstancecreatePortletInstanceAggregation Component (client)Service ComponentAddsPortletRemovesPortletClicksActiongetPortletMarkupISSUserViewsPortletAllocate new InstanceGenerate Markup,(opt: create Session)Action Handling(opt: create Session)IIAISAIIAIISIDestroy instanceIASIA

Markup RetrievalClientUser informationClient stateLocaleInstance/session handleMarkup typeRequest parametersServerGenerates markup based on the clients request dataMay have internal stateMay embed encoded action URLs in the markupUse namespace to encode named entities

Markup Retrieval (contd)WSRPServiceRegistrydata2. Client stores stateUsermanagementuseruserdataMarkupRequestmarkupUserAggregationMarkupResponseWSRPAggregation Component (client)Service Component

State HandlingIdeaLet the server decide whether to store persistent data on the server or client

ConceptAllow the server to return its (modified) state in a serialized form to the clientThe client persists the servers state and passes it to the server in each requestServers may choose to persist only parts of its state (security)AggregationWSRPRegistryRegistry??

State Handling (contd)AggregationWSRPServicePortal RegistrySSS3. Client hands over servers stateService generates or modifies state2. Client stores stateAggregation Component (client)Service ComponentWSRP

Action HandlingServerEncodes actions in a special WSRP URL syntaxClientRecodes WSRP action URLs to match the portals URL syntaxIntercepts WSRP URL clicksInvokes action processing via WSRPServerProcesses an action and optionally invalidates its markupClientRequests new markup if necessary

Action Handling (local case)ActionencodergeneratePortletencodePortal URLclickBrowsermarkupInvoke action handlerdecoderInvoke action handler

Action Handling (remote case)PortletActionWSRP encodergenerateencodeclickBrowsermarkupdecoderWSRP URLInvoke action handlerProxyencoderPortal URLProxyparseServiceInterfaceInvoke action handlerProcess ActionrecodeSOAPSOAPmarkupWSRP

Action Handing (summary)TransparencyActions are represented by handlesNo changes in portlet programming requiredClient can handle WSRP URLs without knowledge of the servers detailsNeither client nor server needs to be a portalUniquenessURLs are automatically unique by using a GUIDEfficiencySimple string replacement required on client side (eg. BM algorithm){3096CAEB-031A-42a1-923C-F641CA340E4E}{0}Escape IdentifierAction handleClientMode

Namespace EncodingProblemThe portlets markup may contain named entities (e.g. form names)Names from different portlets that are aggregated onto a single page may conflictThe same portlet may be aggregated multiple times which leads to conflicting names

Service instance 2Aggregator (Portal)Name clash in StocksService instance 1StocksStocksSTOCKSSTOCKS

Namespace Encoding (contd)SolutionThe aggregator must lift every named entity into a unique namespaceWhen passing the names to the portlets the namespace must be resolved for each destination portletHow to locate the named entities in the markup?Write a parser for each markup type Let the portlet indicate the names by tagging them Service instance 2Aggregator (Portal)Ok, no naming problemsService instance 1ID1:StocksID2:StocksWSRP:STOCKSWSRP:STOCKS

Namespace Encoding (contd)WSRPServiceWSRPencoderWSRPdecodernamespaceencoderAggregationBrowserclicknamespacedecoderWSRPencoderWSRPdecoderAggregator (Portal)ServiceSTOCKSWSRP:STOCKSSTOCKSID1:STOCKSSTOCKSWSRP:STOCKSSTOCKSID1:STOCKSStart

Possible ImplementationsBaselineImplementing both a WSRP server and a WSRP client is very simple!

Sample ImplementationsJava based WSRP Server (on Tomcat)Java (Swing) based WSRP Client.NET service as WSRP ServerActiveX Control as WSRP Client

Implementing a WSRP Server on TomcatSOAP ServletWSRP InformationProviderServerSimpleServiceWSRP-letServiceWSRP-letRequest DispatcherClientPersistenceRegistryJSPJSPWSRPService generatesmarkup directlyService invokes astandard servletStandard servletcalling JSPsWSRPWSRPServlet

Making a portal server a WSRP serverRequest DispatcherDeviceSOAP ServletWSRPPortal ServerWSRPRouterPortletInvokerLocalPortletPortlet APIPrepare the WSRP parameterssuch that they are compatibleto the portals internal parametersAggregationDeviceRemotecaseLocalcaseOne singlelocal portletcan be used forthe local and theremote case.Portlet APIWSRP specific

Making a portal server a WSRP client AggregationDeviceRequest DispatcherPortlet APIGenericProxyPortletInvokerWSRPServicePortal ServerWSRP

Open Source Projects used for Reference Impl.Projects for server impl.Jakarta TomcatApplication serverAxisSOAP implementationUDDI4JUDDI accessXercesXML parsingStandardsSOAPBasis for the communication layerGuarantees interoparabilityWSDLUsed as the interface definitionUDDIServing portals publish the UDDI to make their content availableClient portals can query published portals from UDDIUDDI registry strores binding and configuration informationWSIAWSRP is a special case of a WSIA serviceRemote portlets will be accessible from WSIA clientsPortlet API

WSIA WSRP RelationshipBasic IssuesWSIA provides a generic set of basic interfaces for life cycle, presentation, persistence and event handlingWSRP extends selected WSIA interfaces and provides an own specialized interface to its services

Design GoalsImplementing a compliant service should be as easy as possibleServices should be extensibleAccessing interfaces should be efficient

WSIA WSRP InteroperabilityInteroperability goalsSpecialized clients can access WSRP services by only using the WSRP interfaceGeneric clients can make use of WSRP services by only using the WSIA interfaces

ImplicationsWSRP services must implement the WSIA interfaces for special cases only (the WSRP relevant ones)

WSIA WSRP Interoperability (contd)WSIAServiceWSIABaseWSIAWSIA aware service PortletWSIABaseWSRPWSRP aware serviceWSIAClientPortletProxyAdaptorWSRPWSIABaseWSIAWSIABaseWSRP

SummaryA standardized portlet model is key to interoperability between portal servers and portletsPortlets can be published as WSRP servicesWSRP services can be wrapped in PortletsInteroparability with different platformsJ2EE client and server.NET client and serverIn sync with WSIA

Client Server Communication (Java)To be demonstratedFind a portlet via UDDIBind to the portletReact on an actionWSRPClientTomcatServerWSRP

Java client consuming at .NET serviceIIS.NETobjectMS OfficeasOLE serverWSRP

WSRP service inside a Word DocumentTomcatServer.NETobject

Questions!?

Publish/Find/BindServiceRequestorServiceProviderServiceRegistryPublishFindBind Access point Description tModel key service description title default expiry window states markup types locales keywordsUDDI entryXML descriptionWSRP ServerServerDatabaseWSRP ClientClientWSRP

Action Handling (URL recoding)PortletsUse the same URL encoder in local and remote caseClientProvides different encoders for the local and remote (same interface) caseEach action is assigned a locally unique action handleRecognizes WSRP URLs in the markupDecodes the URL to distinguish between window state changes and remote action handlesWSRPDefines globally unique action identifiers which prefix action handles

Information FlowPersistent AttributesPortal registration initialization per portalPortlet ID to bind to initialization per portlet

Transient AttributesMarkup type (HTML, VoiceXML, etc.)LocaleUser informationWindow stateSessionActions

transfer per request

Web Services for Remote Portlets (WSRP) some DetailsMarch 18-20 2002Dr. Carsten LeueThomas SchckPeter Fischer

SummaryWebServices for Remote PortletsRecapitulation: Architecture and DesignInterfacesProtocoll

ImplementationClient SampleServer Sample

MiscPerformance, CachingDiscussion

Portlet / User InteractionUser actionsRead the markupTrigger actions by clicking on linksEnter data into forms and send it to the serverEdit the portlet

PortletGenerate markup based on user settings (identitiy, markup type, locale)Encode actions as links in the markupEncode namespacesReact on actions triggered by the user by modifying the portlets stateReceive form data entered by the user and process it

PerformanceGoalUse as little rountrips as possibletwo roundtrips to setup a portlet (bind, createInstance)one single roundtrip per markup request (getPortletMarkup)one or two roundtrips per action (invokePortletAction)

Enable caching of remote services

Efficient markup interpretationFast string search algorithmsUse of escape tokens for efficient parsing

CachingRequirementsWSRP clients may want to provide caching to relieve the WSRP serviceThe WSRP service must provide information on the expiry of its content

SolutionThe WSRP service returns an expiry flag to the client on each markup callEach action event may explicitely expire the markupeither a subsequent getPortletMarkup call followsor the service returns its markup in a single roundtrip

Boyer Moore String SearchRequirementsString search is needed for URL rewriting and namespace encoding

BM offers a verify efficient string search algorithmRun time typically of order O(N/M) N = len(text), M = len(token)Small initialization costs

Implications for WSRPSelect the same escape token for URLs and namespacesChoose the token as long as possible consisting of unlikely characters(Robert S. Boyer, J Strother Moore: A Fast String Searching Algorithm, Communications of the ACM, October 1977, Volume 20, Number 10)

WSRP Interfacepublic interface WSRPComponent extends WSXLBindable { // markup and actions public WSRPMarkupResponse getPortletMarkup(String hPortlet,WSRPMarkupRequest request) throws WSXLException;

public WSRPActionResponse invokePortletAction(String hPortlet,String hAction,WSRPActionRequest request) throws WSXLException; // instance management public String createPortletInstance(String hBinding, String classID) throws WSXLException;

public String createSession (String hPortlet) throws WSXLException;

public void destroyInstance (String hGeneric) throws WSXLException;

public String bindClient () throws WSXLException;

};

WSRP Interface bindClientInput:NoneOutput:Handle identiying the binding

Remarks:Can be omitted if the binding information has been transfered otherwisepublic String bindClient () throws WSXLException;

WSRP Interface createPortletInstanceInput:Binding handleIdentifier of the service within the server (LUID)Output:Handle identiying the remote instance public String createPortletInstance(String hBinding, String classID) throws WSXLException;String hBinding = bindClient();String hInstance = createPortletInstance(hBinding,107);...destroyInstance(hInstance); destroyInstance(hBinding);

WSRP Interface destroyInstanceInput:Arbitrary handleOutput:none public void destroyInstance (String hGeneric) throws WSXLException;String hBinding = bindClient();String hInstance = createPortletInstance(hBinding,107);...destroyInstance(hInstance); destroyInstance(hBinding);

WSRP Interface getPortletMarkupInput:Instance or session handleMarkup request containing client data, user data, portlet state etc.Output:Markup response public WSRPMarkupResponse getPortletMarkup(String hPortlet,WSRPMarkupRequest request) throws WSXLException;String hBinding = bindClient();String hInstance = createPortletInstance(hBinding,107);

WSRPMarkupResponse res = getPortletMarkup(hInstance,request);System.out.println(res.getResultString());

destroyInstance(hInstance); destroyInstance(hBinding);

WSRP Interface invokePortletActionInput:Instance or session handleAction handleAction request containing client data, user data, portlet state etc.Output:Action responsepublic WSRPActionResponse invokePortletAction( String hPortlet, String hAction, WSRPActionRequest request) throws WSXLException;...WSRPActionResponse res = invokePortletAction(hInstance,hAction,request);String out = res.getResultString();if (out==null)out = getPortletMarkup(hInstance,request).getResultString();System.out.println(res.getResultString());

Implementing a WSRP Server on TomcatSOAP ServletWSRP InformationProviderServerSimpleServiceWSRP-letServiceWSRP-letRequest DispatcherClientPersistenceRegistryJSPJSPWSRPService generatesmarkup directlyService invokes astandard servletStandard servletcalling JSPsWSRPWSRPServlet

Instantiating a WSRP servicethe server defers the service type from the incoming class handlethe registry maps the service type against a service factorythe factory instantiates the service

ServerServiceFactoryServiceRegistrytype_0x_classClassIDtypemappingcreate factory1234classWSRPcreateInstanceinstantiation5

Summary

Questions!?

Working on the development of WPSProblem: works fine locally, but remote portlets would be coolNeed to align the attempt with other vendorsSome work has been done tohether with WSIAPrincipal ideas a little bit more in detail that lead to this meetingLevel of abstraction and interoparability to achieveTo prove that the concept works in principle we have implemented a J2EE and .NET based versionBasis for a proposal for a reference implementationBasic idea came from a portal servers point of view: powerful aggregation component, still the content must be provided on the portal serverIdea: make the net the ultimate content providerClients no not need to be portals but any compliant containerKeep it as simple as possibleNot data oriented by visual and interactiveFind-publish-bind triangleNo programming for portal providers- Position WSRP as opposed to the standard WS approach- Data oriented vs. visual and interactive- Layered view to the usage scenario- Services may be used by different clients in different configurations- So far so good if the connection to a WS has already been established. But how to locate a service -> UDDIServices register under a predefined tModel key (= interface)Clients can find the remote servicesClients can bind and integrateLets define terms.Service component: a WS that exposes the WSRP interface via SOAP. The service generates markup based on user and client information (e.g. Name, locale, markup type) Aggregation component: the client that consumes a WSRP service. In general the aggregation component takes input from different sources and transforms the input into one page (markup stream). An example is a portal server. But it is also possible to have a client that only consumes the markup of one single server.Device component: the device that displays the aggregated markup to the end user and primarily handles user input.hCloser look at the WSRP architecture:- Different configurations require the notion of instances.statement: the information comes in in form of data not markup or any other visual formInformation: massive coding effort, information still comes in in form of dataConfusion about the variety of the many different interfacesInformation: the Lets compare the local and remote case to find out the requirements....Closer look at life cycles.Four logical levels of instances:Service itselfBinding loosely associates service and client. This can be thought of as logical coupling between client and server. Access to individual services is only granted in the context of a binding.An Instance is the logical union of data and service logic. This can be represented as a real instance in terms of a programming language or in the form of a flyweight pattern. Important: the instance is persistentSession lives within the scope of the instance and holds transient data (e.g. Usage history)How does the markup retrieval work?Data from the client to the serverData back from the server

Instances hold state per definition: which side is responsible for persisting the state:Example: portal server as a service. The server has large database capacities and happily holds the instances state. Simple WSRP news provider that has minimal state per user but millions of users. Would exceed the servers capacity.

Let the server choose who persists.What is an action: reaction to the click on a link or button by the user.Transfer user information and form data