Re: [DotGNU]Re: [Vrs-development] Defining WebServices (NetServices???)

[Chris Smith]

Sorry, this got a bit long.  Kind of a brain vent as to my intentions of the 
DGEE and the webservice model, what I expect to happen when it is released, 
and how we should proceed.

Peter, the code examples were useful - especially so as demonstration of 
thought processes,  and DO fit in with the architecture of the DGEE, but I 
can't say that it'd be how you expect as I'm not you!

I've put your post in my 'Keep' folder for reference!

Anyway, read on:

On Friday 06 December 2002 18:43, you wrote:
> If memory serves me right, Peter Minten wrote:
> > It's a good idea to set up a MS compatible system in the short term, but
> > the webservices interface spec is meant for the long term. Let me
> > restate: the way I see things there are 2 paths taken to the DGEE at the
> > moment. The first is the short term path to setting up an .NET compatible
> > system to get things working fast. The second is the long term path to
> > setting up an .NET independent system to get things working well. It's
> > kinda like Rhys motto: 'Make it work, then make it work better', I'm
> > working on the second part already.

And it's already a pain in the butt.
.Net only supports SOAP (would you believe it!)... but some industrious peeps 
have produced XML-RPC classes for it, from which I am learning... :o)

I've hit problems as it is, just getting something simple working (on the 
'api' point of view).  We've got to have some 'standard' RPC API in place for 
the Jan release and XML-RPC seemed to the the simplest, but finding where on 
the datapath to implement the protocol specific handling is not easy with 
each proposal bringing with it a different set of headaches.  Sigh.

This was supposed to be a prototype,  b u t  I wanted the architecture to be 
sound and, well, correct.  (admitting that nothing is ever perfect, but I did 
not want the 'make it better' phase to be a total redesign! - and it 
shouldn't be, the architecture is founded in 'modularity' and 'plugability' 
to facilitate changes - changes which should be to the functionality 
implemented over the architecture and not to the architecture itself (at 
least not much)).

Even though it is a prototype, it's going to be significantly more than that 
to make it a vehicle with which to carry lots of publicity in Jan.

So I'm going with XML-RPC to begin with (but probably won't have arrays 
working completely 'cos I can't figure out how to do that properly, and won't 
be in a position to until the other xml-rpc types are done).

Peter, The other reason for getting the DGEE done was so everyone could see 
what the architecture looks like, how the internal API's work, how the 
scaling model works and how messages get passed about.  I admit that I have 
found it very difficult to explain what I have in mind, as it's based on a 
lot of techniques that I've been using with customers over the last few years 
and a lot of developers see them as alien concepts and miss the point. 
[Sorry: Sweeping statement, applies to the engineering community in general, 
there is a significant proportion of people on the dg-ml who DO think the 
same way as me, just with different terminology]. There's nothing new in the 
concepts I feel, but they often seem to be different to other peoples initial 
direction.  This is not to say that they are necessarily correct, but from 
experience I do get a gut feeling when this type of architecture 'Is The 
One...' and find that the design literally falls into place.  I have such a 
gut feeling on this occasion. Whether other people in the dotgnu community 
agree with little-ol-me is up for debate, and for that I need to demonstrate 
what I'm on about, and get the prototype out!