We had some conflicts, so we postponed the Herndon, VA-based training to next week. It’s now 4/16-4/18 for administrators and 4/18-4/20 for developers. We’ll be accepting registrations until 4/13, so if you’re interested, please send a note to [email protected].
Here’s some more shameless self-promotion (isn’t that what blogging is all about?) — we’ve just been confirmed as a sponsor for BEA Participate 2007.
Look for more details about our role in the upcoming conference here.
Hope to see you there!
We’re very pleased to announce that we’ve finalized the date for our next ALUI/Plumtree training course, scheduled for the week of April 9th, 2007.
We’re changing the lineup a tad to provide three days of ALUI administration training followed by three days of developer training, but all in a five day week. So how do we plan to pack six days of training into five? The answer is “super Wednesday,” which will be a day when we teach administration for developers. In other words, it’s the last day for the administrators (advanced administration) and the first day for the developers.
Bottom line: to sign up for either class (or the whole week), send an email to [email protected].
This just in: BEA has announced that they will be hosting a user conference for ALUI and ALBPM customers and prospects. This conference is called “BEA Participate” and all the details can be found at http://www.bea.com/participate. As of this posting, there’s not much more than a “Save the Date,” which, BTW, is May 6th-9th, 2007. Seeing as how BID’s new products (Runner, Builder and Graffiti) will be nearing General Availability at that time, I would expect to see some very cool demos.
Watch this space for more info about bdg’s role in the conference!
A quiet little announcement was made last week: BEA plans to host an ALUI (formerly Plumtree) and ALBPM (formerly Fuego) user conference! Suprisingly, I don’t see any references on BEA’s web site, on dev2dev or really anywhere else about it, so I thought I would take a minute to promote the conference here.
Could this be a response to some customer and integrator concerns that there weren’t enough AL* breakout sessions at BEA World 2006? Possibly. Could this be the final nail in the coffin that was once called the “Unified Portal Roadmap.” I’m not sure.
Regardless, you can bet that I’ll be there along with several other folks from bdg. Stayed tuned for more information here about how we’ll be involved as an event sponsor, exhibitor and perhaps even as a presenter. I expect that we’ll have a lot of fun, share a great deal of what we know about ALUI and learn a great deal more from ALUI customers and other BEA partners.
The full extent of the information that currently exists about this conference can be found at http://www.bea.com/participate. We’ll be watching that space for more info and also posting several more times about our specific role in the conference. I suggest you do the same.
One obvious question any customer or partner should ask is: if I’m getting my budget together for 2007 conferences, should I attend BEA World or BEA Participate? If you’re a current ALUI or ALBPM customer, it’s a no brainer: attend BEA Participate. But what if you’re a prospect who is considering a portal or SOA solution from BEA? If you can afford it, I would say attend both!
Comments are listed in date ascending order (oldest first)
- Now I’m officially confused. Very weird that these are separate unless they’re using BEA World as a venue for “technical building blocks” and “Participate” to sell business collaboration / process solutions – that’s the only way I can see this.
I have to be careful how I word this, so if the tone comes across in any way negative, well… that’s not my intention. IMO I would not attend BEA World again if it’s a repeat of last year’s.
I loved Odyssey – it was well organized, had _great_ sessions targeted toward user education and productivity, and was all about the customer – sharing best practices, discussing common problems, and engaging in one-on-one w/ engineers and product managers. Sessions were focused on empowering the customer and making sure they were just a bit better at their jobs when they left. It was always worthwhile and our entire team (repeatedly) came away saying “glad we went.” Awesome stuff all around and did a lot to let the customers sell the solutions to other customers (always a better way to go).
In attending BEA World last year I got the constant nagging sensation that it was a big (overt) sales conference and not really about the user and how to better utilize tools. ALUI was barely even on the map (which really bothers me). I didn’t have the sense that my needs were being addressed as much as in previous years and I really didn’t come away with anything “tangible” I could take back to justify the fee. The customer keynotes were cool, but beyond that we struggled to find value.
Doing something with a “Participate” focus thing is a _great_ idea on the part of BEA if it’s about targeting the customer and helping understand how to succeed with the tools (and make friends along the way ;). Keywords: using the tools to succeed in business. That, IMO, was always the point to me in attending.
Obi-wan – hear me. This should really be incorporated into BEA World for the benefit of your current and prospective customers. It will really boost the value of BEA World and do something to hammer home the fact that BEA and Plumtree are one company with one comprehensive suite (something Jay Simons’ web conference last year did a great job of explaining). Separating things like this … well… I get it, but it does imply a continued level of separation that customers expressed concern with last year.
That said – and I sincerely hope that didn’t come across as negative – I’m excited to see what 2007 brings for the new products. Seeing a bit of what they’re cooking up, it’s nice to users finally getting past a lot of the geekware bits and into things they can build and use w/o IT bottlenecks. Very cool. Buy three 🙂
- It’s not Obi-wan here, but Christine Wan and we’re definitely listening! BEA organized Participate to directly address the needs of business and IT users working with ALUI and ALBPM products. This is very much a forum for customers to gather and share best practices, to go deep with product managers and engineers and to hear the latest on new product developments.
And it is an important complement to BEAWorld, providing much richer detail on these two specific product lines and more focus on bringing these specific users together in a forum where they can share experiences and ideas. The announcement last week was just a Save-the-Date. Stayed tuned, you’ll see a lot more information to come on the bea.com homepage and bea.com/participate.
- Hi, Christine 🙂 Very cool – I’m glad to hear this. We loved the “interactive” and focused nature of the Odyssey sessions. You guys did such a good job on that I think we just kinda got spoiled and expected something on that order for BEA World last year. That’s what happens when you make us too happy year after year 😉
- I know that many customers I spoke with during and after BEAWorld echoed the same sentiment of being “underwhelmed” simply from being spoiled by Odysseys past. Along those same lines, an Advanced Developer Conference either as part of Particpate, an extension to it or separate from it would be awesome as well. I know that may be hard to do as part of this initial effort but it would be great at some point. We are definitely excited about it and all of this just builds anticipation until May.
I recall sitting in a meeting in 1998 where we were discussing how to aggregate portlet content into a portal page. We talked a lot about iframes but couldn’t consider them as a serious integration option because of security, scalability/performance, caching and portal-to-portlet communication. Instead, we spent the next year building and testing the HTTPGadgetProvider, which later came to be called the “(Massively) Parallel Portal Engine.” (The term “Massively” was later dropped and I believe the name “Parallel Portal Engine” or PPE for short finally stuck.) I won’t go into details about how the PPE works, but if you’re interested, you can check out this great page in edocs that sums it up nicely.
So anyway, iframes are certainly reasonble way to build a portal in a day. But, in terms of building a robust enterprise portal that can actually withstand the demands of more than say, ten users, and that will pass even the most rudimentary security evaluation, iframes are complete nonsense.
So, today, during my lunch break, I attended Peter Laird’s Webinar, which he advertised in his nascent blog. It was all about enterprise mashups, a topic by which I’m very much intrigued. (Recall that PTMingle, my winning entry in the 2005 Plumtree Odyssey “Booth of Pain” coding competition was a mashup between Hypergraph, Google Maps, del.icio.us and Plumtree User Profiling.)
Imagine my surprise when Peter described how you can mash up Google “Gadgets” and other resources available via URLs using Adrenaline, a “new” technology from the WLP team based on, of all things, iframes. It was like entering a worm hole and being transported back to 1998. (I was single again, I had no kids, I was thinner and I had more hair on my head . . . and less on my back.) But the weird thing about this parallel universe is that BEA engineers were telling me that iframes were a great way to mashup enterprise web content and that intranets all over the world could benefit from this revolutionary concept. Intranets? You mean the things that everybody replaced with portals in the last millennium? Iframes? I must have been dreaming . . . .
When I finally came back to my senses, a few things occurred to me.
First of all, it’s 2007. Portals are a thing of the past. For some of us, that will be a hard pill to swallow. But let’s face it, innovators have moved on to blogging, wikis, tagging/folksonomies and lots of other nice web 2.0 sites that all have rounded corners. The bleeding edge folks have decided that many is smarter than any. The rest of the world will catch up soon.
Secondly, if you are still building a portal or composite application of any flavor, iframes are not a viable solution. They fall short in the following ways:
Say you want to send information (like the name of the current user) down to a portlet running in an iframe. Hmmm, the request for an iframe comes from the browser, not from the portal. So, if anything needs to be passed into the iframe, I guess you have to put in in the URL in the request for the iframe. That’s great, but that URL is now visible in the page’s source. So a simple, “Hello [your name]” portlet where the portlet gets the name from the portal is doable. But what about passing a password? That information would need to go first to the browser and then back to the remote tier, which, from a security standpoint, is a complete showstopper.
Let’s talk a little more about security. Since you’re using an iframe, the requests aren’t proxied by the portal. Instead, a page of HTML gets sent from the portal to the browser and then the browser turns around and makes requests to all the iframes on that page. Since the portal isn’t serving as a proxy, it can’t control what you do and don’t have rights to see, so security is completely thrown out of the window. (Or should I say, thrown out of the iframe?) Moreover, in an enterprise deployment, the portal usually sits in the DMZ and proxies requests out to bits and pieces of internal systems in order to surface them for extranet users. If you’re using iframes, every bit of content needs to be visible from an end user’s browser. So what’s to stop an end-user from scraping the URL out of a portal page and hitting a portlet directly? Nothing! (If I understand what I’m reading correctly, the WLP team is calling this a feature. I would call it a severe security risk.)
Yes, this approach will work for Google Gadgets. But Google has more money than pretty much everyone. They can afford to spend frivolously on anything, including hardware. However, the rest of the world actually cares about the kind of load you put on a system when you create a “mashup.” A page consisting of five iframes is like five users hitting the sites with five separate requests, separate sessions and separate little “browsers.” If any of the iframes forces a full-page refresh or if the user does the unthinkable and say, moves to another page, every request is reissued and the mashup content is regenerated. This simply does not scale beyond a few users, unless you have as much money and as much hardware as Google does.
A properly designed portal or content aggregation engine will only issue requests to portlets when necessary. In other words, each remote portlet will only get a request if it needs to be loaded because the portal doesn’t have a cached entry. Unfortunately, you can’t do this with iframes because the portal doesn’t even know they exist. (Remember, all requests for iframe content go directly from the browser to the remote content, bypassing the portal entirely.)
What baffles me is why a company would acquire another company with a revolutionary technology (the PPE) and then start from ground zero and build a technology that does the same thing but without a portal-to-portlet communication model (preferences), security, scalability or caching. If consumers weren’t already confused, now they most certainly are.
As technologists, I hope you can see through the hype about Adrenaline and consider a product that actually allows you to mash up web content in a scalable and secure way and has been doing so since 1999. It’s called AquaLogic Interaction and it’s sold by a company we all know and love called BEA.
Comments are listed in date ascending order (oldest first)
- I just discovered that the BID/AquaLogic (formerly Plumtree, Fuego, Flashline, etc.) folks are having another webinar, entitled “Harnessing Enterprise Mash-ups with Security and Control.” This webinar (I hope) will show:
- how ALI has been handling mashups since before mashups was even a buzzword and
- how Project Runner enables next generation mashups that allow you to invoke back-end applications and provision security, branding, SSO, etc. without actually funneling everything through the portal.
If you were at today’s webinar and you’re now wondering how to do mashups with more robustness and security, then I hope you’ll attend this webinar. By all means, it’s just the responsible thing to do in order to offer customers different integration options when creating their mashups.
- I’d like to add a couple points of clarity from BID product management. First of all, we’re happy to have passionate developers, but I fear this post may give the wrong impression about some of BEA’s technology and plans.
WLP Adrenaline, ALUI, and project Runner are all complementary technologies that have a very exciting future when applied to problems such as Enterprise Mashups. You’ll be hearing more about them from BEA over the coming months through various venues, including Webinars targeted at WLP-specific use cases (such as Peter’s excellent talk) and ALUI use cases (including tomorrow’s Runner Webinar). There will also be the usual blogging and other activities.
Just as WLP and ALUI product teams are aligned, these different technologies are aligned. Adrenaline offers WLP customers a way to extend their reach in fundamentally new ways, and Peter will expound on some technical subtleties to address some of Chris’ concerns. Runner, too, is very exciting, enabling a completely different set of use cases. As the details unfold we’ll demonstrate how well aligned these technologies are — just wait until you see them working together!
– David Meyer
- Just for those that don’t know about Adrenaline, here’s an article introducing Adrenaline.
As David writes, BEA is moving ahead with multiple approaches to address the enterprise mashup space. My webinar covered the approach WLP is taking, and in no way implied that ALUI is not also a viable player in this space. We offer our customers a choice of products, and different products make sense to different customers.
As for the specific issues you raised:
** Technical Reply
Good technical points, but I think you overemphasized the role of iframes within WLP. Let me cover the two places we showed the use of iframes:
Use Case 1: injecting a portlet into a legacy webapp
Demo: An iframe was used in the demo to inject a portlet into a legacy static html page with almost no modification to that page (one line change).
WLP does support an alternative approach – an Ajax streamed portlet. I simply did not have time to demo it. Also, this is not a portal use case for including external non-portal content into a Portal; instead it is the inverse, which is to publish existing portal content into legacy web applications . It was intended to show a very inexpensive way to energize a dated application until it is rationalized into a portal. The focus here is on minimizing cost of supporting legacy, while building portlets in transit to a portal solution.
Use Case 2: WLP as a Mashup composition framework
Demo: Iframes were used to pull in non-WSRP capable components (e.g. Google Gadgets) onto a WLP page
First, as background info, the WLP architecture supports the rendering of various types of portlets:
- Local portlets (deployed within the webapp, JSF, JPF, etc)
- WSRP portlets – an advanced remoting approach which handles security, inter-portlet communication, etc…
- Iframe portlets – an available remoting approach
- WLP partners with Kapow for remote clipped portlets (similar to the ALUI approach)
In regards to this use case, you brought up specific concerns:
Concerns about shared authentication were noted in my talk. If components come from outside the enterprise, there is no easy solution to that problem, regardless of what product you are using. However, I spoke of a couple approaches in the webinar, including SAML.
If those components come from inside the enterprise, the security hacks you were referring to are generally not necessary. Our customers that expect SSO have a web SSO solution (typically, cookie powered, not password in the URL powered) in place within the enterprise.
The most serious concerns of yours appear to be performance related. Specifically, the concern is that a full page refresh of a page that contains N number of iframes will cause an N+1 number of requests. To expand on your concern, I will add that this is not only seen in pages with iframes, but also pages that use Ajax to pull in data. I would say that there are several reasons why this does not invalidate WLP’s approaches:
1. Mashup pages with lots of iframe portlets approach
Google Personalized Home Page makes use of iframes to implement their mashup framework. Many of the Gadgets on the page are rendered with an iframe. But you are mistaken in saying that this scales because Google is throwing tons of hardware at the problem. The iframe Gadgets rendered in GPHP are rendered not by Google, but by 3rd party gadget hosting servers around the world. Google does NOT have to process those iframe Gadget requests, it is a distributed approach. Likewise, you could create a WLP page where most of the portlets are iframe portlets that hit a distributed set of servers, if that makes sense. Or…
2. Mashup pages with a mixture of portlets
The 2nd demo in my webinar wasn’t showing a page with all iframe portlets. Rather, what the demo was showing was a WLP page with a couple of iframe portlets mixed in with local portlets. As shown above, WLP supports a number of portlet types, and a good approach is to build pages that are a mixture of that set.
3. Ajax helps minimize page refreshes
Your concern about iframe performance stems from the case in which the entire page refreshes. With the usage of Ajax becoming common, plus with WLP 9.2 built in support for auto-generating Ajax portlets, this impact can be minimized. Page refreshes are becoming more rare. With WLP 10.0, which releases in a few months, the Ajax support has been expanded to support Ajax based portal page changes, further reducing the liklihood of a page refresh.
4. The “Bleeding Edge” guys are also using browser based mashup approaches
You referred to the “Bleeding Edge” technologists in your blog as the people that are doing things correctly. What are they doing? Some of the time, those guys are doing browser based Mashups. They often use a combination of iframes and Ajax from the browser to implement their mashups. So the same approach that you dislike is already in common use across the web.
** Market Reply
You state “Portals are a thing of the past”. An interesting opinion, but just that. IT cannot afford web sprawl, and so a framework for rationalization will always be in demand whether you call it a Portal or something new.
New technologies continue to provide alternatives to existing methodologies and portals are no different. However, one thing that has distinguished portal frameworks is their ability to embrace new technologies. Struts, WSRP, JSF are all examples of this as are the Web 2.0 constructs like mashups and rich interfaces based on Ajax. This is all good news as the enterprise has a wealth of options to choose from.
- I must say, as a customer and developer, it’s great plumtree (I mean BEA, or is it Oracle) management allows you guys to express your own opinions. It so happens I’ve spent quite a bit of time trying to get JBoss Seam (and Ice Faces) to work with Aqualogic 6.1. I’ve been looking at the IFrame route, because the gateway stuff just isn’t working (it doesn’t properly rewrite the URLs for the Ajax stuff). I’ve come to hate the gateway. I bet it was a great idea before Ajax, but now it seems like almost every web 2.0 application is incompatible (needs major modification to get it to work). Or maybe I just don’t understand how to get it to work. Is there any good documentation on it? I’m hoping for some major improvements when 6.5 comes out though.
It’s time for another ALUI fireside chat! Join the ALUI/Plumtree community for an entire workday’s worth of smores, ghost stories and Kumbaya. The fun begins at 9 AM EST this Friday, 12/15 at http://www.aqualogicinteraction.com.
All of us at bdg are very excited about BEA World 2006. We’ve got our booth all ready to go, we’ve got bdg mousepads and playing cards to give away along with a brand new 4Gb iPod nano (to one lucky winner). Be sure to stop by our booth, located in the Portal Pavilion, just off the corner of BEA’s main exhibit in the center of the exhibition hall.
On top of all that, I was given a short (but sweet) speaking spot at the ALUI Developer User Group on Monday toward the end of the day (not sure exactly what time). I’ll be presenting on ALUI TagLibs, my favorite topic as of late.
Can’t wait for the big event — see you there!
On a related note, the bdg Plumtree Podcast, after an almost one-year hiatus, returned last week with Episode 4. Believe it or not, we’re back today in Episode 5 with our first special guest, long-time Plumtree/ALUI supporter and frequent contributor to the dev2dev forums, Eric Whitley.
With a resounding victory this morning in the Booth of Pain, bdg put the wraps on what will probably be the last Plumtree Odyssey.
We sent five people this year: me (President & CEO), Eric Bucchere (Account Manager) and Rich Weinhold (Plumtree Developer) representing the East Coast and Howie Bagley (VP Sales & Service) and Steve Markoff (Plumtree Architect) representing the West Coast. We had the opportunity to meet many of you at our booth – thank you for stopping by and introducing yourselves! In the upcoming weeks we’ll be raffling off the iPod Nano that was on display in our booth. If you asked us to follow up with you, expect to receive a follow up call or e-mail in the next 2-3 weeks.
Although the official feedback has not been tallied up yet, the talk we gave with Wind River was standing room only and I personally received lots of positive comments including one person who said that our session was the highlight of this year’s Odyssey. Another piece of feedback I got from Jack Jones of DTIC was that without our training (given in 2004), they would have gotten nowhere with their Plumtree project.
Winning the Booth of Pain competition was the icing on the cake. Despite the heat, the claustrophobic booth and numerous distractions from David Meyer (including scaling my booth, firing projectiles at me and scrawling the word “LOSER” across my booth with Silly String), I was able to compile and assemble the PTMingle application in about 25 or 30 minutes and then give a demo, which was very well received by the audience. In a humorous moment, I clicked on a del.icio.us hobby link related to “Romance Novels” and it displayed a half naked, hunky long haired dude with a cheesy smile (think Fabio). I quickly closed the window amid quite a bit of laughter from the audience.
PTMingle at this point is no more than a concept application/prototype, but expect to see the code used in the Booth of Pain competition up on the Code Share within the next few days. Plumtree data visualization in hyperbolic trees, profile integration with del.icio.us and Google maps integration are all hot topics right now and all areas of interest that bdg would like to pursue, so you should keep an eye out for more offerings from bdg that exhibit these features.
In closing, I wanted to send a resounding THANK YOU out to Yi Hong Xu of Wind River for her help with the presentation, to Mattias Cudich for plugging this blog during his Holland presentation (more on this later), to all of you who attended our presentation or the Booth of Pain, to all of you who stopped by our booth and last but certainly not least to the stellar team of bdg-ers who made this event a huge success for bdg.
On a personal note, this year’s Odyssey had a bittersweet feel for me. It was my sixth Odyssey, having attended four as a Plumtree employee, two as a bdg-er and missing just one (in 2003) and it will most likely be the last. We do, however, look forward to seeing all of you again next year at BEA World in San Francisco.
Look for more posts from me regarding the material presented at Odyssey, especially on Project Holland, which has exciting implications for future BEA/Plumtree offerings.