Building a RESTful Enterprise Integration with Oracle and SnapLogic

In the enterprise space, integration problems abound.  IT must connect numerous legacy systems in new applications to adjust to the changing needs of the business. Technologies to achieve such integrations include SOAP based Web Services (WS-*) and binary protocols such as CORBA and RMI. This blog entry discusses a different approach - integration using lightweight REST APIs.

To illustrate the concept, a demo has been created showing how to combine data from Oracle's WebLogic Portal product with data from Oracle Database. This demo is accomplished using RESTful APIs as the data transport mechanism, and is orchestrated by a third party data integration product called SnapLogic. This demo was showcased at a REST Symposium I organized for Oracle employees in July, which featured speakers from Oracle, SnapLogic and Yahoo! (see below for details).

 

What is REST?

REST is an acronym for REpresentational State Transfer, and was coined by Roy Fielding in his PhD thesis published in 2000. It is not a technology, a standard, or a product. REST is an architectural pattern that describes the underlying architecture of the World Wide Web and how it came to be such a massively scalable computer application. The WWW is known to have the following qualities:

• Highly scalable - millions of websites
• Fault tolerant - at any given time, many websites are offline, but the web continues to work
• Performance- HTTP allows for intermediaries to help improve performance via caching
• Interoperable - nearly every computing platform has a browser, and websites are written in a myriad of languages
• Distributed - websites and clients span the globe
• Self describing - there is no user manual required for users to navigate the WWW

Aren't the above qualities desired for any enterprise systems as well? The power of REST lies in the idea that the same fundamentals that work so well for the WWW can also work with great success within the enterprise. 

There are plenty of resources on the web that explain the principles of REST, and so I have no intention of duplicating that material. In essence REST describes an architecture in which:

• Application resources (objects, in the OO world) are exposed as URIs
• HTTP requests are used to retrieve and update data on the server
• The HTTP requests utilize the standard HTTP verbs (GET, POST, PUT, DELETE) to define the API operations, helping client developers by providing a consistent interaction model

An example is the following:

• A client issues a request to the following URI:  http://wlp.bea.com/dvt/api/content/autos.jsp
• The server response contains a list of automobiles, described in a format such as XML
• The client consumes the XML document and outputs the entries that match the user's criteria

This pattern is seen most often with Rich Internet Applications (RIA), where the client is a browser and the API is being invoked via Ajax (more precisely, the JavaScript XmlHttpRequest facility). While this is a very powerful use of RESTful APIs and is alone enough to justify the creation of RESTful APIs, this use case is not the focus of this blog entry. I would encourage you to research Ajax application development for more background.

Instead, we will look more closely at how RESTful APIs can also make data integration easy.

 

RESTful Integration in Concept

RESTful APIs expose data in a way that is easily consumed. Invoking the API is as easy as issuing an HTTP request, which is possible to do from almost any programming language/platform. While enterprise data integration can be implemented using a wide variety of technologies, the purpose of this blog entry is to show how it can be done with RESTful APIs.

As stated in the preamble, there are non-RESTful approaches to solving this problem. A SOAP based solution could be implemented and for some cases is the preferred approach. If your use case requires the support of the WS-* family of standards, then WS-* is the way to go. What this example shows is that REST offers an alternative and is appealing in its simplicity.

Instead of discussing the theory, it is more useful to look at a working example.

Example: Oracle WebLogic Portal + Oracle Database + SnapLogic + REST

Consider the following example:

• An insurance company is using the Content Management capabilities of Oracle WebLogic Portal to store auto claims. Each claim contains a photo of the damaged vehicle, and some data about that vehicle such as make, model, year and a description of the damage.
• The insurance company also has a Oracle Database that is populated with industry data regarding the fair market value of the cars, and the salvage value. These values are specific to the make, model and year.
• The insurance company wishes to put the repair of the damaged vehicles out to bid to a community of auto repair shops. The intent is to allow shops to bid on the vehicles they are willing to repair using the industry data and the information from the claim.

The insurance company decides to use a quick and lightweight approach to build a data mashup with a web UI. The implementation is achieved using RESTful APIs, and orchestrated using a product called SnapLogic. SnapLogic is an open source server that provides:

• Many pre-built connectors to expose native data sources as RESTful APIs (e.g. database, spreadsheet, XML)
• Sophisticated data manipulation capabilities, such as joins, filtering, sorting, and computations
• A variety of output formats for the completed RESTful feed

The data integration demo was implemented as follows:

• A RESTful API is configured for the WebLogic Portal (WLP) Content Management system. In this example, the RESTful API was custom built as a JSP, but this capability will come pre-built in a future version of WLP.
• The Oracle Database schema is exposed as a RESTful data API using an out of the box Database Reader component of the SnapLogic server.
• The two data sources are joined using a SnapLogic pipeline. The pipeline reads the claims from WLP CM and the industry data from the database using the RESTful APIs.
• The joined data is converted into an ATOM syndication feed via the SnapLogic server (using an Xml Writer component)
• The ATOM feed is displayed in a ATOM reader, in this case the Google Mashup Editor UI

All of this is achieved via configuration, not code. The architecture is depicted in this diagram:

The resulting web application appears like this:

For more detailed information on the implementation of this mashup, consult the companion entry on SnapLogic's blog:

• SnapLogic CTO Mike Pittaro's blog entry on the Oracle mashup

Oracle and REST

This is a simple demonstration that shows the ease of implementing integrations using RESTful techniques, especially when combined with a REST integration enabler such as SnapLogic. It is a stated goal of some of the Oracle product groups to provide RESTful APIs for access to product data. Check with the roadmap for each product to understand when these APIs will be available.

Attendees to Oracle Open World 2008 will have several sessions related to Oracle product groups and REST:

• Deploying a Web-Oriented Architecture with Oracle WebCenter, Oracle WebLogic Portal, and Oracle WebCenter Interaction
• Give Users What They Want: Web-Based Data Access and Rich Internet Applications
• No REST for the Weary: REST APIs and the Activity Stream

Oracle Internal REST Symposium

For Oracle employees, more information is available on the company intranet. I organized an internal symposium on REST amongst the product groups on July 28th, 2008. The event included speakers from Yahoo! and SnapLogic.

The agenda covered a number of RESTful topics, including:

• Explaining REST (Subbu Allamaraju of Yahoo!)
• Industry product landscape - SnapLogic (Mike Pittaro, CTO SnapLogic), and other products
• Enabling technologies - RESTlet, JSR 311, WADL, JSON marshalling
• Oracle Product efforts - presentations by various products groups on their REST efforts

Access to the recordings and slide decks can be found on the intranet here.

Resources

You may find the following links helpful:

• The hosted WLP CM REST feed of crashed automobiles
• The WLP CM REST API implementation (offered as a JSP for easy distribution, but could be a servlet)
• The hosted demo on Google Mashup Editor
• SnapLogic website.
• SnapLogic CTO Mike Pittaro's blog entry explaining the implementation
• SnapLogic CEO Chris Marino's blog entry discussing his thoughts on the REST Symposium
• REST wikipedia entry

Technorati Tags: REST,Oracle,SnapLogic,WebLogic,WebLogicPortal,integration,HTTP,GoogleMashupEditor

WebLogic Portal: Exposing Portlets (JSR 168, WSRP, JSF, Struts, etc) as Enterprise Google Gadgets

