[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RE: Traditional RPC

  • To: 'Mike Champion' <mc@x...>, xml-dev@l...
  • Subject: RE: RE: Traditional RPC
  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Mon, 18 Feb 2002 10:38:41 -0600

vba rpc
Do you really think the average office worker knows what the 
<!DOCTYPE at the top of an HTML file is for?  I don't. OTOH, 
they don't code them.  They make others do it for them.

1.  The average office worker still hides behind FrontPage and it's ilk. 
Having spent a lot of time a week ago rebuilding several FP enabled 
pages and closing security holes (ODBC strings in .htms?????), I can 
say it wasn't too hard to do it right the first time, but these folks 
were career-oriented, got what they wanted, moved on to bigger and 
better, and left a mess behind.  One reason I dig into these issues 
is a real-world awareness that the mess lands on my desk.

2.  It is interesting to take a look at the MS pages on web services 
with their animation of how Visual Studio, VBA etc., will support 
discovery and integration.  It glosses over the right to use these 
services, how to pay for them, the contract bits, but it looks about 
like what a VBA programmer is used to.   Let's be honest:  it isn't 
just programmers (the pure, the mighty, the powerful, the knowledgeable) 
vs everyone else (the slothful, the ignorant, the spoiled, the needy).  Most 
web programming above the level of core technology is object scripting 
and that includes HTML (particularly HTML). The model the MS pages 
show is the model many scripters know. 

I have to think that is a key reason: ease of integration into VBA and 
the toolkits that support it and languages like it (Javascript).

Point:  it would be nice to get this right. Legacy builds fast and 
there are dimensions of that that extend into the organization, the 
habits of the humans, and the performance of both.  I don't like 
to clean up the messes of the politically correct or the wild-eyed 
individuals.  (somewhere between objectivism and vedantic beliefs, 
there must be a middle ground better than "do the right things for 
the right reasons", but I'm danged if I know what that is).

Scalability worries me.  Treating a WAN like a LAN worries me.  Getting 
the scripters to not code too close the process of an individual 
desktop worries me.  On the other hand, reliance on a global namespace 
has its perils too.  The issue today is edge system integration; not 
understanding the philosophy of URI.  That is corrupt on the face of 
it; it conveniently "webs" but the namespace as URI is corrosive.

The Web Way doesn't worry me.  The Web doesn't exist.  Parts and 
assemblies exist.  After that, what works had better work for 
long enough to get ROI.  My intuition is that that is what the 
WSIO is about:  code on the loading docks.

len


From: Mike Champion [mailto:mc@x...]

2/18/2002 10:03:40 AM, "Bullard, Claude L (Len)" <clbullar@i...> wrote:

>So Why Traditional RPC?  Why Web Services per UDDI/WSDL/SOAP?

I didn't think there was much dispute -- this is the programming way,
the CORBA and DCOM way, to access remote applications.  It works
well on LANs, so there's a solid base of experience to draw on that
you can hide the network behind an RPC.  It makes a lot of intuitive
sense -- SOAP-RPC as a neutral wire format, WSDL as a neutral IDL,
UDDI as a directory service.  It has a plausible business model:
vendors compete on ease of use and quality of implementation rather 
than on basic protocols.

I can agree with the REST people that it's not "the Web way",
that it forces a reinvention of things that the Web already 
supplies, and that it may not scale to the web as it really exists... 
but I understand why the Web Services people chose the "programming
way" and treat the Web as simply a giant LAN.  We shall see if
it works out that way.

I'll predict that both win: Traditional RPC really is the easiest
way for programmers, and will work well enough behind firewalls
and between established partners and in arenas where user simplicity
matters more than system reliability (e.g., for Userland's typical
customer, AFAIK). But now matter how fast the Internet that we know 
today improves latency, reliability, security, etc., it will 
be extended geographically and to smaller 
and more mobile devices,continually opening more niches where the REST 
paradigm shines.   

The only "REST rules, RPC drools" scenario I can imagine, i.e. that
would make the WS tool vendors' inital focus on RPC ill-considered,
is if the non-programmers somehow grok REST big time
and find it an easy migration path from what they do now to
the Wonderful World of Web Services. It's more likely than 
assuming they will learn to think like a programmer, no?   
Will non-programmers build and use web services?  Maybe not, 
but who would have thought 10 years ago that the average student, 
office worker, etc. would have a basic knowledge of a markup 
langugage (HTML) today?

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.