Does anyone have an idea for an architecture with a hosted
browser-based database application where the backing database is not
hosted by the same provider?

If you look at various rich internet applications, the software and the
database are often both hosted. That is how gmail works as well as
emerging hosted word processing applications and other ajax web
pages/apps. There might be an option of pulling the data down to your
PC, such as by using popmail in combination with gmail or e-mailing a
document to yourself, but there is no option on where you store your
data when interacting with the application.

We often use client-based applications with client or server data
persistence (e.g. Word) in addition to the hosted applications with
hosted data. I am looking for any examples of hosted browser-UI
database applications where the user indicates a data source that can
be anywhere accessible on the internet.

This is more likely in the SQL world, but I'm not looking for database
independence -- the specific database tool can be fixed. I'm looking
for database-location independence in an application hosted as a web
browser application.

I would like to write a piece of software that can be used by anyone
but where I host the app and not the database software or data. If
someone wants to use it, they need to have a database somewhere (of
whatever type is required by the application) and the application will
take the data source specification as input. I might want to use a
service-oriented architecture where the read and writes to the database
are not with a direction connection, but I have not seen a example of
that either.

In case I haven't said this right yet, it would be a free for use,
no-installation required, database application where the database is or
possibly where to put the database if it is not already there. People
could then use the very same application, but have completely separate
databases.

There might be more issues than I would want to tackle to do this, but
I'm curious whether there are examples or not. Thanks. --dawn

dawn wrote:

Hi Dawn.

I might be stating the obvious or misunderstanding your requirements but
surely what you are describing is "Web Services" and SOAP?

hth


John

John Bend wrote:
I'm just mentioning web services, whether using SOAP or REST or ..., as
one option. In that case the user would need to have both a data
source and related services (CRUD services, for example).
Alternatively, the hosted service could do direct reads and writes of a
specified data source. --dawn

dawn wrote:
I take it you're looking for an extension to your AJAX HTTP data
transfer control here?

This could be done using a signed Java applet, but not with an unsigned
applet. The Java sandbox would stop any access to a server other than
that which served up the applet itself, and good thing too. OTOH, I'm
pretty sure that an ActiveX control doesn't suffer from this
restriction. But then, ActiveX doesn't work for all browsers.

Luke

Back when I was first introduced to web programming I was given the
impression that ActiveX was a no no - at least for internet use - due
to security issues. If that was the case is it still so now?

Mike.

Just thinking out loud here...

I don't like fat clients. I see the browser as the user interface - and
am happy to pass it the mark-up, sufficient logic (js functions) to
behave intelligently, and of course the data from the server. That's
not to say I reject the idea you're proposing - that the data can be
collated from other sources (via cURL for instance) - but I would
usually do the information gathering on the server and feed the client
as if it all originated from the same server. Having said that - there
will be times when it makes perfect sense for another server to take
over for a time - like when you're validating credit card info for
example. To me that simply becomes a link.

Mike.

Dawn,

We have a couple of examples of this with people using Visage. Indeed,
the very FIRST Visage deployment we did was for a Hong Kong based
company that sold hotel memberships - Database was in Australia, with
web server & users in HK.

Likewise we have people where website is housed @ ISP, but database is
at their office.