Wondering how to expose Google Gadgets from WebLogic Portal? As promised, this is the second entry in a two part series talking about Google Gadgets. The first entry explained how to build a simple gadget. Now we will explore how to surface a Java portlet as a gadget using WebLogic Portal. Exposing a Google Gadget from any WLP portlet type (JSR 168, WSRP, JSP, Pageflow, JSF, Web Clip, etc) requires no coding - just a simple XML configuration file. This blog entry will show you exactly how to do it.

NOTE: this blog entry was originally posted April 23rd, 2008 on my previous blogging system (dev2dev.bea.com).

History of the Integration

As I mentioned in the first posting we have been doing demos of WLP portlets as Google Gadgets for a long time - since the second half of 2006 with our WLP 9.2 release. This was all possible because of a feature introduced in that release called Portlet Publishing. Portlet Publishing allows any WLP hosted portlet to be exposed as a URL. If you understand the basics of Google Gadgets, you can hopefully see how this feature can be used to turn any portlet into a gadget simply by referencing that portlet's URL in the gadget descriptor.

Early demos used a servlet to dynamically generate the appropriate Google Gadget descriptor on the fly. We even experimented with clever hacks to enable Single Sign On between iGoogle and WLP. We worked with the Google Gadget engineering team to explore ideas in this area.

But in the end we decided not to productize the integration. This is due in large part because authoring the Google Gadget descriptor for a portlet is quite easy, and therefore an official feature wouldn't add tremendous value. Additionally, we were concerned about the supportability of such a feature, for example what would happen if the descriptor format changed. Also, the explorations around authentication were not enterprise quality approaches, and so not something we wanted to promote.

Therefore, at this time WLP does not offer a "Generate Google Gadget..." option in the IDE, or provide any other specific feature. However, as this blog entry will show, using the FULLY supported feature of Portlet Publishing, you can expose your portlets as gadgets with NO CODING required.

Portlet Publishing

Before we can talk about generating a Google Gadget, we need to take a look at Portlet Publishing. Once again, this feature exposes any WLP hosted portlet as a URL - an HTTP addressable end-point. The power of this feature is that any thing that can consume an HTTP end-point (e.g., an IFrame within any webpage) can be host to a WLP portlet. It is important to note that Portlet Publishing works for all WLP portlet types, like JSR 168, WSRP, JSF, Struts, Web Clipper, etc.

This means that with a single deployment of your portlet on WLP, it can be used over the following channels simultaneously:

• Directly embedded in a standard WLP portal/desktop
• Directly embedded in any JSP hosted on the WLP server (see the portalFacet JSP tag)
• Federated to external WSRP consumers (WSRP is a web services standard for consuming remote portlets)
• Federated to any consumer of HTTP, notably browsers via IFrames and XmlHttpRequests (which means ANY website on the planet)

In WLP 9.2 and WLP 10, Portlet Publishing was limited to the library instances of portlets. This meant user preferences were not supported through the HTTP channel. However, with WLP 10.2, Portlet Publishing has been augmented to allow for Desktop Instances (and thus user preferences) to be exposed over the HTTP channel. Consult the documentation for more details on this point.

To consume portlets published over the HTTP channel in any web page, you can inject the portlet into the HTML using one of these techniques:

• An inline frame (iframe) that points to the URL to the portlet
• DOM Injection - using simple JavaScript that WLP provides, you can dynamically inject the portlet into the page using Ajax (XmlHttpRequest)

Once again, consult the documentation for more details on these points.

Exposing your WLP Portlet as a Google Gadget

You have hopefully read my previous blog entry on how to build a simple Google Gadget. This section builds on that knowledge. Essentially, we will author a Google Gadget descriptor that points at a WLP portlet exposed over HTTP (via Portlet Publishing).

To make this entry as simple as possible, we will use the library definition form of the Portlet Publishing URL. For example, assume you have a portlet that is exposed at this URL:

http://wlp.bea.com/dvt/portlets/wlp/stackWLP.portlet

If you are unfamiliar with WLP, the .portlet file is a file based XML document that describes a portlet's meta data. In this case, it has been deployed in the portlets/wlp directory of the dvt webapp. When directly addressed, Portlet Publishing kicks in and serves up the portlet implementation associated with this .portlet file (this is the library definition approach to publishing).

You can now easily author a gadget descriptor that targets that URL, and thus exposes that portlet as a Google Gadget:

<?xml version="1.0" encoding="UTF-8" ?>

  <Module>

<ModulePrefs

title="WLP Portlet Gadget"

height="120"

author="Peter Laird"

  />

  <Content href="http://wlp.bea.com/dvt/portlets/wlp/stackWLP.portlet" type="url" />

</Module>

Copy this gadget descriptor to a public web server, and then add this gadget to your iGoogle portal as I showed in my previous post. And Presto!

The Fine Print

Some details to think about:

Titlebars: WLP will by default render a titlebar to the portlet, and so will iGoogle. To avoid nested titlebars, use the "light" decoration option with Portlet Publishing desktop portlet instances.

Authentication: if you have a cookie based web SSO solution in place, your users will automatically be logged into the WLP server even when the user navigates to iGoogle (by virtue of how iframes work). In other circumstances, you will need to provide a login screen within the portlet.

Add to Google button: it is often nice to have an "Add to Google" button on the portlet. This is easily done by just copying the URL pattern seen on other sites that provide such a button. You will essentially need to embed the URL to your gadget descriptor into the button link.

Preferences: you will need to decide what to do with preferences. WLP manages preferences on the server side. If your portlet is exposed over multiple channels, stick with that. However, if the portlet will ONLY be consumed as a Google Gadget, you may consider using the Google provided preference service.

JavaScript Libraries: Google provides a number of JavaScript libraries for Gadget developers. When developing a portlet that will only be exposed as a gadget, feel free to use these. However, if the portlet will be exposed over multiple channels (like on a WLP desktop), be aware that none of the Google libraries have been certified within WLP.

References

• WLP Portlet Publishing documentation - an amazingly powerful feature, allows WLP portlets to surface just about anywhere. Available since WLP 9.2.
• Google Gadget Developer documentation - excellent documentation covering gadgets in much greater depth than I have done here
• Google Gadget Ventures - get funding to develop your enterprise gadget
• Enterprise Gadget Handbook - Jonathan Sapir of LimitNone produced an extensive document discussing the merits of enterprise gadgets
• WLP Demo Server - running WLP server

 

Technorati Tags: gadgets,google,weblogic,portal,portlets,168,wsrp,JSF,Java,enterprise2.0

Introduction to Google Gadgets

We have been showing how to expose WebLogic Portal portlets as Google Gadgets for almost two years now. Embarrassingly enough, we haven't written any blogs or articles on HOW to do it. We have answered email questions about it, but nothing public. This two part blog series will correct that omission. You will hopefully see that it is really quite simple to do. This first entry will talk about building a generic Google Gadget (without WLP), and then the following entry will show how to convert any WLP portlet into a gadget.

NOTE: this blog entry was originally posted April 22nd, 2008 on my previous blogging system (dev2dev.bea.com).

What are Google Gadgets, and iGoogle, please?

Google Gadgets are web based widgets/portlets/[insert your favorite web component term here] that are based on technology provided by Google specifically to make federating gadgets easy. To see gadgets in action, the best place to try them out is on the iGoogle portal.

