RE: Late binding

Edwin,

Yes, this is why I'm interested in finding a middle ground. 

I am actually am not very interested in the RPC oriented aspect of Web
services; I think the document oriented (or messaging oriented) is much
more interesting, and much more suited to the Web.

I hope we can keep the discussion within the context of use cases we are
trying to resolve.  Within the message oriented world, there's a need to
associate the content of a message with an operation on the message.
Meaning that whenever anyone receives a message, there must be a way to
associate processing with the message.

For the browser oriented Web, the processing is always the same --
that's why GET and POST work out so well. The primary use case is to
exchange hypertext documents and display them in browsers.

With Web services we are attempting to solve an additional problem, as
you said.  I agree there's a lot we can learn from the existing Web, and
those of us with distributed computing backgrounds have to adjust our
thinking to this new world.  But I also think the opposite is true;
those with only a markup language background also have to adjust.

Perhaps the initial SOAP and WSDL specifications need improvement; there
are W3C working groups set up for the purpose.  Our job is more to put
those and other technologies into sensible relationship.  Our main goal
is to develop a reference architecture that helps guide  progress on Web
services as it evolves toward a more full featured environment; but not
really to question what's already been accomplished.

Eric

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Sunday, June 30, 2002 6:24 PM
To: 'Newcomer, Eric'; bytecode@Phreaker.net; 'Mark Baker'
Cc: www-ws-arch@w3.org
Subject: RE: Late binding


Eric,

I very much agree with you: 

*** We indeed are trying to solve a different problem: it is no longer
about we use the web to let a user access a resource through a browser,
but how multiple applications talk to each other. Therefore it is not
about how a user agent access a resource but about how a developer
programs and automates a service. And I believe that this is why we are
attracted towards API and the early uses of Web Services look like RPC.

*** XML, XMLSchema, SOAP are very good first steps in promoting
interoperability.

But as we start to deploy some of service-oriented applications for our
customers, we start to realize that we need more: 2 of the most
important requirements are adaptability and reliability. 

I think that adapability is one area where the web is shining. The web
has an incredible ability to adapt to constant change. No other
architecture (mainframe, client/server, corba or J2EE) has this ability.
You might say that it is easier to build an adaptative system when one
end is a user (who can dynamically adapt to new page layout/content,
exception, etc.) but all the resources are still linked and there are
definitely lessons to be learned.

On the reliability side, asynchrony and messaging are key because they
compensate for heterogeneous performance and life cycle.

Together adaptability and a more messaging-driven linking abstraction
raise serious question regarding the current RPC mechanism that web
services expose to developers today. One other way to say that is that
if early toolkits make it easy for developers to use the web for RPC,
then there will be adoption because RPC is developer friendly but we
might end up hitting the wall because we will have applications that are
very fragile and very difficult to evolve.


Edwin

Received on Sunday, 30 June 2002 19:37:48 UTC