This pattern is used in some commercial framework as WebEngine and WSBCC from IBM. We are implementing it in a propietary framework that my employer has developed and I would like to hear your opinion.
Pattern stands from the definition of an XML tree. Such a tree is composed of either indexed, complex or simple nodes:
* Simple nodes basically contains a single typed or not value,
* Complex nodes are expected to be parents of a set of simple nodes,
* Indexed nodes are expected to hold an array of complex or simple nodes for tabular data storage.
All the data values for the presentation are expected to be stored in simple nodes. On the other hand, nodes has an scope attribute managing its lifecycle.
When data is introduced in the tree, it is validated against the data type associate to each simple node in its definition, raising exception if it does not match type.
When a request comes, it fills the right simple nodes in the tree. It is also possible to handle data in the tree programmatically.
In that way, business tier can query the data holder for necessary data at any time supposing they know where the data is stored. Such a location is reached since nodes are mapped in another XML file with a logical name asociated to each position in a namespaces notation.
Also some API methods to fill special VO from the data holder. A set of node values, defined in XML is extracted from the data holder, to fill the previous VO by reflection techniques.
Some more features mostly configured in XML allows funny operations with the data holder.
I could not identify any pattern related with this one, neither from the GoF nor anywhere else, and I have not seem references in the web, so I would appreciate your opinions.
Very powerful.;-) But unnecessarily complex. You got a greate idea but a slightly out of track in your implementation.
The support for properties builded in System in Java is too simple to use. The idea that an application context should be provided is valueble just as what you said. The SystemContext, what I call for Applcation Contex, could be implemented as a singleton which can be easily accessed by all the classes and instances within one JVM and provides a place to store globle status. You can implement it in various way, like SimpleSysContex, JDBCSysContex, etc. Sure, an factory must be provided to seal these implementations.
Your implementation is a bit complex. Look at the type, restriction and validation, what else do you want to add into it? You want to reinvent the JavaBean model in XML, don't you?;-) You only need to store Object just like what Map does and never tangle the business logic, like validation, into the abstraction of such a data store. XML should only be used to define config and only be refered to when system start up or shut down. It should never be used as an internal store of data when system is running, you never want a DOM tree in your memory to slump the over all performence.
As an globle data store, the most important thing is the mechanism that will manager the register and notification on changes of certain data. Events like data being created, modified or removed should be monitored.
I used to think such a concept of globle data store in one JVM is of no use. I am very happy to know that you has the same idea with me.
actually that is not my implementation but my employer´s implementation. They made the design and I agree with you that it is probably overdesigned in some parts. Mostly because XML configuration is sometimes redundant.
Thanks for your comments. I will come back whenever I get a deeper experience in this pattern. Further enhacements that you can figure out are also welcome.
For the existing example, you can refer to context like, HttpServleteContext, HttpSession, EJBContext, JNDIContext, etc. Some of them have simple or full mechanism of event notification, some of them not.
The difference between my context interface and these are:
1. Full integration with JavaBean event model. I found that model is just for my interface.
2. Life cicle management. Such as init, pause, resume, shut down, etc.
3. Can be accessed from anywhere through static method of factory.
When you say "accessed anywhere" through static method of a class, be careful. That only applies within one VM instance. That is one of the gotchas for "singletons" in distributed systems.
You are quite right that the singleton can not be accessed out of one JVM. You can use JNDIContext in this case instead of register RMI stub into the SystemContext. But what I said SystemContext is focus on working within one JVM and one container that hasn't provided a context yet or the implementation is not powerful enough. If you build you app with the SystemContext, you can easily migrate you application to any container, such as ejb container, web container, etc, using bridge pattern.
I think you should also
take care of the classloader
issue .. IMHO when
you have different classloaders
( which can be in App-Servers )
you can have different "versions"
of the singleton ..
IMHO some app-servers
are using a different
classloader for each
jar or ear ..
That's a problem. In that case, both the SystemContext and the EventListener must be distributed computation enabled. Such as RMI, WebService and Message, etc. Where bidirection comunication is possible, you can use this pattern and chose proper communication mechanism regarding to your performence reqirement. Although this pattern can be used in distributed enviroment, I prefer use it to gain a clear internal infomation structure along with observer pattern and avoid passing numerous parameters in objects within one JVM.
Most application servers use custom class loaders to separate their J2EE components from each other (hot deployment is just one side effect they get). This means that even in one J2EE application which contains several ejb-jar's you will have multiple instances of your singleton.
A workaround is using the System Class Loader (by adding your classes to the app server classpath) - which will solve only part of your issue - what about clusters?
I recommend JNDI for that purpose - you may need to check the documentation of you JNDI tree how registered objects get handled in a clustered environment.