Subject Re: [Firebird-Architect] Strategic Replacement for Services API
Author David Jencks
On Jul 27, 2005, at 3:37 PM, Jim Starkey wrote:

> In a post last week, Geoff Worboys mentioned that something he needed
> was a mechanism to determine the names of available databases. Putting
> aside the solveable issue of security, this struck me as a reasonable
> request, perhaps problematic, but something we might want to support.
> The services API would be the logical place for such service, but given
> the rather limited scope of the existing services API, it is hardly up
> to the task of reporting a list of database let alone a list of
> databases each with an open ended collection of attributes.
> Rather than pushing the services API, I think it's time to talk about a
> strategic replacement. While we want to maintain the services API, I
> think it's a waste of resources to extend it.
> As a strategic alternative, I suggest we consider a standalone
> administration server to take over the services API functions as well
> as
> new extensions. An architecture I've used before is a GUI frontend
> communicating with a backend administration server exchanging XML
> trees. The interface to the administration backend is pure XML, so any
> number of front ends -- command, gui, or API -- are possible. In every
> case, the front end establishes a socket to the administration server,
> establishes its credentials (login, site password, or other suitable
> authentication), the sends XML structured commands. The adminstation
> server parses and validates the XML, then dispatches to a named
> service. The result of a request (or reasons for failure) would be
> send
> back to the front as XML.
seems more or less reasonable as long as you stay far away from the web
service "standards"
> I'd be incline to structure the administration server so actual
> services
> are loadable modules for extensibility, with a local (probably XML)
> configuration file, with the requests passed as parsed XML. This would
> allow for third party administration tools within an established
> framework.

Are you thinking of providing a schema for the command and response
structures? How will the extensibility elements fit into the schema?
IMO schemas are pretty much necessary but the extensibiltiy stuff gets
hairy quickly.
> In addition to the current services API, we would also want facitities
> to return information about known databases and database attributes
> (gotta throw a bone to Geoff), modify Firebird configuration files,
> invoke other backup tools, restart servers, etc.
> The split between front and back end using XML as request protocol is a
> very easy, robust, and extensible technology -- basically anything can
> be passed either direction. If I were doing it, I'd create a Window's
> GUI in C++ for the front end and C++ for the administration server. I
> have a lifetime ambition never to do another Unix GUI, so if we go that
> path, it's either Wine or somebody else's front end.

Whatcha got against doing it once in java???? An eclipse plugin would
also see wide use :-)

david jencks
> There are other advantages of an administration server outside the
> database server process, particularly when execute extensions. If the
> extension crashes, the worst case is that the front loses it's
> connection to the backend -- nobody is gets clobbered.
> Any thoughts?
> --
> Jim Starkey
> Netfrastructure, Inc.
> 978 526-1376
> Yahoo! Groups Links