Ну, для короткого ответа это потокобезопасный, да. Причина в том, что серверная сторона службы будет иметь больше сказать, а затем клиентское соединение о возможностях потоковой передачи. Клиент - это просто прокси-сервер, который излагает запрос так, как может понять сервер. Он ничего не знает. Это базовый класс, не имеющий внешнего доступа, кроме соединения с сервером. До тех пор, пока сервер допускает несколько соединений, все будет в порядке. Таким образом, нет конкуренции за ресурсы (за исключением того, что сервер может обрабатывать все ваши запросы).
На стороне клиента вы можете использовать несколько потоков одного и того же класса, но разных экземпляров. Вероятно, это будет предпочтительный сценарий, так что каждая транзакция может быть атомарной. В то время как общий экземпляр вам придется обрабатывать свой собственный поток, блокирующий доступ к самому классу, иначе вы можете столкнуться с условием гонки на ресурсе, внутреннем для вашего кода.
Существует также возможность иметь асинхронный вызов. Окурки, созданные с помощью инструмента wsdl, создадут методы begin, end invoke, чтобы вы могли предоставить метод обратного вызова, чтобы эффективно разрешить вам отправлять ваш запрос и продолжать свой код, не дожидаясь ответа. Это, вероятно, будет лучшим для вашего второго сценария с единственным экземпляром.
Однако это также зависит от того, как кодируется серверный компонент. Если это веб-сервис, вы можете одновременно отправлять несколько запросов. Однако, если это служба на основе сокетов, вам может понадобиться сделать некоторое дополнительное кодирование на вашем конце, чтобы обрабатывать несколько входящих соединений или даже создавать сокеты, например.
Итак, вкратце да, разные экземпляры ведут себя так же, как однопоточное выполнение в пределах серверной части, способное обрабатывать несколько параллельных соединений.
Что касается единственного экземпляра, если вы используете процесс обратного вызова, который предоставляется, вы можете получить то, что вам нужно, без слишком большой головной боли. Однако он также ограничен пределами кода на стороне сервера.
Причина, по которой я указываю, что ограничения сервера - это компании, которые будут создавать веб-службы, которые ограничивают количество подключений исходящих хостов, поэтому ваша пропускная способность ограничена этим. Таким образом, количество эффективных потоков, которые вы могли бы использовать, было бы уменьшено или устарело.