Martin Percival, European technology evangelist and technology manager for BEA Systems Ltd, will present a free seminar on Apache Beehive in London on December 1st.

Beehive consists of components of the Weblogic Workshop that donated by BEA to the Apache Software Foundation that include:

    * NetUI (Page Flow + JSP tag library)
    * Controls framework
    * System controls for accessing JDBC, JMS, and EJB resources
    * Many bug fixes
    * Significantly enhanced documentation
    * Additional samples

You can register for the seminar at the Skillsmatter website.

Has anybody got real life experience with Beehive?

Have myself used BEA Workshop 8.1 pageflows+controls which were completely unusable due to the enormously long (up to 10 minutes) develop-compile-deploy-test cycle.

Is Beehive also deploying controls as EJBs or is there something more lightweight?

Are Beehive pageflows still an outdated version of struts with some state/nested state management logic?

Controls have moved to a POJO model for Beehive, so yes, a little more lightweight.

The seminar itself is one that we are running with Skills Matter who help us to run the UK BEA User Group. There will be a second session in the evening concentrating on some of the new toys in WebLogic Server 9.0 and maybe a sneak preview of Workshop 9.

Martin

Have myself used BEA Workshop 8.1 pageflows+controls which were completely unusable due to the enormously long (up to 10 minutes) develop-compile-deploy-test cycle.

That's very odd. Perhaps if you dump everything in one project, use all the default settings (which include full JSP pre-compilation!), and did a full project rebuild every single time you ran your project you might run into 10 minute build times, but why would you do that?

Not that you're the first to note long build times with the default settings. It should be better out of the box. Workshop's big problem is the lack of incremental compile (which will by fixed in Workshop 9 in Eclipse). But generally it's not going to have significantly longer of a build time than (for example) JBuilder or an ANT script would.

Anyway, in 8.1, page flows (JPF's) are dynamically compilable like JSP's, you hit them, and they recompile if necessary. Ditto for JWS web services, JPD process flows, etc. If you have a lot of POJOS, you could also modify the underlying ant script to turn on incremental compilation.

What really struck me was total annotation overkill.
While I had the feeling with EJB3 and also seam that they severely tried to cut down on configuration settings and kept them to a bare minimum of what you really need.
Beehive seemed to push almost every config option 1:1 of struts into annotations, which does not really make things that easier.
You have a little bit less to code but you get rid of the central config file point.
At the current state of affairs, unless I had a wrong impression, there is not too much additonal value in the usage of beehive, unfortunately because annotations are an excellent tool to get rid of verbosity, if applied correctly.

(See the @transactional and @webmethod usages, or simply have a look at EJB3, which makes things really simple)

Beehive seen through WebLogic Workshop makes life a lot easier and less annotated. Beehive clearly works in Workshop and saves time. The jury may still be out to Beehive's productivity benefits without the wizards.

Beehive seemed to push almost every config option 1:1 of struts into annotations, which does not really make things that easier.

Well, in reality a number of options still require a struts-config.xml, they're not in annotations.

The main "benefit" of page flows (depending on your perspective) is the central controller class for a set of pages. This has the benefit of making flows as easy as ASP.NET event handlers, but they're still Struts actions under the covers, with all the power that brings you.

I would also note that you don't need to use annotations unless you're actually setting something. And I'll note that .NET (Indigo) is also going heavy on annotations, so it's not exactly a rarity. Now, with Workshop sometimes there will be a longish annotation (for example, in a Web Service, if you're applying an XQuery to map an inbound or outbound XML document to your method's parameters), but I'm not sure it's better to spin it into an a seperate XML file. Annotations & deployment descriptors are intended to be tightly bound to the implementation.

If you need loosely-coupled or pluggable configuration, there usually are API's for every annotation so you can dynamically inject the dependency however way you'd like (properties, Spring, or whatever).

unless I had a wrong impression, there is not too much additonal value in the usage of beehive, unfortunately because annotations are an excellent tool to get rid of verbosity, if applied correctly.

The real benefit are Controls. For example the JMS control eliminates a lot of the boilerplate for JMS connection setup and catch-alls. Ditto for the EJB control, etc.

Hi,

It seems to me that the Java Page Flows (JPF) are similar to Spring Web Flow. Have any one compared these two interms of functionality?. seems to me that both does state management for the user.

srini

My impression is that the "old" Workshop 8.1 addressed important productivity issues with J2EE 1.3. and the then-current IDEs. Its underlying foundation of (partly hidden) EJBs for business logic and Struts for Web-UIs became, however, very soon a technology choice that few projects would have made otherwise. (For instance, as you would expect, Workshop 8.1 applications were/are notoriously difficult to unit-test.)

In the light of Java EE 5.0's EJB 3 and JSF (and frameworks such as Seam) the now-open-source Beehive seems like an interesting piece of technology that has, somewhat sadly, lost its reason for existence, as most of what it solves has in the meantime been solved by other - and standardised - means.

That's my very personal opinion, of course.

  cheers,
  gerald

http://www.gerald-loeffler.net

Since we're offering personal opinions, I'll share mine and will, not surprisingly, beg to differ. :) For full disclosure, I'm a Beehive committer and BEA employee.

  Arguing that action based frameworks like Beehive's NetUI are irrelevant because of the JSF standard probably comes as a surprise to many developers. JSF is certainly interesting from a component perspective as a view tier, and NetUI supports this fully. But, there are clearly people building NetUI-based applications (I know of several that are already in production on Beehive 1.0), and there is innovation happening in flow frameworks like Beehive's Page Flow and Spring Web Flow.

  We believe that there is a place for frameworks like NetUI that provide a consistent development model, state management, declarative exception / validation, and nesting / sub-flows. Thus, we believe we exist for a reason.

  As far as unit testing in Workshop 8, I completely agree -- it was difficult if not impossible to unit test both Controls and Page Flows out of the server. Fortunately, all of the Beehive source artifacts are testable out of container. Additionally, we've taken steps to change the architecture of Controls to be POJO based and have changed the in-server compilation model.

  Might actually be worth a look:

    http://beehive.apache.org

  ;)

