Garrett Conaty - Principal Technologist

Garrett Conaty is a principal technologist at BEA where he works with the Beehive team on developer and partner adoption activities, including the development of Beehive service control packs. He has over 10 years industry experience, with the last 6 years focused on SOA and J2EE development in both integration and infrastructure. Prior to joining BEA, Garrett was the lead architect at TrueLink, a TransUnion company, where implemented an SOA application using WebLogic Workshop and WebLogic Integration. Before TrueLink, Garrett spent a number of years in Ireland, where as a principal engineer he drove the inception of IONA's first J2EE product. He also was the CTO of ebeon, a 200 person systems integrator, providing J2EE application development for enterprise customers in the US and Europe.

Introduce yourself to the community.

My name is Garrett Conaty. I work as a technologist in developer marketing at BEA. I am primarily focused on the VI project, evangelizing the work that the engineers have done, as well as helping to jump start the community around it, working with vendors on providing controls, things like that.

So, what exactly is Beehive, how did it happen?

Beehive had its beginnings back in Workshop 7.0 and we were focused at that point on making web services easier to use for the Java developer from treating them just like a java beans, acts as a web service. That expanded into Workshop 8.1 where we added support for Java page flows, Web services and some more controls. Beehive is then the next generation of that evolution and it was a project that we open sourced out to the Apache community and it’s now in the Apache inhibitor. So, it’s the next version of workshop framework as an open source framework.

So what exactly is in it? What do I get if I download it?

There are three components to Beehive and a fourth, which is another Apache project, but let us focus on the three. There are java page flows, which enable you to build UI applications on top of Struts in a workflow like manner. There are controls, which let you treat any enterprise resource simply through a Java bean like interface,e and there are Java Web services. So you can take a Java object and annotate it using the JSR 181 standards, annotate those and expose your Java object as a Web service. All those three tools make a lot of use of a separate Apache project, which is XML beans, and that lets you treat XML documents as a Java bean like object as well.

So if I go to the Apache site and download it. Is it going to run out of the box or is there anything else that need to download first?

The Apache project uses Tomcat as the reference for building beehive applications. Of course, it runs best on the WebLogic platform but Beehive does not require a specific app server to run on. The controls themselves make requirements of servers. For example, if you wanted to use an EJB control then you would need an EJB container if you wanted to use Web service controls, you need Web service capabilities and the like, but for most intents and purposes then it is up to the control what underlying structure they need.

How does the whole control thing start off? Why did you find you needed controls?

There are a heck of a lot of lot of enterprise job APIs, lot of web service APIs and they seem to keep growing more complex as time goes by. We created controls to provide real simple access to those enterprise resources. Java beans is a natural component model that is straightforward, easy and very accessible to most Java developers so we created controls then to provide that simple Java bean interface to complex resources, like Web services and EJBs.

Is there an engine behind how all this works, and how does that work?

Yes and no. Essentially you are looking at Beehive controls as almost a lightweight type of container and that container is essentially a Java bean. When you provide a control, lets say a control to talk to a Java message queue, then that implementation is wrapped by a Java bean and capabilities of the containers for things like property access, or events, and access to the metadata are provided then, by a wrapper, that is created in assembly time for your control implementation.

What kind of controls are there?

In Workshop 8.1, we released controls for talking to JMS Queues, EJBs, databases, Web services of course, and some other ones like Timer, and things like that. There are a number of controls that are service controls that we announced a few months ago for talking to Web services like E-bay, Amazon, Paypal etc., to provide a Java developer with really drag and drop functionality to take a POJO and talk to these vendor’s Web services.

How about if I want to write lan control? How do I go about that?

The first thing to do would probably be to go to the Apache website and look at some of the examples that are there for the Beehive project, look at the unit tests and how they work for writing controls. There is a good example of how to write a JMS control, for right now, and then of course you can reference the Workshop 8.1 controls.

But simply, you create you control interface which is a Java bean interface, you define the properties that that interface is going to require as metadata and then you write an implementation class and the Beehive control framework takes care of matching those together and providing the simple interface for the client.

Is there a place I can go to find other people that run controls and download them?

The best place I would say to go would be at the BEA developer site, Dev2Dev, and we have a controls gallery that showcases a lot of controls that vendors have put together. Controls from vendors like Documentum, Salesforce.com and their like. We have also sponsored an open source community called Controlhaus, which is a sister site to one that a number of people are familiar with called Codehaus that have some projects, really new projects like Groovy, which combines Ruby and Python into the Java language and some other really innovative projects. So we sponsored that; the creation of a community where any developer could create controls and then have access to Version Control, issue tracking, WIKIs and things like that.

So why did you think you need it on an independent site?

It really helps to have a neutral place, since the Apache Beehive project is an open source project and there are a number of different vendors that then are support for Beehive. So we wanted to have a place where there was really no barrier to entry, if I were working at home in my spare time and had an idea for control, that I could publish this control right to that site. All the way up to that, of course, a company is making controls and needing to handle, lets say, host and development with an independent site.

So if I am building an application with controls what if I want to use the Java page flow? What if I want to use something like JSF. How do I go about integrating the two?

Controls are actually quite complementary to the page flows, but they are complementary to the JavaServer Faces. Essentially, controls just provide a POJO interface to a business object, or a service. That means that if you are using JavaServer Faces, which talk about the construction of view for your web application, those could actually be used quite well with Java Page Flows and then have the Page Flows call your controls. So, you have got a real complementary solution of your view than with your controls essentially being your model.

What are some of the other newer innovations like lightweight containers and some of the persistence framework that are out there? How do they all fit in with this control methodology?

