geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Geronimo Wiki] Update of "Architecture/JSR-88" by AaronMulder
Date Sat, 02 Jul 2005 03:05:26 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by AaronMulder:
http://wiki.apache.org/geronimo/Architecture/JSR-88

The comment on the change is:
Added information from recent e-mail thread

------------------------------------------------------------------------------
  
  = About JSR-88 =
  
- JSR-88 is a JCP specification that will be incorporated into J2EE 1.4.  It describes a standard
way for deployment tools to configure J2EE applications for specific server products, and
then deploy the applications to the servers.  This way, a single IDE or deploy tool can support
all J2EE server products at once, rather than providing separate deployment descriptor editor
screens and deployment logic for every server product.
+ JSR-88 is a JCP specification that is part of J2EE 1.4.  It describes a standard way for
deployment tools to configure J2EE applications for specific server products, and then deploy
the applications to the servers.  This way, a single IDE or deploy tool can support all J2EE
server products at once, rather than providing separate deployment descriptor editor screens
and deployment logic for every server product.
  
  For the specification and downloads, visit http://www.jcp.org/en/jsr/detail?id=88.
  
@@ -17, +17 @@

  
  attachment:jsr88-arch.png
  
+ '''Warning: This picture is a little misleading: the DDBeans are the responsibility of the
tool not the server, and Geronimo does not currently include a DDBean implementation.'''
+ 
   * The user interacts with a deployment tool.  That deployment tool includes an implementation
of the JSR-88 '''Tool Provider''' API.
   * Part of the Tool Provider API implementation are '''DDBeans''', which are objects that
represent elements in the standard J2EE deployment descriptors.  For example, the EJB deployment
descriptor includes an element called "session" for each session bean, so there would be a
DDBean corresponding to each "session" element.  (This is a bit of an oversimplification.)
 DDBeans are not Java''''''Beans per se; if you want the "ejb-name" property of a "session"
DDBean, you have to ask it for the content of the relative "ejb-name" XPath, instead of calling
a "getEjbName" method or something like that.
-  * Geronimo provides some standard Tool Provider implementation code, which is used by the
Geronimo deployment and management tools.  The Geronimo DDBeans are currently lightweight
wrappers around a '''JDOM''' tree for each J2EE deployment descriptor.  The reason for this
is that DDBeans are primarly accessed via XPath, and JDOM makes XPath easy.  
-  * Every app server provides and implementation of the JSR-88 '''Server Provider''' API.
 This API has methods to connect to a server, deploy, undeploy, configure/load/save server-specific
deployment information, and so on.
+  * Every app server provides an implementation of the JSR-88 '''Server Provider''' API.
 This API has methods to connect to a server, deploy, undeploy, configure/load/save server-specific
deployment information, and so on.
   * The Server Provider API includes '''DConfig''''''Beans''', which are Java''''''Beans
that represent server-specific deployment information.  For example, if every session bean
includes an integer for the number of beans to keep in the EJB pool, then there might be a
"Session" DConfig''''''Bean with an int property called "numberOfBeansInPool" with getters
and setters and so on.  The DConfig''''''Beans and DDBeans communicate with each other via
events and listeners (e.g. so that if the name of an EJB is changed, then the corresponding
server-specific deployment information can be mapped to the new name).
-  * The Geronimo implementation of the Server Provider API include DConfig''''''Beans to
represent the server-specific XML deployment descriptor.  Those DConfig''''''Beans are not
directly tied to XML data.  They have all the proper getters and setters, and special data
types and Java''''''Beans Bean''''''Info classes and property editors and so on, and are generally
very UI-oriented.  When it comes time to save DConfig''''''Beans, the DConfig''''''Beans are
mapped to a set of the standard Geronimo '''XML POJOs''' for the server-specific deployment
descriptor, and then the DD is saved from there.  (Loading works similarly; POJOs are loaded
and then mapped to DConfig''''''Beans.)
+  * The Geronimo implementation of the Server Provider API needs to include DConfig''''''Beans
to represent the server-specific XML deployment descriptors.  Those DConfig''''''Beans are
not directly tied to XML data.  They have all the proper getters and setters, and special
data types and Java''''''Beans Bean''''''Info classes and property editors and so on, and
are generally very UI-oriented.  When it comes time to save DConfig''''''Beans, the DConfig''''''Beans
are mapped to a set of the standard Geronimo '''XML POJOs''' for the server-specific deployment
descriptor, and then the DD is saved from there.  (Loading works similarly; POJOs are loaded
and then mapped to DConfig''''''Beans.)
   * The Geronimo Server Provider implementation needs to communicate with a running app server
