title: Using NSOperation for threading creates too many objects
body: <p>I have an app that makes SOAP calls.  To keep the UI from blocking, we are putting each SOAP call into a subclass of NSOperation.  This works well, but we have a ton of different types of SOAP calls.  So if we use 3 WSDLs each with 10 Ports or Operations, then we 30 different calls in SOAP and if we put each of those in a thread using NSOperation, we end up with 30 NSOperation subclasses.</p>
  
  <p>This may not be a bad thing, but we are trying to create a reusable library, so we have one object per WSDL which encapsulates the calls.  This is nice because we are using WSDL2ObjC and this encapsulates all that logic.  But it seems odd then to have a nice api that we wrap calls to in these many NSOperations.  Also, we are doing the threading in the api itself, so that the invoker can use it how he/she sees fit.  </p>
  
  <p>Any suggestions would be great.</p>