Gadgets can really do anything. This example shows an eBay integrated gadget that allows a user to interact with their eBay account within the gadget:

The technology provided by Google can be lumped into these buckets

• An xml file format for describing a gadget (called the descriptor)
• A gadget preferences model - for storing user specific preferences for a gadget external to the gadget implementation
• Various JavaScript libraries for doing useful things
• An online directory of pre-built gadgets
• iGoogle - the reference platform for users to use gadgets
• Google Gadgets for your Webpage - a JavaScript mechanism for including a gadget on ANY web page

Several things are notably missing from what Google provides with regard to gadgets

• Gadget hosting - aside from a few official Google gadgets, all the gadgets are hosted independently by their creators
• Gadget validation - treat every gadget with suspicion; even though it is flying the colors of a well known brand it may be hosted by a guy in a basement.
• Authentication - there is no provided mechanism for gadgets to inherit authentication from the consuming page, notably no single sign on with iGoogle

Finally, note that there is another gadget technology offered by Google called Desktop Gadgets. There gadgets are targeted toward Google Desktop, and aren't related to the gadgets we are discussing.

The Google Gadget Phenomenon - why should you even care?

Google Gadgets and iGoogle were the fastest growing product offered by Google in 2006 and had strong growth again in 2007

“The star performer for [2007] was Google’s personalized start page service iGoogle which increased traffic in the 12 months to November by 267.64%.” (TechCrunch)

Useful Gadgets get heavily used:

“The Google gadget ecosystem received 960 million pageviews last week” (Niall Kennedy)

These metrics are largely based on use of gadgets and iGoogle in the consumer space. But consider how your enterprise can benefit from deploying Google Gadgets:

• A new channel to your customers within iGoogle
• Offered as a widget to your customers to place on their own web pages
• A new channel to your partners/employees within iGoogle

Building a Simple Google Gadget - as easy as falling off a bike?

This section discusses the express route to building a gadget. Steps to build:

1. Create a gadget implementation, which is nothing more than an HTML document served from a public web server.
2. Create a gadget XML descriptor, that refers to the gadget implementation.
3. Add the gadget to iGoogle.

Step 1: Create the Gadget Implementation

Save this HTML into a file on a public web server.

<html>

<body>

Hello World.

</body>

</html>

Step 2: Create the Gadget Descriptor

