Re: [Vrs-development] New Thread on Service modules Framework

[Chris Smith]

On Saturday 23 March 2002 00:21, you wrote:
> i was just going thru the phoenix architecture. even
> though the functionality is quite different, the base
> model could be modified for the service modules
> framework.
>
> The Service manager could be active on a unix domain
> socket. The information received by the port manager
> could be passed to the service manager. The service
> manager passes this request (usually a SOAP object)
> onto another thread, <Unknown> which determines what
> the request could be. All the web services are
> registered with a registry module. This module then
> invokes the actual web service within the sandbox to
> handle the request.

This is essentially *what* goldwater is for.
What follows is the design I have in my head (translated into your words):

The service manager is a goldwater-service which sits and waits for a request
message (whatever that is defined to be) from a PortManager.
*Something* sits on the network accepting SOAP requests (say Apache for SOAP
over HTTP).  This PortManager detatches the XML request payload from the SOAP
request and sends it to the Service Manager along with the details of the
requested web service. (see ** below).
The service manager queries the Registry (just another goldwater-service) to
find out where the webservice is.
It calls the appropriate Goldwater-service to retrieve the webservice code
and then it invokes the webservice within the sandbox to handle the request.

[** You could split this into PortManager->SOAP-Handler->ServiceManager so
that different PortManagers (ftp,smtp,http etc) can share the same
SOAP-Handler.  If you look at the diagram in
http://www.nfluid.com/goldwater/docs/gw-dotGNU-SEE.pdf you'll see what I'm
getting at...]


Phoenix is just a network handler.  It doesn't do very much but is terribly
good at receiving stuff from a network and passing it on to something else to
do the actual processing.  I think you've realised this given that you
suggest using Phoenix as a PortManager and squirting the data it receives
into another process via a unix domain socket.

A VERY early version of Goldwater did exactly this!!!!!!!!!!!!!!!!

These days it doesn't use unix sockets because for multiple simultaneous
requests you'd need lots of them in parallel and really wasn't scalable.
These days Goldwater uses a different scheme and employs parallel message
queues combined with FIFO queueing and message routing.  It's now wonderfully
scalable, and the message routing will route transparently across networks to
goldwater services on other machines if required.


Chris

-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk