SOA has come a long way from a concept to wide-scale adoption by the enterprise at multiple layers of IT. SOA implementation at the UI layer is the latest in SOA adoption trends. SOA has manifested itself in a number of flavors such as the creation of a rich user experience by using technology like AJAX (e.g., Google Maps), provisioning value-added services by mashing up data from multiple sources (e.g., chicagocrime.org), community-based peer-to-peer interactions (e.g., Facebook and Flickr), creating collective intelligence (e.g., Digg and del.icio.us), creating collaborative platforms often catering to a trusted community, and creating modular content-based sites (e.g., Marumushi.com).

All of these adoption models use an architecture best suited to their purpose that includes techniques such as of Java scripting at the browser end to asynchronously fetch data (e.g., Google Maps); creating content mashups at the server end from multiple data sources like RSS or screen-scraping techniques; and creating mashups purely at the client end, which might be difficult due to browser-based restrictions (e.g., Mozilla restricts direct data access from multiple machines from a single browser session). The core idea is there’s no single technique to address different kinds of scenarios for SOA adoption at the UI layer.

Scenarios that require aggregation and customization of reusable UI components along with value-added features of rich user experience and security can greatly benefit from using technologies such as AJAX and WSRP. Picking up on that point, we have proposed an architecture involving WSRP and AJAX that not only presents a customized UI to the user but can also handle non-functional requirements such as security, which assumes significance in creating trusted business communities.

In the proposed architecture (as shown in Figure 1) an Enterprise Service Bus manages UI customization based on a user profile by transforming a markup fragment generated from the WSRP producer. The ESB also handles features such as security and caching and acts like a single-point proxy for WSRP producers and the Web Services there by addressing any browser-side restriction. In this architecture AJAX controls are used to do partial updates of remote portlets by making a direct call to the ESB instead of routing the call from the browser to the WSRP producer via the WSRP consumer, thereby achieving significant performance benefits and a rich user experience.

The proposed architecture also handles overall security concerns like authentication, single sign-on (SSO), authorization, message confidentiality, and privacy. Consider a business scenario where a user needs to access data from more than one portlet from different WSRP producers either simultaneously or one after the other. In either of these cases the user credentials should be validated only once; this feature is provided using WSRP Security. Features like the selective access of portlets to certain users, message encryption, digital signatures, and SSO/secure access to enterprise services from browser-based AJAX controls is also provisioned using the enterprise service bus. Using WSRP and AJAX along with an ESB is an interesting proposition in a number of real-world scenarios that needs to share a dynamically customized UI based on consumer profiles and provisioning of a rich user experience, while catering to security requirements conducive to a trusted business community.

References

• OASIS Web Services for Remote Portlets (WSRP), OASIS. (accessed Dec 11, 2007).
• RSS 2.0 Specifications. (accessed Dec 11, 2007).
• Srinivas, P.; Krishnendu, K.; Lipika, S.; Shaurabh, B. “Coupling RDF/RSS, WSRP and AJAX for Dynamic Reusable Portlets: An Approach and a Use Case.” (accessed Dec 11, 2007).
• WSRP Security Technical Note, OASIS.