@Peeyush: It generates useless wrapper... that is, besides the generated service you will get another class "in the middle". Note that inheriting classes, unlike decorators will drag all their superclass properties with them, and you will never utilize even 50% of them in any particular situation. however, if you're going to use WebService / HTTPService, that's not going to be efficient, because it is to multipurpose for any given single task, and if you're going to use SOAP, even if it's gZipp'ed, it will loose a lot even to plain AMF (could be one order of magnitude), Protobuf, would win comparing to plain AMF, but, you can use IExternalizable and pack the data in a more efficient way, but then again, the AMF protocol itself may be optimized, and, it depends on many different factors, like average message size, whether you send several messages at once or not and so on... In the end, HTTP isn't the most optimized way to transfer data over internet, in fact, it is the less optimized among existing protocols :) OK, I know, that's already kind of of-topic :) But, even, if we agree to use SOAP and WSDL we could've have better solution, if the generated service would not *load* the WSDL at runtime - that's what the generation is for - you give Fiber the WSDL and, ideally, it would generate a class that wraps or extends (however you like) URLStream / URLLoader and generates the methods described in WSDL. WebService may be OK if you need a tool to do everything, but, when you already have the description of the protocol, you don't need that robust class / configure the protocol at runtime.
Bottom line, if you really care about performance, you can achieve a result that would be 2-3 orders of magnitude more efficient in every regard, then the setup we are discussing now, it all depends on how the effort you take to optimize it will pay you back in the end. Best. Oleg
