"Mark J. Stang" wrote:
> Joel Rosi-Schwartz wrote: > > > "Mark J. Stang" wrote: > > > > > Kimbro, > > > After reading Stefanos reply, I forgot to mention dynamic linking. > > > I am currently doing it myself, but on the client side. That means > > > that when my client makes a change I have to decide which > > > Key + Path to update and apply the changes to the right document. > > > > > > So I guess I have a vested interest in being able to build documents > > > out of pieces, update/display/view the pieces and the whole, > > > transparently. > > > > > > I have put together a Publish/Subscribe XML Database using JMS, > > > my version of a Query Language and Xindice. If the internal data > > > changes, I need to be notified. So are there any plans on any kind > > > of a CallBack mechanism? Except for one or two obscure relational > > > databases, the only mechanism for detecting changes is polling. I > > > added a layer around that to avoid the problem. It would be nice > > > if there was someway for a client to be notified when the data > > > changes. > > > > I must admit upfront that architecturally I am rather opinionated in this > > area, so > > you may want to take my thoughts with an appropriate measure of salt. > > > > There comes a time when a cleanly defined system starts crossing the line > > and > > taking on services that are already provided more appropriately in other > > quarters. > > Imbedding callbacks in the database seems to me have crossed that line. J2EE > > defines a rather clean model for implementing this use case. Put a service > > bean or > > two in place and pass *all* modifications to the data through the server. > > Client > > notification then is moved out to the server were it can (and has been) > > implemented in a generic fashion. With low cost or free J2EE servers like > > Jboss > > available there is little reason to avoid them once the initial learning > > curve is > > paid up. > > > > I don't know if I agree or disagree. I agree that we should maintain the > encapsulation. > And not crossing the border between "products". However, I have always felt > that it > is a MAJOR drawback, that Relational DBs don't have any way of notifying their > clients without polling. And if you take a look at EJBs one problem with > their > performance is that without going out and retrieving the data, they can't > tell if the > data has changed. They do an enormous amount of re-reading data just to be > sure that is hasn't changed. Precisely because there are other users of the > data. No not at all, if you are willing to insist on discipline. The essential ingredient is that *all* access to the data *must* be via the server; all bets are off if you allow cheating. Now once you buy into this philosophically many problems fall by the wayside. EJBs do do excessive reads when you use CMP; this is their way of trying to compensate for an undisciplined universe. If you switch to BMP---and for Xindice there is currently no CMP option anyway---and manage when to persist the data, e.g. carry an isDirty flag, then thrashing the data store is prevented. The Entity beans should not be exposed to the client. The client should talk to coarse grained session service beans that in turn manages the entities. Now if you require callbacks on data change it is straight forward to register for it with an Observer pattern. A few years back we even built an online insurance quotation system for a Lloyds underwriter that used this architecture front ended by a Web client. By putting a light weight applet (non gui) into the browser we managed callbacks to refresh the browser when the underlying data changed. It is even easier with a full blown client on the other end. The point here is that this is not academic; been there do it. It is a shame that it is not better known in the EJB/J2EE world that these issues are quite manageable if you put in place an architecture suitable to the problems at hand. As is always true in developing interesting solutions, not every application requires quite the same mix. The trick is simply understanding which are the best to apply to the one at hand. > Have we not moved past the 80's technology of client-server? > > I have a complete implementation of JBoss running as part of my customer > installation. > > I don't use EJBs, they don't talk to Xindice. Easy enough to resolve. Trust me we are doing. > If they did how would the EJB server know if I had modified a document? As per above, by only modifying via the server. We are seriously considering embedding Xindice directly into JBoss using the JMX layer. Then all issues of who changes the data disappear. Alternatively you could select to only talk to the Xindice via servlets and perhaps embedding it into Tomcat. Either approach requires a fascist approach to changing data only through the chosen interface. > The only way was to ask for last time modified > and check to see if it "might" be different. And if it has, then what? Do > you > overlay > the changes anyway, last in wins? Or do you tell your current client, data > changed, > do you want to overlay someone elses changes or abandon yours? Or do you > just > lock the document? And while someone is typing in a large document, someone > goes in and deletes their tag. Now the person typing for an hour says save, > but > XPath can't because it can't find the tag? Obviously all of these issues need to addressed in a fashion appropriate for the application at hand. I would guess that you are currently still faced with all of these issues, but have simply pushed them all the way out to the client. I would prefer centralizing these issues as much as possible at the server level. > > Sorry for running off at the mouth for so long. I guess I am opinionated > also :-). Not at all, I am enjoying the conversation ;-) - joel > > - mark > > > > > - joel > > > > > Mark > > > > > > Kimbro Staken wrote: > > > > > > > Anything in particular you're interested in? > > > > > > > > On Saturday, February 16, 2002, at 01:05 PM, Mark J. Stang wrote: > > > > > > > > > Count me in. > > > > > > > > > > Mark > > > > > > > > > > Kimbro Staken wrote: > > > > > > > > > >> We need to get new development kick started here. To start I'm > > > > >> trying to > > > > >> collect all the bits of information/features/ideas/questions into a > > > > >> document for everyone to see. I've posted the start here > > > > >> http://www.xindice.org/papers/planning.html > > > > >> > > > > >> This is basically a brain dump of things that have been looked > > > > >> at/asked > > > > >> for in the project. It isn't complete, but there's already a lot of > > > > >> stuff > > > > >> there. > > > > >> > > > > >> Number 1 on the list is "Critical to bring in more developers". This > > > > >> is > > > > >> very important, if you're interested in getting involved here, now > > > > >> is the > > > > >> time. > > > > >> > > > > >> My plan for the immediate future is to continue filling in this > > > > >> outline > > > > >> and to collect feedback and expand on the items. I know that right > > > > >> now it > > > > >> probably isn't exactly clear what a lot of this stuff is, but I > > > > >> wanted to > > > > >> get the general ideas down first and then expand and detail. There's > > > > >> a > > > > >> LOT > > > > >> missing so please help me fill it in. > > > > >> > > > > >> Thanks > > > > >> > > > > Kimbro Staken > > > > XML Database Software, Consulting and Writing > > > > http://www.xmldatabases.org/ > > > > >
begin:vcard n:Rosi-Schwartz;Joel tel;fax:+44 1435 831011 tel;home:+44 1435 831010 tel;work:+44 1435 831010 x-mozilla-html:TRUE org:Techne Research Limited version:2.1 email;internet:[EMAIL PROTECTED] title:Architect adr;quoted-printable:;;Downgate Farmhouse=0D=0AFurnace Lane;Warbleton near Heathfield;East Sussex;TN21 9AZ;United Kingdom fn:Joel Rosi-Schwartz end:vcard