Save this XML into a file on a public web server (I have also hosted one publicly here for now: http://wlp.bea.com/blogs/simplestGadget.xml). You will need to update the href included in the body to the URL to your HTML document created by step 1.

<?xml version="1.0" encoding="UTF-8" ?>

<Module>

<ModulePrefs

title="Simplest Gadget"

directory_title="Simplest Gadget"

title_url="http://wlp.bea.com"

description="Very very simple gadget."

height="120"

author="Peter Laird"

/>

<Content href="http://wlp.bea.com/blogs/simplest.html" type="url" />

</Module>

Step 3: Add the gadget to iGoogle

Login to iGoogle, and then click the Add Stuff link, and then Add Feed or Gadget link. Provide the URL to the XML document created in step 2.

Step 4: Enjoy!

 

Next Steps

In the next blog post, I will show how to expose any WLP portlet as a Google Gadget. Stay tuned!

References

I only covered a small part of the Google Gadget technology. Their developer documentation is excellent, so please refer to it for more details:

• Google Gadget Developer Documentation
• Building Dynamic Google Gadgets in Java - a slide deck I have used to present Google Gadgets to Java developers

Technorati Tags: weblogicportal,googlegadgets

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Deploying the ALBPM Workspace into WebLogic Portal

Customers that purchase both WebLogic Portal (WLP) and AquaLogic Business Process Management (ALBPM) will certainly want them to work together. Specifically, customers want to be able to deploy the ALBPM Workspace user interface as portlets on a WLP portal. This blog explains how to do that, and provides a script to help automate the most tedious steps.

NOTE: this blog entry was originally posted December 17th, 2007 on my previous blogging system (dev2dev.bea.com).

Use Case

The ALBPM Workspace contains a total of 4 portlets. By default, they deploy in their own pre-built web application. But if you have both ALBPM and WLP in your environment, it would be useful to be able to deploy the portlets into WLP.

The four portlets are:

• Actions Menu: lists the operations the user can perform, like create a new process
• Views Menu: lists the various views available, like process inbox and bookmarks
• Worklist: displays the list as directed by the Views menu, like the list of active processes
• Instance Detail: shows the details of a specific process

A view of the completed Workspace on WLP:

Integration Implementation

Behind the scenes, there are some challenges to this project. First, when the user authenticates with WLP, they shouldn't have to also sign into ALBPM. Fortunately, ALBPM implemented an SSO mechanism in ALBPM 6.0. This can be enabled via a couple of checkboxes during the configuration of ALBPM (more on this later).

Second, the portlets and all supporting file based artifacts need to be brought into the WLP Web Project. While most of this is straightforward, it is an error prone operation. Also, merging in the necessary web.xml entries for the ALBPM workspace into the stock WLP web.xml is tricky. A simple error can create headaches. This part screams for an automated solution.

To make this integration as easy as possible, I have created a distribution that contains movies and an Ant script. The movies will to help guide you through the process. The Ant script removes a lot of tedious steps from the process.

Note: while this integration guide and script are deemed reliable, they are not officially supported. The official documentation is the supported source of information on this integration.

ALBPM 6.0 Workspace for WLP 10

There is official documentation to explain how to integrate the products. But sometimes seeing the integration is the best teacher. Therefore, the distribution that I have created includes a series of movies. Additionally, it contains an overview presentation on the process of integrating the products. Finally, the actual deployment of the ALBPM Workspace onto WLP is scripted via an Ant script that I provide.

I have hosted the files of the distribution in this location:

ALBPM 6.0 Workspace for WLP 10 Download Center

Note: to view the Flash FLV movies you will need an FLV player, such as the free FLVPlayer

ALBPM_for_WLP_slides.zip and ALBPM_for_WLP_slides_movie.zip

Start with these. One zip contains the Powerpoint presentation, the other contains a movie of me talking through the slides. This deck explains what the integration is all about, and the high level steps needed to perform the integration.

ALBPM_for_WLP_movie1.zip, ALBPM_for_WLP_movie2.zip, ALBPM_for_WLP_movie3.zip

These zip files contain detailed walk throughs of various parts of the integration. View these movies in order, and use the Pause button so you can follow along while you perform the integration on your machine.

ALBPM_for_WLP_script.zip

This zip contains the Ant script and associated files that will automate the ALBPM Workspace deployment into WLP. This script does a ton of file copying and also includes some new files (.portlets) to make this a smooth process. While you can do all of this by hand, the script gets the job done quickly and correctly.

Acknowledgements

I didn't complete this project by myself. The ALBPM Development and QA teams (Eduardo, Nico, Mariana, Alex, Mariano, and others) did a lot of work on sorting out the process to get the products integrated. Additionally, some folks from BEA Professional Services (Paddy in particular) helped get this going. THANKS!

Additional Resources

Need more information? Here are some good links to get you started:

• WLP Download - download WebLogic Portal (minimum version 10.0)
• ALBPM Download - download AquaLogic BPM (minimum version 6.0 MP1)
• ALBPM for WLP Official Documentation - official docs for integrating the products
• Alex Toussaint's Blog - ALBPM product manager's blog
• Jesper Joergensen's Blog - ALBPM product marketing blog
• Josh Lannin's Blog - WLP products manager's blog, check out the 5 part WLP futures series

Technorati Tags: weblogicportal,albpm

Comments from the original blog:

• Hi Praveen -

  Yes, something with the Apache config is doing strange things with that. We just did a lot of Apache work to speed up the WLP demos, and I am nervous to touch it to sort out the issue. I have found that Firefox, not IE, should be able to download the files fine. Can you try that?

  PJL

  Posted by: plaird on May 5, 2008 at 11:16 AM

• Peter, thanks a lot. It seems like a very useful information but I am not able to download using the hyperlinks. Can you pls help me in getting these? my emailID: awasthypr@saic.com Thanks again!!

  Posted by: praveenawasthy on May 5, 2008 at 2:15 AM

• ALBPM 6.0 MP2 Update

  I produced the script and movies against ALBPM 6.0 MP1. However, I tested against 6.0 MP2 with success (with one caveat).

  The only issue is that there are some JSPs in the ALBPM MP2 workspace that cause the Workshop IDE (WLW) to report build failures (about 45). You will need to disable JSP validation for the WLP web project to get around this.

  Project Properties->Validation->uncheck the JSP validator

  I have updated the presentation to include this GOTCHA, and will also work with the ALBPM team to discover the root cause.

  Thank you Neville for reporting the issue.

  PJL

  Posted by: plaird on January 8, 2008 at 9:31 AM

• Kunai -

  Sorry about that, I was using an 3rd party file share to host the files. I have rehosted the files on our WLP demo server at wlp.bea.com. I updated the link in the blog too.

  Thanks for the note!

  Posted by: plaird on January 3, 2008 at 11:35 AM

• Peter, I'm about to get started on deploying ALBPM Workspace on WLP and I would've loved to have downloaded your slides, movies on the subject. However, it appears that the hyperlinks for these downloads have been disabled. Is there any other way we can exchange this information? Please feel free to send an email at "kunal.r.shah@citi.com" Regards, Kunal R Shah

  Posted by: kunalrshah on January 3, 2008 at 11:07 AM

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

Discussion on WebLogic Security: Authentication Providers, Internal LDAP, JAAS, WebLogic Portal, Profile

This blog entry comes from an email thread I had with a fellow BEA colleague. We traded a number of emails - he asked a lot of great questions about how WebLogic Portal (WLP) supports various security features. Since WLP relies heavily on WebLogic Server for those features, my answers apply to WebLogic in general and not just Portal. I am posting the email thread here because I think that this discussion might be of interest to others.

NOTE: this blog entry was originally posted September 22nd, 2007 on my previous blogging system (dev2dev.bea.com).

Before I show the thread, I should provide a glossary of abbreviations and concepts:

• WLS: WebLogic Server, the J2EE application server that most people associate with the name "WebLogic"
• WLP: WebLogic Portal, the J2EE portal product built on top of WLS
• CSS: in this context, not cascading style sheets. Common Security Service is the componentized security package that WLS uses for security.
• SSPI: the pluggable security subsystem provided by CSS to WLS
• ATN: authentication, which refers to the process of verifying who a user is (with a password perhaps)
• ATZ: authorization, which refers to the process of deciding whether the authenticated user has the privilege to perform a certain action
• UUP: a WLP feature that aggregates profile information for a user from a variety of backend sources using a plugin architecture
• Internal LDAP: an LDAP repository embedded in CSS historically used for some default SSPI providers

Discussion Thread

From: Colleague

Quick follow-up to our discussion in the hall at BEAWorld, you said that WLP wants to stop using the internal LDAP server altogether and use the database instead. I forgot, though, did you say that had already happened in a previous release, or is that slated for the next release?

From: PJL

Yes and no.

For ATN, WLP does not use internal LDAP. WLP switched to the WLS/CSS provided SQLAuthenticator in WLP 9.2. This does not mean that customers must use it, it is merely the default. A customer may choose to toss the SQL ATN provider and plug in an LDAP, Active Directory, etc. provider instead.

Here is the WLS doc reference to SQL Authenticator: Configuring RDBMS Authentication Providers

As for ATZ (WLP entitlements and delegated administration), we rely on the default ATZ provider from WLS, which in turn uses the internal LDAP store. Currently, we are tightly bound to the default ATZ provider for various reasons, and so WLP therefore has a hard dependency on internal LDAP. This is not ideal, and so WLP wants to eliminate the internal LDAP dependency.

The forthcoming solution to this problem is for WLS to support a database as the backend store for the default ATZ provider. They should have this in the next WLS version (but no promises folks!), and so we will pick it up in a future release beyond Flatirons (the next WLP release).

From: Colleague

Right, makes sense. A couple more questions:

Can customers configure more than one ATN provider, e.g. extranet users in SQL and employees in Active Directory, is that a supported WLP configuration?

Do documents stored in WLP's virtual content repository (VCR) use the default ATZ provider as well?

Where does the Unified User Profile (UUP) fit into this picture?

From: PJL

>> Can customers configure more than one ATN provider, e.g. extranet users in SQL and employees in AD, is that a supported WLP configuration?
Yes, and you can do logic like AND and OR via the JAAS control flags (this is WLS/CSS doing that, not WLP).

>> Do documents stored in WLP's virtual content repository (VCR) use the default ATZ provider as well?
Yes, Entitlements defined on VCR documents are stored in the default ATZ provider. The documents and metadata themselves are in the WLP database if the BEA Repo is being used, or in third party systems like Documentum or Sharepoint.

>> Where does the Unified User Profile (UUP) fit into this picture?
Profile is the third leg to this: ATN, ATZ, and Profile. For WLP, all three are independent, and linked together just by username. So ATN could come from Active Directory, whereas profile can be aggregated from, for example, a mainframe, LDAP, and Siebel via UUP. WLP passes the UUP plugins the username that was authenticated, and then each plugin is responsible for retrieving the correct profile info.

From: Colleague

One piece I'm still a bit fuzzy on is how groups fit into this whole picture, I've been reading this section on edocs:

Adding and Managing Groups (WLP docs)

It sounds like WLP periodically syncs group info from the providers into some local store, which I'm guessing is the default RDBMS. Is that correct?

From: PJL

Good question.

Actually WLP doesn't really maintain its own group mapping. The ATN providers provided by WLS are responsible for doing that. We do some caching of the group tree because it can be expensive to build, so that is what those docs are talking about. But we don't write that in-memory cached tree out to the database or file system.

To see how an ATN provider is involved in group membership, look at how the SQL Authenticator gets configured as an example:

SQL Authenticator Configuration help

You can see that it has methods for managing group relationships. How this happens at runtime is a deeper dive into the WLS/CSS SSPI ...

WLS/CSS authentication providers have two components - the JAAS code that actually performs the authentication, and then a set of "mbeans" that the provider chooses to implement. Most of the mbeans are optional to implement. Here is the list for ATN providers which provide the manageability around users and groups:

SSPI MBean Quick Reference

• GroupEditor Create a group. If the group already exists, an exception is thrown.
• GroupMemberLister List a group's members.
• GroupReader Read data about groups.
• GroupRemover Remove groups.
• MemberGroupLister List the groups containing a user or a group.
• UserEditor Create, edit and remove users.
• UserPasswordEditor Change a user's password.
• UserReader Read data about users.
• UserRemover Remove users.

So WLP uses methods from the GroupReader and GroupMemberListers mbeans on the ATN provider to have access to group membership. The SQL Authenticator implements the GroupReader and GroupMemberLister mbeans by using those SQL queries. The LDAP ATN provider GroupReader and GroupMemberLister mbeans derives Group structure from the directory structure.

That's a little abstract - it sometimes helps to see the code. Here is the javadoc for GroupReader and GroupMemberLister java interfaces that the ATN providers implement:

• GroupReader javadoc link
• GroupMemberLister javadoc link

So WLP is not really managing it's own group repository, it's the ATN Providers that are storing that information. A little complicated, I know.

From: Colleague

So does the LDAP ATN provider support the GroupEditor as well? That is, can you write group membership changes back into external LDAP repositories?

From: PJL

The LDAP ATN provider that WLS/CSS provides is read only. You can see what mbeans it implements by looking here:

1. Navigate to BEA-HOME\wlserver_10.0\server\lib\mbeantypes
2. Open cssWlSecurityProviders.jar
3. Find the .xml file that is associated with the provider you care about, in this case LDAPAuthenticator.xml
4. In that xml file, you will see the mbean interfaces that it implements listed:

<MBeanType

 Name          = "LDAPAuthenticator"

 DisplayName   = "LDAPAuthenticator"

 Package       = 
   "weblogic.security.providers.authentication"

 Extends       = 
   "weblogic.security.providers.authentication.LoginExceptionPropagator"

 Implements    = 
   "weblogic.management.utils.LDAPServer,
    weblogic.management.security.authentication.UserReader,
    weblogic.management.security.authentication.GroupReader,
    weblogic.management.security.authentication.GroupMemberLister,
    weblogic.management.security.authentication.MemberGroupLister,
    weblogic.management.security.authentication.UserPasswordEditor,
    weblogic.management.security.authentication.GroupMembershipHierarchyCache"

 PersistPolicy = "OnUpdate"
> 

Since it does not include GroupEditor or UserEditor, you can infer that it is a read-only provider (aside from password). If you are a WLP customer, another way to see which mbeans are implemented for each ATN provider is through the Portal Administrator tool (PAT). Because the PAT disables certain user/group management functions in the tool depending on what mbeans are implemented on the selected provider, the PAT provides UI to show which mbeans are implemented. See the image below:

From: Colleague

Also, is there any way to create a group that includes members from more than one provider, e.g. "John" from the DB and "Bob" from LDAP? Or do you need to use roles for that scenario?

From: PJL

Yes, group membership is aggregated from the collection of installer providers. Multiple providers can contribute membership associations to a single group. Or how about this question: can "Bob" be authenticated by the SQL ATN provider, and put into the "Human Resources" group via the LDAP provider? I believe this does work.

More information...

I would encourage you to use these resources to learn more about WebLogic Security:

• Security Fundamentals - official WebLogic security primer
  
  
  
  
  
  



• WebLogic Server SSPI - the CSS security architecture
  
  
  
  
  
  



• SSPI Provider Samples - reading aboout the SSPI is good, but coding is even better. Try building your own ATN provider.
  
  
  
  
  
  



• Foundations of WLP Security - official doc about how WLP integrates into WLS Security
  
  
  
  
  
  



• Implementing SSO with the WLS SSPI - my dev2dev blog on SSO with Identity Asserters
  
  
  
  
  
  



• JAAS Fundamantals - a dev2dev article by Bill Kemp and Rich Helton
  
  
  
  
  
  



• Bastion - a blog devoted to WebLogic Security
  
  
  

Technorati Tags: WebLogic,Security,Authentication,WebLogicPortal,JAAS

Comments from original blog

• 
  
  
  
  

  Carlo -

  
  
  
  
  
  
  
  
  

  OK, good to hear that it worked for you!

  
  
  
  
  
  
  
  
  

  We don't certify any other authorizers/role mappers. It sounds like at least some use cases work.

  
  
  
  
  
  
  
  
  

  Where my comment comes from is the fact that historically we had code that went around the SSPI and directly to embedded LDAP. Based on your feedback, I looked through the current code base and didn't find anything like that. I will check with the engineer who owns that code to verify. So I might have been wrong in saying it will not work at all.

  
  
  
  
  
  
  
  
  

  I did find a couple of places where you may see odd behavior:

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  • There is code to check if the Admin server is running when doing any policy updates. This is because embedded LDAP relies on the Admin server for distribution of updates in the embedded LDAP replicates in a cluster. You will probably see errors in your logs if your Admin server is down, even if you aren't using embedded LDAP.
    
    
    
    
    
  
  
  
  • WLP has a class called LDAPChangeListener which flushes a role policy cache entry if a role policy has been updated in embedded LDAP. If you are running in a cluster, and are not using embedded LDAP, it looks like you will have to redeploy the application to get the updated role policy recognized across the cluster. Can you verify if this is true with your system?
    
    
  
  
  
  
  
  
  
  
  
  
  

  Thanks for the correction!

  
  
  
  
  
  
  
  
  

  Regards - PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on January 2, 2008 at 11:31 PM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Peter thank you for your answer. Why should the protection of WLP assets (e.g. Portlets) not work? I have written my own XACML Authorizer (based on the OpenSource SUN XACML implementation) and a RoleMapper also and it works. If WLP correctly use the WebLogic Security framework, it should work and fortunately it does ;-) Did you mean that in a future version it will not work? This scaries me because we are strongly basing our security on these implementations (and on XACML). ciao carlo

  
  
  
  
  
  
  
  
  

  Posted by: cdrcdr on December 21, 2007 at 6:19 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Carlo -

  
  
  
  
  
  
  
  
  

  What types of resources do you wish to manage with the Role and Access policies? Do you wish to entitle WLP assets such as portlets and content items, or JEE assets? For JEE assets, you could use an external repository by plugging in additional providers into the SSPI.

  
  
  
  
  
  
  
  
  

  But as for WLP assets, first the bad news. You will not be able to replace the entitlement engine that WLP uses for WLP assets. But I would actually argue that you don't want to replace the entitlements engine, you really want to replace the runtime policy repository. Unfortunately, WLP does not currently support storing WLP policies in anything other than embedded LDAP, except in one case (see ALES link below).

  
  
  
  
  
  
  
  
  

  While this isn't great news, WLP will at least remove the embedded LDAP dependency when WLP ships on WLS 10.3. You will be able to store your runtime ploicy repository in a DB then.

  
  
  
  
  
  
  
  
  

  Now for the good news...

  
  
  
  
  
  
  
  
  

  There is a solution available today. I would encourage you to look at ALES, because it does what you want to do. It centralizes role and policy management in an external repository.

  
  
  
  
  
  
  
  
  

  But if ALES is not suitable, there is another potential workaround here. It is possible to *manage* the policies in your external system, and then periodically sync the policies into the *runtime* repository (the embedded LDAP now, DB in a later release). An issue will be figuring out how to author WLP policies; specifically being able to create the WLP asset resource strings. Also, you will need to figure out how to allow for the external management tool to discover the set of manageable resources that do not already have policies.

  
  
  
  
  
  
  
  
  

  Hope this helps... PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on December 14, 2007 at 8:34 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Great article! One question: we have our RoleAssignmentPolicies (XACML)as well as the AccessPolicies (XACML)in differnet repositories: we need to wtite our own XACML based authorizer (and Entitlements engine) and (possibly) remove the BEA one from the realm. Would it be possible? There would be problem/limitation doing so? regards carlo

  
  
  
  
  
  
  
  
  

  Posted by: cdrcdr on December 13, 2007 at 5:26 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Josh - I haven't worked with the LDAP providers in years, so I can't comment on the specifics. But in the follow up blog entry to this one, I explain how to dive into the cssWlSecurityProviders.jar to find the implementations of the BEA Atn Providers and how providers often extend other providers.

  
  
  
  
  
  
  
  
  

  By doing that now, I see that the BEA IPlanetAuthenticator extends the base LDAPAutenticator, which already implements UserEditor and GroupEditor. If you wish to implement custom logic for those mbeans, extending the BEA IPlanetAuthenticator provider is probably the way to go. You would create a subclass overriding the UserEditor and GroupEditor methods as necessary, and then wire it up using an XML descriptor.

  
  
  
  
  
  
  
  
  

  Look to the IPlanetAuthenticator itself as an example of how to wire up a provider subclass. Put your custom atn provider in its own JAR in the same directory as cssWlSecurityProviders.jar and you should be good to go.

  
  
  
  
  
  
  
  
  

  PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on October 18, 2007 at 9:15 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Peter, What steps would I need to take to add the UserEditor and GroupEditor MBeans to the IPlanetAuthenticator? If I intend for users to be created using a custom objectClass defined in the iPlanet Directory Server that has custom attributes, I'm assuming that I'll have to customize the MBean to do this. Is this correct? Thanks, Josh

  
  
  
  
  
  
  
  
  

  Posted by: joshbrookes on October 17, 2007 at 11:28 AM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hi Luciano - yes, this is why we are keen to eliminate internal LDAP as the repository for ATZ. The best way is to have a Propagation inventory that contains a backup of your policies. In that case, you can wipe it clean, and then reapply the inventory (this is not so simple if you do admin work in production, you will need to be careful about the merge). Also, a colleague was looking into a more fine grained fix (directly updating internal LDAP to fix the problem records). I don't know off-hand where he ended up with that - I will point him to this entry. Ciao, PJL

  
  
  
  
  
  
  
  
  

  Posted by: plaird on September 24, 2007 at 11:40 PM

  
  
  
  
  
  
  

