Upcoming Oracle Web Center Interaction Training

Just wanted to let you know that I (formerly Plumtree’s Lead Engineer, worked with hundreds of different Plumtree, BEA and Oracle customers and now an Oracle ACE Director) am leading a public training course over the next two weeks and if you’re interested, there are few available slots left.

We’re partnering with training provider Peak Solutions and you can find the full details on their web site. Here’s the critical information:

THIS Monday, May 3rd and Tuesday, May 4th in Harrisburg, PA
Oracle WebCenter Interaction Administration – $1,200
Deployment planning, installation, configuration, maintenance, troubleshooting, etc.

NEXT Monday, May 10th, 11th and 12th in Harrisburg, PA
Oracle WebCenter Interaction Portlet Develoment in Java and .NET (also Ruby and PHP) – $1,800
Hello world all the way through advanced portlet dev concepts like setting preferences and using caching

Please drop us a note if you’d like to attend. There are only 4-5 slots left, so please act now to reserve your space!

Top Ten Tips for Writing Plumtree Crawlers that Actually Work

Just in time for Halloween, I’ve decided to publish my Top Ten Tips for Writing Plumtree Crawlers that Actually Work. This post may scare you a little bit, but hey, that’s the spirit of Halloween, right?

[Editor’s note: yes, we’re still calling it Plumtree. Why? I did a Google search today and 771,000 hits came up for “plumtree” as opposed to around 300,000 for “aqualogic” and just over 400,000 for “webcenter.” Ignoring the obvious — that a short, simple name always wins over a technically convoluted one — it just helps clarify what we’re talking about. For example, if we say “WebCenter,” no one knows whether we’re talking about Oracle’s drag-n-drop environment for creating JSR-168 portlets (WebCenter Suite) or Plumtree’s Foundation/Portal (WebCenter Interaction). So, frankly, you can call it whatever you want, but we’re still gonna call it Plumtree so that people will know WTF we’re talking about.]

So, you want to write a Plumtree Crawler Web Service (CWS), eh?

Here are ten tips that I learned the hard way (i.e. by NOT doing them):

1. Don’t actually build a crawler
2. If you must, at least RTFM
3. “Hierarchyze” your content
4. Test first
5. When testing, use the Service Station 2.0 (if you can get it)
6. Code for thread safety
7. Write DRY code (or else)
8. Don’t confuse ChildDocument with Document
9. Use the named methods on DocumentMetaData
10. RTFM (again)

Before I get into the gory details, let me give you some background. First off, what’s a CWS anyway? It’s the code behind what Oracle now calls Content Services, which spider through various types of content (for lack of a better term) and import pointers to those bits of content into the Knowledge Directory. This ability to spider content and normalize its metadata is one of the most underrated features in Plumtree. (FYI, it was also the first feature we built and arguably, the best.)

Each bit of spidered content is called a Document or a Card or a Link depending on whether you’re looking at the product, the API or the documentation, respectively. It’s important to realize that CWSs don’t actually move content into Plumtree; rather, they store only pointers/links and metadata and they help the Plumtree search engine (known under the covers as Ripfire Ignite) build its index of searchable fulltext and properties.

Today, Plumtree ships with one OOTB CWS that knows how to crawl/spider web pages. Not surprisingly, it’s known as the Web Crawler. Don’t let the name mislead you: the web crawler can actually crawl almost anything, as I explain in my first tip, which is:

Don’t actually build a crawler.

But I’m getting ahead of myself.

So, back to the background on crawlers. Oracle ships five of ’em, AFAIK: one for Windows files, one for Lotus Notes databases, one for Exchange Public Folders, one for Documentum and one for Sharepoint. Their names give you blatantly obvious hints at what they do, so I won’t get into it. Along with the OOTB crawlers, Oracle also exposes a nice, clean API for writing crawlers in Java or .NET. (If you really want to push the envelope, you can try writing a crawler in PHP, Python, Ruby, Perl, C++ or whatever, but it’s hard enough to write one in Java or .NET, so I wouldn’t go there. If you do, though, make sure that your language has a really good SOAP stack.)

