RE: Late binding

Eric,

May be we are saying the same thing here then: In a document/messaging
world, Web Services are a set of interoperability standards that let us
think of the web as a network of "queues". Each queue knows how to
process a "XML Schema" typed document and if necessary return when
completed another "XML Schema" typed document to 1 or many observers.
The processing of the document could take 2 seconds, 30 seconds, 5
hours, 10 days or 3 months.

In that perspective, in order to increase adaptability and simplify the
composition, we can learn from the web and limit the number of verbs
that each queue understand: one verb to put the document to the queue,
one to get the status of processing, one to notify observer, etc.
Interoperability also requires the propagation of context as part of the
document: security context, transaction context,
conversation/correlation/callback context, expiration, etc. and the need
for protocols like BTP to coordinate the distribute processing of those
documents. If we are able to define such abstraction and it ends up
beeing isomorphic to a web resource then we might be able to leverage
the foundation of the web architecture.

Regarding the processing of the message once it is put in a queue, I
believe that this should be left to J2EE and .Net similar to how
Servlet, ISAPI, ASP, etc. did the mapping for HTTP requests to a class,
etc... Are you suggesting that this workgroup should try and define how
a SOAP message should be extracted from a queue and processed as part of
each architecture?

Finally, I think that part of the challenge of the workgroup is facing
is that document/message oriented use of web service (app to app
cooperation) is only one use case of Web Service standards. The other
one, is the real-time integration of content into portals, excel and
other user driven, desktop applications. The requirements and
application model there are different. Trying to find one unique
architecture that satisfies both requirements and remains simple will
not be trivial.

I believe that finding a middle ground between the web and distributed
computing starts by determining the (developer) representation of a Web
Service. Meaning is it a resource/state like in the web, an object with
methods like for distributed computing, an typed-queue like for
messaging/EAI. All have their pros and cons. :-)

Edwin 









-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Newcomer, Eric
Sent: Sunday, June 30, 2002 3:26 PM
To: Edwin Khodabakchian; Newcomer, Eric; bytecode@Phreaker.net; Mark
Baker
Cc: www-ws-arch@w3.org
Subject: 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 20:41:42 UTC