[ome-devel] Shoola-back-end consistency issues

[Josh Moore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Ilya Goldberg wrote:

>> Great, and when client X modifies the DB using VBA/.NET, which magical
>> messaging and distributed objects pattern will ensure that client Y
>> using ICE will update itself to be consistent?
>> Presumably these modifications would end up being processed by some
>> back-end aggregator that will then go and issue messages to any
>> connected clients to update themselves.  This aggregator will have to
>> perform translation services for any and all interfaces used by
>> clients.  Will it go and update the Web UI the user's got open also?
>> What about clients that connect via JDBC/ODBC?

>> I don't think there are any magic bullets here.  If we want a monolithic
>> system where we control all of the ins and outs explicitly, this all
>> becomes fairly simple using whatever we pull off a shelf.  If we want a
>> system that's maximally open with many ways in and out (the "O" in OME),
>> then this becomes a more difficult (not to say interesting) problem. 
>> When deciding on these interfaces, we should be thinking "Who and what
>> can we afford to exclude from access into this system?".  Its
>> instructive to look at a long list of real-world systems that we need to
>> talk to - not hypothetically sometime in the future, but like
>> yesterday.  None of these things use ICE or Java or anything even
>> remotely that intelligent.  Some can do web-services or at least pretend
>> to.  Its really these systems that we need to concentrate on talking
>> to.  As far as clients that we develop, we have pretty much free reign
>> as long as we don't close anything off in the process.

I'd second Chris on this one. We can't be everything to everyone. The
logical conclusion of the first paragraph is to put everything in the
database so however whoever/whatever touches it, they'll be seeing the
real OME. I don't want to go there.

And the implication of the second is that we need to support simple
web-based clients. That's easy.

I prefer and suggest a real server. If we can't let everyone in the
world talk to it, tough nuggies. On the other hand, lots of people are
working on interoperability -- I bet we can steal something. But I want
a real programming language and tested/standardized/accepted components
that I can use without having to do it myself. Enterprise people have
being doing this for years; let's gain something from that fact.



>> They're actually polling, aren't they?  The server doesn't notify the
>> client that its time to refresh.  The client just does a refresh at some
>> point, and either it gets new data or it doesn't (i.e. polling).

No. JMS is (can be) notification. You say "tell me about X" and it tells
you. No polling. Pubsub.


>> When we've asked these questions before, we've pretty consistently
>> decided in favor of polling.  If you look around the web, that's pretty
>> much what everyone else decided as well.  Various forms of "push" have
>> sprouted up before and quickly died.  RSS readers are all universally
>> polling.  Some of the news web-sites I visit do timed refresh, but
>> that's just polling again.  Real notification over a stateless protocol
>> (like HTTP) would require the client to implement a server so that the
>> "real" server could issue requests on it, saying "Hey, time to
>> update!".  There are a great many issues with a server initiating
>> requests to a client machine.

We all know what a fan I am of the W3C, but OME isn't (doesn't have to
be) the web. That's really a side point. Chris will talk about ICE and
I'll talk about J2EE, basically we're talking about typical systems very
different from the web (though a part of it) which make systems like
ours work well.


>> Versioning introduces a whole host of new side-effects.  In effect, all
>> data in OME is already versioned because its attached to a MEX.  The
>> self-consistent solution here is to enforce that all dataset changes
>> (like adding or removing images) result in a MEX.  I don't think there
>> are any major side-effect issues with doing that.

What does the "in effect" modifier in the above mean?


>> I don't like ad-hoq solutions either unless its the only way to avoid
>> major side-effects.  I would prefer doing this with MEXes.  It would be
>> slightly harder to implement because it would likely introduce some
>> minor side-effects, but I don't think it would be too bad.  The pay-back
>> for doing this is that it closes the penultimate loophole for escaping
>> the wrath of the MEX.  The last loophole is creation of the container
>> objects themselves, which is also not done with a MEX.  Once those two
>> are closed, everything can become a semantic type.

What are the side-effects you're talking about?

Also, at least it terms of portraying this to the outside world, if
eventually everything is a semantic type (==owl:class students.) and
every state change gets a MEX even if not coming from the AE, I'd
suggest renaming MEX because there's no "module" "executing" in many
cases. This is partially what I'm talking about in stretching the idea.
(below).


> Josh:
> Can we stretch our idea of MEX to make this clean? This returns to my
> comment about the mex_execution table being an "AuditLog", Ilya. If
> things not strictly done by the AE could also be included in the
> AuditLog, we're in business.

Ilya:
>> There's plenty of that going on.  Annotations aren't done with the AE. 
>> Import is done partially with the AE and partially not.  The only
>> requirement is that the state of the system after this is done is
>> compatible with the AE (otherwise the AE won't be able to use this info).

So I assume those things aren't getting mexes, which make them currently
not queryable for refresh. That's where either MEX has to be stretched,
or a super-concept introduced to handle these cases.


- -Josh.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzD3YIwpkR5bKmAsRAk+2AJ9Qi90wlNc5YjJ3TVL3+tRMKUcsKwCdGYbP
F1PXWonH/Y0ktYhFwM4C7qo=
=VAK6
-----END PGP SIGNATURE-----