Hi everybody, just a short note:
I am more a front-end person (plan to start a OSS GUI project in 2008), although I have an vested interested in a open persistence solution, since I would like to see an end-to-end system demonstrator based on OSS components (GUI, kernel, persistence). IMO (and in Rong's etc) this would really boost openEHR. I believe a generic persistence layer API(s) - as Tom said - is the way to go. This won't happen in one go. So in a truely agile development style this has to happen over several iterations, while every iteration product has to be usable! The reason for this post is that I recently investigated the IBM DB2 9 DBMS . This could be a good starting point or reference to build the API layer on. Reasons for IBM DB2 9 DBMS (http://www-306.ibm.com/software/data/db2/express/) are: - the Express-C version is free and only has restrictions regarding the hardware (max 2 CPUs and 2 GB Ram). Compared to the 'Express' versions of Oracle and Microsoft, with limited DB size etc. - it is a long-around enterprise SQL DBMS, now with additional native XML support (pureXML feature) - it seems to have good documentation (2 books and several recent articles) and a active community - there is a well-maintained performance testing toolkit for it (http://tpox.sourceforge.net/). - the Express-C license can even be used commercially! If the hardware limitations become a problem an upgrade can be bought without having to change the underlying code. Cheers, Thilo On Jan 1, 2008 8:54 PM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > > Bert Verhees wrote: > > I believe, it is rather sensitive, because, when you publish a > persistence-layer, you have a full blown product, which others can use, > I think, people fear to put their self out of business if they publish > too much knowledge. That, I beleive is the reason because the > discussions about this subject often die. > > > I would suggest various reasons: > > > building an enterprise usable persistence layer - one that is highly > performant, reliable (in terms of data integrity) and scalable is a serious > endeavour. It requires real investmnet, not just for the design and > implementation, but for load and performance testing. Trying to do it open > source is likely to be a slow project, because it requires concentrated > ongoing effort. > there is no such things as the perfect back-end for all use contexts, so a > single mighty build-it-once-forever open source solution is likely to be > flawed from the outset. What would be useful as open source is the binding > layer containing an agreed API, e.g. an object db style API, or my current > node+path idea > (http://www.openehr.org/wiki/pages/viewpage.action?pageId=786487). > Because of the different needs of different contexts, commercial > implementations are more likely to be the right business model, as long as > they conform to the interfaces demanded by the community, possibly be > incorporating lightweight open source components. Therefore one of the needs > of openEHR (and information processing in general) is a standardised > persistence layer API that provides the right kind of sematics without > predetermining limiting choices to do with technology, performance or > scalability to much. We have recognised this for a long time in openEHR, but > not had the effort to implement it. I would describe the levels of > interfaces needed as fllows: > > > a virtual EHR API - this is a fine-grained application interface for talking > to an openEHR system, including building, saving and retrieving EHR data. It > does not contain any persistence primitives, but provides the main interface > for any application writer, who should be able to largely forget about > everything else > an EHR service interface - this is a coarse-grained interface that knows > about Compositions, Contributions, queries > a persistence layer that is archetype- (i.e. path-) enabled, in the sense of > the node+path model described above. For the first two we have developed > working versions in our own products, and will release the entire interfaces > soon in documentary form. There is not much secret here, and we would expect > an openEHR 'standard' for these interfaces to be developed by integrating > such APIs built by anyone in the community, or defining > alternative/componentised APIs, if it makes sense in some cases. The normal > community process is the correct vehicle for doing this (i.e. discussion, > proposals, Change Requests, ARB review etc). > > The 3rd layer above is not standardised at all, and would not have to be > openEHR-specific, but needs to know minimally about paths. Creating a > specification for this could be useful for creating archetype-based > information processing systems in general. This could be done by the same > process, but will undoubtedly take longer since more implementation-based > evidence is required. > > Lastly, implementing highly performant database layer is largely a matter > of experience. Beginners may think that you can just plug an object model > into a hibernate tool and generate a schema, but it wll be dreadfully > inefficient. Object databases as Tim has said are better aligned > semantically to the kind of data we are dealing with, although they > generally don't know much about paths. XML-enabled databases may in fact be > a better rather than a worse bet than a straight relational design, due to > the path capabilities, although I have no direct experience with them (and I > agree that almost anything to do with XML is sadly compromised at the outset > by the terrible inefficiency of XML itself - but nevertheless, using XML in > our own SQL Server system is surprisingly fast). > > There are two main positions for people in this community to take: > - front-end people - application developers who just want to get real > systems up and running, > - back-end people - people who want to engineer enterprise ready openEHR > back-ends > > The latter job is the expensive one, and I recommend that people think > carefully before just jumping in. This is not to discourage competition, > diversity etc - it is simply that the world is littered with dead projects > which turn out to be 10x harder than the developers thought. I therefore > believe that the best approach is to find the correct balance between > standards / open source, and commercial implementations, which are based on > those standards. Getting these API and service layers is a key part of that > approach, and is how commercial implementations can be kept honest. By the > way, commercial implemtations may or may not be open source. > > In the end, our approach in openEHR is overturning some basic beliefs about > how to build information systems, so we probably have to accept that making > the whole thing successful will not be instant. We seem to be making good > progress however, and I think the effort will be worthwhile. > > - thomas beale > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
