Help

Inactive Bloggers
27. Oct 2007, 02:14 CET, by Gavin King

The theme of Web Beans is:

  • Loose coupling with strong typing!

/Loose coupling/ comes in a variety of guises:

  • deployment time polymorphism
  • runtime polymorphism
  • lifecyle independence
  • decoupling of technical concerns
  • decoupling of event producers from event consumers

Loose coupling makes a system more /dynamic/. The system can respond to change in a well-defined manner. In the past, frameworks that attempted to provide the facilities listed above invariably did it by sacrificing type safety. For example, many frameworks use XML deployment descriptors, or string-based identifiers to wire components together and define their lifecycle. Other frameworks use some kind of string-based expression language to bind interceptors to components (the most disgusting example of this is the use of regexes in AOP pointcut expressions).

Web Beans lets components interact in a loosley coupled way without /ever/ resorting to XML or String-based identifiers. The only time component /names/ are used is for binding Web Beans components to a non-typesafe language such as Unified EL.

  1. deployment time polymorphism is provided via typesafe /binding annotations/ and /component types/
  2. runtime polymorphism is provided via typesafe binding annotations on /producer methods/
  3. lifecycle independence is a feature of the /contextual component model/
  4. technical concerns are decoupled by interceptors bound via typesafe /interceptor binding annotations/
  5. event producers and event consumers are decoupled via a typesafe /event object/ and event binding annotations

You don't see string-based identifiers in Web Beans code, not because the framwork is hiding them from you using clever defaulting rules (configuration by convention, as the Ruby folks say, or configuration by exception, as we used to say in the EJB3 expert group), but because there are simply no strings there to begin with!

This provides obvious benefits in that /any/ IDE can provide autocompletion, validation and refactoring without the need for special tooling. But it also provides a less-immediately-obvious benefit. It turns out that when you start thinking of identifying components, events or interceptors via annotations instead of names, you have an opportunity to lift the semantic level of your code.

Web Beans encourages you develop reusable annotations that model concepts, for example,

  • @Asynchronous,
  • @Mock,
  • @Secure,
  • @Action or
  • @Updated,

instead of non-reusable compound names like

  • asyncPaymentProcessor,
  • mockPaymentProcessor,
  • SecurityInterceptor,
  • LoginAction or
  • DocumentUpdatedEvent.

When I look at Java code today, and I see these kind of compound names, it reminds me of old-fashioned naming conventions for variables in dynamic languages, which embed the type of the variable in the variable name, for example str_username. These naming conventions were a clear workaround for the fact that the language had no primitives for expressing typing information.

Compare the following observer methods:

void onDocumentUpdate(@Observes DocumentUpdatedEvent event) { ... }
void onDocumentUpdate(@Observes @Updated Document doc) { ... }

Both are correct, but the second approach is more Web-Beansy. The @Updated binding annotation models a reusable notion. We can use it for other events:

void onDocumentUpdate(@Observes @Updated Order order) { ... }

And notice how much more /literate/ this code is.

Or compare the following implementations of Login:

public 
@SessionScoped
@Component 
@Interceptors(SecurityInterceptor.class)
class Login { ... }
public
@SessionScoped
@Secure
@Component 
class Login { ... }

The second form is more Web-Beansy - the code is more decoupled and more literate.

The nirvana of this kind of literate programming is a new feature of Web Beans called /stereotypes/. A stereotype lets you encapsulate scope, interceptor bindings, component type, etc, into a single package that models a /role/ in the application architecture. For example, instead of defining:

public 
@RequestScoped
@Named
@Secure
@Transactional
@Component
class LoginAction extends BaseAction { ... }

We could create a stereotype:

@RequestScoped
@Named
@Secure
@Transactional
@Component
@Stereotype(requiredTypes=BaseAction.class)
@Target(TYPE)
@Retention(RUNTIME)
public @interface Action {}

And reuse it for all our actions:

public @Action class LoginAction extends BaseAction { ... }
public @Action class UpdateDocumentAction extends BaseAction { ... }

Another example is a stereotype for singletons. Of course, we /could/ write:

public 
@ApplicationScoped 
@Component 
class ReferenceData { ... }
public 
@ApplicationScoped 
@Mock 
class DummyReferenceData extends ReferenceData { ... }

But I would prefer:

@ApplicationScoped
@Component
@Stereotype
@Target(TYPE)
@Retention(RUNTIME)
public @interface Singleton {}
public 
@Singleton 
class ReferenceData { ... }
public 
@Mock 
@Singleton 
class DummyReferenceData extends ReferenceData { ... }

Well, this stereotype did not save much typing. But on the other hand, it tells us more about the ReferenceData class. The code is more literate and understandable. Even better, it's /much/ easier for me to find all singletons in my code, or to add an interceptor to singletons. It also makes it easier to ensure that certain patterns are followed consistently in a large project.

26. Oct 2007, 00:25 CET, by Norman Richards

I'm happy to announce that we've just released Seam 2.0.0.CR3. (download it) As you can see from the release notes, we've been rather busy the last few weeks. Most of the changes since CR2 are documentation and test related, but we've also been busy fixing bugs, upgrading dependencies and making sure that JBossTools and Seam 2.0 work together.

We expect the GA release to come in the next few days, so stay tuned!

25. Oct 2007, 22:28 CET, by Christian Bauer

Mark Newton presents JBoss application server 5.0 What's New at the JUG Switzerland.