to deploy or undeploy, as well as to list and review deployed applications and so on.  The
Server Provider implementation communicates with the '''Application Deployer MBean''', which
is a JMX server component running as part of Geronimo.  That MBean is responsible for all
the usual deployment activities.  When the MBean needs to review the server-specific deployment
information provided in the application, it also uses the '''XML POJOs''' to save, load, and
manipulate the deployment information.
+ 
+ = Geronimo JSR-88 Implementation =
+ 
+ == DConfigBean Background ==
+ 
+ DConfigBeans are a series of JavaBeans that represent the content of the Geronimo deployment
plans for each J2EE module.  For example, if the geronimo-jetty.xml plan looks like this:
+ 
+ {{{
+ <web-app ...>
+   <context-root>/MyApp</context-root>
+   <security>...</security>
+   <ejb-ref>
+     <ref-name>ejb/SomeEJB</ref-name>
+     <target-name>geronimo.server:...</target-name>
+   </ejb-ref>
+ </web-app>
+ }}}
+ The we'd need something like:
+  * A DConfigBean to represent the web-app, with a property to represent the content-root
+  * A DConfigBean to represent the ejb-ref, with properties to represent the ref-name and
target-name
+  * A JavaBean to represent the security element and its children
+ 
+ Why a DConfigBean in some places and a JavaBean in other places?
+  * A DConfigBean is only used to represent Geronimo data that corresponds directly to an
element in the J2EE deployment descriptor (here, web.xml)
+  * A JavaBean is used to represent Geronimo data that does not directly correspond to an
element in the standard J2EE DD, but is more complex than we can represent as a series of
properties on the parent DConfigBean
+ 
+ So here, the web-app DConfigBean corresponds to the web-app element in web.xml.  The content-root
can just be represented as a property on the web-app DConfigBean.  The security element does
not correspond to any specific element in web.xml, and it's too complex to represent as properties
(it has around 20 interesting elements and attributes), therefore it must be a JavaBean (most
likely itself with a combination of simple properties and nested JavaBean properties).  The
ejb-ref corresponds to an ejb-ref in web.xml, so that's another DConfigBean, and its child
elements shown above can be represented as properties (though if you look at the element in
detail, the objectNameGroup might be represented as a nested JavaBean).
+ 
+ === DConfigBean & JavaBean Example ===
+ 
+ While editing an ejb-jar.xml, you'd have a few server-specific screens or options after
the standard ones.  So, something like:
+ 
+  1. Define EJBs (ejb-jar.xml enterprise-beans)
+  1. CMP Relationships (ejb-jar.xml relationships)
+  1. Security Roles (ejb-jar.xml assembly-descriptor)
+  1. Container-Managed Transaction (ejb-jar.xml assembly-descriptor)
+  1. Messaging Destinations (ejb-jar.xml assembly-descriptor)
+  1. "Add Common Libraries to ClassPath" (openejb-jar.xml dependency)
+  1. "Geronimo Security Settings" (openejb-jar.xml security)
+  1. "Add Module-Scoped Geronimo Services" (openejb-jar.xml gbean)
+ 
+ So the first few entries are straight from ejb-jar.xml, and may have Geronimo information
mixed in (the example above included Geronimo settings within the "Define EJBs" section).
+ 
+ The last few entries are Geronimo things that have no counterpart in ejb-jar.xml.  We can
probably put a nice name on them like above, if they have appropriate BeanInfo.  But the screens
themselves must be built dynamically, based on the fields and properties in the beans.
+ 
+ == Geronimo DConfigBean Status ==
+ 
+ Geronimo has a couple DConfigBeans right now.  They are generally not current, so they can
be used as a reference, but need to be updated and/or replaces.  The best place to look is
in the connector-builder module, as it has a couple DConfigBeans and a couple JavaBeans in
org.apache.geronimo.connector.deployment.dconfigbean
+ 
+ I put a little work into making a viable example out of those -- they load properly, and
have some BeanInfo objects that provide property names and descriptions that a tool can take
advantage of.  But they are still not necessarily correct as far as representing the current
deployment information for connectors -- they were built based on an older geronimo-ra.xml
format.
+ 
+ There are few or no DConfigBeans for Web (Jetty or Tomcat), EJB, EAR, or Client App modules.
+ 
+ The existing DConfigBeans are built on some base classes in the deploy-config package. 
These are all in turn built to use code generated by XMLBeans to represent the Geronimo deployment
plans.
+ 
+ == Where to go from here ==
+ 
+ To begin with, my recommendation would be to pick a module, get familiar with the J2EE deployment
descriptor and Geronimo deployment plan format, and make a list of the DConfigBeans, JavaBeans,
and properties you think are appropriate for that module, and run that by the mailing list
for review.
+ 
+ == Testing ==
+ 
+ Aaron has a little Swing GUI that lets you load a J2EE module (JAR/WAR/etc.) with existing
J2EE DD and Geronimo deployment plan, and it will present a dynamic user interface built off
the J2EE DD (JSR-88 DDBeans) and the DConfigBeans.  This is still a pretty basic tool, but
it'll let you make sure that the beans don't blow up, that they get mapped to deployment descriptor
elements correctly, etc.
+ 
+ === JSR-88 GUI ===
+ 
+ ''Prefix: note that JSR-88 applies only to J2EE module configuration -- WARs and EJB JARs
and so on -- not server configuration like ports and the admin account and which web container
to run.''
+ 
+ 
+ For a pure JSR-88 tool, it is not possible to customize the GUI for server-specific information.
 All you can do is build a GUI appropriate to the JavaBeans (and DConfigBeans) supplied by