• 
  
  
  
  
  
  
  
  

  Hello Peter, very interesting reading. I wish that more articles like this one could be published by Bea. I take advantage of this blog to ask you a question: we have hit on a Portal9.2Mp1 production installation the infamous out of sync between embedded Ldap and the portal db (p13n tables). Result, Delegated Admin page fails with a NPE and Entitlements also are not very well. It's easy to fix this problem in a non prod environment (wipe p13n tables, wipe ldap files) but which is the recommended way to deal with this issue in a clustered production environment? Thanls a lot Luciano Fiandesio

  
  
  
  
  
  
  
  
  

  Posted by: koevet on September 24, 2007 at 11:21 PM

  
  
  
  
  
  
  

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

BEA WebLogic Portal + Swivel.com + Excel Spreadsheet = Enterprise Data Mashups

IT works hard to build web applications and other infrastructure to support the needs of information workers within the enterprise. However, it is commonly found that significant portions of the business are managed using ad hoc processes based around email and spreadsheets. While we have been tackling the issue of collaboration via email for years, we should also be looking at the role of spreadsheets and the amount of data locked up inside of them. In this blog entry I will explore an approach that allows spreadsheet data to be managed by IT, and then visually mashed up with other data sets. This solution combines the Content Management capabilities of WebLogic Portal with the data mashup features of Swivel.com.

