- From: Igor Gorbunov <gorbunov@pacbell.net>
- Date: Mon, 03 Jun 2002 19:52:28 -0400
- To: www-ws-arch@w3.org
Hello, This message is addressed to all Web Services enthusiasts and opponents, since I hope to get positive feedback from both camps this time :) Dear gurus, I need your opinion on the technology, which could be able to solve many of the important Web Services problems. It also extends the boundaries of Web Services applicability. I call this technology "Farelets". Before continuing with technical explanation, I would like to mention one important thing, axiom, if you will, to make sure that discussion will be conducted within designated "duel spot": this technology comes as a bonus: its goal is to extend Web Services, make them better without sacrificing achievements, which have already been made. Farelets are local Web Services. Once discovered and bound, they get downloaded to the client's machine and are being executed as a local code. By taking this approach, farelets address the following issues: 1. reliability, 2. performance, 3. security, 4. scalability. Issues 1-3 are considered by many as very serious problems. In fact, in my experience, almost all opponents of Web Services name one of these 3 issues as their main concern. Farelets can help. Two key characteristics of farelets make it possible: -use of local calls instead of remote calls; -communication method flexibility. Here are some important aspects, you have to take into consideration before finalizing your opinion: - Farelets are Web Services. Downloading is optional. Client still can use farelet remotely, just as regular Web Service (.NET client for Java farelet, dial-up client for 20MB farelet); - Farelets are Web Services. They are registered, discovered and bound just as regular Web Services; - Farelets are Web Services. From the client's prospective farelets are no different from regular Web Services. All farelets specifics are handled by client libraries in transparent fashion; - Farelets are Web Services. They are still accessed using SOAP, even locally (for compatibility reasons and to take advantage of SOAP's extensibility). This one is a question mark actually, your thoughts will be appreciated; - Farelets do not have to be entirely local. Obviously, they can include remote calls, but they have a freedom of choosing optimal transport and encoding protocols, communication patterns and caching strategies; - Farelets can do more than regular Web Services (farelets with UI, farelets using local resources, client code callbacks etc.); - Farelets are not peer-to-peer technology. There is still a clear distinction between client and server; - Farelets are not for everyone :). Some Web Services will not benefit from converting into farelets (Web Services wrappers over legacy apps.), but most will (IMHO). Well, I think this should do it for casual readers. For those, who are interested and want more details, I have put together a document (with examples and illustrations): <a href="http://www.entente-llc.com/farelets/">Farelets docs</a> Of course, any feedback regarding the document is greatly appreciated. One more thing: next message contains some example applications of farelets. I would be most grateful to those, who will find time to elaborate their opinion, but even a brief answer would be valuable to me. Those, who prefer to contact me personally, are welcome to send emails to gorbunov@pacbell.net Of course, I will try to answer all questions you will care to ask, and I hope this message is not frustrating to anybody. Thank you all in advance, Igor Gorbunov
Received on Monday, 3 June 2002 19:48:31 UTC