> Concern 3 > By using a normalized DB, then JS2 is scalable by adding machines. > Although a file system can be shared among machines, a database is a > much cleaner, secure, and reliable approach,
+1 I agree with, having most of the information centralized in an RDBMS as it makes load balancing and high availability implementations much cleaner and easier to implement. *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � > -----Original Message----- > From: Paul Spencer [mailto:[EMAIL PROTECTED] > Sent: Friday, August 08, 2003 9:25 AM > To: Jetspeed Developers List > Subject: Re: RE : J2 PSML persistence > > Luta, Raphael (VUN) wrote: > > > De : David Sean Taylor [mailto:[EMAIL PROTECTED] > > > >>On Thursday, August 7, 2003, at 09:54 AM, Luta, Raphael (VUN) wrote: > >> > <snip> > > >>>For mt PSML stuff in JS2, I've currently broken down the > >> > >>persistence > >> > >>>options like this: > >>>- PageManagerService: > >>> > >>> Function: > >>> Handles page persistence (ie loading and saving pages and > >> > >>fragments > >> > >>>to > >>> storage as well as creating new pages and fragments) > >>> > >>> Implementation: > >>> I have 2 implementations in the works: > >>> - XML/Castor, with XML files on disk (complete, I just need to > >>> stop answering mails and write the related unit test files :) > >>> - OJB based (through the persistence plug-in) (in progress, 80% > >>> complete) > >>> > >> > >>Do you mind if we look at this from the database table view? > >>I know its a implementation detail, but Im interested in the database > >>end of things, so if you don't mind > >> > >>Have you had a look at the DDL in the CVS? > >>see create-db-phase2.sql > >>The DDL does not have blobs. > >>I was hoping that the database impl would not make use of blobs... > >> > > > > > > I don't think blobs would be necessary. I specifically kept > > a typed fragment class in the OM to be able to store fragments as rows > > in a single table. > > > <snip schema> > > > > My main concern right now is whether to keep this schema normalized > > with the costs associated for looking up an object tree or have a > > denormalization fields to speed up fragment requests. I'm not familiar > > enough with OJB to see right now if such a denormalization field could > > be easily used by OJB. > > > > > >>I see the service as storing something like the PSML_ENTRY table (see > >>the phase2 sql file) > >> > > > > > > As you can see, it's pretty similar to phase2 except that I'm using > > varchar for keys instead of INT IDs, for 2 main reasons: > > - I wanted to use the impl objects for the time being for both XML > > and OBJ > > - I want to be able to store GUID/UUID as PK if we move this way. > > > > > >>> For the XML files, the default service implementation just write > >>> files in a flat directory, with files identified by an id (this > >>> is different from JS1 behavior). > >>> > >>> Typical directory layout would be: > >>> /WEB-INF/pages/ > >>> pageID1.psml > >>> pageID2.psml > >>> pageID3.psml > >>> ... > >>> pageIDX.psml > >>> > >>>- PageRegistryService > >>> > >>> Function: > >>> Register available portal pages and map these pages to > >> > >>user and role > >> > >>> profiles. The API of this service will be an extension of > >> > >>the default > >> > >>> Registry service > >>> > >> > >>I see this service as storing the equivalent of the PSML table in the > >>above sql fle > >> > > > > > > Yes, similar but I'm still playing with exactly what attributes/objects > > I want to include in this registry (this will probably be the subject > > of another mail). > > > > > >>> Implementation: > >>> Again 2 implementations possible: > >>> - XML/Castor based on the current JS1 registry code (70% complete) > >>> - OJB/Persistence plug-in like the new PortletRegsitry written by > >>> Scott (0% complete) > >>> > >>> With XML implementation, information is stored in one or several > >>> xreg files in /WEB-INF/conf by default. > >>> > >>> Example of page registry entries: > >>> > >>><snip markup examples> > >>> > >>>This setup should IMO be both more efficient in the XML and SQL > >>>persistent mode because of the flatter structure and be > >> > >>more flexible > >> > >>>because the PageRegistry allows a central page repository and some > >>>user->page mappings that were not possible in JS1, including the > >>>ability to "off-line" a page without removing it physically. > >>> > >> > >>For the file-based system, I see the big difference in that > >>the PSML is > >>not stored in a directory tree. > >>All PSML is stored in one flat directory area, and a new XML > >>file makes > >>the mapping. > >>I guess Im not too concerned, since I prefer to store in the > >>DB. But it just makes me wonder about two things: 1. > >>migration. people are used to the directory layout 2. Is this > >>going to overly complicate the simple deployments > >> > >>I see the file-based solution best for users who need a simple portal > >>that is easy to configure. > >>The directory layout was very easy to understand. > >> > > > > > > Concern 1: > > Luckily it's very easy to flatten a deep directory > > structure, actually mush easier than moving from one tree structure to > > another :) > > The PSML migration task will have to perform the following actions > > (assuming migration from PSML on disk) > > - create a new empty Page Registry (XML or OJB) > > - browse the PSML disk tree structure and for each PSML file found: > > - register the page in the page registry based on the directory path > > - extract the <entry> parameters and store them separately in the > > user preferences store (and create a new GUID for this entry) > > - transform the current PSML file to the new format through XSLT > > - store the tansformed page in the flat page store > > The most tricky action here is exporting the user prefs to another > > store because of the amount of ID messing involved. > > > > Concern 2: > > Yes, it does add an additionnal step but OTOH, even when using disk > > based persistence I foresee a much greater reliance on tools/GUI > > for deployment issues that JS1. The PageRegistry will make > > implementation of an updated PsmlBrowser both much simpler and more > > powerful so there should be really fewer incentives to manipulate > > the psml files directly. > > > > To add another point on the PSML XML vs SQL debate: > > in the proposed Page OM, the page description is completely user > > neutral and *never* stores any user-specific information even when > > it's shared by several logged-in users. > > Because of this, Page caching will be much more efficient and the > > portal should very rarely have to update the pages. > > That makes page loading performance from storage a much > > smaller issue than for JS1 and make the XML viable for larger > > deployments than in JS1. > > > > I agree with the above. > Concern 3 > By using a normalized DB, then JS2 is scalable by adding machines. > Although a file system can be shared among machines, a database is a > much cleaner, secure, and reliable approach, > > > -- > > Rapha�l Luta - [EMAIL PROTECTED] > > Jakarta Jetspeed - Enterprise Portal in Java > > http://jakarta.apache.org/jetspeed/ > > > > ********************************************** > > Vivendi Universal - HTTP://www.vivendiUniversal.com: > > The information transmitted is intended only for the person or entity > > to which it is addressed and may contain confidential and/or privileged > > material of Vivendi Universal which is for the exclusive use of the > > individual designated above as the recipient. Any review, > retransmission, > > dissemination or other use of, or taking of any action in reliance upon, > > this information by persons or entities other than the intended > recipient > > is prohibited. If you received this in error, please contact immediately > > the sender by returning e-mail and delete the material from any > computer. > > If you are not the specified recipient, you are hereby notified that all > > disclosure, reproduction, distribution or action taken on the basis of > this > > message is prohibited. > > > > Paul Spencer > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