NOTE: this blog entry was originally posted June 26th, 2007 on my previous blogging system (dev2dev.bea.com).

Mashups in the Enterprise

While mashups started in the consumer space, mashups are beginning to migrate into the enterprise space as well, as noted by technologists such as Dion Hinchliffe. The promise of cheap, quick and easy applications that tie together existing assets is appealing to both IT and the business. Enterprise mashups don't intend to solve every problem, but they do deliver rapid results with enough functionality to draw in the information workers. In previous blog entries and a webinar, I have been showing how to build enterprise mashups using web technologies. This entry will diverge and show how a non-web technology, namely the spreadsheet, can power an enterprise data mashup.

The enterprise data mashup will be built using two products that will be combined to help IT manage spreadsheets within the enterprise. First, I will use the Content Management capabilities of WebLogic Portal to manage the workflow of spreadsheets. Second, I will show you how a new tool called Swivel can extract valuable information out of spreadsheets, visualize it, and then combine in with other data to produce an enterprise data mashup. Finally, the output of Swivel will be fed back into WebLogic Portal Content Management, completing the lifecycle.

Managing File Based Assets using WebLogic Portal's Content Management

As a developer, you can probably appreciate the peril in not using a source code control system. Some of us have worked at places where the central code repository for an application is some guy's machine. The integration environment has a name, like "Larry" or "Bob", and is powered by bagels and coffee. With the widespread use of source code control systems, hopefully you haven't seen this in quite some time.

The same should apply to the non-developer community as well. Instead of source code repositories, file based documents should be managed with a content management system. Without belaboring the point, here is a list of features that make a proper content management system a critical component to deploy in the enterprise:

• Versioning - roll back that bad checkin from 3 AM
• Locking - ever had to hand merge two spreadsheets? A checkout mechanism can do wonders
• Auditing - nothing is more fun than playing the blame game when the train wreck happens
• Workflow - because who can keep track of who needs to sign off on that press release
• Search - philosophically, if a document cannot be found, does it really exist?
• Security - spreadsheets with salary information have a habit of just turning up on public shared volumes; this is bad
• Virtualization - there will never be only one, so WLP serves as a virtualization layer across multiple repositories
• Reuse - documents stored on a worker's laptop are not available for other uses

Because this blog entry is ultimately about enterprise mashups, the last point it especially relevent. Before you can pursue an enterprise mashup project for the enterprise data in these documents, they must be accessible. A content management system is the natural tool for that job, and therefore the first step in this type of project.

Using Swivel to Mashup Enterprise and Public Data

Swivel (www.swivel.com) is a startup funded by Minor Ventures in the bay area. Swivel offers a hosted service that aims to be the YouTube of spreadsheets. It allows the general public to upload spreadsheets from all corners of life, and provides mashup capabilities to combine those data sets to produce meaningful graphs. The intent of this service is to, in their words:

Swivel's mission is to liberate the world's data and make it useful so new insights can be discovered and shared.

What lies underneath that high-level statement is a rich web interface to a powerful data mashup engine. To get right to the point, the workflow to have in mind when using Swivel is as follows:

• Upload one of your spreadsheets
• View the graph of the data from that spreadsheet
• Find a public data set that may correlate to your data (world temperatures, Dow Jones average, GDP by nation, etc)
• Mash them together to create a combined graph - which may show interesting correlations

To take a short tour of the service, visit the Swivel Tour. Or, just visit the site and start clicking around, it is fairly intuitive. Here is a screen shot of the tool in action:

And the result of a mashup - this graph is measuring the sales of Avitek Air Conditioners against world temperature fluctuations. There appears to be some correlation:

