Re: Xquery might have some things right

"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.

>

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