Re: Describing the Janus

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Fri, 09 Sep 2005 02:56:59 GMT
Message-ID: <%R6Ue.27154$FA3.821_at_news-server.bigpond.net.au>


"David Cressey" <david.cressey_at_earthlink.net> wrote in message news:_rXTe.9332$FW1.7976_at_newsread3.news.atl.earthlink.net...
>I want to describe an object that I've been imagining for a while. I've
> called it the "Janus".
>
> A Janus has two faces. I can describe each face reasonably simply: one
> face is an SQL client, the other face is an object, interacting with
> other
> objects in an object world.
>
> In the SQL client face, the Janus simply issues SQL requests to an SQL
> server, and interprets the consequent responses. It's appearance
> doesn't
> differ markedly from any other SQL client, like Interactive SQL, or SQL
> that was written into (or invoked from) an application program.
>
> In the object oriented face, the Janus acts like any other object in an
> object oriented world. It interprets messages, uses encapsulated methods,
> and issues responses. It can also initiate dialogue with other objects,
> as
> needed. Its behavior is much like that of other objects in the same
> object
> world, although it seems to encapsulate an awful lot of data.
>
> The other objects in the object world, don't know that the Janus has
> another
> face. The SQL server (presumably the front end for a relational DBMS with
> a
> database mounted on it) doesn't know anything other than the SQL client
> face of the Janus.
>
> The Janus doesn't keep very much inside of itself. All it does is
> transform
> object oriented requests into SQL requests, and transform SQL responses
> into
> object oriented responses. It's not clear to me when the Janus would
> ever
> initiate a message to another object, but that's food for further thought.
> I have some inklings, but they are very vague.
>
> There it is. I can describe it, but I have no idea how to build it.
>
> Can you build a generic one, or would you need a different Janus for each
> object world? Could several Januses (Janae?) all interact with the same
> database but exist in otherwise disconnected object worlds?
> Could several Januses exist in the same object world, but be connected to
> different databases?

Just the one is required.

> Is there any use for such a thing? I imagine that it might be an approach
> to solving the impedance mismatch between the (SQL based) relational DBMS
> products and the world of Object Oriented application development.

We have created an object, some years back, similar in nature to what you describe above. I have posted about it previously.

Recently for the Australian SQL Server User group, I prepared this message for their internal forum, so I will past it below:

~~~~~~~~~~~~~~[BLURB]~~~~~~~~~~~~~~~~~~~~~~~

This post is to introduce the resourcefulness of an extremely versatile tool in the SQL Server database environment. We have called the tool LittleSteps, due to the simple and sure methodology of approach by which one can develop and implement information reporting applications, and immediately distribute them in an organisationally sensitive manner to the end user.

Its claim to "new technology" is by way of the method of development of applications, both reporting applications and data update applications. All development work (meaning 100%) is actually performed within the database, in the creation and maintenance of stored procedures written in TSQL.

If a primary application were to be written with the tool, it would consist of the LittleSteps user interface tool,

     [ie: the Janus]

a database of application specific data, and a database of application specific TSQL stored procedures. That's it.

The tool obviates in entirety the client layer and any associated middle tier layer, and reduces all development to SQL code.

Complex multi-layered drill down reports are engineered simply by chaining together the corresponding number (per drilling level required) of stored procedures --- it's that easy.

LittleSteps is described as 'portal software' because it provides a direct service level connection to the database, by which the user activates (pre-designed and pre-registered) stored procedures, and which the resultant data output is presented to the user.

The end user can subsequently sort this data by any column, and/or filter the data set by any element contained therein. Print preview, and export to various formats including excel and word (tables) is then optional.

A description of the product and some of its benefits can be found here:
http://www.mountainman.com.au/software/LittleSteps/SQLServer/product_information.html

We are prepared to demonstrate the tool at a future (Australian) SQL Server user group meeting, if there is sufficient interest. In the interim period, I am happy to repond to any questions, or receive any comments, in this thread.

~~~~~~~~~~~~~~[/BLURB]~~~~~~~~~~~~~~~~~~~~~~~


The story behind the creation of this tool is a long one, but I will condense it heavily. After a 10 year term in the Oz federal government, I did another 10 years as the IT Manager for (at that time) Australia's largest patent & trade mark attorney firm.

This 10 years saw IT management of both the old (Wang Labs) and the new (SQL Server) machinery at the basis of a program suite that was hundreds of objects in depth.

Change management of many many hundreds of complex objects was real-time, as I was both QA new releases for my own production system, and on behalf of a few dozen internation client sites that were also using the software (now called InProma).

My DREAM was to reduce all objects in the environment to just one object (of course the purpose of which was to deal with the users and the database), and get rid of the hundreds and thousands of specialised disparities.

That is why, over time, I engineered this tool to do the task of all objects whose purpose is to function as an interface between and end user and an RDBMS.

I have a working version for SQL Server, and in time hope to bridge to both DB2 and Oracle as per the website.

Pete Brown
IT Managers & Engineers
Falls Creek, NSW, Australia
http://www.mountainman.com.au Received on Fri Sep 09 2005 - 04:56:59 CEST

Original text of this message