Eddie

I see Controls as central to Beehive and my primary criticism is that Controls are essentially an alternative component architecture on top of J2EE 1.4. The approach is technically interesting and it actually does provide a much cleaner, easier to grasp programming model than EJB 2. But I also think that EJB 3 is very effective at achieving ease-of-development and so the point for Controls is mostly lost.

As for NetUI, I certainly didn't say that it is "irrelevant because of the JSF standard", I just don't see what new and exciting approaches it brings to the table (in this ridiculously crowded technology corner).

With Workshop 8.1 I thought the single most compelling argument for it was the consistent, integrated development experience it offered. A pity it used to be based on a closed standard. Now, with Beehive, it can be based on an open-source foundation that doesn't capitalise on the innovations available in Java EE 5.0.

  cheers,
  gerald

http://www.gerald-loeffler.net

Thanks for clarifying; I read this comment:

In the light of Java EE 5.0's EJB 3 and JSF (and frameworks such as Seam) the now-open-source Beehive seems like an interesting piece of technology that has, somewhat sadly, lost its reason for existence, as most of what it solves has in the meantime been solved by other - and standardised - means.

as implying that the JSF standard caused NetUI to lose its reason for existence. Apologies for misunderstanding. :)

The exciting approach NetUI brings to the table is that Page Flow encapsulates actions, exception handling, per-session state, and validation logic into a single, and reusable source file -- a Page Flow. And, you can integrate any view tier beneath this rich controller model -- JSP, JSF, etc.

As far as Controls and EJB 3, we're undergoing a revolution around lightweight component frameworks like Spring Beans and Beehive Controls. One goal of these frameworks is to be more than just the component model and to also offer specializations that can be used for resource abstraction (JDBC, EJB, JMS, JAX-RPC, Hibernate, JDO, etc). At least, that's where we see a lot of value in ease of development / productivity.

Eddie