| Carbon FAQ |  |
Author: Anand Raman (araman at sapient.com)
Version: $Revision: 1.8 $($Author: ghinkl $ / $Date: 2003/05/21 03:42:49 $)
Created: April 2003
|
| |
|
Carbon is a lightweigth component model for building framework
and technical services. The carbon project maintains both a core
carbon base and a number of technical services intended to spead
up enterprise development.
|
|
The element Carbon plays a important role in the chemistry of
life. Carbon has four valence electrons in its outer shell,
which can hold a total of eight. This makes carbon equally
likely to give up or take on electrons and places it
among the most combinable atoms in the universe.
On the same line, the Carbon framework is built around software
components which combine with other Carbon components, as well
as external components, to create complex systems.
|
|
Sapient, a leading
business and technology consultancy and has been involved
in researching advanced technologies to deliver
business value for our clients. Carbon is the result of a number
of years of investment in framework technologies. Carbon is
open source to benefit our clients and to fill a niche in
the development of enterprise software.
|
|
Carbon services provide a number of advantages over individual
use of underlying technical APIs. The framework creates a
centralized system for externalized configuration that creates
a more flexible and dynamic application. Carbon services can also
be created as lightweight alternatives to the common singleton
services that are often created in enterprise applications.
Carbon services are also useful in that they impose the common
OO principle of design by interface. By utilizing interfaces and
standardized factory construction, carbon allows for the replacement
of services through simple system reconfiguration. It also reduces
complexity by creating a rigid integration point and standardizing
the creation and configuration of those services.
|
|
Carbon is released under the
Sapient Public License 1.0.
This license is a derivative of the OSI approved Mozilla Public License 1.1.
This license ensures that carbon will always be freely available under
the supplied terms, for both public and commercial use.
|
|
| |
|
Carbon is an open source project and as such support can often
be found on our mailing lists.
Carbon Mailing Lists
|
|
Carbon is designed to use standard and extension Java apis and
does not require a J2EE application server to function. In fact it
will run in standalone applications or even applets.
Some of the carbon services are designed to be used within
application servers, such as the EJB lookup service and the
data source connection service. These services rely on standard
J2EE APIs and therefore can be used with any J2EE Application
Server.
The Weblogic Management Service or Weblogic Security
service are other features designed for use specifically with
the WebLogic application server.
|
|
Submit your feature request with as many possible artificats
here.
|
|
| |
|
Carbon consists of core infrastructure and a set of modular
services. The services are seperate subprojects of carbon and
can be chosen as needed to add functionality. Additionally, some
modules have depenedencies on other modules, such as the cache
modules dependence on the scheduler module. These dependencies are
documented.
|
|
| |
|
A dynamic proxy class is a class that implements a list of
interfaces specified at runtime such that a method invocation
through one of the interfaces on an instance of the class
will be encoded and dispatched to another object through
a uniform interface. For more details refer
Dynamic Proxy Classes.
Carbon uses dynamic proxies to tie together a set of
interfaces with their implementations to provide a single
consistent view of the component. Developers code the business
logic and Carbon ties together the service interfaces with
the business logic to provide a single consistent and
instrumented component view.
|
|
Deployment properties hold information specific to the
current deployment of Carbon. They are used by the Carbon
bootstrap process. e.g. Deployment properties can be set
to factory implementations to be used by the configuration
or the component services. For a exhaustive list of all deployment
properties refer the
deployment properties home page
The DeploymentService on the other hand is designed to help manage
differences in configurations between application deployments.
This service service allows configurations for all environments
and all instances within each environment to be stored
separately and chooses the right configuration at runtime for
each environment/instance. This allows all configurations to
reside under source control and alleviates the error prone
task of maintaining manually modified files on each deployment.
For more details refer to the
deployment service home page
|
|
If you are using CarbonDeployment.properties to specificy your
deployment properties, the file should be available from within
the classloader that loads carbon.
The deployment properties file does not go into the directory
that holds your Carbon configuration XML files. That directory
is not meant to be in your classpath as configuration files are not
loaded through a classloader.
|
|
The deployment service is one of the components started by the
startup service. The bootstrap process starts the configuration
service, component service, and in the end loads all the
components configured in the startup service before servicing
any requests.
|
|
| |
|
A major portion of Carbon is built on top of J2SE (standard java packages).
Few services like (ejb, email, security, management) build on
top of standard extensions and J2EE standards. To get started with
Carbon you should be comfortable with Java programming.
You might want to pick up specific J2EE technologies as and
when the need arises.
|
|
|