The graph above is a sample enterprise data mashup. It shows how sensitive Avitek sales are to weather, which could affect projections and planning for the company's future. This seems valuable to me. In the real world, perhaps you will find some interesting trends that have not yet been identified in your company's performance. It's hard to really say until you give it a try.

But I know what your first question will be, because it always the first question no matter what the topic is. What about security? Who in their right mind would publish sensitive enterprise data to a hosted service? First, ever hear of Salesforce.com? Second, Swivel will offer a private data service in the near future that will allow you to keep your uploads private.

The remainder of this blog entry will cover an integration that I built that combines the Content Management features of WebLogic Portal with the data mashup capabilities of Swivel.

A Look at the WebLogic Portal and Swivel Integration

Note: please don't get the wrong idea about the status of this integration. I built this integration as a working demonstration of the combination of two great products. The code will be made available on dev2dev Code Share, and is not faked in any way. The integration uses only public BEA APIs, and those APIs are supported. But the integration itself is not an officially supported BEA product or solution.

The integration consists of a portlet that is deployed into WebLogic Portal. This portlet is custom designed to manage your Swivel graphs. It also provides an easy user interface to publish new spreadsheets to Swivel in order to create new graphs.

The integration is based on the following workflow:

• A spreadsheet is created in Excel
• The spreadsheet is managed in WLP Content Management, with features such as versioning, workflow, and security
• The Swivel Portlet is used to locate and publish the spreadsheet to Swivel as a new data set
• The data is mashed together with other Swivel data to create a new interesting graph
• The graph is published back to WLP Content Management, to complete the lifecycle

Watch, Learn, and Swivel!

Sometimes the best path towards understanding is to see a demo, and I think this is one of those times. To support this, I have recorded a video of the integration, showing all of the important parts and how they hang together.

Instructional Videos:

To view the demonstration videos, navigate to the video page, or click on one of the links below:

• Part 1: adding the Swivel portlet to WebLogic Portal
• Part 2: navigating the library of spreadsheets and graphs in WebLogic Portal
• Part 3: publishing a spreadsheet from WLP Content Management to Swivel
• Part 4: using the Swivel user interface to create compelling enterprise data mashups from spreadsheets
• Part 5: completing the round trip, bringing the Swivel graph back into WLP Content Management

Hosted Demo:

To try the integration hands-on, follow these steps:

• Navigate to the WLP 10 Playground at wlp.bea.com
• Create a user account
• Add a Page by clicking on the Add Page tab
• Add the Swivel portlet by clicking on the Add Portlet link and dragging the Swivel portlet to your page
• Start Swivelling!

CUFS - Measuring the Potential of Swivel

Swivel aims to empower information workers to build data mashups, but is it on target? I have covered other mashup tools in previous blog entries. Some of the tools I have blogged about are developer focused, and I also covered Schmapplets which is a mashup tool targeted at non-technical users. With the Schmapplet blog entry, I proposed 4 metrics for determining if a non-technical user will find success with a particular tool. Those 4 metrics, abbreviated as CUFS, are as follows along with how Swivel measures up to each:

• Comfortable: spreadsheets are in that sweet spot of comfort for many Information Workers
• Useful: it is up to you to decide: what can Swivel do for you? Please give it a try, and post a comment below
• Focused: it's a focused use case, which allows the UI to be specialized and avoids the need for coding
• Simple: as a hosted service it is pretty easy for both IT and the business. Just write a check and away you go!

To summarize, I think Swivel is on the right track towards building a workable mashup toolset for the information worker.

Last Mile for Swivel

Swivel is currently in Preview mode, which means not all of the intended features are in place. With that said, the site is already quite usable and can be employed for general use within the enteprise. However, a couple of additional features will be needed to allow Swivel to really take hold within the enterprise. Fortunately, they are already in plan to be delivered for the official launch of the service.

Two key features for enabling Swivel within the enterprise:

1. Private data
I covered this above; sensitive enterprise data cannot be publicly available. The revenue model for Swivel depends on getting this feature in, so I think it's a safe bet to assume it's coming soon.

2. Data API
The current integration requires the user to manually publish graphs back to WLP. It would be nice for this process to be automatic, which would be possible if a data API is available. I have been in communication with the Swivel team, and it sounds like this API is forthcoming.

Resources:

• dev2dev Code Share - the Swivel portlet for WLP will be posted on Code Share, I will update the comments below with the direct URL (as of 2009, CodeShare  is offline an unavailable)
• wlp.bea.com - WebLogic Portal Labs, demos of the latest thinking from the WLP engineering team
• Swivel - spreadsheet driven data mashups with Swivel
• My Articles and Blog - more writings on mashup tools and WebLogic Portal
• Swivel blog - see what the Swivel guys are up to
• James Dellow and Mark Bower blogged their opinion that Excel is in fact one of the earliest forms of a mashup tool

Technorati Tags: weblogicportal mashup

Comments from Original Post

• The Swivel Portlet for WebLogic Portal has been submitted to dev2dev Code Share. It can be found at this location.

  Posted by: plaird on June 26, 2007 at 11:32 AM

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand

BEA WebLogic + Microsoft Popfly = Enterprise Mashups

In my last blog entry, I showed how to build a data driven Mashup using Microsoft Popfly. That exercise was a stepping stone to this blog entry: I will show how WebLogic Portal can surface enterprise data into a Popfly Mashup. In particular, I will show how images located in a WebLogic Portal Content Management repository can be brought into a Popfly project. This demo shows how BEA products can be the key ingredient in your enterprise mashup projects.

NOTE: this blog entry was originally posted June 4th, 2007 on my previous blogging system (dev2dev.bea.com). Comments on the old blog were not transferred.

NOTE: as of 2009, Microsoft has announced that it is terminating support for Popfly.

Building a Mashup with Microsoft Popfly

My last blog entry covered Microsoft Popfly, which is a new mashup building tool from Microsoft. Instead of covering that topic again, I will simply point you to that blog entry if you need some more context.

Reference: previous blog entry

Enter BEA WebLogic Portal and Enterprise Mashups

We have been showing customers how WebLogic Portal can be a key component in your enterprise mashup project. You have hopefully seen how WLP can consume Google Gadgets and other external services to create portal based mashups. WLP can also work in reverse - WLP can produce its portlets onto other, non-portal web pages and mashups like iGoogle. For a quick recap of these capabilities please consult these resources:

• Webinar: Enterprise Mashups with WebLogic Portal 9.2 - I presented an introduction to the Enterprise Mashup space
• WebLogic Portlet Publishing - an article discussing how WLP portlets can be produced onto non-portal web pages
• Add a WLP Portlet to iGoogle - WLP portlets can be exposed as Google Gadgets
• WebLogic Portal Playground - home of the WLP engineering labs, showing some online demos of WLP+Google Gadgets

In this blog I will demo WLP participating in a Mashup in a different way: it will be a data feed producer for a mashup. Specifically, I will show you how you can surface images from the WLP Content Respository as a JSON data feed. That data feed will in turn be combined in a Popfly mashup using the technique I covered in the previous blog entry.

This helps to show how WebLogic Portal can be the gateway from the enterprise into the consumer mashup space. WLP provides not only a UI framework for producing portlets (as in the iGoogle case), but it is also a virtualization layer for enterprise data services. The diagram below shows this idea. Notice that WLP provides virtualization capabilities for User Profile and Content Management. Once virtualized, WLP can produce profile and content REST services with ease.

