Re: [DotGNU]Butler = DGEE

[Chris Smith]

On Monday 13 January 2003 12:15, Peter Minten wrote:
> Hi folks,
>
> the Butler is in the current plans a different program than the DGEE but
> has a lot of similarities with it. However this is unnecessary, if you
> think of the Butler working this way:

> That is a lot like the way the DGEE handles webservices. That's why I think
> the Butler can be replaced with the DGEE. The details have to be worked
> out, but this approach seems most logical. It requires an important change
> in the way we think about the client however, the client is no more the
> passive partner like a webbrowser to a PHP webservice but it becomes a
> server itself. The User Interface becomes a set of functionality offered to
> selected webservices over the web. The difference between webservice
> components and webservice applications essentially disappears!

Okay.
You're effectively capitalising on the middleware here.
An extension to your idea would be someone running a DGEE on their unix box.  
They also want to run clients on the same box and point them at the DGEE.
Now there is no reason why the DGEE and the 'CDGEE' below aren't essentially 
the same thing.  Ie it's a DGEE with the client side components there too.

I thinks it's a smart idea.  We truly do get an "Execution Environment" - 
whether it's client or server should be irrelivant?

> There is just one small problem, the main GUI lib used at the moment is
> FOX, but the FOX message passing system is a little different from the
> DotGNU one. This is solved by wrapping the FOX message in a DotGNU message.
> The message send to a FOX object would look like this on the DotGNU level:
> ____OBJECT______MEMBER____ACTION__________CUSTOM_DATA______
> ("objectname", "handle", "invoke", [selector, message_data])

Yes, you'd have to do this for XML-RPC, but if you use another protocol then 
this would perhaps be unnecessary.

I'd like us to offer a DGEE with a selection of transports and protocols.  
Webservices would be authored to use one of the protocols (xmlrpc, soap...., 
jabber-xml) but perhaps over a range of transports that support the 
facilities used of the protocols (http, smtp, Jabber).
A single webservice cannot accept multiple protocols (xml-rpc, soap etc) (the 
solution to this is to vaneer off the functional part and provide different 
protocol interfaces on top of that).

So donkey work such as the packaging you describe above is only necessary if 
you're forced to use a particular protocol.
And you're forced to use XML-RPC 'cos it's all we have at the moment, and 
incomplete :o(

> I imagine the Client DGEE (CDGEE) working like this:
>
> The user gives commands to the CDGEE through a locally running webservice
> app (yes I know it's not a webservice if it's not accessible from a
> network, but you get the point :-) named Webshell. The CDGEE then creates a
> webservice process which accesses the webservice on the server and goes
> through the whole auth process. The local webservice process is linked with
> the UI libs and can thus provide a User Interface for the remote
> webservice.

Is butler was supposed to do intelligent marshalling of data as well as 
authentication?  Correct me if I'm wrong.

You've got a few options here.
- You can ask the CDGEE to do the authentication out your behalf, and then 
carry on doing direct ws requests to the remote dgee yourself (which won't 
work if the CDGEE-Butler is supposed to help with the data marshalling).
- Your client app could connect to the CDGEE and get it to do the 
authentication and other calls on your behalf.  Kind of active proxying.

The latter could be quite good as several simultaneous requests would get 
streamlined down the connection(s) open to the remote DGEE(s).

And you could go a step further.  If you're connecting to the local CDGEE, it 
could just do p2p communications with the remote DGEE (that is currently 
supported by the middleware) instead of hitting the transport network server 
(like apache).  But this probably opens up huge security issues (DOS attacks) 
so perhaps avoid that - and it's a bit of a closed system then.  However, 
this is how the VRS will hang together - but that is a controlled app so 
security is controlled.


Can I add that there is no reason why a webservice cannot request data from 
another webservice.  In a distribted environment that is totally necessary in 
my book.  Thus a webservice running in the DGEE may itself suddenly, if only 
temporarily, become a client itself. This opens up the interesting question 
of whether 'butler' stuff needs to be in the DGEE anyway to perform its tasks 
for this sudden client ?
So does the DGEE not become a CDGEE? :o)

There may be a few components missing from the DGEE that makes it a CDGEE 
(like the VM's perhaps).  However, if we've a SEE (derived from the DGEE) 
then we will be running webservices locally so the VM's WILL be required.

Oh round and round and round and round... :o)

Cheers,
Chris

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