[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Re: Defining WebServices (NetServices???)

From: Chris Smith
Subject: Re: [DotGNU]Re: Defining WebServices (NetServices???)
Date: Wed, 4 Dec 2002 12:00:02 +0000

On Tuesday 03 December 2002 19:17, Stephen Compall wrote:

> To be a proper DotGNU webservice, this interface metadata can't be
> dependent on IL assemblies.  Though it certainly pays to be
> backward-compatible, we should prefer a executable-neutral definition
> format, as not every "compiled target" (including scripts, jar, Parrot
> bytecode) can hold whatever metadata ASPs might want to dump in there.

I agree totally :o)  It was just a first step.

Inspecting the C# IL is the way (or so it appears to me) that .net finds out 
about exposed WebMethods etc.  .net generates an .asmx files from this 
content. It seems to do it a compile time (i've not played with .net at all, 
so this could all be considered hearsay!)

Now if we were to deploy perl webservices within the DGEE, then clearly 
inspecting the 'webservice' for details as to exposed methods would not work.

What the DGEE will ultimately do is have the Service Manager verify that the 
requested method is callable and that suitable parameters have been passed in 
_before_ it sends anything by way of the VM's.

Basically the SM in conjunction with the Resource Manager needs to hold some 
sort of index.  This will be far more efficient than having the valuable VMs 
sort it all out.

For now the SM and RM are simple components on the message path. They don't 
do any validation at all.

For C# IL, we could generate an index entry based on the content of the IL 
either at compile time (with some additional tools or switches to cscc) or 
when the dll is installed in the DotGNU execution environment.

Other language webservices such as perl, ruby, python, C even will also need 
index entries, but generated by other means - presumably at compile time.

(The VRS and SEE guises of the DGEE need additional information such as 
ownership etc for each webservice, this certainly cannot be stored as 
inbedded IL meta-data).

> It's not really the business of the execution environs to go tearing
> into the executable format, looking for metadata and their matching
> methods.  We need a platform-neutral service calling mechanism,
> including that metadata, and an easy way to front-end it on whatever
> platform a user might want.  

Yep, that's what I'm striving for, as above.

> e.g. for IL, a "webservices runtime" that
> runs with the actual service (in the VM) and translates the neutral
> interface to a IL-metadata-specific interface.  
> So the IL-metadata definition of services is only relevant in terms of 
> this runtime, not the environs as a whole.

I'm not sure what you're getting at here, but it's wet my appitite anyway!
Can you go into a bit more detail (examples help!)

Cheers Stephen

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]