So, after reading this, you still want to write a crawler, yes?

Let’s get into my Top Ten Tips:

1. Don’t actually build a crawler

Yes, you really don’t want to go here. Building crawlers is not that hard, as there’s a clean, well documented API. However, getting them work is a whole other story.

Most applications these days have a web UI. So, take advantage of it. Point the OOTB web crawler at the web UI and see what it does. Some web UIs will work well, other won’t (particularly if they use frames or lots of javascript.)

Let’s assume for a moment that this technique doesn’t work. Or perhaps you’re dealing with some awful client-server or greenscreen POS that doesn’t have a web UI. Either way, you may still be able to use the web crawler.

How? Well, the web crawler can crawl almost anything using something that we used to call the Woogle Web. Think of it this way. Say you want to crawl a database. Perhaps that database contains bug reports. Rather than waste your time trying to write a database crawler, just write an index.jsp (or .php, .aspx, .html.erb, .you-name-it) page that does something like select id from bugs and dumps out a list of all the bugs in the database. Then, hyperlink each one to a detail page (that’s essentially a select * from bugs where id = ? query). Your index page can be sinfully ugly. However, put some effort into your detail pages, making them look pretty AND using meta tags to map each field in the database to its value.

Then, simply point the OOTB web crawler at your index page, tell it not to import your index page, map your properties to the appropriate meta tags, crawl at a depth of one level, and get yourself a nice cup of coffee. By the time you get back, the OOTB web crawler will have created documents/links/cards for every bug with links to your pretty detail pages and every bit of text will be full-text searchable. So will every property, meaning that you can run an advanced search on bug id, component, assignee, severity, etc.

At Plumtree, we used to call this a Woogle Web. It may sound ridiculous, but

a Woogle Web is a great way to crawl virtually anything without lifting a finger.

However, a Woogle Web won’t work for everything. If you’re dealing with a product where you can’t even get your head around the database schema AND you have a published Java, .NET or Web Service API, then you might want to think about writing a custom crawler.

2. If you must, at least RTFM

If you’re anything like me, reading the manual is what you do after you’ve tried everything else and nothing has worked out. In the case of Plumtree crawlers, I recommend swallowing your pride (at least momentarily) and reading all of the documentation, including their “tips” (which are totally different from and not nearly as entertaining as my tips, but equally valuable).

Once you’re done reading all the documentation, you might also want to consult Tip #10.

3. “Hierarchyze” your content

Um, yeah, I know “hierarchyze” isn’t a word. But since crawlers only know how to crawl hierarchies, if your data aren’t hierarchical, you darn well better figure out how to represent them hierarchically before you start writing code. Even if you don’t think this step is necessary, just do it because I said so for now. You’ll thank me later.

4. Test first

Don’t even try to write your crawler and then run it and expect it to work. Ha! Instead, write unit tests for every modular bit of code that you throw down. To every extent that’s it’s possible, write these tests first. It’ll save your butt later.

5. When testing, use the Service Station 2.0 (if you can find it)

When you do finally get around to integration testing your crawler, it’ll save you a lot of time if you use the Service Station 2.0. However, it may take you a long time to get it, so start the process early.

Unlike every product Oracle distributes, Service Station is 1) free and 2) not available for download. Yes, you read that correctly.

To get it, you need to contact support. I called them and told them I needed it and after two weeks I got nothing but a confused voicemail back saying that support doesn’t fulfill product orders. Um, yeah. So I called back and literally begged to talk to someone who actually knew what this thing was. Then I painstakingly explained why I couldn’t get it from edelivery (because it’s not there) nor from commerce.bea.com (because it’s permanently redirecting to oracle.com) nor from one.bea.com (because there it says to contact support). So, after my desperate pleas and 15 calendar days of waiting, I got an e-mail with an FTP link to download the Service Station 2.0.

After installing this little gem, my life got a lot easier. Now instead of testing by launching a Plumtree job to kick off the crawler (and then watching it crash and burn), I could use the Service Station to synchronously invoke each method on the crawler and log the results.