History of JBoss AS

119 days average release cycle, 9 releases of JBoss 3.2.x, J2EE 1.3 certification, JDK 1.3.

126 days average release cycle, 6 releases of JBoss 4.0.x, J2EE 1.4 certification, JDK 1.4.

55 days average release cycle, 3 releases of JBoss 4.2.x, JEE 5.0 compatible implementation, not certification, does 95% of it and requires JDK 5.0.

For JBoss AS 5.0.x new standalone implementations:

  • JBoss Messaging (replaces old JBoss MQ)
  • JBoss Security
  • JBoss Federated SSO

New kernel is JBoss Microcontainer 2.0 and a profile service which is responsible for managing the POJOs that now bind the services together. Aiming for a Q1 2008 final release date and a CR in 2007.

JBoss Messaging 1.4

The new JMS 1.1 compatible messaging implementation supports distributed queues and topics as well as transparent failover and load distribution - internally it uses JGroups as transport.

Clustering

New major revision of JBoss Cache (2.1) with a much simpler API and a greater emphasis on usage outside of JBoss AS.

JBoss AOP 2.0

Integrated with the microcontainer: If you add behavior to a POJO using AOP, and you deploy it, you get dependency management - you can't call a POJO without the aspect, it won't be deployed before the aspect is available. And vice versa, aspects are not deployed if the POJOs they depend on are not deployed so far. Aspects can be bound to POJO lifecycle, e.g an aspect that binds a proxy into JNDI when the POJO enters the deployed state. It also has some new plain AOP features: Before, Afer, Throwing, Finally flows for interception.

What does the kernel do?

A microkernel needs to support dynamic loading and unloading of services. For that we need:

  • a way to deploy new services
  • a bus so that the client does not communicate with a service directly, clients are decoupled from services

How was this done in JBoss 3.x and 4.x? We used an MBeanServer to provide the bus and deployers that load services into the kernel together with a simple dependency injection mechanism. MBeans were used to implement services and configured with XML descriptors which injected attribute values into the MBeans at deployment. XMBean are special MBeans that allow you to add method interception to an MBean. Calls pass through the bus and interceptors with a level of indirection through a generic invoke(method, arguments, argumentTypes) operation.

For performance reasons the bus wasn't actually used much: A reference to a services would be looked up directly in the registry. So the interceptors were not used.

What was bad about the JBoss JMX microkernel:

  • JMX is restrictive, lifecycle and classloading were a problem
  • You can't run JMX on Java ME
  • You actually need to know how to implement MBeans
  • If you access services directly through a reference, interceptors are not applied

Design objectives for JBoss AS 5.x

Services should be POJOs and behavior should be added through AOP - effectively reproducing all the features of the JMX microkernel. Much improved dependency injection and classloading. Layered and easily extensible design (no references to JBoss classes), should be usable without JBoss AS.

The new name for this kernel is Microcontainer.

The core of the microcontainer is Container, Kernel, Dependency. Behavior is added with JBoss AOP.

Kernel: Provides the bus and registry, and an event manager.

Container: Wrapper for POJOs, AOP jointpoints and reflection on the actual service implementation POJO.

Dependency: Basically an abstract state machine that manages service dependencies.

Some optional packages on top of the core: OSGI integration, Guice integration.

Creating a service

Define the POJO with <bean> and <property> declarations in jboss-beans.xml (replaces the old jboss-service.xml). Beans have a name and a class, properties support injection with references to (other) bean names.

Add behavior using the <aop:aspect> namespace and elements and pointcut expressions. You can also extract the aspect/pointcut to a separate file.

Profile service

Management system for POJOs instead of the old JMX based administration which was based on editing XML files. People would manage configurations by keeping these files in CVS. The web console only supported changing the runtime values in memory, didn't write back into the files.

What we want:

  • Centralized maintenance as profiles, e.g. all, minimal, default, ...
  • Persistence of changes made to a profile across server restarts
  • Propagation of profile changes across a cluster
  • Versioning of profiles

Implementation similar to JDK 6 Open MBeans specification: A deployment has a collection of ManagedObjects, you define them with annotations in your service, e.g. @ManagedOperation(description="A setting you can change")

Summary

  • JBoss AS 5.0 has a completely new architecture based on the microcontainer with POJOs and AOP
  • Management improved with the addition of profile service
  • Clustering and security is much enhanced
  • It will be fully Java EE 5.0 compliant
24. Oct 2007, 04:56 CET, by Gavin King

The JCP folks seem to have resolved their technical problems, and the Web Beans EDR is now available at jcp.org. We've had some great feedback on the comments alias already. Please keep it coming!

Peter Hilton and Nicolas Leroux will present their experience of implementing an application using Seam, and Bruno Georges will talk about Open Source SOA.

Second JBoss Benelux User Group Meeting

The programme will begin with a presentation on Open Source SOA by Bruno Georges, Technical Development Manager, Enterprise Frameworks at JBoss. This will include an ESB Presentation and a demo based on jBPM for process flow orchestration. In the second presentation, Peter Hilton and Nicolas Leroux, will describe Lunatech's practical experience with JBoss Seam. We will talk about strengths and limitations of JBoss Seam 1.2.1.
  • Date: Friday, 2nd November 2007
  • Time: Arrive 1700-1800, presentations start 1800, finish 2000-2100.
Showing 1026 to 1030 of 1221 blog entries