There is some overlap with a lot of the lightweight containers. A number of them are constructed or based around this principle of inversion of control, which is something that has been around in Workshop for quite a while now, and then this of course exists in Beehive. There is nothing preventing you from incorporating, lets say, Spring components with controls, or working in PicoContainer controls with Beehive controls.

There is definitely some overlap, but there is nothing that prevents that. It terms of things like new persistence frameworks and things, it’s definitely possible to have a hibernate control for accessing your database just like we have JDBC controls and entity bean controls. So, in fact that is something I would love to see.

If I am going to work with controls, do I need Workshop, or can I use other tools?

There was some confusion I think that the Workshop is overloaded, that it’s both IDE that provides the tooling support for the Workshop framework, which consists of controls, page flows and the like. There is no requirement to use the IDE to build Beehive applications. Of course, because Workshop is a mature product and it is built specifically for building these types of applications, it’s going to provide a nice flow for and best user experience for that, but you can build Beehive applications with eMax.

We have actually helped with an Eclipse project called Pollinate, so there is an Eclipse subproject where the Pollinate team is building, essentially, Eclipse support for building Beehive applications so that you can edit your java page flows and build controls from within Eclipse.

So, can you can give me a example of how I would work with the control?

Sure. The simplest way to work with a control would be to incorporate that type of functionality in your app. That could be as simple as looking at a palette of controls, it’ll say in Workshop, and dragging and dropping in support for databases or the E-bay Web services directly in your application. It is also possible of course to build controls, that if you have a certain type of resource like a new type of database, or a new server technology to build a control implementation around that and let uses of your technology access it just through a Java bean.

So, what you think about the issue of hard coding stuff in controls are there any best practices?

Hard coding is something that the Beehive controls attempted to solve, or at least delay until assembly time or runtime. In the case of using metadata for specifying what types of e-controls that you are going to use as well as what requirements the controls need of its environment.

For example, if I use a control for my client application, I can specify using the Metadata and say: add control myControl. The implementation for that can be specified at assembly time, it can even be changed at runtime. Similarly, if I deploy a type of control, lets us say, a Web service control and I declare metadata that this is going to require some type of Web service implementation, then I am not hard coding that Web service implementation, it can be that way until runtime essentially.

So what kind of schemes are there for overriding these annotations at runtime or deployment time? Can you do it programmatically, can you do it through XML documents?

Right, right, so you specify all of your various properties and things to a control and all your annotations directly in your Java source, and at runtime then you have the ability that because they are Java beans, those properties turn into setter and getter methods for that control implementation, which means then that you can dynamically change them at runtime, or using for example the Web Logic administration console to introspect on those controls and have access to the properties that way.

So can I take a control that is supplied to Beehive and extend it to do additional stuff?

Definitely. The best example of that would have to be the service control. The Web service control lets you talk to Web service and has support for creating a SOAP message, send it across the wire, return the response back as a Java object, in fact, an XML bean. The base service control then has all the logic for how to set those things up.

But in a control that extends that, for example, if I had a Paypal control, then there are a number of methods on the web service that will be specific to Paypal that can be extended for the implementation. If I mark my extension with those methods then the base class for the Web service actually knows how to using a reflection, take those methods, convert them to the right SOAP calls, and call the appropriate Web service method.

So controls fit in completely with the Web services, JWS and the net UI java page flows? What does the entire architectural look like for building an entire application?

You can build an entire application based on the controls that are going to provide you business logic. Talking then to remote Web services, if you are using Web services, or to J2EE if you have a J2EE implementation. Then your page flows really define what your UI is going to look like. All your logic and your workload is then defined through your control layer and behind your Web services. With that being exposed, either through a Web service interface, or directly as Java objects to your UI layer which sits right on top of Struts.

So, can you can give me a example of how I would work with the control?

It is definitely not just a BEA thing. Beehive is actually an Apache project so there are definitely committers from BEA as well as a number of committers from the general community. We have gotten support for Beehive from app server vendors like the Geronimo project, JOnAS as well as support from HP, RedHat, etc., and I think that we will see, in the next few months, that Beehive really provides a good SOA type of application framework for any Java developer. It is not restrictive of one platform or another. Of course, at BEA we are putting in definitely a lot of effort on making platform the best environment to run Beehive applications. But they can run on a number of different platforms.

So, that’s in the short term, where do you see this in a couple of years’ time?

I would like to see that Beehive controls are the way to write Java apps. There was through the development of Java beans, Java beans are really a nice, simple yet powerful component model that seems to have ended just with writing UI components. Then we had the whole rise of Enterprise Java, and a lot more complexity in that.

I would like to see the Java community be able to return to a simple type component model for doing complex things. I would like it that if you are a Java developer and you need to integrate with Hibernate, or need to integrate a searching functionality with Lucene, or you need to integrate to a Web service, then there are Beehive controls for all those things, and you can literally wire those controls together in your application.

Do you have any final advise to everyone that is listening on what to do with controls?

I would say, because we are kind of in early days yet with the Apache project, that it is a great time for people to get involved. Subscribe to the Dev mailing list, subscribe to the user mailing list. Check out the documentation for the philosophy and architecture behind controls. As well as there is even an opportunity to influence the direction of controls.

I would also say that the code now is available to build controls. If you have a given type of service type technology and you want to provide a control interface, you can get started right down in building that. Then using java page flows which are also part of the Beehive project, you can then construct web apps and start demoing your Beehive controls. It is definitely open for people to start coming to, and playing with, and checking it out, and starting to move forward out with it.

That is great, it sounds really exciting. Thanks for talking with us today Garrett.

Thank you Steve.