Как подружить ежа и ужа: опыт использования PowerShell в web-приложениях

[mihmig]

Использование данного антикросплатформенного средства может быть оправдано в гомогенной среде, при использовании Windows-only фич (Exchange, AD и т.п.)
Но как обстоят дела с отладкой?

[Mike_Y]

С отладкой дела обстоят так:
1. Есть PowerShell ISE, но с помощью него можно отлаживать только локальные скрипты по факту, т.е. подцепиться к скриптам которые выполняются через .NET (System.Management.Automation) не получится
2. Можно породить свой PowerShell Host и туда попытаться прикрутить отладчик

Но самый простой вариант через логи. У нас логика достаточно простая в модулях, там особо отлаживать нечего интерактивно. :)

[ForNeVeR]

Средство не совсем уж и «антикроссплатформенное». Мы успешно работаем над портированием под операционные системы.

[cyreex]

С какой вервии POA + WPE начали управлять подписками через командлеты Powershell?

[Mike_Y]

Не уверен, что понял ваш вопрос. WPE изначально задумывался как замена MPS, ибо Microsoft сделала ему EOL. И примерно в тоже время появился Exchange 2010 (насколько я помню), который хорошо провизился через PowerShell. Была идея: сделать MPS-like движок, который бы понимал клиентские MPS -запросы (там довольно сложный язык на базе xml), мог бы запускать на стороне сервера старые MPS-провайдеры (кроме native) и работать с новыми провайдерами написанными на PowerShell. Т.е. первая версия WPE сразу умела запускать провайдеры написанные на PowerShell. Но это не совсем: «работать через командлеты PowerShell».

[cyreex]

Да, вы меня правильно поняли. Спасибо за ответ. До вчерашнего дня я был уверен, что wpe не работает с PowerShell провайдерами.

Если я верно понял, то изначально WPE сделали «MPS-like» и провайдеры PowerShell использовались в единичных задачах. Но скоро будут внесены изменения, правильно?

Еще интересный вопрос. MS Lync 2013 так же отлично управляется через PowerShell. Почему для него нет провайдера?

[Mike_Y]

Сейчас новые провайдеры не разрабатываются, поскольку все новые сервисы создаются с помощью APS. С помощью этой технологии значительно легче выпускать новые сервисы для PA. Также важно что APS-пакеты отвязаны от релизов основного продукта PA, т.е. можно делать свои релиз-циклы для пакетов, добавлять новые фичи, не дожидаясь пока будет очередной релиз PA.

Что касается MS Lync 2010-2013 они реализованы как APS -пакеты как раз. :)

Строго говоря WPE это уже legacy — он поддерживается, но новые вещи туда не добавляются. Теоретически, прикрутив какой-нибудь frontend UI, WPE можно было бы выдвинуть на уровень большого enterprise, который настолько богат, что может позволить себе собственные инсталяции Exchange, Sharepoint и прочего. Но пока планов нет.

[cyreex]

А почему вы приняли решение провизить Lync через APS, а не с помощью вызовов PowerShell?

[Mike_Y]

Если просто, то APS это все в одном флаконе: бизнес-логика, UI и возможность выполнять скрипты на конечном сервисе. А программная часть, которая непосредственно управляет Lync (активация и управление) может быть написана на чем угодно — в частности на PowerShell. Я не помню, пакет Lync'а разрабатывала другая команда, но помоему у них как раз PS используется для управления Lync'ом. Ну и вторая (а может быть первая) причина — APS стратегическое направление Parallels, сейчас вся поддержка новых сервисов делается на нем.

[ImLiar]

Но ведь это крокодил и белка

[Mike_Y]

Это чтобы еще больше все запутать :)

[navion]

Простите, промахнулся.