One thing I'm sort of curious about, has anyone looked into using the XML deployment descriptors with perhaps some additions for adverstisement and discovery via some sort of XML server like E-Speak or UDDI? In this sense I could find any container whose deployment supported some specific schema that I needed rather than requiring some aforeknowledge to do JNDI lookups. >From: "Steven J. Owens" <[EMAIL PROTECTED]> >Reply-To: A mailing list for Enterprise JavaBeans development ><[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: J2EE/EJB vs XML+XSLT and XML direct from DB >Date: Thu, 21 Dec 2000 21:45:38 -0500 > >Curt Smith writes: > > I'm architecting a next generation system who's clients [HTML, VXML, > > WML and more] do almost no transactional operations. Transactional > > support being one of the most useful features in EJB in my view. > > We're at the opening stage of designing a business system which >certainly has some transacations to process, but I'm not sure the EJB >transaction support will be relevant. > > > The hotest architecture is not EJB at all (good) and barely > > leverages servlets and jsp's. It's the XSLT transform engine, XML > > emitting directly from the DB (Oracle 9i) or 8i with XML connectors > > to get you by until 9i ships. > > Yup, our approach is heavy on XML documents and XSLT >transformations. A lot of what we're doing is, when you look at it in >the right light and squint right, document-centric. > > > The amount of business logic that's compiled into byte code is > > practically nil which is a stark contrast to EJB, which has all of > > your business logic located in servlets, jsps and numerous EJB's and > > db schema. This looks like a great win for a cheaper way to design > > the HTML content, and change once you've built it. Just edit the > > XSL/XSLT docs or change the schema of your XDB source. > > That's pretty much our thining. > > > Admittadly this architecture just eats CPU and latency. But this is > > what cheaper faster CPUs are all about?? > > Any comments or first hand experiences? > > EJB VS XML? > > We're still trying to decide on some of these issues. Since a >lot of the documents I referred to above won't change all that much in >production, here's an approach we're considering. > > The rest of the system interacts with the documents as one huge >XML DOM that, to the rest of the system, appears to be in memory all >the time. Behind the scenes, each XML entity in the DOM is an EJB >entity bean, which lets us use the EJB server as a big XML DOM cache >manager. Since the XML DOM rarely changes in production, we don't >need to keep track of multiple instances of the entities, except as >needed to distribute load. Also, we're planning on using XSLT >transformations to generate more limited versions of specific >fragments of the XML DOM according to user access permissions. > > I'm still sifting through the EJB-interest archives, trying to >find out if anybody has done something like this, or has thoughts on >what would be involved. > >Steven J. Owens >[EMAIL PROTECTED] > >=========================================================================== >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff EJB-INTEREST". For general help, send email to >[EMAIL PROTECTED] and include in the body of the message "help". > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
