beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie O'Neil" <>
Subject Re: Controls "the next generation"
Date Wed, 21 Jun 2006 05:13:32 GMT
Ken --

  Thanks for starting a list -- we've needed a jump start on this
topic for a long time.  :)

  From a high-level, I agree with the goal of supporting ease of
*usage* but still expecting a certain level of Java expertise to
author a Control.  Taking this further, it makes sense to support both
a bottom-up and top-down development experience that's "complete" in
the former and "easy" in the latter.  Ideally, they share the same
infrastructure.  A shortcoming of many frameworks today is that they
do one or the other -- very few (if any?) support ease of use and
completeness of programming / configurability at the same time.  I'm
not suggesting that we should build all of this ourselves -- Spring
integration might be a good way to get the "completeness" part and
provide Spring the ease of use part.

  My feature list is similar:

- remove the code generation dependency.  I've thought a lot about
this, and the code generation model is great for debugging but makes
testing and builds more complicated.  One reason to move away from
codgen is so that Controls can be created inside of a VM.  This solves
two problems -- removes the need for codegen and makes testing easier
and makes it possible to dynamically wire resource or business logic
facades in process without ever even having a source file.  If this
happens, I think that we need to beef-up the Control base classes so
that any generated code can operate against generic methods in the
base class but preserve a similar set of data structures.

- remove the dependency on the Glasgow / Containment and Services
specification.  While this has some good ideas, namely service
provisioning and look-up, it's also very heavy weight and rooted in
Java 1.2 features.  Something more modern would be quite interesting.

- enable ease of testing.  The JUnit test container is a good start
here, but we can do more / better.  Controls should generally
encourage a resource injection model for everything -- for example,
the JdbcControl should have a ConnectionFactory object that can be
wired-up from Spring (etc).  The Controls core and existing system
controls should support this.

- take a good, hard look at Spring integration.  This could take many
forms, and I've some thoughts on this I'll post in a wiki.  In short,
Controls should support more than just resource access -- they should
support business logic in a first-class manner because of the need to
secure / transact this type of code.  Perhaps just using Spring beans
is a good way to go here.

- support various annotation grammars.  As grammars proliferate,
runtimes will need to make clear what they do / don't support and
behave accordingly.  For example, it'd be really interesting to be
able to bind a Control to a WSDL and surface it as a web service.
Today, that would require running both annotation processors, but
they'd execute in a vacuum.  Would be great to be able to embed some
intelligence in the annotation processing so that grammars can be
checked together.

- enhanced pattern support.  We can gain lots of value from patterns.
Some of the last work we did in NetUI was very pattern focused and
gave us a level of configurability / extensibility that we'd never had
before.  Controls certainly have some points for plug-ins, but they're
not well documented today.

- keep all of the infrastructure around declarative property / event
wire-up.  These are two of the three parts of a POJO (properties,
methods, and events), and it's very convenient to do declarative
wire-up of the Ps and Es.

- look at supporting SCA by making Controls an SCA component model.
At one point or another, Controls have supported a variety of those
features in SCA; seems that it might be worth resurrecting that and
getting involved in the Tuscany project.

- support a more fine-grained resource model.  I'd like to have a
JdbcControl that holds a Connection only during invocation and no
longer.  There should also be a way to disable this, but when using
JdbcControl and then web service control, the Connection shouldn't be
kept around while making the SOAP call.  This requires a more fine
grained lifecycle.

- support schema generation to describe the configuration options for
a control.  These could be plugged into a Spring 2.0 config file via
the namespace support.

  Ken, why de-emphasize the nested use cases?  I assume you still mean
that we should support use of a consistent configuration model for
nested things, right?

These things would certainly be a good start -- sounds more like a 2.0
than a point release to me.  :)


On 6/20/06, Antony Chien <> wrote:
> 2006/6/21, Kenneth Tam <>:
> >
> > I've had a few conversations recently about what kinds of
> > changes/improvements might make sense for Beehive controls to make
> > them more accessible and usable in light of all the changes that have
> > gone on in the Java development world since controls were originally
> > designed.  Here are some rough thoughts/ideas I've had; I'll probably
> > start exploring some of these ideas in the coming weeks via
> > prototyping in a sandbox and post more detailed explanations of what
> > I'm thinking.
> >
> > Goal:
> > Rearchitecture to incorporate support for various contemporary
> > container and ease-of-development technologies, and strea
> > mline/modularize feature-set based on developer feedback.
> >
> > Support strong separation of service provider/consumer concerns
> > - continue to expect control implementation authors (service
> > providers) to be more highly skilled Java developers than
> > consumers.
> > - focus more on adding value to consumers, less on making it easier
> > for the provider (plenty of other technologies in t
> > hat space).
> >    - controls _usage_ should continue to be highly toolable
> >
> > Key use case is consumers authoring interface extensions for extensible
> > controls
> > - rich support for provider-defined annotation grammars & associated
> > semantics
> > - think of controls as making Java dynamic proxies easy &
> > annotation/metadata driven.
> >   - focus on resource access / smart proxy problem
> >
> > De-emphasize nested controls case
> > - controls no longer positioned as generic logic containers
> > - just write pojos, use other containers and their features
> > - limit or refactor eventset support (how important has this been in
> > actual usage)?
> I think that eventSet is important async model. Although the actual usage
> may not be high, but it will be higher, especially considering SOA as next
> big thing.
> Make it easier to use controls from anywhere by reducing/refactoring
> > container requirements
> > - remove or refactor dependency on JavaBeans Runtime Containment and
> > Services Protocol specification (unclear that valu
> > e of that framework justifies cost/complexity)
> Agree on this. Just make it transparent for us, ok?
> - consider interop and co-existence with other annotation sets as an
> > important use case
> >   - JAX-WS
> >   - EJB 3
> >   - JSR-250
> Yes, definitely.
> - consider replacing compile-time code-gen with runtime bytecode gen
> > (asm or cglib style)
> This is very important IMHO. One should be able to write a control and test
> it without waiting code generation. Code generation is not healthy for IDEs
> that consistently check for new files. Sometimes it even break the permanent
> generation of the underling VM!
> - delegate dependency injection/IoC responsibilities; replace
> > @Control and @Context
> >   - expect developers to use injection container of their choice
> >    - Spring
> >    - EJB3/JSR-250 (@Resource)
> >   - refactor declarative property configuration (usage of @Property
> > annotations on fields marked w/ @Control) to make it
> > optional (just another source of injection)
> For dependency  injection, Spring guys are doing a common framework based on
> annotation. IMHO, Beehive Control should work closely with Spring guys, add
> on value where they can't reach.
>   - pluggable lifecycle support (can we replace ResourceContext?)
> >    - JSR-250 (@PostConstruct, @PreDestroy)
> >
> > ---
> >
> > Would love to hear some comments/feedback, especially about other
> > ideas of how controls might be more useful in conjunction with all the
> > other Java technologies that have proliferated in the past few years.
> >
> --
> Regards,
> Antony Chien

View raw message