My research is divided into three categories:
XObject: composing XML document out of variety of diverse even non-XML data sources.
DataInstance: all about generic business object open design.
Other utilities: such as services, managers, design patterns like: "Multiton", "Initializable", "ComponentInitializer", etc.
The idea of "XMLarizing objects", also called "xObject", is the most original concept in my work. It has many important advantages, already described in chapter "3. XMLarized Objects", with significant impact in the field of processing XML centric data flow. I've searched on-line material of several (15-20) universities, including UC Berkeley, Harvard, MIT, Stanford; and I've found no reference to such a solution. Next, I've searched research institutes, non-profit organizations and also commercial products. None of them provided solution as I propose in chapter "3. XMLarized Objects". The closest one is "The Apache Software Foundation" which has "open source" strategy and involves many individual researches and developers from all around the world working on several projects. Two of their focuses is java on the server and XML. Many of their sub-projects came close to my idea of overall server-side architecture (I'll talk about it later), but none of them uses the idea of "XMLarizing objects".
One can find more about some of the institutes, I've done my research on, in the next section "Selected Institutes Description".
There is wide range of business object designs and their actual implementations. So the question could be: what is so special and new about my, yet another, version? First, "DataInstance" lacks the maintainance of the behavior, which most of the existing business object designs provide. My "DataInstance" is strictly "data and their relationships" oriented. Its main goal is to unify the approach ALL data are handled in the applications. It abstracts from the source and format of the data. Because of the unified approach, many generic functionality can be build into component oriented fashion.
During my research, I've found many business object designs, each of them dealt with different aspects such as metadata management, access to the data, etc; but none of them provided complex solution concerning unified access to the data with emphasis on: generic business object representation, component oriented fashion, metadata management, data storage technique abstraction, data storage format abstraction, etc.
Some of the existing solutions are:
DataSourceComponent from Avalon: Avalon is a sub-project of "Jakarta" created by "The Apache Software Foundation". Avalon Excalibur was created in order to ease development of new projects. To that end, Excalibur contains a number of ready to use components and utilities that handle everything from command line parsing to thread concurrency management.
One aspect why I found this project interesting is the thoughtful design of "component centric" environment. "DataSourceComponent" is one of the components having similar use like my "DataInstance". Unfortunately it lacks the generic approach and it is tight to relational databases.
Meta Object Facility (MOF) Specification: MOF specification is intended to provide an open-ended information modeling capability. The specification defines a core MOF model that includes a relatively small, though not minimal, set of constructs for object-oriented information modeling. The MOF model can be extended by inheritance and composition to define a richer information model that supports additional constructs. Alternatively, the MOF model can be used as a model for defining information models. This feature allows the designer to define information models that differ from the philosophy or details of the MOF model. In this context, the MOF Model is referred to as a meta-metamodel because it is being used to define metamodels such as the UML.
Even though MOF was originally created to help to create CORBA IDL mappings, it would be very useful for further improvements of "DataInstance"'s metadata model.
URL: ftp://ftp.omg.org/pub/docs/formal/00-04-03.pdf
A Business Object Framework Architecture: is 5-layer architecture for business object frameworks with the layers: presentation, business process, business entity, data access, and data storage, instead of the more common 3-layer architecture, and give reasons why the 5 layers are required. We have collected and list, for each of the layers, the responsibilities it must fulfill and problems which may arise, together with a reasoning.
The architecture layers should not be mixed up with tiers. A clean layer structure of an application is a precondition for distributing the application on different tiers. For example, the five-layer architecture might be distributed on a two-tier client-server system with a cut either between the business process and the business entity layer (resulting in a thin client), or the business entity and the data access layer, or the data access and the persistent storage layer (resulting in a very fat client). Similar considerations apply to a three-tier system.
Authors: Hans Albrecht Schmid (schmidha@fh-konstanz.de), FB Informatik, University of Applied Sciences, Konstanz, Germany; and others.
URL: http://jeffsutherland.com/oopsla98/schmid2.html
This architecture addresses most of the features I'm trying to propose. The difference is that my work is an actual realization of the addressed features, plus much more.
Object Architects: is a very nicely compiled set of design patterns for Object / Relational Access Layers and it also contains a chapter on Enterprise Java Beans Persistence. Author is Wolfgang Keller.
URL: http://www.objectarchitects.de
It is strongly oriented towards object databases, but it has a lot of in common with my proposal, especially in the portion about object/data storage. I believe that further research or even possible cooperation with Wolfgang Keller would help both sides to improve our approaches.
Two most original approaches from the remaining utilities are the design pattern "multiton" and the services. Most of the other utilities are not necessary my original invention, but they are all nicely packaged together, with intuitive design, which makes them very easy to use.
The "Multiton"'s functionality is already widely used, my contribution is the name and the definition of the base class, providing all the base functionality. I've searched all above described sources, but found no reference to this design pattern.
The approach of a service is also well known and can be found in many places, such as: Avalon, the subproject of Jakarta by The Apache Software Foundation.
What makes my version of services unique is the abstraction from all: transportation layers, nature of the services, container the service lives in, etc.
I've found slight variations of most of my other utilities in some places such as: Initializable, Identifiable also originated from my colleague Roman Szturc, etc.