I’m currently looking at some of the inadequacies that exist inside of the Java architecture vs. that of .NET. Microsoft definitely learned a good bit from watching other technologies grow -- what makes them successful and what hinders them. One of the things that MS did very well was their concept of <i>configuration</i>.
Microsoft’s configuration gives the framework the ability to define configuration sections where a section has a handler. This handler is responsible for not only converting the xml into an object (similar to JAXB) but also to give an extension point for the developer to define how the object is registered with the system.
My company uses this heavily for all sorts of configuration logic. We use it for database configuration (e.g. connection strings and properties of the connection), caching, threading. Ultimately this feeds very nicely into an IoC framework that has been development specifically for our business needs. This is above and beyond the point from this point. I’d like to replicate this pattern (including the core technologies that we’ve developed) into a standardized java library that a) solidifies the patterns b) their usage c) establish concrete practice in relation to abstracts and their derived grammar. Sound like a good idea? I think so. The library is already developed in .NET and is HEAVILY used in our systems. It was one of the more valuable things I’ve added to the organization. Now if I can only figure out a solid pattern to get this done in Java.
Limitations: the .NET framework handles the reflection and invocation for you (b/c it’s intrinsic to the framework) but java does not. This means all of the reflection assets that sit in the library will be heavily used by the library to accomplish the same goal. From a design perspective this will mean that I’ll have to focus more heavily on that minute details.
If anyone has any suggestions please let me know. This will probably be a really good open library....
2 comments:
I may have found a potentially clean, workable solution in the jakarta commons digester library. It will allow for me to identify a digester by type I can then identify a config section for each (which would be the digester/handler class) and then invoke against that to make sure all is ingested appropriately. This will only work for specific objects set for the framework. Ideally we'll expose the interfaces so that others can extend off of it.
It turns out that I can indeed develop the configuration library that I'd like to for Java using JAXB and jarkata commons digester paradigm. Will be working on a PoC here very soon. Currently all threading paradigms have been ported to Java from their original C++ implementation as well as C#. Ultimately goal here is to establish a library that abstracts common technology needs allowing the dev to focus on business logic (not necessarily a framework per say). It will focus on data access, threading, caching, configuration and messaging but leaving IIOP to the application framework.
Post a Comment