Ув. коллеги, вопрос больше архитектурного характера, т.к. нужно определится с подходом в решении проблемы. Собственно есть несколько разрозненных источников данных (сиквельные базы на разных серверах), есть сервис кот. худо-бедно выгребает данные и из них с пом. вьюх и ХП. Что требуется — нужна легко расширяемая система без необходимости кардинально переписывать половину финкционала и/или сервисы. Предполагается что кол-во источников данных будет расти и параметры по которым будут выгребаться данные будут меняться. Т.е. Отсюда следует, что придется либо переписывать/расширять функционал сервисов или дописывать новые и соотв. деплоить все это по-новой, либо найти более гибкое решение, чтобы по- меньше лезть в код всего приложения.
Заказчик настаивает на использовании плагинов для возможности расширения функционала сервисов, но тут встает несколько вопросов: 1. Я видал много способов применения плагинов, но не для сервисов с экстракцией данных. 2. С аггрегацией данных возникают вопросы, т.к. "сырые" данные из разрозненных систем нужно комбинировать и трансформировать и сервис немного не подходящее место для сложных преобразований (имхо, сиквел справляется с такими задачами лучше . 3. Создание отдельного хранилища для операций преобразования и хранения "готовых" данных не подходит ввиду определенных ограничений по безопасности. 4. Куда здесь прикрутить плагины, так жаждаемые заказчиком?
Как возможное решение мне видеться использование сиквельных интегрейшн-сервисов (SSIS), т.е. Пакет или пакеты будут брать данные из тех разрозненных источников, приводить их в удобоваримое состояние и складывать в отдельную таблицу или таблицы одной из этих бд, т.е. Данные будут фактически готовы для отдачи сервисам. Здесь, все что потребуется менять не относится к коду самих сервисов т.е дело придется иметь уже с SSIS-пакетами (чем не плагины . Но клиент настаивает именно на плагинах... Идеи/комментарии?
Вообще, под "веб-сервисы как плагины" обычно понимают некую сервисную шину (Biztalk там, или Oracle ESB). Но у сервисной шины как архитектурного решения есть много недостатков.
Здравствуйте, Sharov, Вы писали: S>WCF тут, по-моему, не причем. Тут нужны плагины уровня доступа к данными. Т.е. какие-то общие интерфейсы и т.д. и т.п.
Тут вопрос еще и в другом... где будут обрабатываться данные. В остальном, пока что единственное применеия плагинов в этой схеме я вижу как составные части сервиса, где каждый плагин представляет логику подключения к источнику и получения данных...
Здравствуйте, scale_tone, Вы писали:
_>Вообще, под "веб-сервисы как плагины" обычно понимают некую сервисную шину (Biztalk там, или Oracle ESB). Но у сервисной шины как архитектурного решения есть много недостатков.
_>А действительно, нужны ли Вам веб-сервисы?
Будет тяжело составить конкуренцию Biztalk Но это как бы и не требуется, т.к. уже есть работающее решение — на сервисах. Вопрос только в том, насколько гибким его можно сделать, т.е. если возникает необходимость подключения нового источника или получения данных, не переписывать (или дописывать сервис), а сделать это через плагины к примеру (здесь возникают сомнения по поводутого, какой функционал включать в плагин и насколько они вообще вписываются в общую картину).
п.с. а что за недостатки у ESB — по-моему этот подход следует вполне оправданной логике (т.е. мухи отдельно, котлеты отдельно), где фактически пользовательское приложение получает уже готовые данные?
Здравствуйте, Allaire, Вы писали:
A>Будет тяжело составить конкуренцию Biztalk
Зачем конкуренцию? Этот инструмент использовать можно было бы, а не переписывать.
A>Но это как бы и не требуется, т.к. уже есть работающее решение — на сервисах. Вопрос только в том, насколько гибким его можно сделать, т.е. если возникает необходимость подключения нового источника или получения данных, не переписывать (или дописывать сервис), а сделать это через плагины к примеру (здесь возникают сомнения по поводутого, какой функционал включать в плагин и насколько они вообще вписываются в общую картину).
Если данные подпадают под определение "массив сущностей", то есть толкаемый MS протокол OData и, соответственно, WCF Data Services как средство создания веб-сервисов, работающих по этому протоколу. Идея в следующем.
Раньше было так: если у тебя есть куча таблиц с данными в разных SQL Server-ных базах тебе нужно как-то эти данные сагрегировать, преобразовать, заджойнить и т.д. — ты пишешь вьюхи, хранимки, user-defined functions etc. 100500 твоих коллег делают то же самое, в результате в компании образуется слоеный пирог из всех этих сотен тысяч объектов.
Теперь выяснилось, что иметь доступ ко всем этим источникам данных хотелось бы по протоколу HTTP, из разных мест земного шара. А также джойнить их с другими источниками, не на MS-овской платформе.
Поэтому придумали протокол OData.
Преимущество по сравнению с обычным SOAP-ом — в том, что OData-сервисы не типизированы (вернее, скажем так, динамически типизированы) и сами по себе поддерживают язык запросов (через query string). Ну и в том, что добавление нового источника данных — это просто развертывание еще одного HTTP-ендпойнта.
Клиенты таких сервисов также стараются быть не привязанными к конкретной схеме данных и конкретному URLу. Грубо говоря, типичный клиент такого сервиса — это веб-браузер: в поле адреса ввел запрос — внизу получил некий рекордсет.
И еще в том, что код пишется не на T-SQL, а на C# (как правило)
Слоеный пирог при этом, правда, тоже образуется
A>п.с. а что за недостатки у ESB — по-моему этот подход следует вполне оправданной логике (т.е. мухи отдельно, котлеты отдельно), где фактически пользовательское приложение получает уже готовые данные?
Сервисная шина (Biztalk, Oracle ESB etc.) — это фактически продвинутый прокси-сервер. Транслирует через себя запросы к сервисам и ответы от них. Как правило, самое умное преобразование, какое шина может сделать — это слегка поменять схему данных. Ну, еще часто есть рутинг и тупая балансировка нагрузки. И еще иногда можно спросить у шины, а какие она вообще сервисы знает.
А недостатки известны:
1. Шина — single point of failure. Тут речь даже не столько про ломающееся железо, сколько про коннективити и кривые руки обслуживающего персонала. Руки могут быть и не кривыми, но просто у этих рук очень мало способов проверить правильность своих действий, и из-за этого настройки, права доступа и WSDL постоянно разъезжаются в разные стороны — и нужный тебе сервис лежит 30% времени.
2. При серьезных нагрузках материальные затраты на обеспечение работоспособности шины легко могут превысить затраты на сами сервисы.
Спасибо за развернутый ответ, многое прояснилось. Однако, покупать готовый продукт вроде BizTalk не вариант в данном контексте, но идея мне нравится)
Главный ответ все-равно еще остается без ответа... если мы к примеру прибегнем к использованию протокола OData в связке с EntityFramework к примеру — какую роль в расширяемости проекта могут сыграть плагины и какого рода функционла в них заключать? Может я немного отстал от технологий, но по-мне — все что связано с данными должно выполнятся на стороне сервера (т.е. любые преобразования). Я к примеру не знаю возможностей EntityFramework и как он будет справлятся с различного рода трансформациями (и это как-то не укладывается в понятия веб-сервисов).
Здравствуйте, Allaire, Вы писали:
A>Спасибо за развернутый ответ, многое прояснилось. Однако, покупать готовый продукт вроде BizTalk не вариант в данном контексте, но идея мне нравится) A>Главный ответ все-равно еще остается без ответа... если мы к примеру прибегнем к использованию протокола OData в связке с EntityFramework к примеру — какую роль в расширяемости проекта могут сыграть плагины и какого рода функционла в них заключать?
Давайте еще раз разберемся, что Вы понимаете под "плагинной архитектурой сервисов".
Чтобы можно было новые сервисы создавать на базе старых и быстро хостить? Так для этого никакой специальной архитектуры не нужно, никаких сервисных шин и прочих баззвордов.
Чтобы новые сервисы автоматом подхватывались клиентами (т.е. чтобы клиентов не нужно было переписывать)? Вот тут да, OData может помочь. Надо только клиентов написать так, чтобы они любой рекордсет могли проглотить (чтобы были нетипизированными, незаточенными на конкретную схему данных). Собственно, может и клиенты не нужны? Вон, MS Excel вроде как OData понимает...
Или что-то другое?
Да, Entity Framework тут вообще не причем, вынесем его за скобки.
Здравствуйте, scale_tone, Вы писали: _>Или что-то другое? _>Да, Entity Framework тут вообще не причем, вынесем его за скобки.
Не совсем так... предполагается что-то в духе "горячей замены", т.е. положим есть некая длл с обширным функционалом, забота программиста собственно будет сводится к реализации интерфейсов и методов плагина (в стороне от работающего сервиса). Здесь точка, т.к. задеплоить ее уже сможет кто угодно, не залазя в код проекта и дикого процесса промоушена и ретеста всего солюшна. Сервис ее "подхватит" и будет реализовывать функционал, заложенный в этой длл-ке. Касательно код-реюз, он тоже будет, зечем изобретать колесо по-новой) Идея в том, что клиент не должен страдать при расширении функционала.
Если поменяются определенные параметры по которым тянутся данные или добавятся новые источники, которые тоже нужно аггрегировать, то хорошим местом для этого будет или сама БД или что-то между клиентом и БД, т.е. сервис (а точнее его плагины). Здесь исключается необходимость переписывания клиента или дописывания сервиса (или сервисов). Здесь я предполагаю что будет несколько универсальных методов, в которых будет менятся только результат выборки (т.е. я предполагаю, что эту логику как раз и нужно вынести в плагины). Проблема в том что я никогда не слышал о таком использовании плагинов ))
п.с. нарыл инфу по MEF — но пока не совсем понимаю как его можно использовать для своих целей и стоит ли вообще заморачиваться...
Здравствуйте, Allaire, Вы писали:
A>Не совсем так... предполагается что-то в духе "горячей замены", т.е. положим есть некая длл с обширным функционалом, забота программиста собственно будет сводится к реализации интерфейсов и методов плагина (в стороне от работающего сервиса). Здесь точка, т.к. задеплоить ее уже сможет кто угодно, не залазя в код проекта и дикого процесса промоушена и ретеста всего солюшна. Сервис ее "подхватит" и будет реализовывать функционал, заложенный в этой длл-ке. Касательно код-реюз, он тоже будет, зечем изобретать колесо по-новой) Идея в том, что клиент не должен страдать при расширении функционала.
Если Вы хостите Ваши сервисы под IIS-ом — у Вас возможность "горячей замены" есть по умолчанию: подложил новую DLL-ку — она сама и подхватилась. Если еще и в виде исходников — можно хоть исходники в блокноте править на продакшене. Для этого никаких плагинных архитектур не требуется, но делать так я бы, понятно, не рекомендовал.
Плагины Вам скорее могут потребоваться на клиенте — чтобы быстро поддерживать новую функциональность сервисов. Это если у Вас клиенты — толстые.
Если клиент — веб-браузер, то существует множество реализаций плагинов (те же Web Parts, например), но это все средства дать юзеру возможность настраивать содержимое страницы.
Если же Вас гложет мысль предоставить некий инструмент для быстрого изменения логики обработки данных кому-нибудь из непрограммистов (аналитикам там всяким) — то лучше забудьте ее сразу же. Такими мыслями выложена дорога в программистский ад, в котором программистов заставляют поддерживать получившиеся у них творения.
A>п.с. нарыл инфу по MEF — но пока не совсем понимаю как его можно использовать для своих целей и стоит ли вообще заморачиваться...
Для толстых клиентов — может пригодиться. Для сервисов — однозначно ни к чему.
Здравствуйте, Allaire, Вы писали:
A> Здесь, все что потребуется менять не относится к коду самих сервисов т.е дело придется иметь уже с SSIS-пакетами (чем не плагины . Но клиент настаивает именно на плагинах...
А чего именно хочет клиент, чего не дадут ему SSIS(или другой ETL)+сервис к результирующей базе(которая может быть как раз оптимизирована под этот сервис)?
Ну уж больно ваше описание на классическую data warehouse задачу смахивает.
. 3. Создание отдельного хранилища для операций преобразования и хранения "готовых" данных не подходит ввиду определенных ограничений по безопасности. 4. Куда здесь прикрутить плагины, так жаждаемые заказчиком? 
Но это как бы и не требуется, т.к. уже есть работающее решение — на сервисах. Вопрос только в том, насколько гибким его можно сделать, т.е. если возникает необходимость подключения нового источника или получения данных, не переписывать (или дописывать сервис), а сделать это через плагины к примеру (здесь возникают сомнения по поводутого, какой функционал включать в плагин и насколько они вообще вписываются в общую картину).
