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