Web Services 2.0?


XML & Web services: Web Services 2.0?

  1. Web Services 2.0? (18 messages)


    This message is addressed to all Web Services enthusiasts and opponents, since I hope to get positive feedback from both camps this time :)

    Friends, I need your opinion on the technology created to solve many of the important Web Services problems. It also extends the boundaries of Web Services applicability. "Farelets" is the name of this idea.

    Before continuing with technical explanation, I would like to mention one important thing, axiom, if you will, to make sure we won't start fighting each other before reaching the designated duel spot:

    this technology comes as a bonus. Its goal is to extends Web Services, make them better without sacrificing achievements, which have already been made.

    Farelets are mobile 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 of 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, 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):
    Farelets docs
    Of course, any feedback regarding the document is greatly appreciated.

    One more thing: next message contains some example applications of farelets.

    Now I would like to ask all of you, to be kind and publish your vote in this thread. Here's proposed voting ballot:

    "What do you think about farelets?"
    1. Amen!
    2. I like it
    3. Neutral
    4. I don't like it
    5. Please do not post here anymore!

    Those, who will find time to elaborate their opinion, will be considered valuable contributors and my personal friends :)

    Those, who prefer to contact me personally, are welcome to send emails to gorbunov at pacbell dot net

    For spam, please use sirota at pisem dot net :)

    I will try to answer all questions you will care to ask, and also will count and publish voting results.

    Thank you all in advance,
    Igor Gorbunov

    Threaded Messages (18)

  2. Farelets Examples
    (where regular Web Services fall short, but Farelets can deliver):

    1. Reliability
    Businesses are unlikely to dedicate mission critical activities to remote Web Service because of Internet’s inherent lack of reliability.

    EXAMPLE 1: scheduler (“CRON?-like) Web Service. A main concern in this case is reliability. As soon as this issue is addressed, scheduler could become a very valuable Web Service application.

    2. Performance
    In many cases performance limitations prevent customers from using otherwise effective Web Service.

    EXAMPLE 2: Sorting, graph traversing, other computational tasks or algorithms do not make good Web Services until their performance is dramatically improved. The root of performance limitations in this case is Web Services remoteness. It is also true for compound- and broker-type Web Services.

    3. There are situations where remote Web Service is trusted but the communication channel is not.

    EXAMPLE 3: flight tracking Web Service or online shopping Web Service, which send sensitive data over the Internet.

    4. Heavily loaded Web Services can be ineffective. Addressing clustering, load balancing and other scalability issues may require either extensive programming or employing some kind of sophisticated tools and frameworks even for simpler Web Services.

    EXAMPLE 4: currency converter on your home machine, which suddenly becomes very popular.

    For graphical illustrations and more details, please visit:
    Farelets docs

    Thank you,
    Igor Gorbunov
  3. Vote: 2. (I like it)
  4. Vote: 2. (I like it)
  5. Vote[ Go to top ]

    Vote: 2. (I like it)
  6. Vote[ Go to top ]

    Vote 2: I like it.
  7. Web Services 2.0?[ Go to top ]

    Vote: 1.5 I like it a bit

    Nice idea, but the more I was reading the Farelets docs the more I was reminded of Java WebStart. IMHO, it'd be easier to employ SOAP support by a piece of existing Java code and turn it into a WebStart application with all the versioning and sandbox security already in place than to reinvent all those wheels again.

    The more so as some examples do not prove anything to me. For instance, why as an end user should I believe in some kind of custom built cipher more than in plain SSL support for sending my credit card info? And on the other hand, being an application developer why should I bother to provide such support istead of reusing well known SSL libraries without [fairy speaking] any additional effort?

    Scalability example is also arguable... I would expect a currency converter to receive a few hits from many different hosts rather than many hits from returning customers. With such a scenario the host would be killed by the number of the Farelet downloads whereas it could potentially serve its clients with a few bytes each in timely fashion. However, I'm sure a better example can be found to illustrate this matter.

    Disclaimer: I am by no means a WebServices guru.
  8. Web Services 2.0?[ Go to top ]


    First of all, I'd like to thank everyone, who found time to answer, I am really grateful to all of you, and I am glad that his idea makes sense to some other people, not just me.


    Your point regarding similarities of Java Web Start and Farelet is perfectly valid. However, the main goal of current Farelets documentation is just to suggest mechanisms for addressing very real and very significant problems of Web Services technology. The question of how those mechanisms will be implemented is beyond the scope of these introductory papers. I think that Java Web Start (or JTrix), or some other existing technology could be used to implement Farelets eventually, but right now it is hard to estimate the probability of such thing happening...

    I have deliberately chosen to avoid implementation "commitments" because the Farelets specification document is at the very early stage of its existence, and not all the requirements and features are finalized. I can't say for sure if the technology, which can be used as Farelets implementation platform, is available at this moment.

    As for Java Web Start, one particular problem I have with it is the requirement that Farelets can be executed either remotely or locally, depending on client's choice. I don't think Java Web Start has this feature right now.


    Security example: unfortunately, there is more to Web Services security, than transport security (SSL). Web Services may need additional help in addressing non-repudiation and third party proxies/intermediaries issues. Also, it may be required to encrypt just a part of the SOAP message. Therefore, I still think that allowing farelet to make its own security arrangements is not only convenient (in a sense of freeing the client programmer from that responsibility), but also practical in certain situations.


    To reinforce my scalability example, we'll have to make some additional assumptions: imagine that your currency converter Web Service (because of its brilliant business characteristics :)) is being used by a number of Wall Street companies. Now these guys are "returning customers". They are also likely to use your Web Service very intensively. By creating a farelet and allowing your clients to download it locally you can solve scalability problem. Downloaded farelets will contact your host to get regular rate updates, however the pace of these calls will be much slower. As you can see, scalability can be addressed in various ways: by changing communication patterns (e.g. broadcasting updates), employing local caching (transparently to the client) or just by reducing remote calls rate.

  9. Web Services 2.0?[ Go to top ]

    3. Neutral.

    Actually I do not see notable gain from Farelets.
    I'll review advantages one by one to explain my point of view.

    1. Reliability.
      To illustrate it scheduler (cron-like) sample is used. You say: "...using Farelets technology, user doesn't have to depend on Internet and remote host reliability characteristics". But if you do not depend on transfer media you do not use it. If you do not use Internet
    then you don't need Web Services at all. You can just download and execute code locally.
      Also such service should be simple enough. For instance, typical business application relies heavily on database-related functionality. Using simple services practically limits database interaction.

    2. Performance
      If you need remote interaction then you can design your Web Service in such way that it becomes as effective as Farelet.
      Using your sample (sorting-related operations before WS call) and having rewritten it's business logic to include sorting you'd just have to transfer row source data (not sorted) and get the result.
      Let's assume: t1 - time of sorting, t2 - time of remote communication, t3 - time of logic execution.
      Than the whole time using farelet would be: t1 + t2 + t3,
    using WS: t2 + t3_1, where t3_1 = t3 + t1.
      Performance could be improved only in case of complex logic that should be executed on the client to reduce network traffic.

    3. Security
      IMHO downloading and execution of outside code locally arise number of security issues. Resolving them leads to making Farelet as restricted as possible. On the other such solution set up new problems (look at applets).
      To secure traffic sent over the Internet SSL/VPN solutions are typically used. It's simple and guarantees confidentiality. There're tasks when other solutions are required but to my mind they're quite rare.
      In general, I think that this technology potentially arises much more security-related problems than it solves.

    4. Scalability.
      In the Internet environment, local execution of code is not really good idea due to a number of different reasons.
    One of them is a variety of target clients. Some of them are quite slow (PDA, for instance) and that leads to lack of scalability.
      Using server-side logic allows developer to support maximum number of different platforms.
      Also I agree with the previous post (about the number of downloads and update redownloads).

      Conclusion: I think that the best feature of Farelets technology is similarity with Web Services to execute components locally. This could be merged into Java Web Start to support automatical downloading, security verification and software updates.

      Just my 2c.
  10. Web Services 2.0?[ Go to top ]

    Hello Alexey,

    Thanks for replying. Your skepticism is understandable, but I would suggest you to look at farelets at a slightly different angle.

    Farelets are not created to replace web services. The goal of farelets is to fill the gaps, address some of the limitations of existing technology. Farelets provide more options to the programmer but they are not the panacea and should not be used blindly (same is true for any technology, in fact).

    You will most likely find a lot of situations, where farelets are no better than regular web services. However, in my opinion, there are also many cases, where farelets can really make a difference. Also, one of the most important design goals for me was to make sure farelet will NEVER be less effective than a regular web service. This is why client can use farelet remotely (just as regular web service) or locally (if it provides an advantage).

    Let me use your examples to illustrate my point of view:

    - reliability:
    If web service just turns around and queries the database, farelet will not provide any benefits, but in case web service implements some business logic and reliability is a concern, farelets can help.
    -- remote calls can be eliminated (this does not necessary apply to simple farelets only. Some complex farelets may not require remote communications: computational farelets, UI form validation, text processing etc.);
    -- remote calls can be reorganized (use of reliable protocols, acknowledgement modes etc.);
    -- remote calls can be delayed/cached or reissued in case fault is detected.
    With farelets, all these approaches are implemented transparently to the client, while with regular web services, this will require extra programming from both sides.

    - performance:
    I think, simple formulas like t1+t2+t3 not always apply...
    With farelets programmer has the ability to optimize remote communications for performance:
    -- native binary protocols, caching, batch requests/updates, connection-based communication in contrast with connectionless HTTP etc.;
    -- as in case of reliability, performance can be improved by changing remote calls patterns (simultaneous connections to different data sources, caching, etc.);
    Web Services do not give programmer such freedom.

    - security:
    this one is actually "half-full, half-empty" dispute. My belief is, that industry has accumulated substantial experience in addressing security risks of mobile code. There are tried and proven models (from applets, to mobile agents, to peer-to-peer technologies). I think we (by that I mean all programmers) definitely have ability and knowledge to implement security and resource access model successfully, applying positive experience we have and avoiding known mistakes.

    - scalability:
    local call execution may still be a good idea. There is plenty of code you execute locally on your machine, and a lot of this code could take advantage of web services metadata and discovery features (text processors/IDEs, antivirus tools, multimedia tools etc.). There were a lot of attempts to implement these kind of tools as services (or at least to employ some of web services features), but farelets could provide a real, standard-oriented way to do that.

    Best regards,

  11. Web Services 2.0?[ Go to top ]

    Hello Igor,

      I've tried to compare Farelets with Web Services (following your document). Your last response changes my view of Farelets a lot. Currently I see it as just another "installer" like JWS (and that makes sense).
      I don't think that you could ever be able to work with remote and local objects seamlessly. Too many differences exist between them (including your own business logic, exceptions handling, etc). It's the same as using EJB remote interfaces as local ones. You should choose what you want first.
      Of course, you could add a notion of "local Web Service" (like Local EJB interface). But this would not be "Web Service" as for me.
  12. Web Services 2.0?[ Go to top ]

    Hello Alexey,

    Thank you for taking time to elaborate your opinion. I'm glad that my reply had clarified Farelets concept to you.

    As for treating local calls as remote calls - it sure is possible. In fact, you often execute code locally by employing remote call constructs (accessing your servlets/jsps from local machine, or EJB-to-EJB communications in "pre-EJB 2.0" containers). Farelets work in exactly same fashion. Client code uses SOAP libraries to access farelet just as he would access remote web service. From the client's point of view, there is absolutely no difference between web service and farelet. SOAP libraries (with farelets support) will download farelet and execute it locally or call farelet remotely (depending on different factors like client machine characteristics, pre-configured client preferences, farelet transport requirements etc.).

    The issues you have mentioned (error handling differences, performance considerations etc.) arise when somebody tries to implement some sort of "location transparency", e.g. tries to treat remote calls as local ones. That is completely different story, though, and has nothing to do with farelets...

    Please, let me know if I answered your question, Alexey, and of course, it is never too late to change your vote ;-)

    Best regards,

  13. Web Services 2.0?[ Go to top ]

    Generally, I like it, though I worry about security concerns.
  14. Web Services 2.0?[ Go to top ]

    3. Neutral
  15. Web Services 0.2?[ Go to top ]

    I don't like it

     You might check out my farwell comments in "The Saturn Times" at http://vamphq.com/times

      - Gerald
  16. Web Services 0.2?[ Go to top ]

    For your convenience a hyperlink http://vamphq.com/times
  17. Web Services 0.2?[ Go to top ]

    Would you care to elaborate your opinion a little bit

    > (either privately or publicly)?

      You can sum up my criticism as follows:
       - Reuse, reuse, reuse
       - Don't reinvent the wheel, the toothbrush or the trash can
       - build on existing infrastructure
       - don't talk about it, show me the code,
          show me real examples

      Anyway, keep up your work. Don't expect everyone to agree with you. No personal offence. It's just my opinion.
  18. Web Services 2.0?[ Go to top ]


    First of all, let me assure you, that no offence is taken.

    As for your criticism, it really comes down to two points:
    - adopting some existing product (namely, Java Web Start) as a platform for farelets;
    - providing code or example as a starting point for discussion.

    Allow me start with the latter one. My personal opinion is that demonstration of source code or an example of some kind is not the best way to communicate ideas of such level. The goal of my initial post was to get a feedback on the idea, not on the implementation.

    "Reuse, reuse, reuse".
    I'm always wondering about what automotive industry engineers have to say about reinventing the wheel... How many times the wheel really got reinvented (or improved, or modified)?
    Reusability is a strong argument and a noble principle, but it should not replace the ultimate goal in one's mind. Efficiency, IMO, should always be the first priority. That's what managers and architects are in fact delivering. Reusing is a part of efficiency, one way to reach it, if you will. However, in certain situations reusing existing solution may not be the best way to go. Lots of people come to this through practice. That's why XP followers proclaim simplicity and clarity over reusability and universality (I am not a big fan of XP myself, but their points usually have certain practical value).

    For me, reusing of ideas, elements and practical discoveries usually works better than chiseling and tuning complex system to fit my requirements. May be I am lucky this time, and Java Web Start can provide all I need (and hopefully very little of what I do not need :)). Below is a list of problems farelets may have with Java Web Start. If they can be addressed easily, I sure will be happy to use it:

    1) Java Web Start technology belongs to Sun. It is not an open source. I don't know of any easy way to make farelets technology a part of Java Web Start product.
    2) Java Web Start belongs to Sun. Basing farelets on Sun's product will prevent me from integrating farelets with SOAP client libraries, which are already out there. Also, customers won't have a chance to use farelets unless they have downloaded Java Web Start;
    3) Java Web Start does not have SOAP client libraries as a part of it right now. This probably means, that I'll have to implement SOAP client libraries myself. Even if I will do that, people will have to change their code to make use of my libraries, instead of ones they have been using previously. It is unlikely they will do so.
    4) As far as I know, Java Web Start downloads and launches an independent application. In my case, client libraries download farelet and then act as a server, communicating requests and responses between client and farelet. I am not sure current Java Web Start can do this.

    Igor Gorbunov
  19. Web Services 2.0?[ Go to top ]

    have you seen XWT Project
    Looks very close to your description, and already implemented. Lots of examples.