Re: Xquery might have some things right

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Mon, 15 Mar 2004 23:42:02 GMT
Message-ID: <ebr5c.104974$Wa.53857@news-server.bigpond.net.au>

"Hiran Chaudhuri" <hiran.chaudhuri_at_lrz.fh-muenchen.de> wrote:  in message news:c358aa$4n0$1_at_wsc10.lrz-muenchen.de...
> "Marshall Spight" <mspight_at_dnai.com> schrieb im Newsbeitrag
> news:kSl4c.16961$ft4.103187_at_attbi_s54...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:bi22c.55867$%b5.36952_at_newssvr33.news.prodigy.com...
> > >
> > > I'd still like to hear a good definition for "services design
pattern".
> I'm
> > > not being facetious... I'd just like to be clear on what
differentiates
> > > services from other forms of remote call we've had in the past.

The differentiation will be in *what* is fetched.

> > I don't see any reason to think it's anything other than client-server
> > computing under a new name. You get RPC but with XML as
> > the transport.
> >
> > That's one beef I have with XML and its ilk; they like to come up
> > with new names for old things and act as if they've invented something
> > miraculous.

>

> It's not that bad. Of course you are right. A webservice is just RPC with
> underlying XML communication. But then this allows breaking platform
> barriers. Or how do you implement RPC between a Java program and Cobol on
> mainframes on the other side? Either you use a middleware product, or you
> use XML. And guess what: Today middleware also supports XML communication.

There is another option ...

I have called it RDBMS portal software as its whole function is simply to send RPC calls to the RDBMS and to (generically) handle the output data sets returned from the RDBMS executing such calls.

You then write all application level code in the form of (R)DBMS stored procedures and allow the portal software to be the user interface.

The end result is ....

• no client application environment (except the portal software)
• no application development environment external to the database
• the leanest and meanest performance benchmarks possible
• simplicity - for we are dealing only with the RDBMS technology.

Middleware is a bridge between an (often existent) application and an (R)DBMS.
The contruction costs of (getting and using) middleware are often far less than rebuilding the application correctly from the ground up.

-- 
Pete Brown
Winluck P/L
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software

Received on Mon Mar 15 2004 - 17:42:02 CST