Before I show you how to build it, take a quick look at the WLP+Popfly live demo hosted here. You will be prompted to download the Microsoft Silverlight browser plugin - you must accept to see the demo. Notice how the Photosphere is animating with a set of pictures? Those pictures are being retrieved from the WLP instance at http://wlp.bea.com. Note: the Photosphere Block is computationally expensive, so your CPU usage will spike.

Curious to know how I built it? Follow the steps below to build your own enterprise mashup with WebLogic Portal and Microsoft Popfly!

Step 1: Provisioning the WLP Content Repository

The first thing to do is provision the WLP Content Repository with images. In an enterprise, this will be done by content authors who are using Content Management to store the artifacts that they create on a daily basis. In my case, I loaded a number of pictures I took at the Smithsonian Air and Space Museum in Washington DC into the content repository on wlp.bea.com. I made sure that anonymous users are entitled to see the content, and that all images are in 'Published' status.

Next, I modified the default image content type by adding a multivalued text property called "tag". Then, with each picture, I added a few tag words that describe the picture, like "plane", "propeller", "jet", "warplane", etc. This allows us to quickly query the images by keyword.

Step 2: Building a REST-style service for the WLP Content Repository

In the first blog post, I showed how to build a Popfly Data Block to consume a data service that returns JSON. We are going to use that same pattern in this mashup. To implement this, we need to deploy a REST service for WLP CM.

I turned to dev2dev CodeShare to quickly get my service up and running. There is a download available (that includes sample code for working with the WLP CM repository). I lifted the code from the Search sample to build my service. Also, Tejas Joshi coincidently just blogged about how to create a CM service just a few hours ago. My REST service does the following:

• Queries the WLP CM system for all images
• Optionally, the service accepts a tag to search for to scope the result set, like "plane"
• The result set is composed as a JSON response, including the URL for each image
• The client can then deserialize the JSON and extract the URLS for the images

The servlet I created for the service is implemented with a .JSP, not a .java file, to allow for easier distribution for others who want to use it. For a quick demo of the service, try the hosted service:

• JSON result set of all images on wlp.bea.com
• JSON result set of all images with the tag "plane" on wlp.bea.com

I won't post the code for the JSP here. But I will see about submitting it to CodeShare. (as of 2009, CodeShare is no longer available)

Step 3: Building the Popfly Data Block for Consuming the JSON Service

Now that we have our JSON service, we need the associated data block in Popfly. Since I have already covered how to build a JSON data block in the previous blog entry, I will just show the code and move on. The code snippets below show how I defined the JSON consumer block. I have shared my block on Popfly with the title Air and Space Museum Images, so you should see it in your Block palette.

Block Descriptor

<?xml version="1.0" encoding="utf-8"?>
<block class="AirAndSpaceMuseum">
  <providerName>AirAndSpaceMuseum</providerName>
  <providerUrl>
    http://ajaxmashup.googlepages.com/
  </providerUrl>
  <providerLogoUrl>
    http://wlp.bea.com/images/bea_logo.gif
  </providerLogoUrl>
  <blockIconUrl>
    http://wlp.bea.com/images/bea_logo.gif
  </blockIconUrl>
  <operations>
    <operation name="getImages">
      <description>
        Images from the Smithsonian Air and Space Museum, 
        hosted on BEA WebLogic Portal.
      </description>
      <inputs />
      <outputs>
        <output isArray="true" type="custom" object="Photo" />
      </outputs>
    </operation>
  </operations>
  <objects>
    <object name="Photo">
      <field name="url" type="imageUrl" 
                isArray="false" />
      <field name="thumbnailUrl" type="thumbnailImageUrl" 
                isArray="false" />
      <field name="id" type="id" 
                isArray="false" />
      <field name="owner" type="userName" 
                isArray="false" />
      <field name="title" type="title" 
                isArray="false" />
      <field name="longitude" type="longitude" 
                isArray="false" />
      <field name="latitude" type="latitude" 
                isArray="false" />
    </object>
  </objects>
</block>

Block Code Implementation

// create our namespace for the Block
function AirAndSpaceMuseum() { }

AirAndSpaceMuseum.prototype.getImages = function () {  
	// set the URL to our JSON service
	// hosted in CM on wlp.bea.com
	// tagged with the word 'plane' to scope it 
    url = "http://wlp.bea.com/dvt/"+
          "api/content/images.jsp?tag=plane";

	// get the JSON list of locations
    var resultJSON = environment.getText(url);
    var responseObject = eval("(" + resultJSON + ")");
    
    // convert to the Array type we want
    var resultsArray = new Array();
	for(i=0;i < responseObject.images.image.length; i++) {
		resultsArray[i] = new Photo(
			responseObject.images.image[i].id, 
			"Peter Laird", 
			responseObject.images.image[i].image_name,
			responseObject.images.image[i].url, 
			responseObject.images.image[i].url,
			0, 0);
	}		
    return  resultsArray;  
};

// Define the output payload, must match the XML 
function Photo(id, ownerName, title, url, mediumUrl, 
               lon, lat)
{
    this.id = id;
    this.owner = ownerName;
    this.title = title;
    this.url = mediumUrl;
    this.thumbnailUrl = url;
    this.longitude = lon;
    this.latitude = lat;

    this.toString = function()
    {
        return "<table><tr><td><a href='" + 
          environment.escapeQuotes( this.url ) + 
          "' target='_blank'><img src='" + 
          environment.escapeQuotes( this.thumbnailUrl ) + 
          "' title='" + 
          environment.escapeQuotes( this.title ) + 
          ", ID: " + 
          environment.escapeQuotes( this.id ) + 
          "'/></a></td><tr><td>" + 
          this.latitude + ", " + this.longitude + 
          "</td></tr></table>";
    }
}

Step 4: Assembling the Mashup

As we saw in the previous blog entry, assembling the mashup is easily done. In this case, we connect the output of our Data Block to the input of the Photosphere Block. Without any coding, the Mashup is complete. Click the following link to see it in action:

WebLogic Portal + Popfly Mashup

This image shows the linkage of the mashup in the Popfly workspace:

Taking a Step Back

Now that you have invested yourself in reading this tutorial, I will state without hesitation that this specific mashup has absolutely no value to the enterprise. Are your customers or employees really going to be entertained by images from your enterprise rotating in a Photosphere? Is it going to improve their productivity? Doubtful. To be a true mashup, shouldn't two services (like JSON+Flickr) be combined like in my previous blog? Probably.

So what was the point of building this mashup?!?

My intent was to show how easily it is to surface data from the enterprise into Popfly using WebLogic Portal. Mashups crave easily consumable data - which is exactly what WLP can provide. Finding a useful purpose for that data once it is in the Popfly environment is entirely up to you.

BEA WebLogic Portal + Microsoft Popfly = Enterprise Mashups

Happy mashing!

The simple CM REST service used above was submitted as a code sample here:

Simple CM REST CodeShare Project (as of 2009, CodeShare is no longer available)

Technorati Tags: mashup,weblogicportal,popfly,rest,json

Want short SaaS/Cloud news updates throughout your day? Subscribe to the ondemand Twitter microfeed. http://twitter.com/ondemand