[Design of POJO Server] - Quick design notes.
by adrian＠jboss.org
I don't think this was ever posted publicly in one unit?
Bits of it are spread around different threads. :-)
| Deployers Design
| ----------------
|
| This is split into three sections:
| 1) Definitions - to try to avoid the
| "Humpty Dumpty syndrome"
| 2) Requirements - defines what we
| are trying to achive
| 3) Issues/Design - complications that result
| from the requirements
| (some very basic attempt at design)
| 4) Priorities - which doesn't actually
| prioritize anything :-), it just states
| the initial "must haves".
|
| WARNING: This is very much a quick
| brain dump that brings together
| thoughts from previous discussions
| (both verbally and in the forums).
|
| There are certainly bits missing,
| templates and "use case" configuration
| spring to mind. :-)
|
| Definitions:
|
| Archive - a packed deployment, e.g.
| a jar or zip
|
| Aspect - Cross cutting concern, see orthogonal
|
| Component - a part of a deployment, e.g.
| an ejb deployment can have many ejbs,
| a web deployment can have many servlets
|
| Deployer - a plugin that does the real
| deployment work
|
| Developer - JBoss developer or experienced user
|
| Explicit Rule - a rule that is defined in
| meta data to say "this is what I want"
| when an implicit rule doesn't work for them.
|
| Factory Settings - the configuration as
| delivered by JBoss or the vendor of the
| deployment
|
| Implicit Rule - a rule that is a default
| to ease the users life. i.e. a convention
| that uses a default behaviour without them
| having to specify anything
|
| JSR77 - the JavaEE management/monitoring/stats
| spec based on a hierarchical namespace model
| similar to JMX.
|
| JSR88 - the JavaEE deployment spec based on
| the idea that xpaths (xml locations) are
| modified in a GUI
|
| Metadata - The data applicable to a deployment
| aspect. I use this term to mean the xml, e.g.
| ejb-jar.xml, jboss.xml, web.xml, etc.,
| but this also includes the annotations from
| Javaee4 which potentially can be defined
| by the generic metadata, see Metadata(2).
|
| Metadata(2) - Generic metadata (annotations/objects)
| attached to a scope. e.g. you can attach an
| @TransactionTimeout(300) at the server scope or
| an @TransactionTimeout(600) for a whole deployment.
|
| Meta data location - the place to look for
| meta data, e.g. META-INF or WEB-INF
|
| Managed Object - The object model (java object)
| equivalent of a piece of Meta Data.
|
| Main Deployer - The entry point/broker
| for the deployment system
|
| Orthogonal - The idea that a complicated system
| can be broken down into non-interacting parts
| by carefully identifying those parts (in general
| not possible and can lead to overcomplication
| when all possible interations of those parts,
| regardless of likelihood, is catered for).
|
| "Open the gates" - a quote from Baron Munchausen,
| a more generic "barrier" or "valve" process.
|
| Profile - a list of preconfigured deployments
| with potentially overrides
|
| Scanner - a simple "profile" that determines
| the deployments by looking at a directory
| (emulates the old JBoss4 behaviour)
|
| Scope - the identity/context of a component
| e.g. an ejb, ejb deployment,
| resource adapter, connection factory, servlet,
| web deployment, etc.
| But can also be more general like:
| * Subsystem - JCA, EJB, WEB, etc.
| * Server
| * Cluster
| * etc.
| These are obviously hierarchical, but it
| is not a trivial hierarchy. :-)
| e.g. a deployment defines which cluster
| it is part of not the server.
|
| Structure - breaking a deployment into
| "contexts" or subdeployments that are
| processed "independently".
|
| Structural Deployer - a deployer that
| calculates what is deployable, i.e.
| determines the structure
|
| Unpacked - a directory structure
| that pretends to an archive
|
| VDF - Virtual Deployment Framework
| (explained in the text)
|
| VFS - Virtual File System
|
| Requirements - philosophy:
|
| 1) Aspectization
| A developer when writing a deployer should only
| have to deal with their aspect. Other aspects,
| e.g. aop.xml, classloader.xml, security.xml
| are not their concern and should be orthogonal.
|
| 2) Transparency
| A developer should not be concerned with
| the underlying structure of the deployment.
| They should be presented with a logical
| model of the deployment structure
| that works whether the deployment is
| * an archive
| * a part of an archive,
| * is unpacked
| * is semi-unpacked (e.g jar in an unpacked deployment)
| * a logical archive (scattered around an ide)
| * etc.
|
| This requires a logical model that includes:
| * Where to look for metadata (aop.xml, etc.)
| * What is the classloader to load classes
| * How to build the classloader from the
| structure (see 3)
|
| 3) Structure
| Further to (2) the structural part of
| a deployment is a different concern.
| It can be:
| * Predetermined - you are told the structure
| * Calculated - you are given the "root" and
| structural deployers determine the subdeployments
| determing the model
| * Something in between
| Similarly, the classloader can be calculated
| or predetermined, the later is most useful in
| unit tests.
|
| 4) Raw Metadata vs managed object (JSR88)
| Each deployer should be fundamentally
| based on a "managed object".
| Each deployer should know how to build
| the managed object from the meta data.
| It should be possible to deploy the
| following scenarios:
| a) Predetermined structure + managed objects
| b) Predetermined structure + meta data locations
| c) Calculated structure + meta data locations
| d) Others?
|
| * For the full profile/JBoss ON we want (a).
| * JBoss4 mechansism is (c)
| * Unit tests would likely use (b or c)
|
| 5) Deployment should be width first
| To ease the implicit rules, deployments
| should be done in levels rather than per
| deployment.
| e.g. If the deployers are aop, classloader, ejb
| (gross simplification) via a deployment scanner
| then the protocol should be something like:
| scanner -> add all deployments to main deployer
| scanner -> main deployer - now process
| main deployer -> determine structures (where relevant)
| main deployer -> do aop for each deployment
| main deployer -> create classloaders
| main deployer -> create ejbs
|
| 6) Two phase/atomic deployments
| Internally the deployment should be two phase
| Phase 1: prepare the deployment, i.e. bring
| it to the state where it is ready to go
| Phase 2: "open the gates" which makes
| it available to receive requests, i.e.
| bind to jndi, link to transports, etc.
| This enables automatic (re)deployments
| where a redeploy can do:
| a) New deployment do phase 1
| b) Old deployment reverse phase 2
| c) New deployment do phase 2
| d) Old deployment reverse phase 1
| Ideally (b) and (c) should be the
| same process atomic process.
|
| 7) Two phase/JSR88
| Different but related to (6) we need to support
| the distribute and activate of JSR88
| from a client across a cluster.
|
| 8) Profile
| The profile should be a list of
| preconfigured services with overrides.
|
| The profile service can deploy multiple
| profiles to make up a running instance.
|
| i.e.
| preconfigured services == managed objects (factory settings)
| overrides == changes to factory settings
|
| Can take at least two forms (see 4)
| a) Real managed objects (serialized in some way)
| b) Raw deployments where one of the structure/managed objects
| is determined at runtime
|
| 9) Hot deployment
| Deployments should be hot deployable
| this includes the deployers which introduces
| extra complications :-)
|
| 10) Management/Monitoring
| Each deployment/component should be assigned
| a scope which links back through
| "deployment aspects" to the JMX/JSR77
| layer. This should be tranparent to the
| deployers, except as a contextual
| object that they use to construct their components
| and their own "simple" decision of which
| part of the JSR77 model they construct.
|
| 11) Embedded/Server
| The implementation should cater for simple
| bootstrap in embedded mode (including unit tests)
| which might not have the JMX, JSR77, JSR88, profile,
| hot deployment, etc.
| and the full server mode which has everything.
|
| 12) On demand
| If I don't deploy a WAR then Tomcat shouldn't
| be started
|
| Issues - complications or implementation choices:
|
| (numbers correspond to requirements above)
|
| 1) Aspect
| This is based on a Deployer
| which has at least the following
| prepare() - bring the deployment to the
| nearly ready state
| commit() - "opens the gates"
| managedObject() - determines managed objects
| from meta data + openmbean style definition
| jsr77MetaData() - jsr77 type/context and
| stats mapping, etc.
| jsr88MetaData() - maps managed object to the
| jsr88 xpath model
|
| 2) Transparency
| This is based on a VFS model that maps
| the underlying structure protocols
| to a single VirtualFile model
| but also on a VDF that picks out
| certain parts of the VFS to provide
| things like the meta data location
| or the parts used for classloading.
| e.g. WEB-INF for wars or META-INF
| for most others
|
| 3) Structure
| There are essentially three structural
| deployers:
| * JAR - classloading is the root,
| the meta data location is META-INF
| jars in the jar are subdeployments.
| This caters for most things like jars,
| zips, sars, rars, ejbs, etc.
| * WEB - classloading in WEB-INF/classes
| and jars in WEB-INF/lib, the meta data
| locations is WEB-INF, no subdeployments!
| * EAR - application.xml and jboss-app.xml
| defines the subdeployments/classloading
| the meta data location is META-INF
|
| The main complication comes from
| things like:
| a) An unpacked directory with no META-INF
| can be a deployment, e.g. just classes
| but a subdirectory is not.
| b) An xxx-service.xml or xxx-ds.xml
| in a jar is a valid subdeployment,
| but in most circumstances an xml file
| in the root of a jar is not a subdeployment.
|
| 4) Meta data, managed objects, JSR88
| a) Need to define the protocol that lets
| a deployer know a managed object exists
| or whether it should try to generate
| it "on the fly".
| b) The same generation mechanism needs
| to be exposed to the profile service
| c) The managed object needs to be
| mapped to JSR88 style xpaths
| d) The managed object needs to be
| defined using a mechanism similar
| to JMX's OpenMBeans/XMBeans
|
| 5) Width first deployment
| Need to be able to define
| the order for width first.
| Choices (not necessarily exclusive):
| a) Ordering, e.g. aop=100, classloading=200
| (like JBoss4)
| b) Dependency, e.g classloading depends aop
| (better but what if aop is not deployed?)
| c) something else?
|
| 6) Atomic deployments
| Beyond getting this protocol defined
| this is not a requrement for the initial JBoss5
|
| 7) JSR88 deployment protocol
| Spec requirement
|
| 8) Profiles
| This is really a seperate topic/design,
| this should drive the deployment layer
| via the MainDeployer from
|
| 9) Hot Deployment
| Lots of complications here, e.g.
| a) adding/removing deployers
| b) Reprocess previous deployments
| c) Dependencies help in what needs
| to get reprocessed (see 5).
| d) One deployment creates another deployment,
| e.g. old JBoss4 deployment scanner or farm
| service
|
| Other issues including providing a protocol
| where a managed object's property doesn't
| require a redeploy. e.g. changing a
| transaction timeout for a method can
| be done "on the fly" without redeploying
| an ejb.
|
| 10) Scoping JSR77
| This is largely a deployment aspect, see
| the JMX *prototype* in the Microcontiner.
| This links in heavily with the metadata(2)
| repository and its scopes (incomplete work).
|
| 11) Embedded/Server
| These will both need to be developed.
| a) The embedded so we can write some unit tests
| without bootstrapping a JBossAS instance to test
| different pieces/configs
| b) The server for JBoss5
|
| 12) On demand
| This is basically an extension to the Microcontainer
| behaviour. If the deployers are designed properly
| then this is virtually automatic, however it
| does require the seperation of things like:
| a) The Web Deployer (always there)
| b) The Web Container, started when there is a deployment
| that references it
|
| Priorties:
| The initial priorities are (in no particular order):
| 1) "Reproducing" the JBoss4 behaviour
| 2) Passing the JavaEE5 TCK
| 3) Features for JBoss ON.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976276#3976276
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976276
19 years, 3 months
[Design of POJO Server] - Re: Allowing multiple AbstractParsingDeployer to work with t
by adrian＠jboss.org
Ok, FYI I'm currently working on reworking the JavaEE parsing.
I started this so I could get a real idea of what we need
to create the ManagedObjects, but when I looked
I got more deeply involved.
I looked at what EJB3 is doing and it is basically broken
for the following main reasons (there are others):
1) It is incomplete and the error handling is rubbish (non-existent)
2) It is not backward compatible so a user written EJB2 interceptor/plugin
won't work because BeanMetaData, etc. is a different type.
3) It is EJB centric, but there has been some work recently to
copy parts of back into the original model for the injection stuff.
I'm working on a schema based deployer for JavaEE5 where
EJB2,3, RAR, WAR, CAR, EAR can share the same metamodel.
To make this simpler, I've created a layer on top of JBossXB
that uses annotations to bind the model to the schema.
I'll describe this is a different JBossXB thread.
I've also started a refactoring of the current metamodel
(with a backwards compatibilty layer that basically wraps the new model)
so we can improve the model.
I have lots of ideas in this direction, but I been blocked from
implementing them because of the compatibity consideration.
One of them, is being able to override anything in ejb-jar.xml
with the jboss.xml
Another, which I haven't looked at yet in the current refactoring,
is to reuse the annotations in the model.
Which will obviously make it more consistent
and also integrates better with the metadata repository.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976258#3976258
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976258
19 years, 3 months