Another handy testing tool is the PocketSOAP TCPTrace utility. (It’s also very handy for writing Plumtree portlets.) You can set it up between the Service Station and your CWS and watch the SOAP calls go back and forth in clear text. Very nice.

6. Code for thread safety

So, as the documentation says (and as I completely ignored), crawlers are multithreaded. The portal will launch several threads against your code and, unless you code for thread safety, these threads will proceed to eat your lunch.

Coding for threadsafety means not only that you need to synchronize access to any class-level variables, but also that you must use only threadsafe objects (e.g. in Java, use ArrayList instead of Vector).

7. Write DRY code (or else)

Even though you’re probably writing your CWS in Java or .NET, stick to the ol’ Ruby on Rails adage:

Don’t Repeat Yourself.

Say for example, that you need to build a big ol’ Map of all the Document objects in order to retrieve a document and send its metadata back to the mothership (Plumtree). It’s really important that you don’t build that map every time IDocumentProvider.attachToDocument is called. If you do, your crawler is going to run for a very very very long time. Crawlers don’t have to be super fast, but they shouldn’t be dogshit slow either.

As a better choice, build the Map the first time attachToDocument is called and store it as a class-level variable. Then, with each successive call to attachToDocument, check for the existence of the Map and, if it’s already built, don’t build it again. And don’t forget to synchronize not only the building of the Map, but also the access to the variable that checks whether the Map exists or not. Like I said, this isn’t a walk in the park. (See Tip #1.)

8. Don’t confuse ChildDocument with Document

IContainer has a getChildDocuments method. This, contrary to how it looks on the surface, does not return IDocument objects. Instead, it expects you to return an array of ChildDocument objects. These, I repeat, are not IDocument objects. Instead, they’re like little containers of information about child documents that Plumtree uses so that it knows when to call IDocumentProvider.attachToDocument. It is that call (attachToDocument) and not getChildDocuments that actually returns an IDocument object, where all the heavy lifting of document retrieval actually gets done.

You may not understand this tip right now, but if drop by and read it again after you’ve tried to code against the API for a few hours, and it should make more sense.

9. Use the named methods on DocumentMetaData

This one really burned me badly. I saw that DocumentMetaData had a “put” method. So, naturally, I called it several times to fill it up with the default metadata. Then I wasted the next two hours trying to figure out why Plumtree kept saying that I was missing obvious default metadata properties (like FileName). The solution? Call the methods that actually have names like setFileName, setIndexingURL, etc. — don’t use put for standard metadata. Instead, only use it for custom metadata.

10. RTFM (again)

I can’t stress the importance of reading the documentation enough.

If you think you understand what to do, read it again anyway. I guarantee that you’ll set yourself up for success if you really read and thoroughly digest the documentation before you lift a finger and start writing your test cases (which of course you’re going to write before you write your code, right?).

* * *

As always, if you get stuck, feel free to reach out to the Plumtree experts at bdg. We’re here to help. But don’t be surprised if the first thing we do is try to dissuade you from writing a crawler.

Have a safe and happy Halloween and don’t let Plumtree Crawlers scare you more than they should.

Boo!

Chris Bucchere’s Oracle Open World Schedule

oracle_open_world_unconferenceI’m headed to Oracle Open World on Saturday, 9/20. Here’s my proposed schedule. Like I said earlier, I’m probably going to spend most of my time in the unconference anyway, but here’s what looked interesting to me.

[Editor’s note: I’ve removed the gCal from here because it defaults to the current date, so it’s not really usable anymore, now that Oracle Open World 2008 is a thing of the past.]

If you’d prefer, you can also access this schedule in XML or ICAL format.

Chris Bucchere Speaking at the NovaRUG on June 18th, 2008

Calling all local Rubyists! I’m speaking about modular page design in Ruby on Rails at tomorrow night’s NovaRUG. The title of my talk is “To Portal or Not to Portal: How to Build DRY, Truly Modular Mashups in Rails.”

The meat of my talk is going to come from these two recent blog posts:

Modular Page Assembly in Rails (Part 1)
Modular Page Assembly in Rails (Part 2)

I’ll be followed by Arild Shirazi of FGM giving a presentation entitled “CSS for Developers.”

Get all the details here.

P.S.: Free pizza!

Modular Page Assembly in Rails (Part 2)

In Part 1, I explained how you can develop clean, DRY and encapsulated MVC code that allows for completely modular page assembly in Ruby on Rails.

In this follow up post, I explain how you can use a combination of layouts and content_for to apply title bars and consistent styles to your page components (or modules or portlets, or whatever you want to call them).

The code here is easy to follow and it pretty much speaks for itself. It consists of two layouts (which I called aggregate and snippet), a sample controller and two sample views. Let’s start with the controller for one page in your site that, say, aggregates a couple of modular page components together to show a nice view of company information.

Controller code (app/controllers/company_controller.rb):

def index
  render :action => 'index', :layout => 'aggregate'  
end

This controller simply delegates the rendering of the page to the index.html.erb view and tells Rails to use a layout called aggregate.

Now let’s inspect the view.

View code (app/views/company/index.html.erb):

<% content_for :left do %>
 <%= embed_action :controller => 'company', :action => 'company_list' %>
 <%= embed_action :controller => 'feed', :action => 'feed' %>
<% end %>

<% content_for :center do %>
 <%= embed_action :controller => 'company', :action => 'detail' %>
<% end %>

<% content_for :right do %>
 <%= embed_action :controller => 'home', :action => 'sponsors' %>
<% end %>

This view defines three content regions, with the end goal being to create a page with three columns of “portlets.” The left column contains two portlets: a list of all companies (company_list) and a news feed (feed). The center column contains a company detail portlet and the right column contains a portlet with information about sponsors. (Note that the portlets come from three different functional areas of the site, so they’re decomp’d appropriately into three different controllers.)

Now, let’s take a look at some layout magic.

Here’s the aggregate layout (app/views/layouts/aggregate.html.erb):

<table class="main" cellspacing="0" cellpadding="0">
  <tbody>
    <tr>
      <td id="column-left" class="column" valign="top">
        <div id="region-left" class="region"><%= yield :left %></div>
      </td>
      <td id="column-center" class="column" valign="top">
        <div id="region-center" class="region"><%= yield :center %></div>    
      </td>
      <td id="column-right" class="column" valign="top">
        <div id="region-right" class="region"><%= yield :right %></div>
      </td>
    </tr>
  </tbody>
</table>

I chose a table (yes, I still use tables) with three divs in it, one for each region of modules, but you could use pure divs with floating layouts or any other approach.

The three content regions, left, center and right, match up with the three content sections defined in the index view above using content_for. In case this isn’t obvious, when the layout encounters a page-level definition of a content region in the view, it renders it. If there is no definition for a particular region, the containing column will just collapse on itself, which is the behavior we want.

This is a slight digression, but note how I used CSS classes to identify the columns and regions in a general way (using classes) and a specific way (using ids). This allows me to style the whole module-carrying region with CSS using table.main as my selector, all the columns using table.main td.column as my selector or all the regions using table.main td.column div.region as my selector. I can also pick and choose different specifc areas (e.g. table.main td.column#column-right) and define their style attributes using CSS. As you’ll see in a minute, I can write CSS selectors to say if module A is in the left column, apply style X but if module A is in the center or right column, apply style Y. Pretty cool.

Now, let’s explore the module layout. (Note that I’ve been calling page snippets portlets, modules or components, pretty much interchangeably. I think this illustrates that it doesn’t make a difference what we call ’em — e.g. portlets vs. gadgets — the concept is fundamentally clear and fundamentally the same.)

Module layout (app/views/layouts/snippet.html.erb):

<div id="<%= yield :id %>"><%= yield :id %>" class="snippet-container">
  <div class="snippet-title"><%= yield :title %></div>
  <div class="snippet-body"><%= yield :body %></div>
</div>

This layout expects three more content regions to be defined in the view: id, title and body. Here are the matching content regions from one sample view (for sponsors) — for brevity’s sake, I didn’t include all the views.

Sample module view (app/views/home/sponsors.html.erb):

<% content_for :id do %>sponsors<% end %>

<% content_for :title do %>Our Sponsors<% end %> 

<% content_for :body do %>
Please visit the sites of our wonderful sponsors!
<% end %>

Now, because of some nicely-placed classes and ids, I can once again use CSS selectors to give a common look-and-feel to all portlet containers (div.snippet-container), portlet titles (div.snippet-title) and to portlet bodies (div.snippet-body). Of course, if I want to diverge from the main look-and-feel, I can call out specific portlets: div.snippet-body#sponsors.

If I really want to get fancy, I can use CSS selectors to select, say, the sponsor portlet, but only when it’s running in the right column: table.main td.column-right div.snippet-container#sponsors.

So, in summary, using layouts, content_for and some crafty CSS, I can create a page of modules that can be styled generically or specifically. Combine this approach with what I described in Part 1, and you can “portal-ize” your Rails applications without using a portal!

Was this useful to you? If so, please leave a comment.

BEA Participate is Only Two Weeks Away

There’s still time to register for this great conference and take part in a one-of-a-kind social computing experiment.

Register now!

Comments

Comments are listed in date ascending order (oldest first)

  • I heard some rumors that this event is going to demo some seriously killer app love that will blow people away. OK – they’re not rumors. It’s just common sense when you put this much brain power and off the wall creativity in one spot. I’m all for long fireside chats about protocols and geek plumbing (/swoon), but what really excites me about Participate is the ability to kick back with developers, product managers, and engineers and talk about business challenges and solutions – then arm you with the tools and tricks to get your business humming. Got a problem? Chances are these pros have a suggestion that will make your life easier and your business users that much more productive. Food, folks, fun, and forward thinking. You just can’t beat that.

    Posted by: ewwhitley on April 29, 2008 at 5:16 PM

  • Tada! The triumphant return of Eric Whitley to dev2dev!

    Posted by: bucchere on April 30, 2008 at 12:33 PM

One Portal to Rule Them All

I won’t rehash what’s already been said by everyone in the press and the blogosphere — Oracle is buying BEA. I wrote almost three years ago that this was inevitable, and now it’s upon us.

I’m hopeful that the BEA/Oracle management crew can take what they learned from the Plumtree, Fuego and Flashline (for BEA) and Siebel, PeopleSoft and Oblix (for Oracle) acquisitions and apply it to the challenges their own merger presents.

Over the past three years, Oracle has acquired dozens of companies. The most notable were probably PeopleSoft (which had just acquired JD Edwards, if I remember correctly), Siebel and Oblix, which gave them a great suite of HR apps, CRM apps and identity management, respectively. These were all enterprise software products that Oracle had, with a modicum of success, built on their own from the ground up, sold and supported as “Oracle Apps.”

Of course, with almost every major company they’ve acquired, Oracle has picked up a portal product. (And with BEA, there’s a special bonus — they get two: WLP and ALI.)

That’s going to create a portal soup consisting of at least the following ingredients:

  • Siebel Portal
  • JD Edwards Portal
  • PeopleSoft Portal
  • Oracle Portal (part of Oracle Fusion Middleware)
  • WLP
  • ALI

Oracle won’t want to endanger existing customer relationships by terminating support for the non-horizontal portals from Siebel, PeopleSoft, etc. Besides, the word “portal” really only loosely applies there, because those “portals” are really just web UIs into Siebel, PeopleSoft, etc.

But what about the horizontal portals: Oracle, WLP and ALI?

They are all playing in the same space. It’s already questionable that we need all three in the market now. And three under the same circle-shaped roof that is Oracle? Absurd.

What will Oracle do with this portal quandary?

Well, I think they’ll do the only thing they can do and support all the products. So that covers legacy customers, but what about future customers? If I’m an Oracle sales rep and my customer wants to buy a portal to front their SOA stack, what on earth do I sell them?

In my opinion, which is just that — my opinion — post-merger, there need to be some decisive acts from Oracle regarding the future direction of their portal strategy.

And, again, IMO, this is where the ALI portal and the ALUI suite of products (formerly Plumtree) can really shine. Why? Because not only can you front Java, .NET, Rails, PHP and any other web application stack with ALI, but ALI already has integration kits for Siebel, PeopleSoft, JSR-168, WSRP and five different flavors of SSO, including Oblix! (Not to mention the obvious fact that since day one, ALI has run beautifully on Windows and *nix systems using Oracle’s bread-and-butter product, their database.) So naturally, if you’re an Oracle shop running a clustered Oracle DB for storage, Siebel for CRM, PeopelSoft for HR, Oracle Financials for the books and Oblix Identity Management, no other product under the sun has more pre-packaged, no-brainer integration and integration options than ALI.

It may be a hard, bloody battle to get Oracle to drop it’s own beloved portal product in favor of AquaLogic Interaction, but I think it’s a battle that needs to be fought.

Same goes for WLP. In fact, I think every product acquired by Oracle has to fight for it’s life and fight to be the #1 product in the space, retiring the others to “maintenance and support” but focusing all futures on the product that is rightfully #1. And I think — and hope — that Oracle has the good sense and the wherewithal to encourage this.

It may cause some near term pain, but taking a longer-term view it’s the right thing to do.

Comments

Comments are listed in date ascending order (oldest first)

  • Interesting post, Chris. Obviously this is something we ALUI consultants have been considering in the past few days. One monkeywrench I have for you: as far as I know, Oracle offers their portal product for free to existing customers, whereas we (obviously) charge for it. I wonder how that kind of business model might change the landscape of how the ALUI portal is distributed/used.

    Posted by: rbrodbec on January 18, 2008 at 7:02 AM

  • Funny you should mention the price issue. About two years ago, we had a customer switch from ALI to Oracle portal for that exact reason. Why pay for licenses and support for ALUI products when Oracle gives you the portal for free? That customer still calls on us for ALUI support, so apparently the migration hasn’t gone exactly as planned.Two old adages come to mind here:
    1. You get what you pay for.
    2. There’s no such thing as a free lunch.

    Regarding #1, the products really don’t cover the same feature set — Oracle portal cannot be the gateway to SOA that we all know ALUI is, so it’s really not an apples-to-apples comparison.

    Regarding #2, with any free software, whether it’s from a large company like Oracle or from the Apache Software Foundation, you always need to think about Total Cost of Ownership (TCO). If you need to build services integration points in Oracle Portal to talk to all of Oracle’s other products, that adds to your TCO. Moreover, if somebody is giving something away, what sort of quality expectations do you have about the product? What happens if you need to request support from Oracle or ask them to develop a patch for you? All of a sudden, the fact that you didn’t pay for the software comes back and bites you in the butt. 🙂

    Posted by: bucchere on January 18, 2008 at 7:23 AM

  • I guess I agree with you, since I’m not an Oracle portal consultant (not yet, anyway); but I think the bigger question is how Oracle will assimilate these new portals given its current pricing strategy (aka – the bloody war you speak of). If I were an existing Oracle customer, the first question I’d ask is “how come I can get XYZ portal for free but not ABC portal”. And if I’m Oracle product management, I’m thinking about how my current “free portal” strategy has been working out for me versus the ALUI model of charging for it.

    Posted by: rbrodbec on January 18, 2008 at 8:22 AM

  • You’re right — the big issue is how will Oracle deal with the portals they’re acquiring and will there be a shakedown or more of a graceful assimilation.There’s a similar issue with WLS and Oracle’s application server, although I think in that case the answer is a little less complicated. 😉

    Posted by: bucchere on January 18, 2008 at 8:32 AM

  • Of course you completely forgot to mention Oracle WebCenter. In spite of your assertions, there are only 2 portal products at Oracle. Oracle Portal and WebCenter. WebCenter is the future “face” of Fusion Applications, so any integration of portal products will move in that direction. IMHO….plumtree is as proprietary as Oracle Portal, and its dead. WLP and the folks on the WebCenter team will need to figure out how to integrate the code bases of those two products since they are the most similar in their support of Web 2.0 futures.

    Posted by: Dr. BEA Good on January 20, 2008 at 11:44 AM

  • Thanks for the correction about Oracle WebCenter — I’m not too familiar with Oracle products other than the DB and I should have done more homework before posting this!However, I still disagree that there are only two portals at Oracle. I’m not too sure about JDE, but I remember with 100% certainty that PeopleSoft and Siebel called their UIs “portals.” They’re not truly portals in a horizontal sense like Oracle Portal, WebCenter, WLP and ALUI and I don’t think they’re actually relevant to this discussion, so it’s a moot point.

    Now, given the four remaining portal products, I challenge your assertion that WebCenter and WLP “support Web 2.0 futures” and I’d like to see some examples that support that claim. As far as I know, the only products coming out of BEA that deserve the “Web 2.0” label are AquaLogic Pages, Ensemble and Pathways. (Note I don’t include ALI itself as a Web 2.0 product, despite the fact that ALI 6.5 has some pretty slick social features that might someday earn it that distinction.)

    I also take issue with your calling Plumtree/ALUI proprietary and I’m not sure what makes you make that claim. It’s written in Java and ported to C#.net, so it runs “natively” on IIS (which no other products from BEA or Oracle can do). Its Java version (from the same source base), runs on WebSphere, WLS, Tomcat and probably JBoss and other app servers and it supports both Oracle and SQL Server, so in terms of how and where you can run it, it’s probably the most open and flexible product in the entire 40+ product lineup that BEA boasts.

    That’s just one side of the proprietary vs. open argument. The other is how well one supports standards for plugging in functionality. In those terms, I think ALUI stands out from the pack as well. It supports portlets over two very well supported standards: HTTP and HTML, which again makes it the most flexible portlet development environment on the market. (You can develop ALI portlets using ANY web server that speaks HTTP and I’ve personally done so using Java, .NET, LAMP, Ruby on Rails, Groovy on Grails and even Domino if you can believe that.) It also supports JSR-168 and WSRP. (In reading about WebCenter, all portlet development documentation was Java-centric, so I’m not sure if they support any other kind of portlet development, e.g. .NET. It’s crucial that any product which claims to be the “face of SOA” supports at least Java and .NET development and plugins; however, many would argue that you need to support much more — e.g. Ruby on Rails, PHP, etc.)

    Leaving portlets out of the picture for a moment, consider the other ALUI integration points: AWS, PWS, CWS and SWS. All of them use SOAP, which is a documented open standard. In fact, in my next blog post (which went up last night), I talk about how I integrated a custom MySQL/Ruby on Rails user store with ALI using a Rails-based SOAP-driven web service to interface with ALI’s user management system. It just doesn’t get any more open than that. At last year’s Participate conference, I demonstrated how you could use the ALI “face” to front WLS applications written to run on the WL message bus and communicating with data stores using DSP, proving that you integrate ALUI products with pretty much anything. I would like to see how a WebCenter consultant or a WLS guy would approach integrating Siebel or PeopleSoft, two products now in the Oracle family.

    I may make many “assertions” (as you call them), but they’re backed up by solid facts. I’m open to continuing this dialog because I want to hear more facts about 1) how you perceive ALUI as a proprietary technology and 2) how WLP and WebCenter claim to support “Web 2.0.”

    Posted by: bucchere on January 20, 2008 at 6:10 PM

  • Out of respect of SEC rules, I won’t touch the Oracle topic. But as for WebLogic Portal (WLP)…2) how WLP … claim to support “Web 2.0.”There are a bunch of features that contribute to the overall Web 2.0 story for WLP. Look at the WLP Groupspace application, for example. Web 2.0 is about publishing social applications that get better the more people use them. Groupspace is such an app. It is first a packaged social app ready to go out of the box, but secondly shows off many of the WLP features in the area of “Web 2.0”.

    Groupspace doc link (community framework, RSS, Groupnotes (think wiki), discussion forums, shared document repository, calendar, contacts, etc, etc).

    Also, read up on Josh Lannin’s blog to see what will be out shortly in terms of WLP and REST, more Ajax, more Portlet Publishing (Google Gadgets, RoR, PHP, etc). Lannin’s WLP futures

    Cheers – PJL

    Posted by: plaird on January 21, 2008 at 8:30 PM