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. :) Eddie On 6/20/06, Antony Chien <[EMAIL PROTECTED]> wrote:
2006/6/21, Kenneth Tam <[EMAIL PROTECTED]>: > > 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
