Team spirit for objects Building complex systems from isolated objects often yields poor structure which readily decays during system evolution. Objects should team-up in order to co-operate and jointly deliver complex behaviors. Objects play specific roles within a given Team.
line
Context based dispatch Object behavior is controled by the currently active context of execution. Contexts are reified into Team instances, which may be used to mediate between roles and maintain state of the collaboration.
line
Modules larger than classes On the road to re-use of modules larger than classes two approaches compete: frameworks and components. For many applications white box frameworks are too fragile and black box components to rigid. Object Teams provide a middle road which balances encapsulation and adaptability.
line
Key Features of Object Teams
*
Weaving of aspect code into existing classes (no source code needed).
*
Teams are modules that encapsulate the interaction of a set of role objects.
o
Teams can be type-checked in a modular way.
o
Roles are automatically managed by their enclosing Team instance.
*
Teams can be refined using inheritance.
o
Collective refinement of role classes.
o
Team refinement realizes type-safe covariance of role signatures.
*
Teams are instantiable first class entities.
o
Teams are aspects that can be activated/deactivated at run-time.
o
Roles may refer to their enclosing Team.
*
Explicit connectors bind an abstract Team definition to a base package.
o
Binding happens a-posteriori, i.e., no modification in the base package is required.
o
Team binding is specified in a declarative style.
o
Bindings may specify different kinds of adaptations.
*
Object Teams require a minimal number of new language constructs to be learned for a maximum of modularity and composability.
How good is your software? jmove eases the understanding and valuation of the design and architecture of complex software written in java. It provides dependency analysis, metrics, design rule checking and impact analysis. Define your desired architecture model and check consistency with the implementation.
jmove offers a framework and an extendable set of tools to ease the understanding of the design and architecture of software systems and to provide support to control the software from this point of view. It is based on a model centric approach which allows to analyze different kind of sources like source code and byte code.
EasyBeans is an open-source Enterprise Java Beans (EJB) container hosted by the OW2 consortium. The License used by EasyBeans is the LGPL.
EasyBeans main goal is to ease the development of Enterprise Java Beans. It uses some new architecture design like the bytecode injection (with ASM ObjectWeb tool), IoC, POJO and can be embedded in OSGi bundles or other frameworks (Spring, Eclipse plugins, etc.).
It aims to provide an EJB3 container as specified in the Java Platform Enterprise Edition (Java EE) in its fifth version. It means that Session beans (Stateless or Stateful), Message Driven Beans (MDB) are available on EasyBeans.
The new persistence layer used by EJB 3.0 is now called Java Persistence API (or JPA). It replaces the CMP (Container Managed Persistence) model used by EJB 2.x. The default persistence provider used in EasyBeans is Hibernate Entity Manager or Apache OpenJPA but other JPA providers have been tested like for example Oracle TopLink Essentials.