Can Beehive Spur Portable J2EE Controls?

Apache's Beehive is gaining momentum, despite naysayers. It has attracted top Java toolmakers, ISVs and at least 100 end-user devs. Beehive's aim is to provide J2EE devs an open approach for building vendor-independent, "portable" J2EE controls, relying largely on metadata techniques. Integration Developer News looks deep into the Beehive.

Tags: Controls, Developers, J2EE, Java, Support, Devs, J2EE App,


If supporters of Apache's Open Source Beehive project have their way, Java/J2EE developers may soon have a new and efficient method of creating a new array of container-independent, portable J2EE controls and code assets, driven by metadata technologies, not unlike those under consideration for EJB 3.0.

In the month or following the passing of the baton of Beehive technology to Apache (from BEA Systems), there are signs Beehive is gaining credibility among toolmakers, ISVs and enterprise developers.

"Two shoes have to drop to make Beehive rise to a de facto standard level, such as Java Struts," BEA director of dev marketing Dave Cotter told IDN<.I>:

  1. IDE Support: "We have to have tools vendor that support Beehive, so we spent a lot of initial efforts for Borland, Compuware, Pollinate (Eclipse) and Weblogic Workshop. As a result, Beehive is now supported in 4 different IDEs. "

  2. J2EE Application Server Support : "Architects and devs have a choice of platform infrastructure that can access and run Beehive's annotations," Cotter said. Earlier this summer, the platform list added HP, RedHat, Jonas (Object Web Consortium J2EE app server) and Geronimo (Apache Software Foundation's Open J2EE app server) to BEA's own app server and Apache/Tomcat.

    We're at a point now that there is a very big footprint for Java developers. Now, [the question for them is] 'What can I run Beehive on?' In BEA's view, now that they've given developers choice in tools to write apps and choice in infrastructure for where Beehive-driven apps can be deployed, it's time to kick in the entrepreneurial spirit."

    Cotter says Apache's Beehive project already has 100 people who have written controls. "They say they absolutely love the idea that our controls can now not only run on BEA's stack, but run on all these other stacks. So, yes, we're already starting to see the start of a [cross-platform controls community] based on the inbound inquiries we're getting around controls," Cotter said.

    Integration Developer News Interview
    with Dave Cotter,
    BEA Director of Developer Marketing


    IDN: With Beehive, are you saying that Java/J2EE developers should be thinking about a new category of "open" or cross-platform controls? And will it be possible for J2EE devs to begin harvesting their current controls for multi-platform use?

    Cotter: It's not only plausible, that's the strategy. Look at what was successful in the Microsoft world. From a developer's perspective, it was two key elements: abstractions and reusable components (which in VB were called "controls"). Those [controls] are now pervasive through Microsoft's entire system. What Beehive delivers is both of those -- abstractions and reusable components -- to the Java community. Before Beehive, we just didn't have either.

    IDN: Let's talk about timing. Once could argue that Microsoft's success came from the fact that it introduced controls at the beginning of a cycle, not the end of a maturing one. Now that we're in a maturing phase of Java/J2EE, what do you think has to happen to get developers even more supportive of creating hundreds of controls?

    Cotter: I think it's an awareness thing, or a timing thing. There's good and bad news with the timing. The good news is that we're bringing new tools to let developers create a highly productive dev environment. The bad news, or the challenge, now rests with us and Apache and all our Beehive supporters: We need to build the awareness of the productivity benefits that [reuse] of controls can bring.

    IDN: Do you see Beehive as setting a new entry point for how Java or J2EE devs can think of and deploy controls? From an architectural or business applications/rules point of view, for instance?

    Cotter: I think that's a very astute observation. In the conversations I've had with senior developers, a lot of them have embraced this move for two reasons: One is job security, and the second is the continuation of the feeling [they can deliver] value as a top-line Java developer. For them, [Beehive] gives them the opportunity to develop J2EE apps and proliferate them.

    IDN: And how do you see Beehive contributes to this opportunity?

    Cotter: Because J2EE developers were in a little bit of a rock and a hard place before, which was touting the benefits of the J2EE architecture and Java as a language, but knowing that only a small percent of the Java devs in that enterprise could do anything with J2EE.

    IDN: So, your vision is that Beehive extends the reach of J2EE developers, architects and applications -- rather than limits or minimizes J2EE?

    Cotter: If you think about the essence of EJBs, controls are a lightweight EJB or "EJB for the rest of us." Both the experienced [and inexperienced] J2EE developer worlds need to be satisfied. Take Microsoft's Visual Basic and Visual Studio, for example. Visual Basic and Visual Studio are both extremely beneficial. It's not the MS programmer that's worried about their job.

    Where Beehive has scored a tremendous amount of points is that it is Open Source. They get to see the sophistication of what we did, they have an opportunity to tweak it and refine it as they see fit. But it also now gives experienced J2EE developers a platform by which they can introduce J2EE [capabilities] to a larger dev group within their organization. It also, in our view, gives them a better and more efficient way to deliver on the promise of "Java portability" in a substantial way -- one they probably have been espousing for some time but never were in a position to deliver on, primarily because a single J2EE developer team was never going to write an [end-to-end] enterprise application all by themselves.

    IDN: What's the key to having these Beehive-based "open" Java/J2EE controls run cross-platform or multi-platform?

    Cotter: Every time I do something for Java, I have to go and pick which particular Java vendor I want to do it with first. Today's Java [implementations} are now different enough that I can't just write one. So, with Beehive, a "controls" developer will not just be a silo J2EE app developer. With Beehive, the developer sets up a framework that provides J2EE devs with an SOA pallet. [you can deploy natively in Java].

    IDN: What has to happen next for that vision to become a realty?

    Cotter: The first order of business is to provide running in the EJB tier, so basically what you'll have is two types of containers that support controls, based on what they do. One of the things we're making available is our database control OS and EJB control so developers can see how controls that run in a servlet container (that may actually just be a pageflow-specific control) run in a servlet tier versus a control that's wrapped with an EJB.

    We still need to come up with a specification for how controls are going to run on multiple containers. And, from that, as developers develop and deploy, we'll have experience that we can use to derive patterns associated with: how to do; when to do and anti-patterns -- or what not to do.

    IDN: And how close is that specification work to being completed?

    Cotter: We're at the spec phase right now. We just made the code available so we're really at the beginning of people jumping in aggressively. Now that there's code, and developers can see this is real, the real work and comments begin. So, for now, it's too early to try to document patterns and anti-patterns for Beehive because dev has just begun.

    IDN: What about the J2EE developer concerns that working with Beehive will mean they just know how to build for BEA WebLogic faster, and that they won't gain an upper hand for other J2EE app servers?

    Cotter: Our intention is that controls should be thought of as services. Just like people author web services and don't want to be concerned about what platform it will run on or what other service might consume it. People want to create controls and not be worried about whether it is consumed in an IDE or what platform stack it runs on. They want to write a control that has some business value, and use that as a loss leader to sell added software or services -- or bundle them together.

    Inside the Beehive 'Portable Controls' Architecture
    Beehive's Controls architecture provides a common framework and configuration model for how enterprise resources can be exposed to clients. It does not replace existing resource access models; it provides a unifying layer on top of them to provide consistency and simplification.

    Beehive's Control architecture is a lightweight component framework based upon JavaBeans, which exposes a simple and consistent client model for accessing a variety of resource types.
    Controls take the base functionality of JavaBeans and add in the following unique new
    capabilities:
    • Enhanced authoring model uses a public interface contract and an associated implementation class to enable generation of a supporting JavaBean class for
      handling the details of property management and initialization; and an
    • Extensibility model enables the construction of views and custom operations
      (with implied semantics) on the Control using metadata-annotated interfaces.


    To help promote wide developer support, Beehive's Controls architecture is designed to be IDE-friendly, so defining and configuring client access to J2EE resources can be a property or wizard-driven process, and can be represented using visual design metaphors.

    At its core abstraction approach, Beehive extends the base concepts of JavaBeans to add the new metadata capabilities of JSR-175, an extensibility model that allows the definition of customized and preconfigured views (operations), and a resource management strategy that enables client-side resources (such as stubs, handles, connections, sessions, etc.) to be managed transparently on behalf of the client. JSR-175 metadata attributes and external configuration data provides an enhanced configuration model for resource access, which focuses on the Controls programming and configuration model from two perspectives: (a) The authoring and extensibility model for defining a new type of control; (b)The client access model for declaring and using controls.

    Beehive's use of JSR 175 includes a set of metadata attribute/property definition conventions that enables introspection and presentation of available configuration options and value validation. It provides a JAR-based packaging model, allowing Controls to be easily discovered by tools and assembled into application modules.

    Go to http://ftpna2.bea.com/pub/downloads/ControlProgramming.pdf> for a white paper that describes how Beehive helps J2EE devs build controls to run in multiple servlet containers, or multiple J2EE application server stacks.



    back