the server vendor, so you're limited by what they choose to provide in their BeanInfo, etc.
 We do need a tool like this to use while developing DConfigBeans on order to get an idea
of whether our BeanInfo is adequate. :)
+ 
+ Of course, we can write a configuration tool that does not conform to JSR-88 as well, and
provides a fully customized GUI for everything. I'm not sure how useful that is as a standalone
tool -- I'd assume that we'd do better to provide IDE plugins that do the same.
+ 
+ A wizard-style approach would be interesting for J2EE module configuration.  Note that we
could, for example, provide a "configure your EJB JAR" wizard, which took you step by step
through all the elements of the ejb-jar.xml, and happened to let you configure server-specific
information for the EJBs as you go.  But the server-specific part would be a little generic.
 Such as, when working on a CMP entity bean, Geronimo lets you configure an automatic primary
key generator (DB sequence or whatever).  We wouldn't necessarily be able to say "next, decide
whether you want the database to automatically provide primary keys for your entity bean"
-- because via JSR-88, we don't really know which server-specific settings are which, only
that there are some.  On the other hand, the Geronimo automatic key generation properties
could be encapsulated in a JavaBean with a BeanInfo that includes a shortDescription saying
"These settings allow you to configure automatic key generation for
  an EJB, for cases where the database can supply the IDs for new beans (such as with a database
sequence or auto_increment column".  Then our tool can pop up a screen that edits that JavaBean,
with that description on the screen.  So this is why it's important to have high-quality BeanInfo
and stuff -- so we don't just have a screen full of 10 fields with cryptic names.
  
  = JSR-88 Q&A =
  
@@ -31, +105 @@

  
  '''Answer:''' DConfig''''''Beans have extra methods to deal with DDBeans, and special methods
to handle any children which are also DConfig''''''Beans.  It wouldn't be appropriate to expose
child DConfig''''''Beans as properties, whereas in the case of the XML POJOs we want everything
exposed as properties.  Also, in order to support editing in a UI environment, some data types
must be strange.  For example, an "ejb-link" can't be a String; it needs to be a special data
type that knows how to look up the available EJBs to link to.  This is a fairly unpleasant
workaround for the fact that a Java''''''Bean property editor doesn't get a reference to the
bean it's editing, it only deals with "old value" and "new value".  Some people argue the
semantics (if an "ejb-link" can only have one of a small list of values, then it really ''isn't''
a String, but is instead an "ejb-link" subset of all avialable Strings), but that's neither
here nor there.  The bottom line is that there ar
 e things in the XML POJOs that we don't want to expose through DConfig''''''Beans, and there
are things in the DConfig''''''Beans that we don't want to expose through the XML POJOs.
  
- '''Question:''' Why do the DDBeans use JDOM when nothing else in the server does?
- 
- '''Answer:''' Because we're still in the experimentation phase.  However, it's not clear
that a more Java''''''Bean oriented solution would be better.  For example, a single DDBean
may be accessed by a number of different XPaths, and when any caller uses it, the caller can
ask for the XPath, and the DDBean must return the value that was originally used to look it
up.  For example, a session bean may have been looked up by the absolute XPath "/ejb-jar/enterprise-beans/session"
from any node, or the relative XPath "session" from the "enterprise beans" DDBean, or both.
 If both, we would have to have 2 different Java''''''Beans representing the same data, and
they could be changed independently and would need to stay synchronized.  The only sane solution
seems to be for the DDBeans to delegate the data storage to some underlying store.  Currently,
they delegate to a JDOM tree.  Perhaps they could be changed to delegate to a Java''''''Bean
tree.  In any case, once our implement
 ation grows to support editing the J2EE deployment descriptors, the data storage layer will
need to launch events to the DDBean layer, so the DDBeans can in turn launch events to the
DConfig''''''Bean layer (if our one "session" instance changes, it needs to launch one event
to caller A with the changed XPath of "/ejb-jar/enterprise-beans/session/xxx" and another
event to caller B with the changed XPath of "session/xxx" or something like that).  But I
digress.
- 

Mime
View raw message