Re: Data source options
- From: Glen <nospamwebmaster@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 26 Oct 2005 00:29:06 -0400
On 25 Oct 2005 07:20:41 -0700, "dawn" <dawnwolthuis@xxxxxxxxx> wrote:
>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 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.
>
>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.
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.
>
>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.
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!
>
>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.
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. :/
>
>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
Glen
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.
- References:
- Data source options
- From: dawn
- Data source options
- Prev by Date: Re: How do we get there from here?
- Next by Date: Re: Data source options
- Previous by thread: Re: Data source options
- Next by thread: Re: Data source options
- Index(es):
Relevant Pages
|
