Web Services for Remote Portlets (WSRP) provide solutions for implementation of lightweight Service Oriented Architecture (SOA). UDDI extension for WSRP enables the discovery and access to user facing web services provided by business partners while eliminating the need to design local user facing portlets. Most importantly, the remote portlets can be updated by web service providers from their own servers. Remote portlet consumers are not required to make any changes in their portals to accommodate updated remote portlets. This approach results in easier team development, upgrades, administration, low cost development and usage of shared resources. Furthermore, with the growing interest in SOA, WSRP should cooperate with service bus (ESB).In this paper, the author examines the technical underpinning of the UDDI extensions for WSRP (user facing remote web services) and their role in service sharing among business partners. The author also briefly outlines the architectural view of using WSRP in enterprise integration tasks and the role Enterprise Service Bus (ESB).
TopIntroduction
Leveraging web services through portals by means of the Java Portlet and WSRP standards gives companies a relatively easy way to begin implementing an SOA. Most portals have built-in support for the Java Portlet API and WSRP in the Portal Server which makes implementing a portal-based SOA even easier and cheaper. Portal support for the WSRP standard allows companies to easily create and offer SOA-style services and publish them in order to be accessed by other Consumers. The Consumers can combine several of these user facing services from diverse sources and portals to form the visual equivalent of composite applications. This approach delivers entire services to the other Consumer in a fashion which enables conveniently consume the services and use them without any programming effort. Furthermore, Enterprise Service Bus (ESB) can be used to create controlled messaging environment, thus enabling lightweight connectivity.
During the architectural design involving WSRP we have to consider several design issues associated with usage of currently web technologies:
In the following section we will discuss each of these topics and where possible, suggest the solution approach and highlight architectural points which would need special attention in the design.
TopCookies Handling
Cookies are commonly used in any web application. WSRP standard does not prescribe strictly how cookies should be handled thus introducing possible “disagreement” between the WSRP Consumer and Producer. These discrepancies are handled by WSRP extensions (WSRP 2.0 Portlet Specification, 2006). There have been several different approaches taken by Consumer implementations of how cookies sent to the Consumer are stored and distributed. The key difference is the distribution scope of a cookie set via a Set-Cookie response header during a markup operation other than initCookie() (getMarkup(), performBlockingInteraction(), handleEvents(), getResource()) (Polgar Jana, 2009). The WSRP extension enables the Producer to discover the method the Consumer uses to handle cookies (the actual protocol) and may allow the Producer to amend its behavior accordingly. In IBM WebSphere Portal Server cookies that the Consumer receives are stored in the Consumer session. They are later forwarded in requests to remote portlets. The portal also handles cookies set by resources that are served by the WSRP Consumer as a proxy. They are served by the WSRP Consumer as a proxy according to the standard cookie matching and expiry rules.
The two distribution schemes have been proposed:
The proposal in the WSRP extension so far suggests to tie portlet cookies to the transport level similar to Producer managed cookies as a plain HTTP state mechanism. Cookies should be transferred and managed at the transport level. This approach has already been introduced in the earlier specification 1.0 and does not require any need for a change.