The ArcticBeans project is about components and their platform (run-time). More precisely, it is about a special type of components often called "enterprise" or "server" components and how to make a platform supporting such components more flexible and adaptable.

"Enterprise" or "server" components are traditionally providing a service for a client. The client performs operations (remote method calls) on the "enterprise" or "server" component. The platform (run-time) provides security properties, transactional behaviour, persistence and other supporting services for the "enterprise" or "server" component. On the client side no such supporting platform exists.

In the Arctic Beans project we belive that such a supporting run-time should exists for all components, including the client side components. This is important if we want to configure and control both sides of the communication stream between two components. Examples of its usage is to configure or reconfigure the security or transaction protocol used. This supporting environment should be configurable and adaptable. It will exist in different configurations supporting both small footprint components using limited resources and complex components needing a lot of resources and support.

Architecture

Components

The component model of programming evolved from object-oriented programming and the concept of separating an interface description from the actual implementation of it. Components is not the next hot thing for the future, it is already there [1,2]! The ActiveX and COM component technology has been an integrated part of Microsoft Windows since Windows 95 [3] and Java has its own component model called JavaBeans. DCOM, Java RMI and CORBA adds distribution to these component models.

Several different definitions or descriptions of components are available from the providers of component implementations and in the litterature [4]. The essence is that components are self-contained and they provide and use services through one (or more) interfaces. Self-contained is important. This makes it possible to deploy (and reuse) a component in different settings and environments.

Enterprise components

Enterprise or server components are components deployed in an environment providing support for business applications. This support usually includes support for transactions, security, persistence, location transparency and so on. Enterprise JavaBeans (EJB) [5,6] and the CORBA Component model [7] are examples of enterprise component models. The CORBA Component model is closely related to the EJB model. The main difference is the language independence of the CORBA approach. This note will focus on EJB, but most assumptions will fit the CORBA Component model too.

Container

An Enterprise JavaBean executes within a container. A container provides an application context for one or more beans. It provides management and control services for the beans. In practical terms, a container provides an operating system process or thread in which to execute the bean and the implicit services needed to fulfil its business tasks.

The container supports a number of implicit services, including life-cycle, state management, security, transactions, and persistence. Enterprise beans do not need to manage these services individually. They are automatically managed by the EJB container. For instance, the EJB container automatically performs all security checking on behalf of the enterprise bean. It can also automatically manage the start, enrolment, commitment and rollback of transactions on behalf of the enterprise bean

EJB components can be customised at deployment time. This includes transaction behaviour, security features, life-cycle, state management, persistence and so on. However, these customisations are limited, preselected, and dependent on the actual container implementations.

Reflection

The ArcticBeans project will try to open up the implementation of a component (enterprise bean) with the use of the concept of reflection [8]. We will focus on the security and transaction services and how to adapt these services according to the application needs and its environment (container).

Security

In the real world, security is always an issue. The EJB containers provides security functions to control the access to operations the user wish to perform. Users are validated via access control lists (ACL). An ACL lists the users and their rights. Java Development Kit 1.2 (JDK 1.2) provides a security model for authentication and authorisation. In EJB, these services are used to provide transparent security.

The security model provided by EJB might not fit a given application or set of users. The ArcticBeans project will open up the security model using the concept of reflection. This makes it possible to customise (or replace) the security functions provided by the container to fit a specific application and set of users.

A computer security "reader" is available from the home pages of TaSK.

Transactions

Transactions are handled by the underlying transaction operations in EJB containers. This makes it possible to provide implicit (automatically) transactions performed by the containers on behalf of the transaction participants.

Transaction processing is essential in enterprise applications. This is basically supported by a transaction service or transaction monitor. The available transaction monitors support only basic transactional behaviour. Support for extended transactional features is highly demanded.

The transaction support is hard-coded in EJB container implementations and therefore is vendor-specific, and tend to comply with only one particular transaction monitor. It is not possible to configure or even dynamicly choose which transaction monitor/service the server is to work with, nor is it possible for the server to apply extended transactional features.

The reflection technique of ArcticBeans is our key to solving this hard problem.

A transaction processing "reader" is available from the related AdTrans project.

References

[1] M. D. McIlroy. "Mass Produced Software Components". Proceedings, NATO Conference on Software Engineering, P. Naur and B. Randell (eds), Garmisch, Germany, October 1968.

[2] Peter M. Maurer. "Components: What If They Gave a Revolution and Nobody Came?". Computer, Vol. 33, No. 6, June 2000.

[3] Don Box. "Essential COM", Addison-Wesley, Object Technology Series, 1998.

[4] Clemens Szyperski. "Component Software, Beyond Object-Oriented Programming". ACM Press/Addison-Wesley 1998.

[5] Sun Microsystems. "Enterprise JavaBeans Technology". Home page.

[6] Anne Thomas. "Enterprise JavaBeans Technology: Server Component Model for the JavaTM Platform". Patricia Seybold Group (Prepared for Sun Microsystems, Inc.), Revised December 1998.

[7] OMG. "CORBA Components". OMG TC Document orbos/98-10-18, November 1998.

[8] Brian Cantwell Smith. "Procedural Reflection in Programming Languages". PhD Thesis, Massachusetts Institute of Technology, 1982.