W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2002

Web Services 2.0?

From: Igor Gorbunov <gorbunov@pacbell.net>
Date: Mon, 03 Jun 2002 19:52:28 -0400
To: www-ws-arch@w3.org
Message-id: <KCEBLPJMAEJKHLAHKAGHGEKDCCAA.gorbunov@pacbell.net>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:00 GMT