RE: Article on WS architecture and best practice ... may be of in terest

Paul -- I would find it very useful if you amplified what you say on the
bottom of this thread a bit.  What factors do you have in mind that would
make a web service interface a "good network application".  Does this have
to do with the granularity of the calls because of latency considerations?
Or the nature of the argument typing -- that is, preferring interoperable
typing to, say, Java-specific types?  Am I on the right track or are you
thinking of other things entirely?

-----Original Message-----
From: Paul Prescod [mailto:[email protected]] 
Sent: Thursday, October 03, 2002 2:55 PM
To: Ugo Corda
Cc: 'Champion, Mike'; [email protected]
Subject: Re: Article on WS architecture and best practice ... may be of in
terest



Ugo Corda wrote:
>>this methodology
>>defeats the whole purpose of Web services, which is to hide the 
>>implementation of a service completely behind an XML-based interface. 
>>VS.NET generates the interface from the implementation.
> 
> 
> I don't see the conflict here. For any user of the Web service the 
> generated interface does exactly that: hides the original 
> implementation.
> 
> If the point made by the article is that Web services interfaces 
> should be defined first and implementations should follow, this is 
> evidently not possible in all those cases where Web services are used 
> as wrappers for legacy implementations.

I think that the point is that the web service's interfaces should be 
designed to make it into a good network application which could be 
radically different than the appropriate interfaces for a LAN-based or 
desktop software component for all of the reasons described in the 
"Waldo paper" and elsewhere. If you are just letting software "generate" 
your network interface from a pre-existing interface then the chances it 
is optimal as a network application is tiny.

  Paul