- From: Newcomer, Eric <Eric.Newcomer@iona.com>
- Date: Sun, 30 Jun 2002 19:26:18 -0400
- To: "Edwin Khodabakchian" <edwink@collaxa.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>, <bytecode@Phreaker.net>, "Mark Baker" <distobj@acm.org>
- Cc: <www-ws-arch@w3.org>
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