content/concepts.mdtext - tomee-site - Git at Google

 Title: Concepts
 OpenEJB was founded on the idea that it would be embedded into third-party
 environments whom would likely already have three things:

  - their one "server" platform with existing clients and protocols
  - their own way to configure their platform
  - existing services like TransactionManager, Security, and Connector

 Thus the focus of OpenEJB was to create an EJB implementation that would be
 easily embeddible, configurable, and customizable.

 Part of achieving that is a drive to be as simple as possible as to not
 over-define and therefore restrict the ability to be embeddible,
 configurable and customizable.	Smaller third-party environments could
 easily 'downscale' OpenEJB in their integrations by replacing standard
 components with lighter implementations or removing them all together and
 larger environments could 'upscale' OpenEJB by replacing and adding heavier
 implementations of those standard components likely tailored to their
 systems and infrastructure.

 Container and Server are mentioned in the EJB spec as being separate things
 but are never defined formally.  In our world Containers, which implement
 the basic component contract and lifecycle of a bean are not coupled to any
 particular Server, which has the job of providing a naming service and
 providing a way for it's clients to reference and invoke components (beans)
 hosted in Containers.  Because Containers have no dependence at all only
 Server, you can run OpenEJB without any Server at all in an embedded
 environment for example without any work or any extra overhead.  Similarly
 you can add as many new Server components as you want without ever having
 to modify any Containers.

 There is a very strong pluggability focus in OpenEJB as it was always
 intended to be embedded and customized in other environments.  As a result
 all Containers are pluggable, isolated from each other, and no one
 Container is bound to another Container and therefore removing or adding a
 Container has no repercussions on the other Containers in the system.
 TransactionManager, SecurityService and Connector also pluggable and are
 services exposed to Containers.  A Container may not be dependent on
 specific implementations of those services.  Service Providers define what
 services they are offering (Container, Connector, Security, Transaction,
 etc.) in a file they place in their jar called service-jar.xml.

 The service-jar.xml should be placed not in the META-INF but somewhere in
 your package hierarchy (ours is in /org/apache/openejb/service-jar.xml)
 which allows the services in your service-jar.xml to be referenced by name
 (such as DefaultStatefulContainer) or more specifically by package and id
 (such as org.apache.openejb#DefaultStatefulContainer).

 The same implementation of a service can be declared several times in a
 service-jar.xml with different ids.  This allows for you to setup several
 several different profiles or pre-configured versions of the services you
 provide each with a different name and different set of default values for
 its properties.

 In your openejb.conf file when you declare Containers and Connectors, we
 are actually hooking you up with Service Providers automatically.  You get
 what is in the org/apache/openejb/service-jar.xml by default, but you are
 able to point specifically to a specific Service Provider by the 'provider'
 attribute on the Container, Connector, TransactionManager, SecurityService,
 etc. elements of the openejb.conf file.  When you declare a service
 (Container, Connector, etc.) in your openejb.conf file the properties you
 supply override the properties supplied by the Service Provider, thus you
 only need to specify the properties you'd like to change and can have your
 openejb.conf file as large or as small as you would like it.  The act of
 doing this can be thought of as essentially instantiating the Service
 Provider and configuring that instance for inclusion in the runtime system.

 For example Container(id=NoTimeoutStatefulContainer,
 provider=DefaultStatefulContainer) could be declared with it's Timeout
 property set to 0 for never, and a
 Container(id=ShortTimeoutStatefulContainer,
 provider=DefaultStatefulContainer) could be declared with it's Timeout
 property set to 15 minutes.  Both would be instances of the
 DefaultStatefulContainer Service Provider which is a service of type
 Container.
	Title: Concepts
	OpenEJB was founded on the idea that it would be embedded into third-party
	environments whom would likely already have three things:

	- their one "server" platform with existing clients and protocols
	- their own way to configure their platform
	- existing services like TransactionManager, Security, and Connector

	Thus the focus of OpenEJB was to create an EJB implementation that would be
	easily embeddible, configurable, and customizable.

	Part of achieving that is a drive to be as simple as possible as to not
	over-define and therefore restrict the ability to be embeddible,
	configurable and customizable. Smaller third-party environments could
	easily 'downscale' OpenEJB in their integrations by replacing standard
	components with lighter implementations or removing them all together and
	larger environments could 'upscale' OpenEJB by replacing and adding heavier
	implementations of those standard components likely tailored to their
	systems and infrastructure.

	Container and Server are mentioned in the EJB spec as being separate things
	but are never defined formally. In our world Containers, which implement
	the basic component contract and lifecycle of a bean are not coupled to any
	particular Server, which has the job of providing a naming service and
	providing a way for it's clients to reference and invoke components (beans)
	hosted in Containers. Because Containers have no dependence at all only
	Server, you can run OpenEJB without any Server at all in an embedded
	environment for example without any work or any extra overhead. Similarly
	you can add as many new Server components as you want without ever having
	to modify any Containers.

	There is a very strong pluggability focus in OpenEJB as it was always
	intended to be embedded and customized in other environments. As a result
	all Containers are pluggable, isolated from each other, and no one
	Container is bound to another Container and therefore removing or adding a
	Container has no repercussions on the other Containers in the system.
	TransactionManager, SecurityService and Connector also pluggable and are
	services exposed to Containers. A Container may not be dependent on
	specific implementations of those services. Service Providers define what
	services they are offering (Container, Connector, Security, Transaction,
	etc.) in a file they place in their jar called service-jar.xml.

	The service-jar.xml should be placed not in the META-INF but somewhere in
	your package hierarchy (ours is in /org/apache/openejb/service-jar.xml)
	which allows the services in your service-jar.xml to be referenced by name
	(such as DefaultStatefulContainer) or more specifically by package and id
	(such as org.apache.openejb#DefaultStatefulContainer).

	The same implementation of a service can be declared several times in a
	service-jar.xml with different ids. This allows for you to setup several
	several different profiles or pre-configured versions of the services you
	provide each with a different name and different set of default values for
	its properties.

	In your openejb.conf file when you declare Containers and Connectors, we
	are actually hooking you up with Service Providers automatically. You get
	what is in the org/apache/openejb/service-jar.xml by default, but you are
	able to point specifically to a specific Service Provider by the 'provider'
	attribute on the Container, Connector, TransactionManager, SecurityService,
	etc. elements of the openejb.conf file. When you declare a service
	(Container, Connector, etc.) in your openejb.conf file the properties you
	supply override the properties supplied by the Service Provider, thus you
	only need to specify the properties you'd like to change and can have your
	openejb.conf file as large or as small as you would like it. The act of
	doing this can be thought of as essentially instantiating the Service
	Provider and configuring that instance for inclusion in the runtime system.

	For example Container(id=NoTimeoutStatefulContainer,
	provider=DefaultStatefulContainer) could be declared with it's Timeout
	property set to 0 for never, and a
	Container(id=ShortTimeoutStatefulContainer,
	provider=DefaultStatefulContainer) could be declared with it's Timeout
	property set to 15 minutes. Both would be instances of the
	DefaultStatefulContainer Service Provider which is a service of type
	Container.