Discussions

News: Performance Considerations in Distributed Applications

  1. Distribution and Communication between applications and services is a central concept in modern application architectures. In order to profit from distribution you have to keep some basic principles in mind – otherwise you can easily run into performance and scalability problems. During development these problems often do not surface. Then suddenly in load testing or production you might then realize that your chosen software architecture does not support the required performance and scalability requirements. In this post we will look at major points to keep in mind when building distributed applications. Read more at http://blog.dynatrace.com/2009/09/28/performance-considerations-
  2. I accept some of your points like avoiding huge messages; prefer chunky services over chatty interfaces for performance improvements, however considering any other protocol for remoting other than SOAP would be a big mistake at this point of time. SOAP is the only defacto standard for interoperability among various platforms. A conformance to WS-I and BP would ensure that application owners would no longer want to worry about interoperability. With advent of SOA, SOAP has become further emboldened. SOAP on HTTP has performance problems, agreed! But there are good alternatives to overcome it in application design itself. Also, who are the ones backing other protocols like Hession, Burlap etc. Regards, prase
  3. I accept some of your points like avoiding huge messages; prefer chunky services over chatty interfaces for performance improvements, however considering any other protocol for remoting other than SOAP would be a big mistake at this point of time.

    SOAP is the only defacto standard for interoperability among various platforms
    . A conformance to WS-I and BP would ensure that application owners would no longer want to worry about interoperability. With advent of SOA, SOAP has become further emboldened.

    SOAP on HTTP has performance problems, agreed! But there are good alternatives to overcome it in application design itself. Also, who are the ones backing other protocols like Hession, Burlap etc.

    Regards,
    prase
    Shocking. Do you really speak seriously ? Guido
  4. I accept some of your points like avoiding huge messages; prefer chunky services over chatty interfaces for performance improvements, however considering any other protocol for remoting other than SOAP would be a big mistake at this point of time.

    SOAP is the only defacto standard for interoperability among various platforms. A conformance to WS-I and BP would ensure that application owners would no longer want to worry about interoperability. With advent of SOA, SOAP has become further emboldened.

    SOAP on HTTP has performance problems, agreed! But there are good alternatives to overcome it in application design itself. Also, who are the ones backing other protocols like Hession, Burlap etc.

    Regards,
    prase
    Why don't you want to for a faster binary protocol in inter-enterprise communication. Even service-oriented systems can be built using these technologies. I agree that there are situations when to use SOAP, but there are lots, when not to use it. Optimization of messages can bring you a long way, but in many cases it is not enough
  5. I’m game for any new protocol which offers better performance over SOAP. It’s not about me embracing the change, but how this industry welcomes it. Sure, hessian or burlap may become the next big thing, but for interoperability what else you have other than SOAP at this point of time. How many vendors and companies are adapting to these new protocols?
  6. I’m game for any new protocol which offers better performance over SOAP. It’s not about me embracing the change, but how this industry welcomes it. Sure, hessian or burlap may become the next big thing, but for interoperability what else you have other than SOAP at this point of time. How many vendors and companies are adapting to these new protocols?
    Are you joking, isn't it ? Speaking about interoperability you cannot compare SOAP with other technologies like CORBA or ICE (www.zeroc.com). SOAP is not simple and has no objects, so it is an access protocol. There is no server-side development model, no server-side portability, no client-side portability. Last but not least it is hard to conceive something more stupid than WSDL. It might "work" in a test lab. You cannot seriously take into account the development/deployment of a moderately complex distributed system using WSDL. What the "industry" promote might be ruled by forces that has nothing to do with technical merit. Guido
  7. I’m game for any new protocol which offers better performance over SOAP. It’s not about me embracing the change, but how this industry welcomes it. Sure, hessian or burlap may become the next big thing, but for interoperability what else you have other than SOAP at this point of time. How many vendors and companies are adapting to these new protocols?
    SOAP was invented primarily to avoid firewall security by 'tunneling objects' over HTTP. Currently, anyone who knows what they are doing will avoid RPC-style SOAP. That leaves us with an envelope and a fault tag both of which are trivial. The WS* constellation of basically exist to correct the interoperability issues of SOAP and WSDL and to reimplement the things it was created to avoid, like secure communication. SOAP and WS* are a joke. Major vendors like IBM and MS are on the REST bandwagon. It's time to move on. SOAP and WS* are for legacy systems.
  8. God! Too much speech full of hate! 1. SOAP was not designed for services, it was for object distribution. 2. SOAP was refactored to be used as an envelop for services, just because it was coming with momentum at MS. 3. WSDL is not as stupid as the idea of REST as a simple URI definition. That is, REST is far, far more than that, and IT IS NOT FOR SERVICES, it is an architectural style for networked applications. 4. The WSA made the worst mistake in history by allowing the RPC literal to be kept as a backward compatibility thing. Who told them Services were an evolution of Distributed Objects? 5. Actual WS implementations are worse. The tools will tell you they are creating document style, while forcing the document to assemble an RPC. The BARE/WRAPPED thing, that is worst idea. 6. If you need distribution, do not think on WSA (note I do not say SOAP, because SOAP is not WS). You need to think fast and reliable comm. But if you need integration, you need to talk at business level, and that is services. 7. If there is a new protocol (not talking of SOAP replacement, since I never accepted SOAP was a protocol at all, it is more an envelope format), it will need tool acceptance. Actual tools offer what clueless developers ask for: an RPC (so they keep seeing things as function calls) that has a fancy name (be it WS or REST). James is right when he says developers that know what they are doing will not use RPC SOAP. Still, tools are RPC all the way around, as I mentioned before, so we have no way to run! 8. Developers need a mind Shift towards services, if they want to use them. 9. Agree that, for performance, you should not go the WSA path. 10. 98% of the tools offer web services, and have a ton of products working with those standards. Some are starting to launch the REST bait, but have no more that URI templates and a couple of other things. So, bottom line: do not use SOAP for performance, use it for integration, and at business level, not RPC. And forget about REST as an alternative, that is simply not for this. William Martinez Pomares.
  9. 3. WSDL is not as stupid as the idea of REST as a simple URI definition. That is, REST is far, far more than that, and IT IS NOT FOR SERVICES, it is an architectural style for networked applications.
    Services are not networked applications (or a part thereof)? Have you read: http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260 The above is a confused statement. It's like saying that a beagle food is not dog food.
    And forget about REST as an alternative, that is simply not for this.
    Nonsense. If that's the case why is Google taking down their WS-styl services? Why does Amazon use REST? Why does it work so well for me? Am I hallucinating that I am producing better quality services with 1/10 (or less) of the resources with better performance, better security and better integration with other tools? If you think that WS* provides benefits over REST, you are just misinformed. I've done both and there is no question which is better.
  10. I accept some of your points like avoiding huge messages; prefer chunky services over chatty interfaces for performance improvements, however considering any other protocol for remoting other than SOAP would be a big mistake at this point of time.

    SOAP is the only defacto standard for interoperability among various platforms. A conformance to WS-I and BP would ensure that application owners would no longer want to worry about interoperability. With advent of SOA, SOAP has become further emboldened.

    SOAP on HTTP has performance problems, agreed! But there are good alternatives to overcome it in application design itself. Also, who are the ones backing other protocols like Hession, Burlap etc.

    Regards,
    prase


    Why don't you want to for a faster binary protocol in inter-enterprise communication. Even service-oriented systems can be built using these technologies. I agree that there are situations when to use SOAP, but there are lots, when not to use it. Optimization of messages can bring you a long way, but in many cases it is not enough
    I’m game for any new protocol which offers better performance over SOAP. It’s not about me embracing the change, but how this industry welcomes it. Sure, hessian or burlap may become the next big thing, but for interoperability what else you have other than SOAP at this point of time. How many vendors and companies are adapting to these new protocols?
  11. To get a better performance and scalability, one can think of using distributed caching platforms like GemFire-Enterprise from GemStone Systems.