If I'm reading the requirement correctly, this is more along the lines
of what you are seeking? When your "client" houses their own database
(or may be provided by a provider like EasyCo, Midwest etc, and YOU (or
YOUR ISP) house the actual web server.

One of our VARS already has a service along the lines you are talking
(I think) is running an ASP style model for an application - people
sign up, and everyone uses the SAME application, BUT they are hooked
into difference databases (which are just seperate accounts)

The only "catch" to this scenario, at least with Visage, but imagine
anything else as well, is that there are times when you want/need to
run code on the database server there does have to be "stuff" loaded
onto the server (triggers, procedures etc)

The architecture we have employed with Vsiage allows us t do this
'easily' (part of our basic design) because there is no "hard coded"
notion of a data source for a page. Instead the pages deal with an
abstraction layer, and the middleware takes care of connections to the
actual data sources.

So, a single Visage middleware/web sever can be hooked into multiple
database servers (and each database server can have multiple active
accounts), yet the clients operate from a single copy of the
"application" (static web pages with dynamic data content)

Can ghet a little more "interesting", because we can actually have
different things happenning for different database accounts, but that
is a whole other story.

FWIW, we are also playing with letting the middleware talk to non-MV
databases at the moment ....we sort of do that now with a few XML data
sources, but are looking at providing an abstraction layer that for ANY
supported database (Oracle, SQL Server, DB2 etc) ... this is a longer
term project, but the results will be "interesting"

IF this does sound like what you are chasing, please drop me an email
direct (I'm in & out of the office at present converting some people
out of Navision, so response will not be immediate)

regards,


Ross Ferris
Stamina Software
Visage > Better by Design!

Ross Ferris wrote:
Yes, sounds like it. I'm looking to see if there is any site similar
to gmail.com that I could navigate to on the internet where the
application was running and requested a data source so that the data
was not hosted. In the access vs. ownership mix, I'm looking for a
customer to access the app and own the data.

It sounds like you have the technology, although not in an open source
hosted "free for all to use" way. I was googling for a free-to-use app
on the web that used this approach. I think that saleforce.com and
other asp apps provided hosted data with download features, and they
are also for-pay services.

Yes, that is what I'm looking for. I couldn't think of why it wouldn't
be a reasonable approach but I could find no open source applications
handled as database-only installations.

It seems like it could be a way to promote a database environment. If
you have a hosted app that is free for use if you use one of these
database products ...,

If the database has an api for required actions that cannot be done
through a web-based interface, that would be a problem with this
scenario.

good design

If you say "SQL" in a few words and are not planning to use something
already written and debugged over many years (I don't know which work
well - IBM? OnGroup? jBASE?), I might try to dissuade you. The devil
is in the details: mapping between 2-valued and 3-valued logic, mapping
ordered nested lists, loose compared to strong typing issues, derived
data (aka virtual fields), database triggers & constraints, metadata,
dates, etc.

Really? OK, you've got my attention. What XML data sources are you
using for data persistence? XML documents in the file system? Any
"XML databases"? I'm all ears.

I understand there might be good rationale, but I can hear the dollars
getting sucked into that project. Look how many folks out there are
working on O-R mapping in light of XML. As soon as the access language
after SQL, to be used for XML persistence, starts making a dent (XQuery
and/or maybe something that comes from the RSS 2.0+ folks) then the
companies that focus on data source connectivity will be there.
Instead of pouring the dollars into your own proprietary approach, you
might be able to plug in something more standard, more quickly if you
wait a bit. Not that I have an opinion on this topic ;-) but feel free
to chat offline.

I've lived it. It is interesting, and I'm absolutely certain it is
more fun for he-who-is-not-paying-the-bill (and I wasn't, thank
goodness).

It does sound like you have done what I'm looking for other than the
free-for-use feature. Since I'm looking for all aspects of the
application to be sans-dollars changing hands, I'm guessing that isn't
a match.

Cheers! --dawn

On 25 Oct 2005 07:20:41 -0700, "dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote:

If you isolate the data onto a public database, you'd better have a
CIPE connection or some kind of 128-192 bit SSL tunnel fo it. Whatever
machine it is running will need to be able to deal with some major DoS
abuse too. Everyone and their hacker brother will be out trying to
shut companies down.

The "accessible anywhere on the Internet" can lead to security
problems and also logistic problems regarding 'rented' bandwidth from
the host. Imagine pulling 30-40 megs of data for a thick screen across
an overloaded pipe at the DB host. Users will be cursing you all day
long. I'm not saying it's not doable, it's just not practical with the
current fiber infrastructure in the U.S. Otherwise, there'd be tons of
people doing that already. Most of the ASPs still prefer to host the
app and the data on the same LAN for both of those reasons.

That's mostly due to the bloat of data required to make sure an
architecture like that worked properly and securely. SSL based XML I/O
is feasible, but is the virtual locality really worth the bandwidth
cost? You could compress the transactions, but that just offloads the
responsibilty onto the CPU(s). Most people won't pay the hosting
overhead costs when they can host it themselves or pay the ASP to host
the data as part of the application package. Just wait until the
database costs 3 times the application. :P People scream bloody murder
with the current MV licensing costs!

The biggest concern I would have, as the application developer, is
what kind of crap people will be trying to remotely load. I'd also be
really concerned about someone hijacking and corrupting the
transactions. They can't steal anything but they can sure kill the
database performance from the comfort of their nested shells. I think
it's a great idea, but making something like that cost-effective will
take a lot of cash, quite a few developers, and some more advancements
in TCP security technology.

There's been many discussions about seperating the user interface,
business rules engine, and the data store. I started an RFC back in
2000, to lay out a generic ASCII protocol for MV data access. The
purpose was to eventually demonstrate ideas like this in simple terms,
which can later be enhanced for corporate use. It got zero interest.
Maybe if it was an XML DTD that automatically worked with an MV
database, then people would recognize a "buzzword" and look at it
again. :/

Glen

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

michael (AT) preece (DOT) net wrote:
Nothing has changed. There is pretty much nothing that an ActiveX can't
do, so the security implications of letting them run in your browser are
enormous. One reason why Firefox is more secure than IE is that it
doesn't natively support ActiveX. I like that.

Luke