Gosh, this list is slow ... Don�t think that I need soooo long to think
about your mails ;-)
So this is also an answer to Marcs intermediate request for an illustrative
example of our "mad"
coarse-grained EJB components idea ...
After some rethinking, I found that Rickard is right in saying that the
refactoring would be
only some kind of expensive cosmetics to a (IMHO Tomcat-driven) "design". I
think that
I can realise the deployment mechanism described below also by just
extending J2EEDeployer
using the implicit currentThread/parentClassLoader interface to
ContainerFactory and EmbeddedTomcat (so my motivation to touch as little as
possible code would be completely satisfied) ...
Hence, this mail is rather to seek your comments
to the following example taken from our last prototype in the ERP domain:
Suppose we�ve got a masterdata.jar application that contains session beans
(we call them business services), such as a DocumentAdministrator,
ItemManager, and BusinessPartnerManager, but that also contains regular
beans (we call them, guess, business objects), such as Document, Line,
BusinessPartner, Item, Address, etc. The busines objects are accepted,
manipulated, persisted and returned by the business methods of the session
beans.
Now we�ve also got a sales.jar application in which we have business objects
such as PurchaseOrder, PurchaseOrderLine, Customer, etc. subclassing the
above Document, Line, and BusinessPartner to realise a specific e-shop
functionality implemented by business services such as
ProcessOrder, CustomerAdministrator, etc. There is also a stock.jar, where
we have Warehouse and Storage business objects (e.g., referring to stored
Items) and a WarehouseService session bean that manages them.
What we have implemented using a heavily modified ContainerFactory (and what
I think could be of interest for the jBoss community, too, if more elegantly
integrated into J2EEDeployer)
is that such jars with dependencies (here, sales-->masterdata<--stock) can
be deployed in a manner that if sales is deployed, masterdata is
automatically deployed in a parent classloader of sales (recursive
deploy(URL) call delivers ClassLoader back which will be used as the parent
classloader). If stock is deployed and masterdata is already up (@see
ContainerFactory.deployedComponents), it just uses the existing classloader
as parent. If masterdata is redeployed, running stock and sales applications
are automatically cycled, too. The implementation goes actually a bit
further by also allowing cyclic dependencies where a clique of jars is
deployed into the same classloader ... The result is in each case a
hierarchy of classloaders that is extensible at runtime (therefore I talked
about non-flat deployment).
In principle, all the business services can now interact: (XML-)
serialisation is applied to transfer sales representations into stock
representations (e.g., the ProcessOrder.processOrder(PurchaseOrder) method
calls the WarehouseService.reserveItems(Item,int) method). Optimised direct
calls can be used as you travel along the dependencies, i.e., the
hierarchical Classloader structure (e.g., the processOrder() calls
DocumentAdministrator.copyDocument(Document)).
In the end, we expect to come up with around 50-100 such "business
components" (they will actually have a narrower domain than "sales",
"stock", etc.) for a complex ERP with additional 200-500 extensions and
variations of those that are individually adapted per industry, customer,
server, process, hairstyle of the secretary, wheather, etc., etc. !
So, it�s simply not possibly to compile the whole stuff once at installation
time into a single jar especially for hot-maintenance, hot-updates, and
hot-configuration. It�s also impracticable to build completely independent
jars (just sales and stock each containing the masterdata functions) because
of redundancy and consistency purposes. Finally, we also would not like to
have some employee sitting at each of our customers, twisting his mind to
coherently (un-)deploy the jars according to todays needs where this can be
easily handled by the "millenium EJB-server" ...
I hope you could follow my thoughts, I hope that not all of this has been
already possible the whole time, and hence my question: Is such a deployment
behaviour of general interest such that I should post the extended
J2EEDeployer once ready?
Best,
CGJ
