Ну, вы действительно затрагиваете две отдельные проблемы:
- доступность локальных и удаленных услуг
- «обычный» или потоковый сервис (для больших файлов)
В целом, если ваша служба работает за корпоративным брандмауэром в локальной сети, вам следует использовать NetTcpBinding, поскольку он самый быстрый и эффективный. Это быстро и эффективно, потому что он использует двоичное кодирование сообщений (вместо кодирования текстовых сообщений через Интернет).
Если вам необходимо предоставить услугу для «внешнего» мира, вы должны попытаться использовать максимально возможную совместимость привязки, и здесь вы выбираете basicHttpBinding (полностью совместимый - «старые» протоколы SOAP 1.1), который не может быть защищен слишком много, и wsHttpBinding, который предлагает гораздо больше гибкости и возможностей, но менее широко поддерживается.
Поскольку вы можете легко создать один сервис с тремя конечными точками, вы действительно можете создать свой сервис и затем определить эти три конечные точки: одну для локальных клиентов, использующих NetTcpBinding, одну из самых широких доступных с использованием basicHttpBinding, и, опционально, другую с wsHttpBinding.
Это одна сторона истории.
Другое: для ваших «обычных» вызовов службы, обменивающихся несколькими элементами информации (размером до нескольких КБ), вы должны использовать обычное поведение по умолчанию «буферизованной передачи» - сообщение готовится полностью в буфер и отправлено целиком.
Однако для обработки больших файлов лучше использовать режим потоковой передачи - либо «StreamedResponse», если вы хотите, чтобы клиенты могли загружать файлы с вашего сервера, либо «StreamedRequest», если вы хотите, чтобы клиенты могли для загрузки файлов или просто "Потоковое", если вы отправляете файлы в обе стороны.
Таким образом, помимо трех «обычных» конечных точек, у вас должна быть как минимум другая конечная точка для каждой привязки, которая обрабатывает потоковый обмен данными, т.е. выгрузка / загрузка файлов.
Это может показаться множеством разных конечных точек, но это на самом деле не проблема, ваши клиенты могут подключаться к любым конечным точкам, которые им подходят - обычная или потоковая, внутренняя / локальная (netTcpBinding) или внешняя ( basicHttpBinding) по мере необходимости - и в итоге вы напишите код только один раз!
Ах, красота WCF! : -)
Марк
UPDATE:
Хорошо, после вашего комментария я бы сделал следующее:
- создать
ILocalService договор на обслуживание с одним методом GetFile, который возвращает путь и имя файла
- создать реализацию для сервисного контракта
- разместить эту службу на конечной точке с
netTcpBinding (поскольку она внутренняя, локальная)
[ServiceContract]
interface ILocalService
{
[OperationContract]
string GetFile(......(whatever parameters you need here).....);
}
class LocalService : ILocalService
{
string GetFile(......(whatever parameters you need here).....)
{
// do stuff.....
return fileName;
}
}
и во-вторых:
- создать второй контракт на обслуживание
IRemoteService с помощью одного метода GetFile, который не возвращает имя файла в виде строки, а вместо этого возвращает поток
- создать реализацию для сервисного контракта
- разместить эту службу на конечной точке с
basicHttpBinding для использования в Интернете
- убедитесь, что в конфигурации привязки есть
transferMode="StreamedResponse", чтобы включить потоковую передачу файла обратно
[ServiceContract]
interface IRemoteService
{
[OperationContract]
Stream GetFile(......(whatever parameters you need here).....);
}
class RemoteService : IRemoteService
{
Stream GetFile(......(whatever parameters you need here).....)
{
// do stuff.....
FileStream stream = new FileStream(....);
return stream;
}
}