Cliff Schmidt, Product Manager at BEA, has been interviewed on the subject of Open source strategy and the Beehive project. He discusses the reasons for Beehive, and what it contains. He also goes into detail on the how BEA feels about open source: from Apache to Codehaus.

Read the full interview: Open source strategy and the Beehive project

It's good to see that Beehive is trying to take care of some of the Java Internet issues (finally). I'm sure Sun was thrilled enough to send a cake!

BRV
Viagra

i can't find an interview to be read. it appears to be a windows media format.

i can't find an interview to be read. it appears to be a windows media format.

I believe that whether you chose Windows Media or Real Media, you end up with a window that has two frames -- the bottom one should have the transcription. I've found that I need to enlarge the browser window to see the transcription.

BTW, the transcription isn't perfect (as few transcriptions are). If something doesn't make sense, take a look at the video. (of course, it still might not make sense, but then you'll know who to blame. ;-)

I saw interviewee beating around the bush on the controls questions, So I could not stop making this comment. I have been working on Workshop 8.1 and controls from when it was released. I think of controls as a facade layer. I think of controls as session facade. The interviewee says that they are essentially javabeans but I do not buy that. I think they are session beans.

Let me know what you guys think about this.

I have been working on Workshop 8.1 and controls from when it was released. I think of controls as a facade layer.

You are dead on here. The goal of Controls is precisely to enable the authoring of simplified (and metadata-configured) facades to represent resources or other abstractions. A key is that a wide variety of things can be represented using a single consistent client model, easing the learning curve for the client of the facade. On the tooling side, this consistency means tools can also discover, present, and configure available facades w/out having to code customized for the thing that lives behind facade.

I think of controls as session facade. The interviewee says that they are essentially javabeans but I do not buy that. I think they are session beans.Let me know what you guys think about this.

Sorry, but you are wrong here. Beehive Controls are 100% JavaBeans, and will fully conform to the JavaBeans spec. They will expose properties using JavaBeans property accessors, enable/deliver events using the JavaBeans EventListener model, and expose tooling information using JavaBeans introspection mechanisms. The confusion is understandable, since this is distinct and different from Controls in Workshop 8.1. BEA has heard and responded to user community comments that 8.1 Controls were a bit too much of a "black box" and rather than inventing yet-another-component-model, has found a way to leverage one (JavaBeans) that already exists and is quite appropriate.

What Controls layers atop JavaBeans is bringing JSR-175 into play to free JavaBean authors from some of the mundane details of writing a bean (property/listener management, etc) and to provide a very toolable client model for instantiating and configuring a bean in a particular client context.

Beehive Controls aren't technically session beans (at least in an EJB sense), because they aren't designed to start/delimit the scope of transactions (what SBs do, and do really well). They may well act as a facade for resources that are transacted, but there the goal is to act as a good and resource-efficient participant in transactions, not an initiator/controller of them. Controls can complement EJBs (or other transacted containers) by providing facades to access them or can play well within them if the EJBs need to consume other resources. It is a non-goal to compete with or replace them. IMO, the last thing the Java community needs is yet-another-transacted container. Aren't there enough choices already? ;)

Sorry to go so long... if you want more details, an appropriate place to look is on the Apache Beehive site, and there are dev and user lists there as well.

-- Kyle Marvin
   Developer, Apache Beehive Controls
   (BEA System employee)

Thanks Kyle that was informative.

Sorry, but you are wrong here. Beehive Controls are 100% JavaBeans, and will fully conform to the JavaBeans spec.


I did some more investigation on this front and found that I was not wrong. We both are right. What I referring to was workshop 8.1 and you were talking in respect to Beehive project.

The controls are stateless session EJBs right now in workshop 8.1. They will be based on Java Bean component model in Beehive because of obvious problems.

If tool-shops buy into these Controls, I think this might be a good concept to simplify development on the J2EE platform, but I think it's essential that not only BEA workshop supports this technology. So the question is whether Eclipse/IntelliJ/NetBeans++ will try to use this technology.

Any indications that this is the case ?

So the question is whether Eclipse/IntelliJ/NetBeans++ will try to use this technology.Any indications that this is the case ?

Eclipse is building support for Controls and the rest of the Apache Beehive framework through the Eclipse Pollinate project. Borland has publicly supported the Apache Beehive project, but I'm not sure exactly what they've got brewing. There's also been some interest from NetBeans folks.

As Cliff mentioned, the Eclipse Pollinate project is building support in Eclipse for the Apache Beehive framework. The Pollinate project just recently received approval from Eclipse.org, and we are still in the process of moving the Pollinate source from its temporary home donated by Instantiations to its official home at Eclipse.org. We are on schedule for an M1 release of Pollinate at the end of September. This release will provide very basic support (i.e. with no fancy UI tools such as a page flow editor) for building Beehive-enabled web apps that use only page flows (but not controls, which will be supported down the road).

    Carl McConnell
    Eclipse Pollinate project

I am still confused over where JSF fits in here. According to the interviewee JSF merely addresses the View aspect of MVC. I thought JSF was an MVC framework that also included UI (view) elements.

Is this BEAs way of saying we don't use JSF but you can use some of UI components?

Chris Braun

According to the interviewee JSF merely addresses the View aspect of MVC. I thought JSF was an MVC framework that also included UI (view) elements.

I read the available chapter on O'Reilly's JavaServer Faces. In this chapter you will see the difference between a 'regular MVC framework' and JSF. I think also there will some work to make JSF work together with Struts.

I am still confused over where JSF fits in here. According to the interviewee JSF merely addresses the View aspect of MVC. I thought JSF was an MVC framework that also included UI (view) elements. Is this BEAs way of saying we don't use JSF but you can use some of UI components?Chris Braun

You can find the answer here:
http://blogs.sun.com/roller/page/craigmcc/20040927#struts_or_jsf_struts_and